ARP yayın taşkın ağı ve yüksek işlemci kullanımı

Burada birisinin umduğumuz karşılaştığımız sorun hakkında bir fikir verebilir. Şu anda Cisco TAC davayı inceliyor, ancak temel nedeni bulmakta zorlanıyorlar.

Her ne kadar başlık ARP yayını ve yüksek CPU kullanımından bahsetse de, bu aşamada ilgili olup olmadıklarından emin değiliz.

Orijinal sayı INE Online Topluluğu'na gönderildi

Ağı artıklık ayarı olmayan tek bir bağlantıya kadar soyduk, bir yıldız topolojisi olarak düşünün.

Gerçekler:

• Bir yığın halinde 4 adet 3750x anahtar kullanıyoruz. Sürüm 15.0 (1) SE3. Cisco TAC, bu belirli sürüm için yüksek işlemci veya ARP hataları için bilinen hiçbir sorunu doğrulamaz.
• Bağlı hub / yönetilmeyen anahtar yok
• Reloaded Çekirdek yığını
• Varsayılan bir rotamız yok "Ip route 0.0.0.0 0.0.0.0 f1 / 0". Yönlendirme için OSPF kullanma.
• Masaüstü cihazlar için kullanılan VLAN 1, VLAN 1'den büyük yayın paketleri görüyoruz. 192.168.0.0/20 kullanıyoruz
• Cisco TAC, / 20 ile ilgili yanlış bir şey görmediklerini, diğerlerinin de geniş bir yayın alanımız olacağını ancak yine de çalışması gerektiğini söyledi.
• WiFi, yönetim, yazıcılar vb. Hepsi farklı VLAN'da
• Yayılan ağaç Cisco TAC ve CCNP / CCIE onaylı kişiler tarafından doğrulanmıştır. Gereksiz bağlantıları kapatıyoruz.
• Çekirdek üzerindeki yapılandırma Cisco TAC olarak doğrulandı.
• Anahtarların çoğunda varsayılan ARP zaman aşımına sahibiz.
• Soru ve Cevap uygulamıyoruz.
• Yeni anahtar eklenmedi (en azından hiçbirini bilmiyoruz)
• 2950 olduğu için kenar anahtarlarında dinamik arp denetimi kullanılamıyor
• Şov arayüzlerini kullandık | inc line | broadcast yayın çok sayıda yayının nereden geldiğini anlamak için, ancak hem Cisco TAC hem de diğer 2 mühendis (CCNP & CCIE), ağda olanlardan (çok sayıda mac flepte olduğu gibi) bunun normal davranış olduğunu doğruladı geniş yayına neden olan). STP'nin kenar anahtarlarında doğru çalıştığını doğruladık.

Ağdaki belirtiler ve anahtarlar:

• Çok sayıda MAC kapağı
• ARP Giriş işlemi için yüksek CPU kullanımı
• Hızla artan ve görünür olan çok sayıda ARP paketi
• Wiresharks, 100'lerce bilgisayarın ağa ARP Yayını ile su bastığını gösteriyor
• Test amacıyla, yaklaşık 80 masaüstü makinesine farklı vlan koyduk, ancak bunu test ettik ve yüksek işlemci veya arp girişinde görünür bir fark yaratmadık
• Farklı AV / kötü amaçlı yazılım / casus yazılım çalıştırdınız, ancak ağda virüs görünmüyor.
• sh mac adres-tablo sayısı, vlan 1'de beklendiği gibi bize yaklaşık 750 farklı mac adresi gösterir.

#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

• Mac adres tablosunu farklı anahtarlarda ve çekirdeğin kendisinde (örneğin, masaüstüne doğrudan takılı, masaüstümde takılı) gösterdik ve arayüzde kayıtlı olmasına rağmen birkaç farklı MAC donanım adresinin arabirime kaydedildiğini görebiliriz buna yalnızca bir bilgisayar bağlı:

 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

• platform tcam kullanımını göster

 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

Şu anda, başkalarının bu tuhaf ve tuhaf sorunun kaynağını veya kök nedenini tanımlamak için bazı fikirleri olmadıkça, her bir alanı izole etmek için büyük miktarda kesinti süresine ihtiyaç duyacağımız bir aşamadayız.

Güncelleme

Ayrıntılı yanıt için @MikePennington ve @RickyBeam'e teşekkür ederiz. Ne yapabileceğime cevap vermeye çalışacağım.

• Belirtildiği gibi, 192.168.0.0/20 kalıtsal bir karışıklıktır. Bununla birlikte, gelecekte bunu bölmek niyetindeyiz, ancak maalesef bu sorun bunu yapmadan önce ortaya çıktı. Şahsen ben de çoğunluk ile aynı fikirdeyim, burada yayın alanı çok büyük.
• Arpwatch kullanmak kesinlikle deneyebileceğimiz bir şeydir, ancak bu bağlantı noktasına ait olmasa da birkaç erişim portunun mac adresini kaydettirdiğinden şüpheleniyorum, arpwatch'ın sonucu yararlı olmayabilir.
• Ağdaki tüm yedek bağlantıları ve bilinmeyen anahtarları bulma konusunda% 100 emin olmama konusunda tamamen katılıyorum, ancak bulgumuzun en iyisi olarak, daha fazla kanıt bulana kadar bu durum böyle.
• Liman güvenliği incelendi, maalesef yönetim bunu çeşitli nedenlerle kullanmamaya karar verdi. Bunun ortak nedeni, bilgisayarları sürekli olarak (üniversite ortamı) hareket ettirmektir.
• Tüm erişim bağlantı noktalarında (masaüstü makineleri) varsayılan olarak genişleyen ağaç bpduguard ile birlikte genişleyen ağaç portfast kullandık.
• Şu anda erişim portunda switchport müzakeresi kullanmıyoruz, ancak çok kanallı Vlans'ta zıplayan herhangi bir Vlan atlamalı saldırısı almıyoruz.
• Mac-adres-tablo bildirimini bir şans verecek ve herhangi bir kalıp bulabileceğimizi göreceğiz.

"Switchportlar arasında çok sayıda MAC flebi aldığınız için, suçluların nerede olduğunu bulmak zor (birçok arps gönderen iki veya üç mac adresi bulduğunuzu, ancak kaynak mac adreslerinin portlar arasında çırpmaya devam ettiğini varsayalım)."

• Buna başladık, herhangi bir MAC flep aldık ve erişim anahtarına dağıtımın tüm çekirdek anahtarından yolumuza devam ettik, ancak bulduğumuz şey bir kez daha oldu, erişim portu arayüzü birden fazla mac adresini hompa ediyordu; böylece bir kareye geri dönelim.
• Fırtına kontrolü düşündüğümüz bir şeydir, ancak meşru paketlerden bazılarının düşürüleceğinden korkuyoruz.
• VMHost yapılandırmasını üç kez kontrol eder.
• @ytti açıklanamayan MAC adresleri bir birey yerine birçok erişim portunun arkasındadır. Bu arayüzlerde hiç döngü bulamadı. MAC adresleri, çok sayıda MAC flebi açıklayan diğer arabirimlerde de bulunur
• @RickyBeam neden ana kadar çok ARP istekleri gönderiyor ile katılıyorum; bu kafa karıştırıcı sorunlardan biridir. Rouge kablosuz köprü, bildiğimiz kadarıyla, kablosuz farklı VLAN'da olduğu düşünülmediğim ilginç bir köprüdür; ancak haydut açıkça VLAN1'de olabileceği anlamına gelecektir.
• @RickyBeam, gerçekten büyük miktarda kesintiye neden olacağı için her şeyi fişten çekmek istemiyorum. Ancak tam da bu noktada olabilir. Linux sunucularımız var ama 3'ten fazla değil.
• @RickyBeam, DHCP sunucusu "kullanımda" problama açıklayabilir misiniz?

Biz (Cisco TAC, CCIEs, CCNP) küresel olarak bunun bir anahtar yapılandırması olmadığını, ancak bir ana bilgisayarın / cihazın soruna neden olduğunu kabul ediyoruz.

Çözüldü.

Sorun şu adı verilen bir hizmet olan SCCM 2012 SP1'de: ConfigMrg Uyandırma Proxy'si . 'Özellik' mevcut SCCM 2012 RTM yok.

Bunu politika içinde kapattıktan sonraki 4 saat içinde CPU kullanımında sürekli düşüşler gördük. 4 saat dolduğunda ARP kullanımı sadece% 1-2 idi!

Özetle, bu hizmet MAC adres sahteciliği yapar! Ne kadar tahribat yarattığına inanamıyorum.

Aşağıda, yayınlanan konu ile nasıl bir ilişki olduğunu anlamak önemli olduğunu düşündüğümden Microsoft Technet'ten tam bir metin.

İlgilenenler için, teknik detaylar aşağıdadır.

Configuration Manager, yazılım güncelleştirmeleri ve uygulamaları gibi gerekli yazılımları yüklemek istediğinizde bilgisayarları uyku modunda uyandırmak için yerel alan ağı (LAN) teknolojilerinde iki uyandırma özelliğini destekler: geleneksel uyandırma paketleri ve AMT açılış komutları.

Configuration Manager SP1'den başlayarak, uyandırma proxy'si istemci ayarlarını kullanarak geleneksel uyandırma paketi yöntemini tamamlayabilirsiniz. Uyandırma proxy'si, alt ağdaki diğer bilgisayarların uyanık olup olmadığını kontrol etmek ve gerekirse onları uyandırmak için eşler arası protokol ve seçilen bilgisayarlar kullanır. Site Wake On LAN için yapılandırıldığında ve istemciler uyandırma proxy'si için yapılandırıldığında, işlem şu şekilde çalışır:

1. Configuration Manager SP1 istemcisinin yüklü olduğu ve alt ağda uykuda olmayan bilgisayarlar, alt ağdaki diğer bilgisayarların uyanık olup olmadığını denetler. Bunu birbirlerine 5 saniyede bir TCP / IP ping komutu göndererek yaparlar.

2. Diğer bilgisayarlardan yanıt gelmezse, uykuda oldukları varsayılır. Uyanık olan bilgisayarlar alt ağın yönetici bilgisayarları olurlar.

3. Bir bilgisayarın uyku dışında başka bir nedenden dolayı yanıt vermemesi mümkün olduğundan (örneğin, kapatılmış, ağdan kaldırılmış veya proxy uyandırma istemci ayarı artık uygulanmamıştır), bilgisayarlar yerel saatle her gün 14.00'de bir uyandırma paketi gönderdi. Yanıt vermeyen bilgisayarların artık uykuda olduğu varsayılmayacak ve uyandırma proxy'si tarafından uyandırılamayacaktır.

Uyandırma proxy'sini desteklemek için, her alt ağ için en az üç bilgisayarın uyanık olması gerekir. Bunu başarmak için, üç bilgisayar belirleyici olmayan bir şekilde alt ağ için koruyucu bilgisayar olarak seçilir. Bu, belirli bir süre işlem yapılmadığında uyku veya hazırda bekletme modlarına yönelik yapılandırılmış güç politikalarına rağmen uyanık kalmaları anlamına gelir. Koruyucu bilgisayarlar, örneğin bakım görevlerinin bir sonucu olarak kapatma veya yeniden başlatma komutlarını onurlandırır. Bu durumda, kalan koruyucu bilgisayarlar alt ağdaki başka bir bilgisayarı uyandırır, böylece alt ağın üç koruyucu bilgisayarı olmaya devam eder.

Yönetici bilgisayarlar ağ anahtarından uyku bilgisayarlarının ağ trafiğini kendilerine yönlendirmesini ister.

Yeniden yönlendirme, uyuyan bilgisayarın MAC adresini kaynak adres olarak kullanan bir Ethernet çerçevesi yayınlayan yönetici bilgisayar tarafından gerçekleştirilir. Bu, ağ anahtarının, uyku bilgisayarı yönetici bilgisayarla aynı bağlantı noktasına taşınmış gibi davranmasını sağlar. Yönetici bilgisayar, girişi ARP önbelleğinde güncel tutmak için uyku bilgisayarları için ARP paketleri de gönderir. Yönetici bilgisayar ayrıca uyku bilgisayarı adına ARP isteklerini yanıtlar ve uyku bilgisayarının MAC adresi ile yanıt verir.

Bu işlem sırasında, uyuyan bilgisayarın IP-MAC eşlemesi aynı kalır. Uyandırma proxy'si, ağ anahtarına farklı bir ağ bağdaştırıcısının başka bir ağ bağdaştırıcısı tarafından kaydedilen bağlantı noktasını kullandığını bildirerek çalışır. Ancak, bu davranış bir MAC flebi olarak bilinir ve standart ağ işlemi için olağandışıdır. Bazı ağ izleme araçları bu davranışı arar ve bir şeyin yanlış olduğunu varsayabilir. Sonuç olarak, bu izleme araçları uyandırma proxy'si kullandığınızda uyarı oluşturabilir veya bağlantı noktalarını kapatabilir. Ağ izleme araçlarınız ve hizmetleriniz MAC fleplerine izin vermiyorsa uyandırma proxy'sini kullanmayın.

4. Yönetici bilgisayar, uyku bilgisayarı için yeni bir TCP bağlantı isteği gördüğünde ve istek, uyku bilgisayarının uykuya geçmeden önce dinlediği bir bağlantı noktasına geldiğinde, yönetici bilgisayar uyku bilgisayarına bir uyandırma paketi gönderir ve ardından bu bilgisayar için trafiği yeniden yönlendirmeyi durdurur.

5. Uyuyan bilgisayar uyandırma paketini alır ve uyanır. Gönderen bilgisayar otomatik olarak bağlantıyı yeniden dener ve bu sefer bilgisayar uyanıktır ve yanıt verebilir.

Ref: http://technet.microsoft.com/tr-tr/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

Buraya mesaj gönderen ve sorun giderme sürecine yardımcı olan herkese çok teşekkür ederiz.

ARP / Yayın fırtınası

• Masaüstü cihazlar için kullanılan VLAN 1, VLAN 1'den büyük yayın paketleri görüyoruz. 192.168.0.0/20 kullanıyoruz ...
• Wiresharks, 100'lerce bilgisayarın ARP Yayını ile ağa baskın yaptığını gösteriyor ...

ARP Giriş işleminiz yüksek, yani anahtar ARP'leri işlemek için çok zaman harcıyor. ARP selinin en yaygın nedenlerinden biri anahtarlarınız arasında bir döngüdür. Eğer bir döngünüz varsa, yukarıda bahsettiğiniz mac fleplerini de alabilirsiniz. ARP taşkınlarının diğer olası nedenleri:

• IP adresi yanlış yapılandırmaları
• Arp kimlik sahtekarlığı gibi bir layer2 saldırısı

Öncelikle, yanlış yapılandırma veya yukarıda belirtilen bir layer2 saldırısı olasılığını ortadan kaldırın. Bunu yapmanın en kolay yolu , bir linux makinesindeki arpwatch'tır ( bir dizüstü bilgisayarda bir livecd kullanmanız gerekse bile ). Bir yanlış yapılandırma veya katman2 saldırınız varsa, arpwatch size aynı IP adresi üzerinden mücadele eden mac adreslerini listeleyen syslog'da böyle mesajlar verir ...
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)

"Flip floplar" gördüğünüzde, mac adreslerinin kaynağını izlemeniz ve neden aynı IP üzerinden savaştıklarını bulmanız gerekir.

• Çok sayıda MAC kapağı
• Yayılan ağaç Cisco TAC ve CCNP / CCIE onaylı kişiler tarafından doğrulanmıştır. Gereksiz bağlantıları kapatıyoruz.

Hatırlamak istediğimden daha fazla kez bu durumdan geçen biri olarak konuşmak gerekirse, tüm gereksiz bağlantıları bulduğunuzu varsaymayın ... sadece switchport'larınızın her zaman davranmasını sağlayın.

Switchportlar arasında çok sayıda mac flebi aldığınız için, suçluların nerede olduğunu bulmak zor (birçok arps gönderen iki veya üç mac adresi bulduğunuzu, ancak kaynak mac adreslerinin portlar arasında çırpmaya devam ettiğini varsayalım). Kenar bağlantı noktası başına mac adreslerinde sabit bir sınırlama uygulamıyorsanız, kabloları manuel olarak çıkarmadan (kaçınmak istediğiniz şey budur) bu sorunları izlemek çok zordur. Anahtar döngüleri ağda beklenmedik bir yola neden olur ve normalde bir masaüstü anahtar bağlantı noktası olması gereken şeylerden aralıklı olarak öğrenilen yüzlerce mac ile kurtarabilirsiniz.

Mac hareketlerini yavaşlatmanın en kolay yolu port-security. Vlan 1'deki tek bir PC'ye (aşağı akış anahtarı olmadan) bağlı her erişim anahtar bağlantı noktasında, cisco anahtarlarınızda aşağıdaki arabirim düzeyinde komutları yapılandırı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

Çoğu mac / ARP sel durumunda, bu yapılandırmayı tüm kenar anahtarı bağlantı noktalarınıza (özellikle portfast olan herhangi birine) uygulamak sizi aklı başında duruma döndürür, çünkü yapılandırma üç mac adresini aşan herhangi bir bağlantı noktasını kapatır ve gizlice devre dışı bırakır ilmekledi portfast bağlantı noktası. Bağlantı noktası başına üç mac, masaüstü ortamımda iyi çalışan bir sayıdır, ancak 10'a yükseltebilir ve muhtemelen iyi olabilirsiniz. Bunu yaptıktan sonra, herhangi bir katman 2 döngüsü kırılır, hızlı mac kapakları kapanır ve tanıyı çok daha kolay hale getirir.

Bir yayın fırtınası (mac-move) ve sel (eşik) ile ilişkili bağlantı noktalarını izlemek için yararlı olan başka bir küresel komut ...

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

Bitirdikten sonra, isteğe bağlı olarak clear mac address-tabletam dolu CAM tablosundan iyileşmeyi hızlandırmak için bir a yapın.

• Mac adres tablosunu farklı anahtarlarda ve çekirdeğin kendisinde (örneğin, masaüstüne doğrudan takılı, masaüstümde takılı) gösterdik ve arayüzde kayıtlı olmasına rağmen birkaç farklı MAC donanım adresinin arabirime kaydedildiğini görebiliriz buna sadece bir bilgisayar bağlı ...

Bu yanıtın tamamı, 3750'nizin soruna neden olan bir hata olmadığını varsayar (ancak wireshark'ın sel olan bilgisayarları gösterdiğini söylediniz). Gi1 / 1 / 3'e bağlı tek bir bilgisayar olduğunda, PC'de VMWare gibi bir şey yoksa bize gösterdiğiniz şey yanlış.

Çeşitli düşünceler

Yaptığımız bir sohbet konuşmasına dayanarak, muhtemelen açık olandan bahsetmek zorunda değilim, ancak gelecekteki ziyaretçiler için ...

• Vlan1'e herhangi bir kullanıcı koymak normalde kötü bir fikirdir (bir karışıklık devralmış olabileceğinizi anlıyorum)
• TAC'ın size ne söylediğine bakılmaksızın, 192.168.0.0/20, katman2 saldırıları riski olmadan tek bir anahtarlamalı alanda yönetilemeyecek kadar büyüktür. Alt ağ maskeniz ne kadar büyük olursa, ARP kimliği doğrulanmamış bir protokol olduğundan ve bir yönlendiricinin en azından bu alt ağdan geçerli bir ARP okuması gerektiği için böyle bir saldırıya maruz kalmanız gerekir.
• Katman2 bağlantı noktalarında fırtına kontrolü de genellikle iyi bir fikirdir; ancak böyle bir durumda fırtına kontrolünü mümkün kılmak, kötü trafik ile iyi trafik çekecektir. Ağ iyileştikten sonra, kenar bağlantı noktalarınıza ve uplink'lerinize bazı fırtına kontrol politikaları uygulayın.

Asıl soru, ev sahiplerinin neden ilk etapta bu kadar çok ARP göndermeleri. Bu yanıt verilinceye kadar, anahtar (lar) arp fırtınasıyla uğraşmakta zorlanmaya devam edecektir. Netmask uyuşmazlığı? Düşük ana bilgisayar arp zamanlayıcıları? "Arabirim" yolu olan bir (veya daha fazla) ana bilgisayar mı? Bir yerde kablosuz bir köprü? "bedava arp" delirdi mi? DHCP sunucusu "kullanımda" problama? Anahtarlar veya katman 2 ile ilgili bir sorun gibi görünmüyor; kötü şeyler yapan ev sahipleriniz var.

Hata ayıklama sürecim her şeyi fişten çeker ve her şey yeniden bağlanırken yakından izler, her seferinde bir bağlantı noktası. (İdeal kilometrelerce biliyorum, ama bir noktada kayıplarınızı azaltmanız ve olası herhangi bir kaynağı / kaynakları fiziksel olarak yalıtmaya çalışmanız gerekir) O zaman seçili portların neden birçok arp ürettiğini anlamaya çalışıyorum.

(Bu ana bilgisayarların birçoğu linux sistemleri olacak mı? Küçük ağlarda daha az sorun olma eğilimindedir, ancak / 20 küçük bir ağ değildir.)

Bu, elinizdeki sorunla ilgili olabilir veya olmayabilir, ancak en azından orada atmaya değer bir şey olabileceğini düşündüm:

Şu anda uzak sitelerimizden bazılarında oldukça fazla yığılmış 3750x var, çoğunlukla 15.0.2 çalışıyor (SE0 ila 4, SE0 ile yavaşça göç ettiğim bazı FRU hataları var).

Rutin bir IOS güncellemesi sırasında, 15.0.2'den 15.2-1'e (en son SE) kadar, yoğun olmayan zamanlarda ortalama% 30 ila% 60 ve daha yüksek bir CPU artışı fark ettik. Yapılandırmaları ve IOS Değişikliği günlüklerini inceledim ve Cisco'nun TAC'si ile çalışıyorum. TAC'a göre, bunun bazı IOS 15.2-1 hatası olduğuna inandıkları noktada görünüyorlar.

CPU artışını araştırmaya devam ettikçe, ARP tablolarımızın tamamen dolduğu ve ağ kararsızlığına neden olduğu noktaya kadar çok miktarda ARP trafiği görmeye başladık. Bunun için geçici sorun, ARP zaman aşımlarımızı ses ve veri vizelerimizde varsayılandan (14400) 300'e manuel olarak geri almaktı.

ARP zaman aşımlarımızı azalttıktan sonra, bir hafta kadar kararlı kaldık, bu noktada IOS 15.0.2-SE4'e geri döndük ve varsayılan olmayan ARP zaman aşımlarımızı kaldırdık. CPU kullanımımız ~% 30'a düşüyor ve ARP tablo sorunlarımız mevcut değil.

Faily basit bir ama belki de gözden kaçan; istemcilerinizin geçerli bir varsayılan ağ geçidi var mı? 3750'nizde ip proxy arp işlevini reddetmeyi düşünebilirsiniz?