Điều gì xảy ra khi bộ đệm ARP tràn?

Trong ít nhất một lần thực hiện, có một giới hạn cứng về khả năng của bảng ARP. Điều gì xảy ra khi bộ đệm ARP đầy và một gói được cung cấp với đích (hoặc hop tiếp theo) không được lưu trong bộ nhớ cache? Điều gì xảy ra dưới mui xe, và ảnh hưởng đến chất lượng dịch vụ là gì?

Ví dụ: bộ định tuyến Brocade NetIron XMR và Brocade MLX có hệ thống tối đa có thể định cấu hìnhip-arp . Giá trị mặc định trong trường hợp đó là 8192; kích thước của một mạng con / 19. Không rõ tài liệu cho dù đây là trên mỗi giao diện hay cho toàn bộ bộ định tuyến, nhưng với mục đích của câu hỏi này, chúng ta có thể giả sử nó là trên mỗi giao diện.

Rất ít nhà mạng sẽ cấu hình một mạng con / 19 trên một giao diện trên mục đích, nhưng đó không phải là điều đã xảy ra. Chúng tôi đã chuyển một bộ định tuyến lõi từ mô hình của Cisco sang thổ cẩm. Một trong nhiều điểm khác biệt giữa Cisco và Brocade là Cisco chấp nhận các tuyến tĩnh được xác định bằng cả giao diện ngoài và địa chỉ hop tiếp theo, nhưng Brocade nhấn mạnh vào cái này hay cái khác. Chúng tôi bỏ địa chỉ next-hop và giữ giao diện. Sau đó, chúng tôi đã học được lỗi của các cách của chúng tôi và thay đổi từ giao diện sang địa chỉ hop tiếp theo, nhưng mọi thứ dường như đang hoạt động ban đầu.

+----+ iface0    +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1       .2+----+
      10.0.0.0/30

Trước khi di chuyển, R1 là một Cisco và có lộ trình sau.

ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2

Sau khi di chuyển, R1 là một thổ cẩm và có lộ trình sau đây.

ip route 10.1.0.0 255.255.0.0 iface0

R2 là một bộ định tuyến của Cisco và các bộ định tuyến của Cisco thực hiện ARP proxy theo mặc định. Đây là cấu hình (mis-) trong sản xuất đặt giai đoạn cho những gì hóa ra là tràn bộ đệm ARP.

1. R1 nhận được gói tin dành cho mạng 10.1.0.0/16.
2. Trên cơ sở tuyến giao diện tĩnh, các ARP R1 cho đích đến iface0
3. R2 nhận ra rằng nó có thể đến đích và phản hồi ARP bằng MAC của chính nó.
4. R1 lưu trữ kết quả ARP kết hợp IP trong mạng từ xa với MAC của R2.

Điều này xảy ra cho mọi đích khác biệt trong 10.1.0.0/16. Do đó, mặc dù / 16 được đặt chính xác ngoài R2 và chỉ có hai nút trên liên kết tiếp giáp với R1 và R2, nhưng R1 bị quá tải bộ đệm ARP vì nó khiến R2 hoạt động như thể tất cả các địa chỉ 65k được kết nối trực tiếp.

Lý do tôi hỏi câu hỏi này là vì tôi hy vọng nó sẽ giúp tôi hiểu được các báo cáo sự cố dịch vụ mạng (ngày sau đó) dẫn chúng tôi, cuối cùng, đến bộ đệm ARP tràn. Theo tinh thần của mô hình StackExchange, tôi đã cố gắng chắt lọc rằng điều mà tôi tin là một câu hỏi rõ ràng, cụ thể có thể được trả lời một cách khách quan.

EDIT 1 Để rõ ràng, tôi hỏi về một phần của lớp keo giữa liên kết dữ liệu (lớp 2) và mạng (lớp 3), không phải bảng chuyển tiếp MAC trong lớp liên kết dữ liệu. Một máy chủ hoặc bộ định tuyến xây dựng địa chỉ IP trước để ánh xạ địa chỉ IP thành địa chỉ MAC, trong khi đó, một công tắc sẽ xây dựng địa chỉ sau để ánh xạ địa chỉ MAC tới các cổng.

EDIT 2 Mặc dù tôi đánh giá cao nỗ lực của những người trả lời đã giải thích lý do tại sao một số triển khai không bị tràn bộ đệm ARP, tôi cảm thấy rằng câu hỏi này rất quan trọng để giải quyết những vấn đề đó. Câu hỏi đặt ra là "chuyện gì xảy ra khi" chứ không phải "nhà cung cấp X có dễ bị" không. Tôi đã thực hiện phần của mình bây giờ bằng cách mô tả một ví dụ cụ thể.

EDIT 3 Một câu hỏi khác không phải là "làm cách nào để ngăn bộ đệm ARP tràn ra?"

Chỉnh sửa 2 :

Theo như bạn đã đề cập...

ip route 10.1.0.0 255.255.0.0 iface0

Buộc thổ cẩm thành proxy-arp cho mọi điểm đến trong 10.1.0.0/16 như thể nó được kết nối trực tiếp iface0.

Tôi không thể phản hồi về việc triển khai bộ đệm ARP của Brocade, nhưng tôi chỉ đơn giản chỉ ra giải pháp dễ dàng cho vấn đề của bạn ... định cấu hình tuyến đường của bạn theo cách khác:

ip route 10.1.0.0 255.255.0.0 CiscoNextHopIP

Bằng cách này, bạn ngăn Brocade khỏi ARP-ing cho tất cả 10.1.0.0/16 (lưu ý, bạn có thể cần phải đánh số lại liên kết giữa R1 và R2 ở bên ngoài 10.1.0.0/16, tùy thuộc vào việc triển khai mọi thứ của Brocade) .

Câu trả lời gốc :

Tôi hy vọng rằng trong hầu hết, hoặc thậm chí là tất cả các triển khai, có một giới hạn cứng đối với khả năng của bảng ARP.

Các bộ định tuyến CPU Cisco IOS chỉ bị giới hạn bởi số lượng DRAM trong bộ định tuyến, nhưng đó thường không phải là một yếu tố hạn chế. Một số công tắc (như Catalyst 6500) có giới hạn cứng trên bảng kề (tương quan với bảng ARP); Sup2T có 1 triệu kề .

Vậy, điều gì xảy ra khi bộ đệm ARP đầy và một gói được cung cấp với đích (hoặc hop tiếp theo) không được lưu trong bộ nhớ cache?

Các bộ định tuyến CPU Cisco IOS không hết dung lượng trong bảng ARP, vì các ARP đó được lưu trữ trong DRAM. Giả sử bạn đang nói về Sup2T. Hãy nghĩ về nó như thế này, giả sử bạn đã có Cat6500 + Sup2T và bạn đã cấu hình tất cả các Vlans có thể, về mặt kỹ thuật đó là

4094 total Vlans - Vlan1002 - Vlan1003 - Vlan1004 - Vlan1005 = 4090 Vlans

Giả sử bạn tạo mỗi Vlan a / 24 (vì vậy đó là 252 ARP có thể) và bạn đóng gói mọi Vlan đầy đủ ... đó là 1 triệu mục ARP.

4094 * 252 = 1,030,680 ARP Entries

Mỗi một trong những ARP đó sẽ tiêu thụ một lượng bộ nhớ nhất định trong chính bảng ARP, cộng với bảng phụ thuộc IOS. Tôi không biết nó là gì, nhưng giả sử tổng chi phí ARP là 10 Byte ...

Điều đó có nghĩa là bạn đã tiêu thụ 10 MB cho chi phí ARP; nó vẫn không có nhiều dung lượng ... nếu bạn có bộ nhớ thấp, bạn sẽ thấy một cái gì đó như thế %SYS-2-MALLOCFAIL.

Với nhiều ARP và thời gian chờ ARP bốn giờ, bạn sẽ phải phục vụ trung bình gần 70 ARP mỗi giây; nhiều khả năng việc bảo trì 1 triệu mục ARP sẽ làm cạn kiệt CPU của bộ định tuyến (có khả năng là thông điệp CPUHOG).

Tại thời điểm này, bạn có thể bắt đầu điều chỉnh giao thức định tuyến và có các IP không thể truy cập được do CPU bộ định tuyến quá bận để ARP cho IP.

Chỉ có kinh nghiệm thực tế tôi có với điều này xảy ra là trên các công tắc C3550 (giới hạn MAC 2-8k, tùy thuộc vào mẫu sdm) và ở đó nó đã bỏ mục nhập cũ nhất khỏi bảng.

Đối với iOS và JunOS và các ngăn xếp thương mại khác mà bạn chỉ cần kiểm tra, thật không may lắm.

Nhưng đối với linux , freebsd, netbsd, openbsd, uIP, lwIP và có lẽ nhiều triển khai khác bạn chỉ có thể kiểm tra mã nguồn của họ để biết hành vi.

Trong Linux, bạn cần kiểm tra 'net / core / neighbour.c' (bắt đầu bằng dòng 'if (mục> = tbl-> gc_thresh3' || ') và' net / ipv4 / arp.c '.
Trong Linux, bạn dường như có ba cấp độ đầy đủ

1. gc_thresh1 - không có gì được thực hiện cho đến khi điều này được nhấn
2. gc_thresh2 - điều này có thể được nhấn trong giây lát
3. gc_thresh3 - kích thước này không thể vượt quá

Khi gc_thresh3 cố gắng vượt quá, nó sẽ cố gắng chạy bộ sưu tập rác, trừ khi nó đã được chạy gần đây. Thu gom rác dường như xóa các mục không được nhắc đến nữa, vì vậy không có nghĩa là cũ nhất hoặc mới nhất, tuy nhiên gc_staletime vượt quá dường như là một cách của mục nhập hội nghị, một lần nữa chuyển thành mục cũ nhất.
Nếu không thể chạy thu gom rác, mục nhập mới chỉ đơn giản là không được thêm vào. Tất cả các khoảng gc_threshN và khoảng thời gian thu gom rác định kỳ có thể được điều chỉnh.
Mã không xác định họ địa chỉ (ipv4, ipv6), do đó, bảng IPv6 ND và IPv4 ARP được xử lý theo cùng một đường dẫn mã, không phải là đường dẫn trùng lặp.

Nó sẽ arp cho địa chỉ IP lưu nó trong bảng và tùy thuộc vào việc thực hiện nên xóa mục cũ nhất. Tác động đến hiệu suất phụ thuộc, nếu đây là một sự cố hiếm gặp không ảnh hưởng nhiều, nhưng đây là một vectơ tấn công để ai đó có thể gửi rất nhiều arps ảnh hưởng đến việc sử dụng bộ xử lý

Công tắc sẽ chuyển đến ARP cho IP đích đó để lấy địa chỉ MAC (cũng sẽ điền vào bảng CAM với phản hồi). Yêu cầu ARP được phát đến tất cả các cổng. Điều này đòi hỏi CPU và liên quan đến ARP Inputquá trình. Nếu các yêu cầu ARP dành cho cùng một IP, do bảng ARP tràn ra thường xuyên, công tắc sẽ giới hạn tốc độ giới hạn ARP một lần trong hai giây. Nếu các yêu cầu là IP ngẫu nhiên đủ thường xuyên, CPU có thể tăng đột biến vì CPU đó có liên quan đến cả yêu cầu và phản hồi ARP.

Từ các cuộc tấn công tôi đã học được trên Cisco 3550, 3560, v.v., bạn có thể biến chúng thành trung tâm khổng lồ một khi bạn quá tải giới hạn địa chỉ MAC. Các thiết bị chuyển mạch có giới hạn đã đặt của địa chỉ MAC (khoảng 6000) có thể được lưu trữ và khi đạt đến giới hạn đó, nó sẽ tràn ngập tất cả dữ liệu ra khỏi giao diện của nó. Không thể nhớ nếu điều đó xảy ra đối với các gói 802.1q bởi vì tôi đã không phải thực hiện nó trong một thời gian dài. Có thể phải kích hoạt phòng thí nghiệm mạng của tôi ở nhà để tìm hiểu.