एआरपी प्रसारण बाढ़ नेटवर्क और उच्च सीपीयू उपयोग

20

यहाँ किसी से उम्मीद करना कि हम जिस समस्या का सामना कर रहे हैं उसके बारे में कुछ जानकारी हो सकती है। वर्तमान में हमारे पास सिस्को टीएसी मामला देख रहा है लेकिन वे मूल कारण खोजने के लिए संघर्ष कर रहे हैं।

हालांकि शीर्षक में ARP प्रसारण और उच्च CPU उपयोग का उल्लेख है, हम इस चरण में संबंधित या असंबंधित होने पर अनिश्चित हैं।

मूल मुद्दा INE ऑनलाइन समुदाय पर पोस्ट किया गया है

हमने नेटवर्क को सिंगल लिंक नो रिडंडेंसी सेटअप पर उतार दिया है, इसे स्टार टोपोलॉजी के रूप में सोचें।

तथ्य:

हम 3750x स्विच का उपयोग करते हैं, एक स्टैक में 4। संस्करण 15.0 (1) एसई 3। सिस्को टीएसी इस विशेष संस्करण के लिए उच्च सीपीयू या एआरपी बग के लिए कोई ज्ञात मुद्दों की पुष्टि नहीं करता है।
कोई हब / अनवांटेड स्विच नहीं जुड़ा है
रीलोडेड कोर स्टैक
हमारे पास एक डिफ़ॉल्ट मार्ग नहीं है "आईपी मार्ग 0.0.0.0 0.0.0.0 f1 / 0"। रूटिंग के लिए OSPF का उपयोग करना।
हम VLAN 1, VLAN 1 से बड़े प्रसारण पैकेटों को डेस्कटॉप उपकरणों के लिए उपयोग करते हैं। हम 192.168.0.0/20 का उपयोग करते हैं
सिस्को टीएसी ने कहा कि वे / 20 का उपयोग करने के साथ कुछ भी गलत नहीं देखते हैं, अन्य तो हमारे पास एक बड़ा प्रसारण डोमेन होगा लेकिन फिर भी कार्य करना चाहिए।
वाईफ़ाई, प्रबंधन, प्रिंटर आदि सभी विभिन्न वीएलएएन पर हैं
स्पानिंग ट्री को सिस्को टीएसी और सीसीएनपी / सीसीआईई योग्य व्यक्तियों द्वारा सत्यापित किया गया है। हम सभी अनावश्यक लिंक को बंद कर देते हैं।
कोर पर कॉन्फ़िगरेशन को सिस्को टीएसी सत्यापित किया गया है।
हम स्विच के बहुमत पर डिफ़ॉल्ट एआरपी टाइमआउट है।
हम क्यू एंड क्यू को लागू नहीं करते हैं।
कोई नया स्विच नहीं जोड़ा गया है (कम से कम कोई भी हमें नहीं पता है)
किनारे स्विच पर गतिशील arp निरीक्षण का उपयोग नहीं कर सकते क्योंकि ये 2950 हैं
हमने शो इंटरफेस का इस्तेमाल किया | inc लाइन | यह पता लगाने के लिए प्रसारण किया जाता है कि बड़ी संख्या में प्रसारण कहां से आ रहा है, हालांकि दोनों सिस्को TAC और 2 अन्य इंजीनियरों (CCNP और CCIE) ने पुष्टि की कि यह सामान्य व्यवहार है जो नेटवर्क पर हो रहा है (जैसा कि बड़ी संख्या में मैक फ्लैप में होता है) बड़े प्रसारण का कारण)। हमने सत्यापित किया कि एसटीपी किनारे के स्विच पर सही ढंग से काम कर रहा था।

नेटवर्क पर लक्षण और स्विच:

मैक फ्लैप की बड़ी संख्या
एआरपी इनपुट प्रक्रिया के लिए उच्च CPU उपयोग
एआरपी पैकेटों की भारी संख्या, तेजी से बढ़ती और दिखाई दे रही है
Wiresharks से पता चलता है कि 100s कंप्यूटर ARP ब्रॉडकास्ट के साथ नेटवर्क को भर रहे हैं
परीक्षण के उद्देश्य के लिए, हमने लगभग 80 डेस्कटॉप मशीनों को अलग-अलग vlan में रखा, हालाँकि हमने इसका परीक्षण किया और उच्च cpu या arp इनपुट में कोई अंतर नहीं देखा।
अलग-अलग एवी / मैलवेयर / स्पायवेयर चला चुके हैं, लेकिन नेटवर्क पर कोई वायरस दिखाई नहीं देता है।
sh मैक एड्रेस-टेबल काउंट, हमें vlan 1 पर अपेक्षित के रूप में 750 विभिन्न मैक एड्रेस दिखाता है।

#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

रैन मैक एड्रेस-टेबल को अलग-अलग स्विच और कोर पर (उदाहरण के लिए, उदाहरण के लिए, सीधे डेस्कटॉप, मेरे डेस्कटॉप द्वारा प्लग किया गया है), और हम इंटरफ़ेस में पंजीकृत होने के बावजूद कई अलग-अलग मैक हार्डवेयर एड्रेस को देख सकते हैं, भले ही वह इंटरफ़ेस हो इससे जुड़ा केवल एक कंप्यूटर:

 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

मंच 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

अब हम एक ऐसे चरण में हैं, जहाँ हमें एक समय में प्रत्येक क्षेत्र को अलग करने के लिए बड़ी मात्रा में डाउनटाइम की आवश्यकता होगी, जब तक कि किसी और के पास इस अजीब और विचित्र मुद्दे के स्रोत या मूल कारण की पहचान करने के लिए कुछ विचार न हों।

अपडेट करें

विस्तृत प्रतिक्रिया के लिए @MikePennington और @RickyBeam धन्यवाद। मैं कोशिश करूंगा और जवाब दूंगा कि मैं क्या कर सकता हूं।

जैसा कि उल्लेख किया गया है, 192.168.0.0/20 एक विरासत में मिला गड़बड़ है। हालाँकि, हम भविष्य में इसे विभाजित करने का इरादा रखते हैं, लेकिन दुर्भाग्य से यह समस्या आने से पहले ही हम ऐसा कर सकते हैं। मैं व्यक्तिगत रूप से बहुमत से सहमत हूं, जिससे प्रसारण डोमेन बहुत बड़ा है।
अर्पॉच का उपयोग करना निश्चित रूप से कुछ ऐसा है जिसे हम कोशिश कर सकते हैं लेकिन मुझे संदेह है क्योंकि कई एक्सेस पोर्ट मैक पते को पंजीकृत कर रहे हैं भले ही वह इस पोर्ट से संबंधित नहीं है, लेकिन arpwatch का निष्कर्ष उपयोगी नहीं हो सकता है।
मैं पूरी तरह से 100% सुनिश्चित नहीं होने के साथ सहमत हूं कि नेटवर्क पर सभी अनावश्यक लिंक और अज्ञात स्विच ढूंढ रहा है, लेकिन हमारी सबसे अच्छी खोज के रूप में, यह मामला है जब तक कि हम आगे के प्रमाण नहीं पाते हैं।
पोर्ट सुरक्षा पर ध्यान दिया गया है, दुर्भाग्य से प्रबंधन ने विभिन्न कारणों से इसका उपयोग नहीं करने का फैसला किया है। सामान्य कारण यह है कि हम लगातार कंप्यूटर (कॉलेज के वातावरण) में घूमते रहते हैं।
हमने सभी एक्सेस पोर्ट्स (डेस्कटॉप डेस्कटॉप) पर डिफ़ॉल्ट रूप से फैले ट्री बाप्डुगार्ड के साथ संयोजन में फैले ट्री-पोर्टफ़ास्ट का उपयोग किया है।
हम एक्सेस पोर्ट पर इस समय स्विचपोर्ट नॉनगोटगेट का उपयोग नहीं करते हैं, लेकिन हमें मल्टीपल व्लान में उछलते हुए कोई वलान होपिंग अटैक नहीं मिल रहा है।
मैक-एड्रेस-टेबल नोटिफिकेशन को जाने देंगे, और देखेंगे कि क्या हम कोई पैटर्न पा सकते हैं।

"जब से आप स्विचपोर्ट के बीच बड़ी संख्या में मैक फ्लैप हो रहे हैं, तो यह पता लगाना मुश्किल है कि अपराधी कहां हैं (मान लें कि आपको दो या तीन मैक पते मिलते हैं जो बहुत सारे आरप भेजते हैं, लेकिन स्रोत मैक पते बंदरगाहों के बीच फड़फड़ाते रहते हैं)।"

हमने इस पर शुरू किया, किसी भी एक मैक फ्लैप को उठाया और स्विच को एक्सेस करने के लिए वितरण के लिए सभी कोर स्विच के माध्यम से अपना रास्ता जारी रखा, लेकिन हमने जो पाया वह एक बार फिर से था, एक्सेस पोर्ट इंटरफ़ेस कई मैक एड्रेस को हॉगिंग कर रहा था इसलिए मैक फ्लैप; तो वापस एक वर्ग के लिए।
तूफान-नियंत्रण एक ऐसी चीज है, जिस पर हमने विचार किया था, लेकिन हमें डर है कि वैध पैकेट बंद करने से कुछ समस्या पैदा हो जाएगी।
ट्रिपल VMHost कॉन्फ़िगरेशन की जाँच करेगा।
@ytti unexplainable मैक पते कई पहुंच बंदरगाहों के पीछे है बल्कि एक व्यक्ति है। इन इंटरफेस पर कोई लूप नहीं मिला है। मैक पते अन्य इंटरफेस पर भी मौजूद हैं, जो बड़ी संख्या में मैक फ्लैप की व्याख्या करेंगे
@RickyBeam मैं इस बात से सहमत हूं कि मेजबान इतने ARP अनुरोध क्यों भेज रहे हैं; यह puzzling समस्या में से एक है। रूज वायरलेस ब्रिज एक दिलचस्प है जिसे मैंने सोचा नहीं था, जहां तक हम जानते हैं, वायरलेस विभिन्न वीएलएएन पर है; लेकिन दुष्ट स्पष्ट रूप से इसका मतलब होगा कि यह अच्छी तरह से वीएलएएन 1 पर हो सकता है।
@ रिकीबीम, मैं वास्तव में सब कुछ अनप्लग नहीं करना चाहता क्योंकि इससे बड़े पैमाने पर डाउनटाइम मिलेगा। हालाँकि यह वह जगह है जहाँ यह सिर्फ शीर्षक हो सकता है। हमारे पास लिनक्स सर्वर हैं, लेकिन अधिक नहीं तो 3।
@ रिकीबीम, क्या आप डीएचसीपी सर्वर को "इन-यूज" प्रोबिंग समझा सकते हैं?

हम (सिस्को TAC, CCIEs, CCNP) विश्व स्तर पर सहमत हैं कि यह स्विच कॉन्फ़िगरेशन नहीं है, लेकिन एक होस्ट / डिवाइस समस्या का कारण बन रहा है।

cisco ethernet arp

— कोल्ड टी
स्रोत

1

मैं नोट करूंगा: जब तक नेटवर्क में लूप नहीं होंगे, मैक फ्लैप नहीं होना चाहिए। केवल अन्य तार्किक कारण एक ही मैक का उपयोग करके वीएम होंगे। (या कुछ बोनहेड में एक ही मैक का उपयोग करने के लिए कई nics सेट हैं)

@ कॉल्ड, मैंने अपना उत्तर अपडेट किया क्योंकि मैंने अपनी मूल प्रतिक्रिया में कुछ चीजें गलत पढ़ी थीं।

— माइक पेनिंगटन

क्या आप कई पोर्ट या सिर्फ एक पोर्ट के पीछे बड़ी संख्या में अस्पष्टीकृत मैक पते का अनुभव करते हैं? बंदरगाह को पाला जा सकता है? क्या मैक पते उस पोर्ट के पीछे रहते हैं या अन्य पोर्ट के पीछे भी दिखाई देते हैं? क्या हमारे पास ARP के लिए PCAP है? मैक फ्लैप की बड़ी संख्या निश्चित रूप से सामान्य नहीं है, इसका मतलब है कि या तो टोपोलॉजी बदलती रहती है या आपके पास नेटवर्क में अप्रबंधित लूप है।

1

@ कॉल्ड, मुझे लगता है कि आपको पोर्ट-सुरक्षा के बारे में प्रबंधन के साथ फिर से जुड़ना चाहिए; मैंने आपको विशेष रूप से कॉन्फ़िगरेशन दिया जो पीसी को स्विचपोर्ट के बीच स्थानांतरित करने की अनुमति देता है। switchport port-security aging time 5और switchport port-security aging type inactivityइसका मतलब है कि आप 5 मिनट की निष्क्रियता के बाद बंदरगाहों के बीच स्टेशनों को स्थानांतरित कर सकते हैं, या यदि आप पोर्ट-सुरक्षा प्रविष्टि को मैन्युअल रूप से साफ़ करते हैं। हालाँकि, यह कॉन्फ़िगरेशन स्विच के पहुँच पोर्ट के बीच मैक फ़्लैप्स को रोकता है क्योंकि पोर्ट मनमाने ढंग से उसी मैक-एड्रेस को अलग पोर्ट से सोर्स नहीं कर सकते हैं।

— माइक पेनिंगटन

यह भी ध्यान देने योग्य बात है कि जब तक कि एक ही आईपी पते के लिए अलग-अलग एआरपी नहीं होते, तब तक arpwatch एक फ्लिप फ्लॉप को पंजीकृत नहीं करता है। कारण के बावजूद, आपको यह जानना होगा कि ऐसा कब होता है। Mere mac बाढ़, Arpwatch को भ्रमित करने के लिए पर्याप्त नहीं है

— माइक पेनिंगटन

12

हल किया।

समस्या SCCM 2012 SP1 के साथ है, जिसे एक सेवा कहा जाता है: कॉन्फ़िगमार्ग वेक-अप प्रॉक्सी । 'सुविधा' में SCCM 2012 RTM मौजूद नहीं है।

पॉलिसी के भीतर इसे बंद करने के 4 घंटे के भीतर, हमने CPU उपयोग में लगातार गिरावट देखी। 4 घंटे ऊपर होने तक, एआरपी का उपयोग केवल 1-2% था!

सारांश में, यह सेवा मैक एड्रेस स्पूफिंग करती है! विश्वास नहीं कर सकता कि यह कितना कहर था।

नीचे Microsoft Technet का एक पूर्ण पाठ है क्योंकि मुझे लगता है कि यह समझना महत्वपूर्ण है कि यह पोस्ट किए गए मुद्दे से कैसे संबंधित है।

जो भी इच्छुक है, उसके लिए नीचे तकनीकी विवरण है।

कॉन्फ़िगरेशन प्रबंधक कंप्यूटर को स्लीप मोड में जगाने के लिए लोकल एरिया नेटवर्क (LAN) तकनीकों पर दो वेक का समर्थन करता है, जब आप आवश्यक सॉफ़्टवेयर, जैसे सॉफ़्टवेयर अपडेट और एप्लिकेशन इंस्टॉल करना चाहते हैं: पारंपरिक वेक-अप पैकेट और AMT पावर-ऑन कमांड।

कॉन्फ़िगरेशन मैनेजर SP1 के साथ शुरुआत करके, आप वेक-अप प्रॉक्सी क्लाइंट सेटिंग्स का उपयोग करके पारंपरिक वेक-अप पैकेट विधि को पूरक कर सकते हैं। वेक-अप प्रॉक्सी एक पीयर-टू-पीयर प्रोटोकॉल और चुने हुए कंप्यूटर का उपयोग करता है ताकि यह जांचा जा सके कि सबनेट पर अन्य कंप्यूटर जाग रहे हैं या नहीं, और यदि आवश्यक हो तो उन्हें जगाने के लिए। जब साइट को वेक ऑन लैन के लिए कॉन्फ़िगर किया जाता है और क्लाइंट को वेक-अप प्रॉक्सी के लिए कॉन्फ़िगर किया जाता है, तो प्रक्रिया निम्नानुसार काम करती है:

जिन कंप्यूटरों में कॉन्फ़िगरेशन मैनेजर SP1 क्लाइंट स्थापित है और जो सबनेट चेक पर सोए नहीं हैं कि क्या सबनेट पर अन्य कंप्यूटर जाग रहे हैं। वे हर 5 सेकंड में एक दूसरे को एक टीसीपी / आईपी पिंग कमांड भेजकर ऐसा करते हैं।

यदि अन्य कंप्यूटरों से कोई प्रतिक्रिया नहीं होती है, तो वे सोए हुए माने जाते हैं। जो कंप्यूटर जाग रहे हैं, वे सबनेट के लिए प्रबंधक कंप्यूटर बन जाते हैं।

क्योंकि यह संभव है कि कोई कंप्यूटर एक कारण के कारण प्रतिक्रिया न दे सके क्योंकि वह सो रहा है (उदाहरण के लिए, इसे बंद कर दिया गया है, नेटवर्क से हटा दिया गया है, या प्रॉक्सी वेक-अप क्लाइंट सेटिंग अब लागू नहीं होती है), कंप्यूटर हैं हर दिन 2 बजे स्थानीय समय पर एक वेक-अप पैकेट भेजा। जवाब नहीं देने वाले कंप्यूटर अब सोए हुए नहीं माने जाएंगे और वेक-अप प्रॉक्सी से नहीं जागेंगे।

वेक-अप प्रॉक्सी का समर्थन करने के लिए, प्रत्येक सबनेट के लिए कम से कम तीन कंप्यूटरों को जागृत होना चाहिए। इसे प्राप्त करने के लिए, तीन कंप्यूटरों को गैर-नियतात्मक रूप से सबनेट के लिए अभिभावक कंप्यूटर चुना जाता है। इसका अर्थ है कि निष्क्रिय रहने के बाद सोने या हाइबरनेट करने के लिए किसी भी कॉन्फ़िगर की गई बिजली नीति के बावजूद वे जागते रहते हैं। संरक्षक कंप्यूटर शटडाउन या पुनरारंभ कमांड का सम्मान करते हैं, उदाहरण के लिए, रखरखाव कार्यों के परिणामस्वरूप। यदि ऐसा होता है, तो शेष अभिभावक कंप्यूटर सबनेट पर एक अन्य कंप्यूटर को जगाते हैं ताकि सबनेट में तीन अभिभावक कंप्यूटर होते रहें।

प्रबंधक कंप्यूटर नेटवर्क स्विच को अपने आप सो रहे कंप्यूटर के लिए नेटवर्क ट्रैफ़िक को पुनर्निर्देशित करने के लिए कहते हैं।

पुनर्निर्देशन प्रबंधक कंप्यूटर द्वारा एक ईथरनेट फ्रेम का प्रसारण करके प्राप्त किया जाता है जो सोते हुए कंप्यूटर के मैक पते को स्रोत पते के रूप में उपयोग करता है। इससे नेटवर्क स्विच व्यवहार करता है जैसे कि सोते हुए कंप्यूटर उसी पोर्ट पर चला गया है जो प्रबंधक कंप्यूटर पर है। प्रबंधक कंप्यूटर ARP कैश में प्रविष्टि को ताज़ा रखने के लिए स्लीपिंग कंप्यूटर के लिए ARP पैकेट भी भेजता है। प्रबंधक कंप्यूटर स्लीपिंग कंप्यूटर की ओर से एआरपी अनुरोधों का जवाब भी देगा और सोते हुए कंप्यूटर के मैक पते के साथ उत्तर देगा।

इस प्रक्रिया के दौरान, सोते हुए कंप्यूटर के लिए आईपी-टू-मैक मैपिंग समान रहती है। वेक-अप प्रॉक्सी नेटवर्क स्विच को सूचित करके काम करता है कि एक अलग नेटवर्क एडेप्टर उस पोर्ट का उपयोग कर रहा है जो किसी अन्य नेटवर्क एडेप्टर द्वारा पंजीकृत किया गया था। हालांकि, यह व्यवहार मैक फ्लैप के रूप में जाना जाता है और मानक नेटवर्क ऑपरेशन के लिए असामान्य है। कुछ नेटवर्क निगरानी उपकरण इस व्यवहार की तलाश करते हैं और यह मान सकते हैं कि कुछ गलत है। नतीजतन, ये निगरानी उपकरण अलर्ट पैदा कर सकते हैं या पोर्ट को बंद कर सकते हैं जब आप वेक-अप प्रॉक्सी का उपयोग करते हैं। यदि आपके नेटवर्क निगरानी उपकरण और सेवाएं मैक फ्लैप की अनुमति नहीं देते हैं, तो वेक-अप प्रॉक्सी का उपयोग न करें।

जब एक प्रबंधक कंप्यूटर एक स्लीपिंग कंप्यूटर के लिए एक नया टीसीपी कनेक्शन अनुरोध देखता है और यह अनुरोध एक पोर्ट के लिए होता है कि स्लीपिंग कंप्यूटर सोने जाने से पहले सुन रहा था, तो प्रबंधक कंप्यूटर स्लीपिंग कंप्यूटर को एक वेक-अप पैकेट भेजता है, और फिर इस कंप्यूटर के लिए ट्रैफ़िक पुनर्निर्देशित करना बंद कर देता है।

सोते हुए कंप्यूटर को वेक-अप पैकेट प्राप्त होता है और जागता है। भेजने वाला कंप्यूटर स्वचालित रूप से कनेक्शन को पुनः प्राप्त करता है और इस बार, कंप्यूटर जाग रहा है और प्रतिक्रिया दे सकता है।

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

उन सभी के लिए धन्यवाद जिन्होंने यहां पोस्ट किया है और समस्या निवारण प्रक्रिया में सहायता की है, बहुत सराहना की है।

— कोल्ड टी
स्रोत

आपने उत्तर में आवश्यक नहीं डाला: आप उस सुविधा को कैसे बंद करते हैं?

— शाम

10

एआरपी / प्रसारण तूफान

हम VLAN 1, VLAN 1 से बड़े प्रसारण पैकेटों को डेस्कटॉप उपकरणों के लिए उपयोग करते हैं। हम 192.168.0.0/20 का उपयोग करते हैं ...

Wiresharks से पता चलता है कि 100s कंप्यूटर ARP ब्रॉडकास्ट के साथ नेटवर्क को भर रहे हैं ...

आपकी एआरपी इनपुट प्रक्रिया उच्च है, जिसका अर्थ है कि स्विच एआरपी प्रसंस्करण में बहुत समय खर्च कर रहा है। एआरपी बाढ़ का एक बहुत ही सामान्य कारण आपके स्विच के बीच एक लूप है। यदि आपके पास एक लूप है, तो आप भी मैक फ्लैप प्राप्त कर सकते हैं जो आपने ऊपर उल्लेख किया है। एआरपी बाढ़ के अन्य संभावित कारण हैं:

आईपी एड्रेस गलतफहमी
लेयर 2 का हमला, जैसे कि आरपीओ स्पूफिंग

पहले गलतफहमी की संभावना या ऊपर बताए गए लेयर 2 के हमले को खत्म करें। यह करने के लिए सबसे आसान तरीका है के साथ है arpwatch एक Linux मशीन (यदि आप एक का उपयोग करने के भले ही पर livecd एक लैपटॉप पर)। यदि आपके पास गलत धारणा या लेयर 2 का हमला है, तो arpwatch आपको syslog में इस तरह के संदेश देता है, जो मैक पते की सूची बनाते हैं जो समान आईपी पते पर लड़ रहे हैं ...
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)

जब आप "फ्लिप फ्लॉप" देखते हैं, तो आपको मैक पते के स्रोत को ट्रैक करना होगा और यह पता लगाना होगा कि वे एक ही आईपी पर क्यों लड़ रहे हैं।

मैक फ्लैप की बड़ी संख्या

स्पानिंग ट्री को सिस्को टीएसी और सीसीएनपी / सीसीआईई योग्य व्यक्तियों द्वारा सत्यापित किया गया है। हम सभी अनावश्यक लिंक को बंद कर देते हैं।

किसी ऐसे व्यक्ति के रूप में बोलना जो मेरे द्वारा याद किए जाने की तुलना में इस समय के माध्यम से अधिक बार हुआ है, यह मत समझो कि आपको सभी निरर्थक लिंक मिल गए हैं ... बस अपने स्विचपोर्ट को हर समय व्यवहार करें।

चूंकि आप स्विचपोर्ट के बीच मैक फ्लैप की एक बड़ी संख्या प्राप्त कर रहे हैं, यह पता लगाना मुश्किल है कि अपराधी कहां हैं (मान लीजिए कि आप दो या तीन मैक पते पाते हैं जो बहुत सारे आरप भेजते हैं, लेकिन स्रोत मैक पते बंदरगाहों के बीच फड़फड़ाते रहते हैं)। यदि आप प्रति-किनारे मैक-पतों पर एक कठिन सीमा लागू नहीं कर रहे हैं, तो इन समस्याओं को मैन्युअल रूप से अनप्लग केबल के बिना (जो आप बचना चाहते हैं) को ट्रैक करना बहुत मुश्किल है। स्विच लूप्स नेटवर्क में एक अप्रत्याशित पथ का कारण बनते हैं, और आप सैकड़ों मैक के साथ हवा निकाल सकते हैं जो सामान्य रूप से डेस्कटॉप स्विचपोर्ट होना चाहिए।

मैक-चाल को धीमा करने का सबसे आसान तरीका है port-security। Vlan 1 में हर एक्सेस स्विचपोर्ट पर जो एक पीसी से जुड़ा हुआ है (एक डाउनस्ट्रीम स्विच के बिना), अपने सिस्को स्विच पर निम्न इंटरफ़ेस-स्तरीय कमांड कॉन्फ़िगर करें ...

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

अधिकांश मैक / एआरपी बाढ़ के मामलों में, इस कॉन्फ़िगरेशन को आपके सभी एज स्विच पोर्ट (विशेष रूप से पोर्टफ़ास्ट के साथ किसी भी) पर लागू करने से आपको वापस एक राज्य में मिल जाएगा, क्योंकि कॉन्फ़िगरेशन किसी भी पोर्ट को बंद कर देगा जो तीन मैक-पतों से अधिक है, और गुप्त रूप से अक्षम करें पासा पोर्टफ़ास्ट पोर्ट। प्रति पोर्ट तीन मैक एक संख्या है जो मेरे डेस्कटॉप वातावरण में अच्छी तरह से काम करती है, लेकिन आप इसे 10 तक बढ़ा सकते हैं और शायद ठीक हो सकते हैं। आपके द्वारा ऐसा करने के बाद, कोई भी परत 2 छोरों को तोड़ दिया जाता है, रैपिड मैक फ्लैप बंद हो जाएगा, और यह निदान को बहुत आसान बनाता है।

वैश्विक आदेशों की एक और जोड़ी जो एक प्रसारण तूफान (मैक-चाल) और बाढ़ (दहलीज) से जुड़े बंदरगाहों को ट्रैक करने के लिए उपयोगी है ...

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

समाप्त करने के बाद, वैकल्पिक रूप clear mac address-tableसे संभावित पूर्ण सीएएम तालिका से चिकित्सा में तेजी लाने के लिए एक करें।

रैन मैक एड्रेस-टेबल को अलग-अलग स्विच और कोर पर (उदाहरण के लिए, उदाहरण के लिए, सीधे डेस्कटॉप, मेरे डेस्कटॉप द्वारा प्लग किया गया है), और हम इंटरफ़ेस में पंजीकृत होने के बावजूद कई अलग-अलग मैक हार्डवेयर एड्रेस को देख सकते हैं, भले ही वह इंटरफ़ेस हो इससे जुड़ा केवल एक कंप्यूटर ...

यह संपूर्ण उत्तर मानता है कि आपके 3750 में समस्या पैदा करने वाला बग नहीं है (लेकिन आपने कहा था कि वायरशार्क ने पीसी को संकेत दिया है कि बाढ़ आ रही है)। जब आप हमें दिखा रहे हैं तो यह स्पष्ट रूप से गलत है जब Gi1 / 1/3 से जुड़ा केवल एक कंप्यूटर है, जब तक कि पीसी के पास VMWare जैसा कुछ न हो।

विविध विचार

हमारे द्वारा की गई बातचीत के आधार पर, मुझे संभवतः स्पष्ट उल्लेख नहीं करना है, लेकिन मैं भविष्य के आगंतुकों के लिए ...

Vlan1 में किसी भी उपयोगकर्ता को डालना सामान्य रूप से एक बुरा विचार है (मुझे लगता है कि आपको एक गड़बड़ विरासत में मिली होगी)
TAC आपको जो भी बताता है, उसके बावजूद, 192.168.0.0/20 लेयर 2 हमलों के जोखिम के बिना एक एकल स्विच्ड डोमेन में प्रबंधन करने के लिए बहुत बड़ा है। आपका सबनेट मास्क जितना बड़ा होता है, उतना ही बड़ा जोखिम आपको लेयर 2 के हमलों की तरह होता है क्योंकि ARP एक अनौपचारिक प्रोटोकॉल होता है और राउटर को कम से कम उस सबनेट से एक मान्य ARP को पढ़ना चाहिए।
लेयर 2 पोर्ट पर स्टॉर्म-कंट्रोल आमतौर पर एक अच्छा विचार है; हालांकि, इस तरह की स्थिति में तूफान-नियंत्रण को सक्षम करने से यह खराब ट्रैफ़िक के साथ अच्छा ट्रैफ़िक निकाल देगा। नेटवर्क ठीक हो जाने के बाद, अपने एज पोर्ट और अपलिंक पर कुछ तूफानी नियंत्रण नीतियां लागू करें।

— माइक पेनिंगटन
स्रोत

1

दरअसल, उनका टेंप्रेचर मैक्सिमम नहीं है। पहला कॉलम अधिकतम है, दूसरा वर्तमान उपयोग है। आप मास्क बनाम मान भाग को अनदेखा कर सकते हैं। यहाँ से, यह एक "सरल" आरपी तूफान की तरह लगता है, लेकिन उनकी टोपोलॉजी और वास्तविक यातायात के ज्ञान के बिना, मैं अनुमान नहीं लगा सकता कि क्यों।

2

असली सवाल यह है कि मेजबान इतने सारे एआरपी को पहले स्थान पर क्यों भेज रहे हैं। जब तक यह उत्तर नहीं दिया जाता है, तब तक स्विच (तों) के पास अर्प तूफान से निपटने के लिए एक कठिन समय जारी रहेगा। नेटमास्क बेमेल? कम मेजबान arp टाइमर? एक (या अधिक) मेजबान एक "इंटरफेस" मार्ग नहीं होता है? कहीं रूज वायरलेस ब्रिज? पागल हो गया? DHCP सर्वर "इन-यूज़" प्रोबिंग? यह स्विच, या परत 2 के साथ एक मुद्दे की तरह ध्वनि नहीं करता है; आपके पास बुरे काम करने वाले मेजबान हैं।

मेरी डिबगिंग प्रक्रिया सब कुछ अनप्लग होगी और चीजों को बारीकी से देखना होगा क्योंकि एक समय में एक पोर्ट को फिर से जोड़ा जाता है। (मुझे पता है कि यह आदर्श से मील की दूरी पर है, लेकिन कुछ बिंदु पर आपको अपने नुकसान में कटौती करनी होगी और किसी भी संभावित स्रोत को भौतिक रूप से अलग करने का प्रयास करना होगा) फिर मैं यह समझने की दिशा में काम करूंगा कि कुछ बंदरगाहों का चयन क्यों कर रहे हैं।

(क्या बहुत सारे मेजबानों में लिनक्स सिस्टम होगा? लिनक्स के पास बहुत डी *** मेड बेवकूफ एआरपी कैश मैनेजमेंट सिस्टम है। यह तथ्य कि यह केवल मिनटों में एक प्रविष्टि को "री-वेरिफाई" करेगा, मेरी पुस्तक में टूट गया है यह छोटे नेटवर्क में एक समस्या से कम है, लेकिन / 20 एक छोटा नेटवर्क नहीं है।)

— रिकी बीम
स्रोत

1

यह हाथ में आपके मुद्दे से संबंधित हो सकता है या नहीं भी हो सकता है, हालांकि मुझे लगा कि यह कम से कम वहां से बाहर फेंकने लायक कुछ हो सकता है:

वर्तमान में हमारे कुछ दूरदराज के स्थलों में 3750x की संख्या है, जो ज्यादातर 15.0.2 (4 के माध्यम से SE0) चल रहे हैं, SE0 के साथ कुछ FRU बग हैं जिनसे मैं धीरे-धीरे दूर जा रहा हूं)।

एक रूटीन IOS अपडेट के दौरान, 15.0.2 से 15.2-1 (सबसे हालिया SE) पर जाने पर हमने एक बहुत महत्वपूर्ण CPU वृद्धि देखी, जो औसतन लगभग 30% से 60% और ऑफ-पीक समय के दौरान अधिक थी। मैंने कॉन्फ़िगरेशन और आईओएस चेंज लॉग्स की समीक्षा की है, और सिस्को के टीएसी के साथ काम कर रहा है। टीएसी के अनुसार, वे उस बिंदु पर प्रतीत होते हैं जहां वे मानते हैं कि यह कुछ IOS 15.2-1 बग है।

जब हम सीपीयू वृद्धि की जांच करना जारी रखते थे, तो हमने एआरपी ट्रैफ़िक को भारी मात्रा में उस बिंदु पर देखना शुरू किया, जहां हमारे एआरपी टेबल पूरी तरह से भरे हुए थे और नेटवर्क अक्षमता का कारण बने। इसके लिए अस्थाई बैसाखी को हमारी एआरपी टाइमआउट को डिफ़ॉल्ट रूप से (14400) से 300 तक हमारी आवाज और डेटा vlans पर मैन्युअल रूप से वापस करना था।

अपने ARP टाइमआउट को कम करने के बाद, हम एक या दो सप्ताह के लिए स्थिर थे, जिस बिंदु पर हम IOS 15.0.2-SE4 पर लौटे, और अपने गैर-डिफ़ॉल्ट ARP टाइमआउट को हटा दिया। हमारे सीपीयू का उपयोग ~ 30% पर वापस आ गया है और हमारे एआरपी टेबल मुद्दे गैर-मौजूद हैं।

दिलचस्प कहानी ... साझा करने के लिए धन्यवाद, हालांकि यह बग को जोड़ने में मदद कर सकता है ताकि यह पता लगाना आसान हो कि ओपी उजागर हुआ है या नहीं। FYI करें, अक्सर अपने ARP टाइमआउट को अपने CAM टाइमर से कम रखना एक अच्छा विचार है।

— माइक पेनिंगटन

टिप्पणी के लिए धन्यवाद, लेकिन मूल मुद्दे के प्रकाश में, हम वर्तमान में ढेर में एक कम आईओएस संस्करण का उपयोग कर रहे हैं और कुछ समय से काफी स्थिर हैं। @ MikePennington डिफ़ॉल्ट रूप से ARP टाइमआउट 4 घंटे पर सेट होता है और CAM टाइमआउट 5 मिनट का होता है? क्या यह मामला नहीं है?

— कोल्ड टी

@ कॉल्ड, इसलिए मैंने इसका उल्लेख किया है। कुछ एचएसआरपी मामलों के लिए, सिस्को के सीएएम / एआरपी टाइमर डिफ़ॉल्ट रूप से चीजों को तोड़ते हैं । जब तक कोई सम्मोहक कारण न हो, तब तक मैंने अपने arp timeout 240सभी एसवीआई / एल 3 इंटरफेस पर सेट कर दिया जो एक स्विच का सामना कर रहे हैं।

— माइक पेनिंगटन

0

एक फेलियर सरल, लेकिन शायद अनदेखी; क्या आपके ग्राहकों के पास एक वैध डिफ़ॉल्ट गेटवे है, तो आप बहुत सारे प्रॉक्सी आर्प्स नहीं कर सकते। आप अपने 3750 पर आईपी प्रॉक्सी आर्पी फ़ंक्शन को नकारने पर विचार कर सकते हैं?