Bảng hàng xóm tràn trên máy chủ Linux liên quan đến bắc cầu và ipv6


9

Lưu ý: Tôi đã có một cách giải quyết cho vấn đề này (như được mô tả bên dưới) vì vậy đây chỉ là một câu hỏi "muốn biết".

Tôi có một thiết lập hiệu quả với khoảng 50 máy chủ bao gồm các lưỡi dao chạy xen kẽ và các công cụ cung cấp iscsi. Tất cả các dom0 đều gần như đơn giản Debian 5. Thiết lập bao gồm một số cầu nối trên mỗi dom0 để hỗ trợ kết nối mạng cầu nối. Tổng cộng có từ 5 đến 12 cây cầu trên mỗi dom0 phục vụ mỗi vlan. Không có máy chủ nào được kích hoạt định tuyến.

Tại một thời điểm, chúng tôi đã chuyển một trong các máy sang một phần cứng mới bao gồm bộ điều khiển đột kích và vì vậy chúng tôi đã cài đặt một hạt nhân 3.0.22 / x86_64 ngược dòng với các bản vá xen. Tất cả các máy khác chạy debian xen-dom0-kernel.

Kể từ đó, chúng tôi nhận thấy trên tất cả các máy chủ trong thiết lập các lỗi sau cứ sau 2 phút:

[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.

Bảng arp (arp -n) không bao giờ hiển thị nhiều hơn khoảng 20 mục trên mỗi máy. Chúng tôi đã thử các chỉnh sửa rõ ràng và nâng cao

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

các giá trị. FInally đến 16384 mục nhưng không có hiệu lực. Thậm chí không có khoảng thời gian ~ 2 phút thay đổi dẫn đến kết luận rằng điều này hoàn toàn không liên quan. tcpdump cho thấy không có lưu lượng ipv4 không phổ biến trên bất kỳ giao diện nào. Phát hiện thú vị duy nhất từ ​​tcpdump là các gói ipv6 bùng nổ như sau:

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

Tôi nghĩ rằng vấn đề có thể liên quan đến ipv6, vì chúng tôi không có dịch vụ ipv6 trong thiết lập này.

Một gợi ý khác là sự trùng hợp của việc nâng cấp máy chủ với sự khởi đầu của các vấn đề. Tôi tắt máy chủ trong câu hỏi và các lỗi đã biến mất. Sau đó, tôi sau đó đã gỡ xuống các cây cầu trên máy chủ và khi tôi gỡ xuống (ifconfig xuống) một cây cầu đặc biệt:

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

Các lỗi đã biến mất một lần nữa. Như bạn có thể thấy cây cầu không có địa chỉ ipv4 và chỉ có thành viên là eth0.2159 nên không có lưu lượng nào đi qua nó. Cầu và giao diện .2159 / .2157 / .2158 ở tất cả các khía cạnh giống hệt nhau ngoài vlan chúng được kết nối không có tác dụng khi gỡ xuống. Bây giờ tôi đã vô hiệu hóa ipv6 trên toàn bộ máy chủ thông qua sysctl net.ipv6.conf.all.disable_ipv6 và khởi động lại. Sau này, ngay cả khi cầu br-vlan2159 được kích hoạt, không có lỗi xảy ra.

Bất kỳ ý tưởng đều được chào đón.

Câu trả lời:


5

Tôi tin rằng vấn đề của bạn là do lỗi kernel đã được vá net-next.

Snooping Multicast bị vô hiệu hóa khi cây cầu được khởi tạo do một lỗi cố gắng để làm lại bảng. IGMP rình mò ngăn cầu chuyển tiếp mỗi câu trả lời truy vấn phát đa hướng HBH ICMPv6, dẫn đến bảng hàng xóm chứa đầy ff02::hàng xóm từ các câu trả lời phát đa hướng mà nó không nên xem (thử ip -6 neigh show nud all).

Cách giải quyết phù hợp là cố gắng kích hoạt lại rình mò như : echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. Cách khác là làm cho ngưỡng gc của bảng lân cận lớn hơn số lượng máy chủ trong miền quảng bá.

Các bản vá ở đây .


Tôi phải làm echo 1 > /sys/class/net/br0/bridge/multicast_snooping.
Adrian Heine

3

sự trở lại của ip route show cache table allkhi bạn gặp lỗi này là gì?

arp -nhoặc ip neigh showsẽ chỉ hiển thị một số mục trong bộ đệm.

ip route show cache table all sẽ chi tiết hơn nhiều (và sẽ bao gồm rất nhiều mục liên quan đến v6).

Chúng tôi đã thử các chỉnh sửa rõ ràng và tăng / Proc / sys / net / ipv4 / neigh / default / gc_thresh *

Bạn đã làm tương tự cho ipv6? đã giải quyết vấn đề cho chúng tôi

Tạm biệt,

- creis


1
lộ trình ip hiển thị bảng bộ đệm tất cả không tiết lộ nhiều mục. Tôi đã sửa các thông báo lỗi bằng cách cài đặt net.ipv6.neigh.default.gc_thresh1 = 1024 net.ipv6.neigh.default.gc_thresh2 = 2048 net.ipv6.neigh.default.gc_thresh3 = 4096)thông qua sysctl.
tim
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.