bug de roteamento do linux?

9

Eu tenho lutado com esse problema que não é facilmente reproduzível há algum tempo. Estou usando o kernel do Linux v3.1.0 e, às vezes, o 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

Posso executar ping em alguns endereços, mas não no 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 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 possui 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

Observe que 172.16.0.59 pode ser acessado nesta LAN a partir de outros computadores.

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

update: respostas aos comentários abaixo:

  • não há interfaces além de eth0 e lo
  • o ARP req não pode ser visto do outro lado, mas é assim que deve funcionar. o principal problema é que um requisito ARP nem sequer deve 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"
Balázs Pozsár
fonte
Eu estou pensando que isso é algum tipo de comportamento padrão, vamos ver a tabela ARP também? A tabela arp da outra extremidade pode ser útil aqui.
SpaceManSpiff
Como você conserta isso? Colocar uma rota específica do host faz com que funcione novamente? Gostaria de saber se você está de alguma forma recebendo um redirecionamento ICMP que faz o host pensar que o destino é local.
Paul
Parece que a resposta do arp não está voltando. Você pode tcpdump no host 172.16.0.59? Este é um convidado vm? Verifique também o tráfego de rede no host.
AndreasM
Você pode postar a saída de ifconfig -a? Você tem outras interfaces / IPs atribuídos a este host?
Khaled
Eu atualizei a questão com as respostas
Balázs Pozsár

Respostas:

7

É de fato um bug do kernel do linux, provavelmente desde a versão 2.6.39. Publiquei a pergunta nas listas lkml e netdev (veja o tópico em https://lkml.org/lkml/2011/11/18/191 ), e isso foi discutido em outro tópico netdev em http: // www .spinics.net / lists / netdev / msg179687.html

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

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

ajuda.

Balázs Pozsár
fonte
infelizmente o acima não parecem ajuda ..
sivann
tente fazer isso para todas as interfaces: encontre / proc / sys / net -name accept_redirects | enquanto lê x; faça eco -n 0> $ x; done ou talvez você tem um outro bug
Balázs Pozsár
Obrigado, eu já o havia habilitado para todas as interfaces. Os IPs são de túneis IPSEC (esta máquina possui centenas deles) e sempre existem 5 a 10 deles (172.x) listados na tabela arp na interface eth0 listada com HWaddress (incompleto) e com HWtype ausente. Eles parecem expirar e novos substituem, mas às vezes é necessário reiniciar.
sivann
-1

A máscara de sub-rede 172.16.XX padrão é 255.255.0.0, você a reconfigurou para 255.255.255.0. Portanto, o host 172.16.0.xe 172.16.1.x estão em sub-redes diferentes. portanto, ele tentará ROTA-lo 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 (provérbio antigo dos engenheiros de rede ... por mim!).

Felicidades,

O zelador do Unix
fonte
Qual aplicativo da Web ou aplicativo de desktop leve você recomendaria para o desenho do diagrama de rede?
Belmin Fernandez 18/11
não tem nada a ver com o que é geralmente a máscara de rede "padrão". de qualquer forma, veja minha resposta acima.
Balázs Pozsár
Obrigado pela marca para baixo. Então, por que você acha que o roteador está gerando redirecionamentos icmp.
The Unix Janitor
O roteador está gerando redirecionamentos, porque o host deve estar usando um gateway diferente. Eu acho que sua compreensão do problema é um bug. A menos que você queira me educar de outra maneira
The Unix Janitor
Por favor, leia os tópicos vinculados na resposta aceita. O problema é que essas informações de roteamento não são descartadas, embora devessem. Não é um problema com o roteador / gateway.
Balázs Pozsár