Neighbor Table overflow บน Linux โฮสต์ที่เกี่ยวข้องกับ bridging และ ipv6

หมายเหตุ: ฉันมีวิธีแก้ปัญหาสำหรับปัญหานี้แล้ว (ดังอธิบายด้านล่าง) ดังนั้นนี่เป็นเพียงคำถาม "อยากรู้"

ฉันมีการตั้งค่าการผลิตที่มีประมาณ 50 โฮสต์รวมถึงเบลดที่ใช้ xen 4 และ equallogics ที่ให้ iscsi xen dom0s เกือบทั้งหมดเป็นเดเบียน 5. การตั้งค่าประกอบด้วยบริดจ์หลายอันในทุก dom0 เพื่อรองรับเครือข่าย xen bridged ทั้งหมดมีอยู่ระหว่าง 5 และ 12 สะพานในแต่ละ dom0 ที่ให้บริการหนึ่ง vlan แต่ละอัน ไม่มีโฮสต์ใดที่เปิดใช้งานการกำหนดเส้นทาง

ในช่วงเวลาหนึ่งเราได้ย้ายหนึ่งในเครื่องไปยังฮาร์ดแวร์ใหม่รวมถึงตัวควบคุมการโจมตีดังนั้นเราจึงติดตั้งเคอร์เนล 3.0.22 / x86_64 upstream พร้อม xen patches เครื่องอื่น ๆ ทั้งหมดเรียกใช้ 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*

ค่า ในขั้นต้นถึง 16,384 รายการ แต่ไม่มีผลกระทบ ไม่แม้แต่ช่วงเวลาประมาณ 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 down) สะพานหนึ่งโดยเฉพาะ:

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ดังนั้นจึงไม่มีการรับส่งข้อมูลที่ควรข้าม Bridge และส่วนต่อประสาน. 2252 / .2157 / .2158ซึ่งอยู่ในทุกด้านเหมือนกันนอกเหนือจาก vlan ที่เชื่อมต่อกับพวกเขาจะไม่มีผลเมื่อนำมาลง ตอนนี้ฉันปิดการใช้งาน ipv6 บนโฮสต์ทั้งหมดผ่าน sysctl net.ipv6.conf.all.disable_ipv6และรีบูต หลังจากนี้ถึงแม้จะมีการเปิดใช้สะพานbr-vlan2159 จะไม่มีข้อผิดพลาดเกิดขึ้น

ยินดีต้อนรับความคิดใด ๆ

ผมเชื่อว่าปัญหาของคุณคือเนื่องจากมีข้อผิดพลาดเคอร์เนลที่ patched net-nextใน

Multicast snooping ถูกปิดใช้งานเมื่อบริดจ์ถูกเตรียมใช้งานเนื่องจากมีข้อผิดพลาดที่พยายามจัดตาราง การสอดแนม IGMP หยุดสะพานไม่ให้ส่งต่อการตอบแบบสอบถามแบบหลายผู้รับ HBH ICMPv6 ซึ่งส่งผลให้ตารางเพื่อนบ้านเต็มไปด้วยff02::เพื่อนบ้านจากการตอบกลับแบบหลายผู้รับซึ่งไม่ควรเห็น (ลองip -6 neigh show nud all)

echo 1 > /sys/class/net/eth0/bridge/multicast_snoopingวิธีแก้ปัญหาที่เหมาะสมคือการพยายามที่จะเปิดใช้งานสอดแนมที่ชอบ: ทางเลือกคือการทำให้ threshold เพื่อนบ้านตาราง 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 หรือไม่? ที่แก้ไขปัญหาให้เรา

บาย,

- creis