erro de roteamento do linux?

Question

Eu tenho lutado com essa questão não facilmente reproduzível desde há algum tempo. Eu estou usando o kernel Linux v3.1.0, e às vezes roteamento para alguns endereços IP não funciona. O que parece acontecer é que, em vez de enviar o pacote para o gateway, o kernel trata o endereço de destino como local e tenta obter seu endereço MAC via ARP.

Por exemplo, agora meu endereço IP atual é 172.16.1.104/24, o gateway é 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

Eu posso pingar alguns endereços, mas não 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

Ao tentar executar o ping em 172.16.0.59, posso ver no tcpdump que um req do ARP foi enviado:

# 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

e / proc / net / arp tem uma entrada incompleta para 172.16.0.59:

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

Por favor, note que 172.16.0.59 é acessível a partir desta LAN a partir de outros computadores.

Alguém tem alguma idéia do que está acontecendo? Obrigado.

update: responde aos comentários abaixo:

• não há interfaces além de eth0 e lo
• o req do ARP não pode ser visto do outro lado, mas é assim que deve funcionar. o principal problema é que um ARP req não deveria sequer ser enviado em primeiro lugar
• o problema persiste mesmo se eu adicionar uma rota explícita com o comando "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0"

Answer 1

É realmente um erro do kernel do Linux, provavelmente desde a versão 2.6.39. Eu postei a questão para as listas do lkml e do netdev (veja o tópico no link ), e foi apenas discutido em um tópico diferente do netdev no link

A solução atual agora é uma reinicialização ou para liberar todas as rotas e esperar 10 minutos para que os redirecionamentos icmp expirem. Para evitar que isso aconteça novamente,

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

ajuda.

    

Answer 2

A máscara de sub-rede padrão 172.16.X.X é 255.255.0.0, você a reconfigurou para 255.255.255.0. Portanto, os hosts 172.16.0.x e 172.16.1.x estão em sub-redes diferentes. assim, ele tentará e ROUTE através do gateway padrão.

Alterar sua máscara de sub-rede para 255.255.0.0 resolverá o problema.

Você pode fornecer um diagrama. Se você não pode desenhar uma rede, ela não pode ser consertada (antigo provérbio de engenheiros de rede ... por mim!).

Felicidades,