Mạng lưới phát sóng ARP và sử dụng cpu cao

Hy vọng ai đó ở đây có thể có một số hiểu biết về vấn đề chúng ta đang phải đối mặt. Hiện tại chúng tôi có Cisco TAC đang xem xét vụ việc nhưng họ đang vật lộn để tìm ra nguyên nhân gốc rễ.

Mặc dù tiêu đề đề cập đến phát sóng ARP và sử dụng CPU cao, chúng tôi không chắc chắn liệu chúng có liên quan hay không liên quan ở giai đoạn này hay không.

Vấn đề ban đầu đã được đăng trên Cộng đồng trực tuyến INE

Chúng tôi đã loại bỏ mạng xuống một liên kết duy nhất không có thiết lập dự phòng, hãy nghĩ về nó như một cấu trúc liên kết sao.

Sự thật:

• Chúng tôi sử dụng các công tắc 3750x, 4 trong một ngăn xếp. Phiên bản 15.0 (1) SE3. Cisco TAC xác nhận không có sự cố đã biết đối với các lỗi cpu hoặc ARP cao cho phiên bản cụ thể này.
• Không có trung tâm / công tắc không được quản lý kết nối
• Tải lại lõi ngăn xếp
• Chúng tôi không có tuyến đường mặc định "Tuyến đường Ip 0.0.0.0 0.0.0.0 f1 / 0". Sử dụng OSPF để định tuyến.
• Chúng tôi thấy các gói phát sóng lớn từ Vlan 1, Vlan 1 được sử dụng cho các thiết bị máy tính để bàn. Chúng tôi sử dụng 192.168.0.0/20
• Cisco TAC cho biết họ không thấy có gì sai khi sử dụng / 20, ngoài ra chúng tôi sẽ có một miền quảng bá lớn nhưng vẫn hoạt động.
• Wifi, quản lý, máy in, v.v ... đều có trên các Vlan khác nhau
• Cây kéo dài đã được xác nhận bởi các cá nhân đủ điều kiện của Cisco TAC & CCNP / CCIE. Chúng tôi tắt tất cả các liên kết dư thừa.
• Cấu hình trên lõi đã được xác minh Cisco TAC.
• Chúng tôi có thời gian chờ ARP mặc định trên phần lớn các thiết bị chuyển mạch.
• Chúng tôi không thực hiện Q & Q.
• Không có công tắc mới nào được thêm vào (ít nhất là không có công tắc nào chúng tôi biết)
• Không thể sử dụng kiểm tra arp động trên các công tắc cạnh vì đây là 2950
• Chúng tôi sử dụng giao diện hiển thị | inc line | phát sóng để tìm ra số lượng phát sóng lớn đến từ đâu, tuy nhiên cả Cisco TAC và 2 kỹ sư khác (CCNP & CCIE) đều xác nhận đây là hành vi bình thường do những gì đang xảy ra trên mạng (như trong số lượng lớn các vạt mac gây ra sự phát sóng lớn hơn). Chúng tôi đã xác minh STP đã hoạt động chính xác trên các công tắc cạnh.

Các triệu chứng trên mạng và thiết bị chuyển mạch:

• Số lượng lớn nắp MAC
• Sử dụng CPU cao cho quá trình nhập ARP
• Số lượng lớn các gói ARP, tăng nhanh và có thể nhìn thấy
• Wiresharks cho thấy 100 máy tính đang tràn ngập mạng với ARP Broadcast
• Đối với mục đích thử nghiệm, chúng tôi đã đặt khoảng 80 máy tính để bàn khác nhau, tuy nhiên chúng tôi đã thử nghiệm điều này và không có sự khác biệt rõ ràng nào với đầu vào cpu hoặc arp cao
• Đã chạy AV / phần mềm độc hại / phần mềm gián điệp khác nhau, nhưng không có vi-rút hiển thị trên mạng.
• Số lượng bảng địa chỉ sh mac, hiển thị cho chúng tôi khoảng 750 địa chỉ mac khác nhau như mong đợi trên vlan 1.

#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  12   111438973    18587995       5995 44.47% 43.88% 43.96%   0 ARP Input
 174    59541847     5198737      11453 22.39% 23.47% 23.62%   0 Hulc LED Process
 221     7253246     6147816       1179  4.95%  4.25%  4.10%   0 IP Input
  86     5459437     1100349       4961  1.59%  1.47%  1.54%   0 RedEarth Tx Mana
  85     3448684     1453278       2373  1.27%  1.04%  1.07%   0 RedEarth I2C dri

• Ran hiển thị bảng địa chỉ mac trên các công tắc và lõi khác nhau (ví dụ, trên lõi, được cắm trực tiếp bởi máy tính để bàn, máy tính để bàn của tôi) và chúng ta có thể thấy một số địa chỉ phần cứng MAC khác nhau được đăng ký vào giao diện, mặc dù giao diện đó có chỉ có một máy tính gắn liền với điều này:

 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
    1    001c.c06c.d620    DYNAMIC     Gi1/1/3
    1    001c.c06c.d694    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6ac    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6e3    DYNAMIC     Gi1/1/3
    1    001c.c06c.d78c    DYNAMIC     Gi1/1/3
    1    001c.c06c.d7fc    DYNAMIC     Gi1/1/3

• hiển thị nền tảng sử dụng tcam

 CAM Utilization for ASIC# 0                      Max            Used
                                              Masks/Values    Masks/values

  Unicast mac addresses:                       6364/6364       1165/1165
  IPv4 IGMP groups + multicast routes:         1120/1120          1/1
  IPv4 unicast directly-connected routes:      6144/6144        524/524
  IPv4 unicast indirectly-connected routes:    2048/2048         77/77
  IPv4 policy based routing aces:               452/452          12/12
  IPv4 qos aces:                                512/512          21/21
  IPv4 security aces:                           964/964          45/45

Bây giờ chúng ta đang ở giai đoạn mà chúng ta sẽ cần một lượng lớn thời gian chết để cô lập từng khu vực trừ khi bất kỳ ai khác có một số ý tưởng để xác định nguồn gốc hoặc nguyên nhân gốc rễ của vấn đề kỳ lạ và kỳ quái này.

Cập nhật

Cảm ơn bạn @MikePennington và @RickyBeam đã trả lời chi tiết. Tôi sẽ cố gắng và trả lời những gì tôi có thể.

• Như đã đề cập, 192.168.0.0/20 là một mớ hỗn độn được kế thừa. Tuy nhiên, chúng tôi có ý định chia tách điều này trong tương lai nhưng không may vấn đề này xảy ra trước khi chúng tôi có thể làm điều này. Cá nhân tôi cũng đồng ý với đa số, theo đó, miền phát sóng quá lớn.
• Sử dụng Arpwatch chắc chắn là điều chúng tôi có thể thử nhưng tôi nghi ngờ vì một số cổng truy cập đang đăng ký địa chỉ mac mặc dù nó không thuộc về cổng này, kết luận của arpwatch có thể không hữu ích.
• Tôi hoàn toàn đồng ý với việc không chắc chắn 100% khi tìm thấy tất cả các liên kết dự phòng và các công tắc không xác định trên mạng, nhưng theo kết quả tốt nhất của chúng tôi, đây là trường hợp cho đến khi chúng tôi tìm thấy bằng chứng.
• An ninh cảng đã được xem xét, không may quản lý đã quyết định không sử dụng điều này vì nhiều lý do. Lý do phổ biến là chúng ta liên tục di chuyển máy tính xung quanh (môi trường đại học).
• Chúng tôi đã sử dụng portfast cây spanning kết hợp với bpduguard spanning-tree theo mặc định trên tất cả các cổng truy cập (máy tính để bàn).
• Hiện tại, chúng tôi không sử dụng tổng đài không chuyển mạch trên cổng truy cập, nhưng chúng tôi sẽ không nhận được bất kỳ cuộc tấn công nhảy Vlan nào nảy qua Vlans đa chiều.
• Sẽ đưa ra thông báo bảng địa chỉ mac và xem liệu chúng ta có thể tìm thấy bất kỳ mẫu nào không.

"Vì bạn đang nhận được một số lượng lớn các vạt MAC giữa các tổng đài, thật khó để tìm ra nơi những kẻ phạm tội (giả sử bạn tìm thấy hai hoặc ba địa chỉ mac gửi nhiều arps, nhưng các địa chỉ mac nguồn cứ liên tục vỗ giữa các cổng)."

• Chúng tôi bắt đầu với điều này, chọn bất kỳ một vạt MAC nào và tiếp tục chuyển qua tất cả các chuyển đổi cốt lõi sang phân phối để chuyển đổi truy cập, nhưng những gì chúng tôi tìm thấy là một lần nữa, giao diện cổng truy cập đã ăn cắp nhiều địa chỉ mac do đó nắp mac; Vì vậy, trở lại một hình vuông.
• Kiểm soát bão là một cái gì đó mà chúng tôi đã xem xét, nhưng chúng tôi sợ một số gói hợp pháp sẽ bị loại bỏ gây ra thêm vấn đề.
• Sẽ kiểm tra ba lần cấu hình VMhost.
• @ytti các địa chỉ MAC không thể giải thích được đằng sau nhiều cổng truy cập chứ không phải là một cá nhân. Không tìm thấy bất kỳ vòng lặp trên các giao diện này. Các địa chỉ MAC cũng tồn tại trên các giao diện khác, điều này sẽ giải thích số lượng lớn các vạt MAC
• @RickyBeam Tôi đồng ý với lý do tại sao máy chủ gửi nhiều yêu cầu ARP; đây là một trong những vấn đề khó hiểu Cây cầu không dây Rouge là một cây cầu thú vị mà tôi chưa từng nghĩ tới, theo như chúng tôi biết, không dây nằm trên các Vlan khác nhau; nhưng lừa đảo rõ ràng sẽ có nghĩa là nó cũng có thể có trên Vlan1.
• @RickyBeam, tôi không thực sự muốn rút tất cả mọi thứ vì điều này sẽ gây ra số lượng lớn thời gian chết. Tuy nhiên đây là nơi nó có thể chỉ là tiêu đề. Chúng tôi có máy chủ Linux nhưng không quá 3.
• @RickyBeam, bạn có thể giải thích việc thăm dò "sử dụng" máy chủ DHCP không?

Chúng tôi (Cisco TAC, CCIEs, CCNP) trên toàn cầu đồng ý rằng đây không phải là cấu hình chuyển đổi mà là máy chủ / thiết bị đang gây ra sự cố.

Giải quyết.

Vấn đề là ở SCCM 2012 SP1, một dịch vụ có tên: ProxyMrg Wake-Up Proxy . 'Tính năng' không tồn tại SCCM 2012 RTM.

Trong vòng 4 giờ sau khi tắt chính sách này, chúng tôi đã thấy việc sử dụng CPU giảm dần. Khi hết 4 giờ, việc sử dụng ARP chỉ là 1-2%!

Tóm lại, dịch vụ này giả mạo địa chỉ MAC! Không thể tin được nó gây ra bao nhiêu sự tàn phá.

Dưới đây là toàn văn từ Microsoft Technet vì tôi cảm thấy điều quan trọng là phải hiểu vấn đề này liên quan đến vấn đề được đăng như thế nào.

Đối với bất cứ ai quan tâm, dưới đây là các chi tiết kỹ thuật.

Trình quản lý cấu hình hỗ trợ hai công nghệ đánh thức mạng cục bộ (LAN) để đánh thức máy tính ở chế độ ngủ khi bạn muốn cài đặt phần mềm cần thiết, chẳng hạn như cập nhật phần mềm và ứng dụng: gói đánh thức truyền thống và lệnh bật nguồn AMT.

Bắt đầu với Trình quản lý cấu hình SP1, bạn có thể bổ sung phương thức gói đánh thức truyền thống bằng cách sử dụng cài đặt máy khách proxy đánh thức. Proxy đánh thức sử dụng giao thức ngang hàng và các máy tính được bầu để kiểm tra xem các máy tính khác trên mạng con có hoạt động hay không và để đánh thức chúng nếu cần thiết. Khi trang web được định cấu hình cho Wake On LAN và máy khách được định cấu hình cho proxy đánh thức, quá trình này hoạt động như sau:

1. Các máy tính đã cài đặt máy khách Trình quản lý cấu hình SP1 và chưa ngủ trên mạng con, hãy kiểm tra xem các máy tính khác trên mạng con có hoạt động không. Họ làm điều này bằng cách gửi cho nhau một lệnh ping TCP / IP cứ sau 5 giây.

2. Nếu không có phản hồi từ các máy tính khác, chúng được cho là đang ngủ. Các máy tính còn thức trở thành máy tính quản lý cho mạng con.

3. Vì có thể máy tính có thể không phản hồi vì lý do không phải là ngủ (ví dụ: nó bị tắt, bị xóa khỏi mạng hoặc cài đặt máy khách đánh thức proxy không còn được áp dụng), các máy tính được đã gửi một gói thức dậy mỗi ngày vào lúc 2 giờ chiều giờ địa phương. Các máy tính không phản hồi sẽ không còn được coi là ngủ và sẽ không bị đánh thức bởi proxy đánh thức.

Để hỗ trợ proxy đánh thức, ít nhất ba máy tính phải được đánh thức cho mỗi mạng con. Để đạt được điều này, ba máy tính không được xác định chọn làm máy tính bảo vệ cho mạng con. Điều này có nghĩa là họ vẫn tỉnh táo, mặc dù có bất kỳ chính sách năng lượng nào được cấu hình để ngủ hoặc ngủ đông sau một thời gian không hoạt động. Các máy tính của người giám hộ tôn trọng các lệnh tắt hoặc khởi động lại, ví dụ, là kết quả của các nhiệm vụ bảo trì. Nếu điều này xảy ra, các máy tính giám hộ còn lại sẽ đánh thức một máy tính khác trên mạng con để mạng con tiếp tục có ba máy tính giám hộ.

Các máy tính quản lý yêu cầu bộ chuyển đổi mạng chuyển hướng lưu lượng mạng cho các máy tính đang ngủ.

Việc chuyển hướng đạt được là do máy tính của người quản lý phát một khung Ethernet sử dụng địa chỉ MAC của máy tính đang ngủ làm địa chỉ nguồn. Điều này làm cho bộ chuyển đổi mạng hoạt động như thể máy tính đang ngủ đã di chuyển đến cùng một cổng mà máy tính của người quản lý đang bật. Máy tính quản lý cũng gửi các gói ARP cho các máy tính đang ngủ để giữ cho mục nhập mới trong bộ đệm ARP. Máy tính của người quản lý cũng sẽ trả lời các yêu cầu ARP thay mặt cho máy tính ngủ và trả lời bằng địa chỉ MAC của máy tính đang ngủ.

Trong quá trình này, ánh xạ IP-MAC cho máy tính ngủ vẫn giữ nguyên. Proxy đánh thức hoạt động bằng cách thông báo cho bộ chuyển đổi mạng rằng một bộ điều hợp mạng khác đang sử dụng cổng được đăng ký bởi một bộ điều hợp mạng khác. Tuy nhiên, hành vi này được gọi là vạt MAC và không bình thường đối với hoạt động mạng tiêu chuẩn. Một số công cụ giám sát mạng tìm kiếm hành vi này và có thể cho rằng có gì đó không đúng. Do đó, các công cụ giám sát này có thể tạo cảnh báo hoặc tắt cổng khi bạn sử dụng proxy đánh thức. Không sử dụng proxy đánh thức nếu các công cụ và dịch vụ giám sát mạng của bạn không cho phép đập MAC.

4. Khi máy tính của người quản lý thấy yêu cầu kết nối TCP mới cho máy tính đang ngủ và yêu cầu là đến một cổng mà máy tính đang nghe trước khi đi ngủ, máy tính của người quản lý sẽ gửi một gói thức dậy đến máy tính đang ngủ, sau đó dừng chuyển hướng lưu lượng cho máy tính này.

5. Máy tính đang ngủ nhận gói thức dậy và thức dậy. Máy tính gửi tự động thử lại kết nối và lần này, máy tính đã thức và có thể phản hồi.

Tham chiếu: http://technet.microsoft.com/en-us/l Library / dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClents

Cảm ơn bạn cho tất cả những người đã đăng ở đây và hỗ trợ quá trình xử lý sự cố, rất cảm kích.

ARP / Bão phát sóng

• Chúng tôi thấy các gói phát sóng lớn từ Vlan 1, Vlan 1 được sử dụng cho các thiết bị máy tính để bàn. Chúng tôi sử dụng 192.168.0.0/20 ...
• Wiresharks cho thấy 100 máy tính đang tràn ngập mạng với ARP Broadcast ...

Quá trình nhập ARP của bạn cao, có nghĩa là công tắc đang dành nhiều thời gian để xử lý ARP. Một nguyên nhân rất phổ biến của lũ ARP là một vòng lặp giữa các công tắc của bạn. Nếu bạn có một vòng lặp, thì bạn cũng có thể nhận được các vạt mac mà bạn đã đề cập ở trên. Các nguyên nhân có thể khác của lũ ARP là:

• Cấu hình sai địa chỉ IP
• Một cuộc tấn công layer2, chẳng hạn như giả mạo arp

Đầu tiên loại bỏ khả năng cấu hình sai hoặc tấn công layer2 được đề cập ở trên. Cách dễ nhất để làm điều này là với arpwatch trên máy linux (ngay cả khi bạn phải sử dụng một livecd trên máy tính xách tay). Nếu bạn có một cấu hình sai hoặc tấn công layer2, thì arpwatch cung cấp cho bạn các thông báo như thế này trong syslog, liệt kê các địa chỉ mac đang chiến đấu trên cùng một địa chỉ IP ...
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)

Khi bạn thấy "flip flops", bạn phải theo dõi nguồn của các địa chỉ mac và tìm hiểu lý do tại sao chúng chiến đấu trên cùng một IP.

• Số lượng lớn nắp MAC
• Cây kéo dài đã được xác nhận bởi các cá nhân đủ điều kiện của Cisco TAC & CCNP / CCIE. Chúng tôi tắt tất cả các liên kết dư thừa.

Nói như một người đã trải qua điều này nhiều lần hơn tôi muốn nhớ lại, đừng cho rằng bạn đã tìm thấy tất cả các liên kết dư thừa ... chỉ cần làm cho tổng đài của bạn hoạt động mọi lúc.

Vì bạn nhận được một số lượng lớn các vạt mac giữa các tổng đài, thật khó để tìm ra nơi những kẻ phạm tội (giả sử bạn tìm thấy hai hoặc ba địa chỉ mac gửi nhiều arps, nhưng các địa chỉ mac nguồn cứ liên tục vỗ giữa các cổng). Nếu bạn không thực thi giới hạn cứng đối với địa chỉ mac trên mỗi cổng biên, sẽ rất khó để theo dõi các sự cố này mà không rút cáp thủ công (đây là điều bạn muốn tránh). Các vòng lặp chuyển đổi gây ra một đường dẫn bất ngờ trong mạng và bạn có thể kết thúc với hàng trăm máy Mac được học xen kẽ từ những gì thường là một tổng đài máy tính để bàn.

Cách dễ nhất để làm chậm các bước di chuyển là với port-security. Trên mọi cổng chuyển mạch truy cập trong Vlan 1 được kết nối với một PC duy nhất (không có công tắc hạ lưu), hãy định cấu hình các lệnh cấp giao diện sau trên các công tắc cisco của bạn ...

switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!!   Beware of people with VMWare / hubs under their desk, because 
!!   "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a 
!!   couple of desktop ports
spanning-tree bpduguard enable

Trong hầu hết các trường hợp ngập mac / ARP, áp dụng cấu hình này cho tất cả các cổng chuyển đổi cạnh của bạn (đặc biệt là với cổng portfast) sẽ đưa bạn trở lại trạng thái lành mạnh, vì cấu hình sẽ tắt bất kỳ cổng nào vượt quá ba địa chỉ mac và tắt bí mật cổng portfast vòng. Ba mac trên mỗi cổng là một số hoạt động tốt trong môi trường máy tính để bàn của tôi, nhưng bạn có thể nâng nó lên 10 và có thể ổn. Sau khi bạn thực hiện điều này, bất kỳ vòng 2 lớp nào đều bị hỏng, các vạt mac nhanh sẽ chấm dứt và việc chẩn đoán dễ dàng hơn nhiều.

Một số lệnh toàn cầu khác hữu ích để theo dõi các cổng liên quan đến cơn bão phát sóng (mac-move) và lũ lụt (ngưỡng) ...

mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900

Sau khi bạn hoàn thành, tùy chọn thực hiện clear mac address-tableđể tăng tốc độ chữa lành từ bảng CAM có khả năng đầy đủ.

• Ran hiển thị bảng địa chỉ mac trên các công tắc và lõi khác nhau (ví dụ trên lõi, được cắm trực tiếp bởi máy tính để bàn, máy tính để bàn của tôi) và chúng ta có thể thấy một số địa chỉ phần cứng MAC khác nhau được đăng ký vào giao diện, mặc dù giao diện đó có chỉ có một máy tính gắn liền với ...

Toàn bộ câu trả lời này giả định rằng 3750 của bạn không có lỗi gây ra sự cố (nhưng bạn đã nói rằng wireshark chỉ ra các PC đang bị ngập lụt). Những gì bạn đang cho chúng tôi thấy rõ ràng là sai khi chỉ có một máy tính được gắn vào Gi1 / 1/3, trừ khi PC đó có thứ gì đó giống như VMWare trên đó.

Suy nghĩ linh tinh

Dựa trên một cuộc trò chuyện mà chúng tôi đã có, tôi có lẽ không cần phải đề cập đến điều hiển nhiên, nhưng tôi sẽ vì lợi ích của khách truy cập trong tương lai ...

• Đặt bất kỳ người dùng nào vào Vlan1 thường là một ý tưởng tồi (tôi hiểu bạn có thể đã thừa hưởng một mớ hỗn độn)
• Bất kể những gì TAC nói với bạn, 192.168.0.0/20 là quá lớn để quản lý trong một miền chuyển đổi duy nhất mà không có rủi ro của các cuộc tấn công layer2. Mặt nạ mạng con của bạn càng lớn, bạn càng phải tiếp xúc với các cuộc tấn công layer2 như thế này vì ARP là giao thức không được xác thực và bộ định tuyến ít nhất phải đọc ARP hợp lệ từ mạng con đó.
• Kiểm soát bão trên các cổng layer2 thường là một ý tưởng tốt; tuy nhiên, cho phép kiểm soát bão trong tình huống như thế này, nó sẽ loại bỏ lưu lượng tốt với lưu lượng xấu. Sau khi mạng được chữa lành, hãy áp dụng một số chính sách kiểm soát bão trên các cổng biên và đường lên của bạn.

Câu hỏi thực sự là tại sao các máy chủ gửi rất nhiều ARP ở vị trí đầu tiên. Cho đến khi điều này được trả lời, các công tắc sẽ tiếp tục gặp khó khăn khi đối phó với cơn bão arp. Netmask không phù hợp? Máy chủ arp thấp giờ? Một (hoặc nhiều) máy chủ có lộ trình "giao diện"? Một cây cầu không dây ở đâu đó? "arp vô cớ" mất trí? Máy chủ DHCP "đang sử dụng" thăm dò? Nó không giống như một vấn đề với các công tắc, hoặc lớp 2; bạn có máy chủ làm những điều xấu.

Quá trình gỡ lỗi của tôi sẽ rút phích cắm mọi thứ và theo dõi chặt chẽ khi mọi thứ được gắn lại, mỗi lần một cổng. (Tôi biết đó là lý tưởng, nhưng đến một lúc nào đó, bạn phải cắt lỗ và cố gắng cách ly về mặt vật lý bất kỳ nguồn nào có thể) Sau đó, tôi sẽ tìm hiểu lý do tại sao các cổng chọn lại tạo ra nhiều arp.

(Rất nhiều máy chủ đó có phải là hệ thống linux không? Linux đã có một hệ thống quản lý bộ đệm ARP rất ngu ngốc. Thực tế là nó sẽ "xác minh lại" một mục trong vài phút, bị hỏng trong cuốn sách của tôi Nó có xu hướng ít xảy ra sự cố trong các mạng nhỏ, nhưng a / 20 không phải là một mạng nhỏ.)

Điều này có thể có hoặc không liên quan đến vấn đề của bạn, tuy nhiên tôi cho rằng nó có thể là một cái gì đó có giá trị ít nhất là ném ra ngoài đó:

Hiện tại chúng tôi có khá nhiều 3750x xếp chồng lên nhau trong một số trang web từ xa của chúng tôi, chủ yếu chạy 15.0.2 (SE0 đến 4, có một số lỗi FRU với SE0 mà tôi đang dần di chuyển khỏi).

Trong bản cập nhật iOS thông thường, từ 15.0.2 đến 15.2-1 (SE gần đây nhất), chúng tôi nhận thấy mức tăng CPU khá đáng kể, từ trung bình khoảng 30% đến 60% và cao hơn trong thời gian thấp điểm. Tôi đã xem xét các cấu hình và nhật ký Thay đổi IOS và đã làm việc với TAC của Cisco. Theo TAC, dường như họ đang ở điểm mà họ tin rằng đây là một số lỗi iOS 15.2-1.

Khi chúng tôi tiếp tục điều tra sự gia tăng CPU, chúng tôi bắt đầu thấy một lượng lớn lưu lượng ARP đến mức các bảng ARP của chúng tôi bị lấp đầy hoàn toàn và gây mất ổn định mạng. Cái nạng tạm thời cho việc này là để thủ công thời gian chờ ARP của chúng tôi khỏi mặc định (14400) thành 300 trên vlans thoại và dữ liệu của chúng tôi.

Sau khi giảm thời gian chờ ARP của chúng tôi, chúng tôi đã ổn định trong một tuần hoặc lâu hơn, tại thời điểm đó chúng tôi đã quay trở lại IOS 15.0.2-SE4 và xóa thời gian chờ ARP không mặc định của chúng tôi. Việc sử dụng CPU của chúng tôi đã giảm xuống ~ 30% và các vấn đề về bảng ARP của chúng tôi là không tồn tại.

Một đơn giản hàng ngày nhưng có thể bỏ qua; khách hàng của bạn có một cổng mặc định hợp lệ không, bạn không phải là người thực hiện nhiều arps proxy. Bạn có thể xem xét để phủ nhận chức năng arp proxy proxy trên 3750 của bạn?