Linux yönlendirme hatası?

Bir süredir kolayca tekrar üretilemeyen bu sorunla mücadele ediyorum. Linux çekirdeği v3.1.0 kullanıyorum ve bazen birkaç IP adresine yönlendirme çalışmıyor. Görünen şey, paketi ağ geçidine göndermek yerine, çekirdeğin hedef adrese yerel olarak davranması ve MAC adresini ARP aracılığıyla almaya çalışmasıdır.

Örneğin, şimdi geçerli IP adresim 172.16.1.104/24, ağ geçidi 172.16.1.254:

# ifconfig eth0 eth0      Link encap:Ethernet  HWaddr 00:1B:63:97:FC:DC
          inet addr:172.16.1.104  Bcast:172.16.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
          TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:191879370 (182.9 Mb)  TX bytes:47173253 (44.9 Mb)
          Interrupt:17

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.1.254    0.0.0.0         UG    0      0        0 eth0
172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0

Birkaç adrese ping atabilirim, ancak 172.16.0.59:

# ping -c1 172.16.1.254
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms

--- 172.16.1.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms

--- 172.16.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms

--- 172.16.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.59
PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
From 172.16.1.104 icmp_seq=1 Destination Host Unreachable

--- 172.16.0.59 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

172.16.0.59'a ping işlemi yapmaya çalışırken, tcpdump'ta bir ARP req'ın gönderildiğini görebiliyorum:

# tcpdump -n -i eth0|grep ARP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28

ve / proc / net / arp, 172.16.0.59 için eksik bir giriş içeriyor:

# grep 172.16.0.59 /proc/net/arp
172.16.0.59      0x1         0x0         00:00:00:00:00:00     *        eth0

172.16.0.59 lütfen unutmayın olan diğer bilgisayarlardan bu LAN erişilebilir.

Neler olup bittiğine dair bir fikri olan var mı? Teşekkürler.

güncelleme: aşağıdaki yorumları yanıtlar:

• eth0 ve lo dışında arayüz yok
• ARP req diğer tarafta görülemez, ancak bu şekilde çalışması gerekir. asıl sorun, bir ARP talebinin ilk etapta gönderilmemesidir.
• "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0" komutuyla açık bir rota eklesem bile sorun devam ediyor

Gerçekten de 2.6.39 sürümünden beri linux çekirdek hatasıdır. Soruyu lkml ve netdev listelerine gönderdim ( https://lkml.org/lkml/2011/11/18/191 adresindeki konuya bakın ) ve sadece http: // www adresindeki farklı bir netdev dizisinde tartışıldı. .spinics.net / listeleri / netdev / msg179687.html

Şu anki çözüm şimdi bir yeniden başlatma veya tüm rotaları yıkamak ve icmp yönlendirmelerinin süresinin dolması için 10 dakika bekleyin. Tekrar olmasını önlemek için,

echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_redirects

yardım eder.

172.16.XX varsayılan alt ağ maskesi 255.255.0.0, 255.255.255.0 olarak yeniden yapılandırdınız. Yani ana bilgisayarlar 172.16.0.x ve 172.16.1.x farklı alt ağlarda. böylece varsayılan ağ geçidi üzerinden dener ve YÖNLENDİRİR.

Alt ağ maskenizi 255.255.0.0 olarak değiştirmek sorunu çözecektir.

Bir diyagram verebilir misiniz? Bir ağ çizemiyorsanız, düzeltilemez (eski ağ mühendisleri atasözü ... benim tarafımdan!).

Alkış,