Entradas estranhas do cache vizinho do linux (síndrome do mundo inteiro é local do link) (linux 3.0.0-16)

Question

Na distribuição Linux padrão do ubuntu-server executando somente o cache BIND, às vezes vejo endereços IP não vinculados a locais na tabela arp / nei e não há como me comunicar com essas entradas

Após pesquisar na maior parte da manhã, não encontrei problemas semelhantes, por isso acho que pode haver algo errado com a minha configuração.

A configuração é muito simples:

1 interface de rede, com 1 vlan ( eth0.264 ) com 1 endereço IP e 1 gateway padrão - nada mais

(para a pergunta - estou substituindo meus endereços IP por 9.9.9.9 , minha sub-rede por 9.9.9.0/24 e a entrada de exemplo por 9.17.100.131 )

# uname -a
Linux space 3.0.0-16-server #28-Ubuntu SMP Fri Jan 27 18:03:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

# ip a li
4: eth0.264@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:30:48:d5:c2:70 brd ff:ff:ff:ff:ff:ff
    inet 9.9.9.13/24 brd 9.9.9.255 scope global eth0.264
    inet6 fe80::230:48ff:fed5:c270/64 scope link 
       valid_lft forever preferred_lft forever

# ip rule li
0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 

# ip ro li
default via 9.9.9.1 dev eth0.264  metric 100 
9.9.9.0/24 dev eth0.264  proto kernel  scope link  src 9.9.9.13 

# ip neigh show 9.17.100.131
9.17.100.131 dev eth0.264  INCOMPLETE

# arp -n 9.17.100.131
9.17.100.131                     (incomplete)                              eth0.264


# sysctl net.ipv4.conf.all.accept_redirects
net.ipv4.conf.all.accept_redirects = 0


# strange route cache stuff
# ip ro show cache 9.17.100.131
9.17.100.131 dev eth0.264  src 9.9.9.13 
    cache <redirected>  ipid 0x05cb
9.17.100.131 from 9.9.9.13 dev eth0.264 
    cache <redirected>  ipid 0x05cb


# ip ro flush cache
# ip ro show cache 9.17.100.131
# ping 9.17.100.131
PING 9.17.100.131 (9.17.100.131) 56(84) bytes of data.
^C
--- 9.17.100.131 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

# ip ro show cache 9.17.100.131
9.17.100.131 from 9.9.9.13 dev eth0.264 
    cache <redirected>  ipid 0x06cb
9.17.100.131 dev eth0.264  src 9.9.9.13 
    cache <redirected>  ipid 0x06cb

# arp -d 9.17.100.131
SIOCDARP(dontpub): Network is unreachable

(é claro que 9.17.100.131 é alcançável a partir do próximo servidor 9.9.9.14 , e as estranhas entradas de arp do 9.9.9.14 são alcançáveis a partir de 9.9.9.13 .. etc)

ip nei flush não remove a entrada,

também arp -s se recusa a configurá-lo (como deveria):

# arp -s 9.17.100.132 00:11:22:33:44:55
SIOCSARP: Network is unreachable
# arp -d 9.17.100.131
SIOCDARP(dontpub): Network is unreachable

Eu tenho 3 servidores, com a mesma versão do ubuntu e executando o mesmo processess (apenas BIND), todos eles experimentam a síndrome do mundo inteiro que é link-local depois de reboot , ele funciona por alguns dias e, em seguida, ele começa a adicionar essas entradas locais não vinculadas.

algumas estatísticas de uso:

eth0.264 ~ 1000 pps udp traffic
load average 0.03
processes - rsyslogd, named, snmpd, sshd

Qualquer ideia será muito apreciada.

    

Answer 1

Eu acho que seu gateway tem uma única interface física para a rede 9.9.9.0/24 e a rede onde 9.17.100.131 está conectado. É por isso que envia redirecionamentos.

Na minha opinião, existem dois erros (ou "características estranhas") no seu servidor Ubuntu:

• Deve-se ignorar os redirecionamentos desde net.ipv4.conf.all.accept_redirects = 0
• Deve ignorar os redirecionamentos para IPs que não podem ser acessados pela rede do seu Ubuntu

No entanto, você pode consertar isso temporariamente no seu Ubuntu usando:

ip route flush cache

E você provavelmente irá corrigir isso permanentemente no gateway, usando:

sysctl -w net.ipv4.conf.all.send_redirects=0

Afinal, provavelmente é uma má ideia permitir redirecionamentos de um gateway que tenha várias redes conectadas à mesma interface física.

    

Answer 2

Por que você está encontrando um registro ARP para computador, que não está na mesma sub-rede? Não é possível.

Se você tiver a rede 9.9.9.0/24 , seu computador terá que ir para o computador 9.17.100.131 via gateway padrão, porque a parte da sub-rede do endereço IP é 9.9.9.x (a máscara de rede é 255.255.255.0 ). Então você tem que ter em seu registro de cache vizinho apenas para o gateway padrão. Seu computador tem que enviar pacotes com destino IP 9.17.100.131 , mas com o endereço MAC do seu gateway padrão. Seu gateway roteará este pacote para a outra rede.

Rede de reclamações da arp 'é inacessível' dizer a você, que o computador não faz parte da rede, no qual é o endereço 9.17.100.131 , então o registro ARP para esse endereço IP é um absurdo.

Sua tabela de rotas informando a você que seu roteador tentou redirecioná-lo para o destino de 9.17.100.131 via pacote de redirecionamento ICMP. É uma mensagem para você, que o seu roteador tenha outra máscara de rede, que o seu computador, digamos /8 ( 255.0.0.0 ) e, na opinião dele, você está na mesma rede que 9.17.100.131 e roteador não precisa encaminhar pacotes você para este computador.

Por favor, verifique cuidadosamente as máscaras de rede em computadores na sua rede, especialmente contra o seu computador ou roteador 'gateway padrão' - elas devem ser as mesmas para todo o trabalho correto.

    

Answer 3

Qual é o valor de net.ipv4.conf.all.secure_redirects ? Se 1, que é o padrão, ele aceitará redirecionamentos do seu gateway, independentemente de accept_redirects . Desativar isso. (e também desabilite send_redirects no seu gateway como sugerido por Arnaud Bienvenu).

Além disso, o kernel 3.0 tem um bug irritante em que rotas redirecionadas nunca serão removidas do kernel mesmo se limpar o cache de roteamento, a única maneira de limpá-los é uma reinicialização, ou algumas etapas complicadas, incluindo a espera por um muito tempo limite longo .

    

Answer 4

Veja o que encontrei:

Meu servidor Ubuntu 14.04 perdeu a conectividade com um host remoto 150.43.127.1 depois que ele foi desligado por alguns minutos para manutenção.

A inspeção do cache de rota mostra uma entrada usando o gw errado (150.150.100.2):

rg@buntu:~$ sudo ip route get 150.43.127.1
150.43.127.1 via 150.150.100.2 dev eth0  src 150.150.100.10
    cache <redirected>

Depois de liberar o cache, agora usando o gw correto (150.150.127.1):

rg@buntu:~$ sudo ip route flush cache
rg@buntu:~$ sudo ip route get 150.43.127.1
150.43.127.1 via 150.150.127.1 dev eth0  src 150.150.100.10
    cache
rg@buntu:~$

O host remoto agora está acessível:

rg@buntu:~$ ping 150.43.127.1
PING 150.43.127.1 (150.43.127.1) 56(84) bytes of data.
64 bytes from 150.43.127.1: icmp_seq=1 ttl=252 time=14.9 ms
64 bytes from 150.43.127.1: icmp_seq=2 ttl=252 time=15.6 ms
^C