Le voci di cache vicine di linux straniere (sindrome di tutto-mondo-è-collegamento-locale) (linux 3.0.0-16)

Sull'assistente Linux ubuntu-server Linux distro che esegue solo la cache di BIND, a volte vedo gli indirizzi ip non-link-local nel tavolo arp / nei e non c'è modo di comunicare con tali voci

Dopo la googling per la maggior parte della mattina, non ho trovato problemi simili, quindi penso che potrebbe essere qualcosa che non va nel mio setup.

L'installazione è molto semplice:

1 interface di networking, con 1 vlan ( eth0.264 ) con 1 indirizzo IP e 1 gateway predefinito – nient'altro

(per la domanda – sostituisco i miei indirizzi IP con 9.9.9.9 , la mia substring con 9.9.9.0/24 e la voce di esempio con 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 

(ovviamente 9.17.100.131 è raggiungibile dal prossimo server 9.9.9.14 e 9.9.9.14 's strano arp entries sono raggiungibili dal 9.9.9.13 .. etc)

ip nei flush non rimuove la voce,

anche arp -s rifiuta di impostarla (come dovrebbe):

 # 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 

Ho 3 server, con la stessa versione ubuntu e che eseguono la stessa procedura (solo BIND), tutti sperimentano la sindrome di tutto-mondo-è-link-locale dopo il reboot , funziona per un paio di giorni e poi inizia ad aggiungere quelle voci non-link-locali.

alcune statistiche di utilizzo:

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

Tutte le idee saranno molto apprezzate.

  • C'è un modo per registrare un id unico per richiesta per nginx?
  • C'è un'applicazione per monitorare l'utilizzo della width di banda esplosa al livello di applicazione per Linux (Ubuntu)?
  • server ubuntu nessuna output audio
  • Cosa devo fare per impedire lo sfruttamento del mio server postfix?
  • L'authentication SVN su Apache (DAV) e Redmine non funziona
  • RAID 1 + 0 vs RAID 0 + 1
  • Come esporre una socket di dominio UNIX direttamente su TCP
  • Upstart: arresto su runlevel contro stop all'avvio rc RUNLEVEL =
  • 4 Solutions collect form web for “Le voci di cache vicine di linux straniere (sindrome di tutto-mondo-è-collegamento-locale) (linux 3.0.0-16)”

    Suppongo che il tuo gateway disponga di un'unica interface fisica sia per la networking 9.9.9.0/24 che per la networking in cui è connesso 9.17.100.131. Ecco perché invia i reindirizzamenti.

    A mio parere, ci sono due bug (o "caratteristiche strane") nel tuo server Ubuntu:

    • Deve ignorare i reindirizzamenti poiché net.ipv4.conf.all.accept_redirects = 0
    • Dovrebbe ignorare i reindirizzamenti per IP che non sono raggiungibili dalla networking di Ubuntu

    Tuttavia, è ansible risolvere temporaneamente il tuo Ubuntu utilizzando:

    ip route flush cache

    E probabilmente lo risolverai permanentemente sul gateway, utilizzando:

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

    Dopo tutto, è probabilmente una ctriggers idea per consentire reindirizzamenti da un gateway che dispone di più reti connesse alla stessa interface fisica.

    Perché stai trovando un record ARP per computer, che non è nella stessa substring? Non è ansible.

    Se si dispone della networking 9.9.9.0/24 , il computer deve passare al computer 9.17.100.131 tramite il gateway predefinito, perché la sua substring è parte dell'indirizzo IP 9.9.9.x (netmask è 255.255.255.0 ). Quindi devi avere nel proprio record di cache vicini solo per il gateway predefinito. Il computer deve submit il pacchetto con la destinazione IP 9.17.100.131 , ma con l'indirizzo MAC del gateway predefinito. Il tuo gateway instraderà questo pacchetto verso un'altra networking.

    La networking di lamentele di arp non è raggiungibile: dica che il computer non fa parte della networking, sul quale si trova l'indirizzo 9.17.100.131 , quindi il record ARP per questo indirizzo IP non è assurdo.

    La tabella di path che ti dice che il tuo router ha cercato di redirect verso la destinazione di 9.17.100.131 tramite il pacchetto ICMP redirect. È il messaggio per te, che il tuo router ha un'altra maschera di networking, che il tuo computer, dire /8 ( 255.0.0.0 ) e secondo te lo trovi nella stessa networking di 9.17.100.131 e il router non deve trasmettere il pacchetto da te a questo computer.

    Si prega di controllare attentamente i netmasks sui computer della networking, in particolare contro il computer o il router "gateway predefinito". Devono essere uguali a tutti i lavori in modo corretto.

    Qual è il valore di net.ipv4.conf.all.secure_redirects ? Se 1, che è l'impostazione predefinita, accetterà i reindirizzamenti dal gateway, indipendentemente dai accept_redirects . Disabilita. (ed anche distriggersre send_redirects sul gateway come suggerito da Arnaud Bienvenu).

    Inoltre, il kernel 3.0 ha un bug infuriante in cui i routes reindirizzati non verranno mai eliminati dal kernel anche se eliminare la cache di routing, l'unico modo per eliminarli è un riavvio o alcuni passaggi complicati, incluso l'attesa di un timeout molto lungo .

    Ecco quello che ho trovato:

    Il mio server Ubuntu 14.04 ha perso la connettività con un host remoto 150.43.127.1 dopo che è stato spento per alcuni minuti per la manutenzione.

    L'ispezione della cache di path mostra una voce usando il gw errato (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> 

    Dopo aver lavato la cache, ora usando il corretto gw (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:~$ 

    L'host remoto è ora raggiungibile:

     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 
    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.