वायरलेस पर रोमिंग क्लाइंट्स के कारण मैक-फ्लैप


13

हम एक Aerohove वायरलेस नेटवर्क (नियंत्रक-कम) चला रहे हैं .. मुझे कभी-कभी एक SSID से जुड़े वीएलएएन के भीतर मैक-फ्लैप मिलते हैं। मुझे पता है कि यह एक रोमिंग क्लाइंट से आ रहा है .. समस्या यह है कि जिस कंपनी के लिए मैं काम करता हूं उसके पास एंड-टू-व्लेंस (एक्सेस-लेयर पर एल 3 डिवाइस लगाने के लिए कोई पैसा नहीं है) और मेरा मानना ​​है कि ये मैक-फ्लैप मैक-टेबल का कारण बनते हैं उस वीएलएएन के लिए पूरे एल 2 डोमेन में प्रवाहित होने के लिए ... जो बदले में और अधिक प्रसारण का कारण बनता है।

मुझे पता है कि एक्सेस लेयर पर L2 डोमेन को समाप्त करना सबसे अच्छा समाधान होगा, लेकिन शॉर्ट टर्म पर कोई पैसा नहीं है ... इस मुद्दे से निपटने के बारे में कोई विचार?


लॉग में फड़फड़ाने की चेतावनी से अलग, आपको किस तरह की समस्याएं दिख रही हैं?
शेन मैडेन

1
यदि आप वास्तव में मुद्दों का कारण बन रहे हैं तो आप इसे देखते हुए सुरंग बना सकते हैं। हालांकि एरोहिव के पास कोई नियंत्रक नहीं है, लेकिन मुझे लगता है कि वे एक निश्चित एपी के लिए जीआरई सुरंग का समर्थन करते हैं जो फिर स्थानीय स्विचिंग पर यातायात को छोड़ सकता है। क्या यह एक परिचालन समस्या पैदा कर रहा है?
जोडी बॉथम

क्या किसी उत्तर ने आपकी मदद की? यदि हां, तो आपको उत्तर स्वीकार करना चाहिए ताकि प्रश्न हमेशा के लिए पॉपिंग न हो जाए, उत्तर की तलाश में है। वैकल्पिक रूप से, आप अपना स्वयं का उत्तर प्रदान कर सकते हैं और स्वीकार कर सकते हैं।
रॉन Maupin

जवाबों:


16

यदि आपके AP आपके वायर्ड नेटवर्क पर वायरलेस राइट से क्लाइंट्स ब्रिजिंग कर रहे हैं, तो आप समय-समय पर इसे देखने जा रहे हैं। ग्राहक अलग-अलग बंदरगाहों से दिखाई देंगे क्योंकि वे ईएसएसआईडी में अन्य एपी / कोशिकाओं के साथ फिर से जुड़ेंगे।

मैं मान रहा हूँ कि आप सिस्को IOS के बारे में बात कर रहे हैं, "MACFLAP" शब्द के आधार पर, जो ऐसा होने पर उनके लॉग संदेशों में दिखाई देता है। उदाहरण के लिए: "% SW_MATM-4-MACFLAP_NOTIF: होस्ट 0011.2233.4455 vlan 123 में पोर्ट Gi1 / 1 और पोर्ट Gi1 / 2 के बीच फड़फड़ा रहा है"

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

हालाँकि, इससे पूरी तालिका को फ़्लश या साफ़ नहीं करना चाहिए । बस फ़्लैपिंग स्रोत मैक पते के लिए प्रविष्टियाँ प्रभावित हो रही हैं।

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

हालांकि, यदि यह कई मैक पते के लिए अक्सर हो रहा है, तो यह एक परत 2 लूप का संकेत हो सकता है जिसे निश्चित रूप से कुछ जांच की आवश्यकता होगी। : p


1
मैं इस धारणा के तहत हूं कि यह सामान्य री-लर्निंग चीज नहीं है। अगर मैं अपने वर्कस्टेशन को एक से दूसरे एहर्टनेट पोर्ट पर प्लग करता हूँ तो मुझे मैकफ़्लैप नहीं मिलेगा। मेरा मानना ​​है कि यह तब होता है जब यह बंदरगाहों के बीच आगे और पीछे कुछ समय बदलता है ...
user209

9

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

जब तक घटनाओं हैं अन्य उत्तर ढंक दिया है, यह कुछ भी नहीं है जो भी के बारे में चिंतित होने के लिए ज्यादा क्या आप कर रहे हैं देखने की तुलना में अधिक लगातार। पेड़ के पुन: अभिसरण और मैक तालिकाओं के निस्तब्धता के बारे में आपकी चिंताएं निराधार हैं; यह फैले हुए पेड़ के लिए एक टोपोलॉजी परिवर्तन नहीं है और तालिका सिर्फ मैक पते के लिए अपडेट हो रही है जो कि फड़फड़ा गया - एक ही स्विच पर अन्य प्रविष्टियां, एक ही वलान, या एक ही पोर्ट अप्रभावित हैं।


मैं सहमत हूँ। समसामयिक macflaps कोई चिंता नहीं है। पूरी तरह से एक एसटीपी टोपोलॉजी परिवर्तन से अलग है।
डेनिस ओलवनी

5

जब तक आप बहुत सारे macflap नोटिफिकेशन प्राप्त नहीं कर लेते, मुझे चिंता नहीं होगी। ऐसा लगता है कि रोमिंग क्लाइंट अस्थायी रूप से दो एपी (जो एक ही स्विच से जुड़े हुए हैं) के साथ संचार कर रहा है क्योंकि यह एक से दूसरे को दिया जा रहा है। मैकफ़्लैप्स इसलिए हो रहे हैं क्योंकि स्विच एक ही समय में दो इंटरफेस पर एक ही मैक से ट्रैफ़िक देखता है। मैं उम्मीद करता हूं कि हैंडऑफ पूरा होते ही मैक्लेफस बंद हो जाएगा। मैकफ़्लैप्स के साथ सामान्य चिंता तब होती है जब वे रुकते नहीं हैं - मैक टेबल को लगातार एक से अधिक बार अपडेट करने से थ्रेशिंग एक स्विच के हार्डवेयर को गंभीर रूप से नुकसान पहुंचा सकती है ($ WORK एक बार सचमुच 6500 सुपरवाइजर कार्ड को इस तरह पिघला देता है)।

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


यह बहुत बार नहीं हो रहा है ... लेकिन मैक टेबल के निस्तब्धता के बारे में मेरा विचार: मैक टेबल को फैले हुए पेड़ से भरा जा सकता है क्योंकि यह एक टोपोलॉजी परिवर्तन के रूप में मैकफ्लैप को रोक सकता है। ट्रंक लिंक पर macflap occures एप के कारण ट्रंक पोर्ट पर जुड़े हुए हैं ... यदि इस मामले में मैक तालिका उस vlan के लिए l2 डोमेन
tushout
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.