브리징 및 ipv6과 관련된 Linux 호스트의 인접 테이블 오버 플로우

참고 :이 문제에 대한 해결 방법이 이미 있습니다 (아래 설명 참조). 이것은 "알고 싶은"질문 일뿐입니다.

xen 4를 실행하는 블레이드 및 iscsi를 제공하는 equallogics를 포함하여 약 50 개의 호스트가있는 생산적인 설정이 있습니다. 모든 xen dom0은 거의 일반 데비안 5입니다. 설정은 xen 브리지 네트워킹을 지원하기 위해 모든 dom0에 여러 브리지를 포함합니다. 총 dom0마다 각각 하나의 vlan을 서비스하는 5 개에서 12 개의 브리지가 있습니다. 호스트가 라우팅을 활성화하지 않았습니다.

어느 시점에서 우리는 머신 중 하나를 RAID 컨트롤러를 포함한 새로운 하드웨어로 옮겼으므로 xen 패치가있는 업스트림 3.0.22 / x86_64 커널을 설치했습니다. 다른 모든 시스템은 debian xen-dom0-kernel을 실행합니다.

그 이후로 설정의 모든 호스트에서 ~ 2 분마다 다음 오류가 발생했습니다.

[55888.881994] __ratelimit: 908 callbacks suppressed
[55888.882221] Neighbour table overflow.
[55888.882476] Neighbour table overflow.
[55888.882732] Neighbour table overflow.
[55888.883050] Neighbour table overflow.
[55888.883307] Neighbour table overflow.
[55888.883562] Neighbour table overflow.
[55888.883859] Neighbour table overflow.
[55888.884118] Neighbour table overflow.
[55888.884373] Neighbour table overflow.
[55888.884666] Neighbour table overflow.

arp 테이블 (arp -n)은 모든 머신에서 약 20 개 이상의 항목을 보여주지 않았습니다. 우리는 명백한 조정을 시도하고

/proc/sys/net/ipv4/neigh/default/gc_thresh*

가치. 마지막으로 16384 개의 항목에 영향을 미치지 않습니다. ~ 2 분의 간격조차도 바뀌지 않았으므로 이것이 완전히 관련이 없다는 결론으로 ​​이어집니다. tcpdump는 어떤 인터페이스에서도 드문 ipv4 트래픽을 보여주지 않았습니다. tcpdump에서 유일하게 흥미로운 결과는 다음과 같이 ipv6 패킷 버스 팅이었습니다.

14:33:13.137668 IP6 fe80::216:3eff:fe1d:9d01 > ff02::1:ff1d:9d01: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:9d01, length 24
14:33:13.138061 IP6 fe80::216:3eff:fe1d:a8c1 > ff02::1:ff1d:a8c1: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:a8c1, length 24
14:33:13.138619 IP6 fe80::216:3eff:fe1d:bf81 > ff02::1:ff1d:bf81: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:bf81, length 24
14:33:13.138974 IP6 fe80::216:3eff:fe1d:eb41 > ff02::1:ff1d:eb41: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:eb41, length 24

이 설정에는 ipv6 서비스가 없기 때문에 문제가 ipv6과 관련이있을 수 있다는 생각이 들었습니다.

다른 힌트는 문제의 시작과 호스트 업그레이드의 일치였습니다. 문제의 호스트 전원을 끄고 오류가 사라졌습니다. 그런 다음 호스트의 브리지를 중단하고 특정 브리지를 다운 (ifconfig 다운)했을 때 :

br-vlan2159 Link encap:Ethernet  HWaddr 00:26:b9:fb:16:2c  
          inet6 addr: fe80::226:b9ff:fefb:162c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:120 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:5286 (5.1 KiB)  TX bytes:726 (726.0 B)

eth0.2159 Link encap:Ethernet  HWaddr 00:26:b9:fb:16:2c  
          inet6 addr: fe80::226:b9ff:fefb:162c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1801 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:126228 (123.2 KiB)  TX bytes:1464 (1.4 KiB)

bridge name bridge id       STP enabled interfaces
...
br-vlan2158     8000.0026b9fb162c   no      eth0.2158
br-vlan2159     8000.0026b9fb162c   no      eth0.2159

오류가 다시 사라졌습니다. 보시다시피 브릿지에는 ipv4 주소가 없으며 유일한 멤버는 eth0.2159 이므로 트래픽이 교차해서는 안됩니다. 브리지와 인터페이스 .2159 / .2157 / .2158 은 연결되는 VLAN과 동일하게 모든 측면에서 동일하지만 게시 중단시 아무런 영향을 미치지 않습니다. 이제 sysctl net.ipv6.conf.all.disable_ipv6을 통해 전체 호스트에서 ipv6을 비활성화 하고 재부팅했습니다. 브리지 br-vlan2159가 활성화 된 후에도 오류가 발생하지 않습니다.

어떤 아이디어라도 환영합니다.

귀하의 문제는에서 패치 된 커널 버그 때문이라고 생각합니다 net-next.

테이블을 다시 해시하려고하는 버그로 인해 브리지가 초기화되면 멀티 캐스트 스누핑이 비활성화됩니다. IGMP 스누핑은 이웃 테이블의 결과로 채우고 모든 HBH 된 ICMPv6 멀티 캐스트 질의 회신, 전달에서 다리를 중지 ff02::가 있어야 멀티 캐스트 응답에서 이웃 하지 참조 (시도 ip -6 neigh show nud all).

올바른 해결 방법은 다음과 같이 스누핑을 다시 활성화하는 것 echo 1 > /sys/class/net/eth0/bridge/multicast_snooping입니다. 대안은 인접 테이블 gc 임계 값을 브로드 캐스트 도메인의 호스트 수보다 크게 만드는 것입니다.

패치는 여기에 있습니다 .

ip route show cache table all이 오류가 발생했을 때 어떤 결과가 발생합니까?

arp -n또는 ip neigh show캐시의 일부 항목 만 표시합니다.

ip route show cache table all 훨씬 더 자세 할 것입니다 (많은 v6 관련 항목이 포함될 것입니다).

우리는 명백한 조정을 시도하고 / proc / sys / net / ipv4 / neigh / default / gc_thresh *를 올렸습니다.

ipv6에 대해서도 동일한 작업을 수행 했습니까? 우리를 위해 문제를 해결

안녕,

-크리스