जिस छोटे से कॉलेज में मैं काम करता हूं वहां कुछ बहुत ही अजीब नेटवर्क समस्याएँ हैं। मैं यहाँ किसी भी सलाह या विचारों की तलाश कर रहा हूँ। हम गर्मियों में ठीक थे, लेकिन छात्रों के गिरने की स्थिति में कैंपस लौटने के कुछ दिनों बाद यह परेशानी शुरू हुई।
लक्षण
मुख्य लक्षण यह है कि इंटरनेट एक्सेस काम करेगा, लेकिन यह बहुत धीमा है ... अक्सर टाइमआउट के बिंदु तक। एक उदाहरण के रूप में, Speedtest.net से एक विशिष्ट परिणाम .4Mbps डाउनलोड आएगा, लेकिन 3 से 8 एमबीपीएस अपलोड गति की अनुमति देगा। कम लक्षणों में गंभीर रूप से सीमित प्रदर्शन डेटा को हमारे फ़ाइल सर्वर से या यहां तक कि कुछ मामलों में भी कंप्यूटर में लॉग इन करने में असमर्थता (डोमेन नियंत्रक तक नहीं पहुंचना) शामिल हो सकती है। समस्या कई vlans को पार करती है, और हमारे द्वारा संचालित लगभग प्रत्येक स्वर पर उपकरणों को प्रभावित करती है।
समस्या नेटवर्क पर सभी मशीनों को प्रभावित नहीं करती है। एक अप्रभावित मशीन को आमतौर पर speedtest.net से कम से कम 11Mbps डाउनलोड दिखाई देगा , और शायद उस समय बड़े परिसर ट्रैफ़िक पैटर्न के आधार पर बहुत अधिक।
बड़े मुद्दे पर एक भिन्नता है। हमारे पास एक वलान है जहां उपयोगकर्ता लगभग सभी मशीनों में प्रवेश करने में असमर्थ थे। आईटी कर्मचारी एक स्थानीय व्यवस्थापक खाते (या कुछ मामलों में कैश की गई क्रेडेंशियल्स) का उपयोग करके लॉग इन करेंगे, और वहां से प्रवेश / नवीनीकरण या गेटवे को पिंग करने से मशीन को काम करने की अनुमति मिलेगी ... थोड़ी देर के लिए। इस समस्या की शिकायत यह है कि यह vlan हमारे कंप्यूटर लैब्स को कवर करता है, जो रिबूट के बाद हार्ड ड्राइव को पूरी तरह से रीसेट करने के लिए डीप फ्रीज नामक सॉफ्टवेयर का उपयोग करता है। यह सिर्फ एक ही मुद्दा है कि मशीनों पर बासी डेटा के कारण अलग-अलग प्रकट हो सकता है जो हफ्तों के लिए स्थायी रूप से निम्न-स्तर की जानकारी को बदल नहीं रहे हैं। हम इसे हल करने में सक्षम थे, हालांकि, एक नया वलान बनाकर और प्रयोगशालाओं को नए वलान थोक में स्थानांतरित कर दिया।
Instigations
आखिरकार हमने देखा कि सभी प्रभावित मशीनों में हाल ही में dhcp पट्टे थे। हम यह अनुमान लगा सकते हैं कि एक मशीन जब धीमे-धीमे पट्टे के नवीनीकरण के लिए आती है, तो यह देखकर "धीमी" हो जाएगी। हमने टेस्ट वलान के लिए लीज का समय बहुत कम निर्धारित करने के साथ खेला, लेकिन जब मशीन धीमी हो जाएगी तो भविष्यवाणी करने की हमारी क्षमता को हटा दिया गया। स्थैतिक आईपी के साथ मशीनों ने हमेशा सामान्य रूप से काम किया है। किसी पते को मैन्युअल रूप से जारी / नवीनीकृत करने से कभी भी मशीन धीमी नहीं होगी । वास्तव में, कुछ मामलों में यह प्रक्रिया तय हो गई हैउस अवस्था में एक मशीन। हालांकि, ज्यादातर समय, यह मदद नहीं करता है। हमने यह भी देखा कि लैपटॉप जैसे मोबाइल मशीन के नए vlans के पार जाने पर धीमा होने की संभावना है। कैंपस में वायरलेस को "ज़ोन" में विभाजित किया गया है, जहां प्रत्येक ज़ोन इमारतों के एक छोटे समूह के लिए मैप करता है। एक नए भवन में जाने से आप एक क्षेत्र में रख सकते हैं, जिससे आपको एक नया पता मिल जाएगा। स्लीप मोड से फिर से शुरू होने वाली मशीन भी धीमी होने की बहुत संभावना है।
mitigations
कभी-कभी, लेकिन हमेशा नहीं, एक प्रभावित मशीन पर arp कैश को साफ़ करने से यह फिर से सामान्य रूप से काम करने की अनुमति देगा। जैसा कि पहले ही उल्लेख किया गया है, किसी स्थानीय मशीन के आईपी पते को जारी / नवीनीकृत करना उस मशीन को ठीक कर सकता है, लेकिन इसकी गारंटी नहीं है। डिफ़ॉल्ट गेटवे को पिंग करना भी कभी-कभी धीमी मशीन की मदद कर सकता है।
इस समस्या को कम करने के लिए सबसे अधिक मदद करने के लिए क्या लगता है हमारे कोर परत -3 स्विच पर arp कैश समाशोधन है। यह स्विच हमारे dhcp सिस्टम के लिए सभी vlans पर डिफ़ॉल्ट गेटवे के रूप में उपयोग किया जाता है, और यह इंटर-वलान रूटिंग को संभालता है। मॉडल एक 3Com 4900SX है। समस्या को कम करने का प्रयास करने के लिए, हमारे पास कैश टाइमआउट को स्विच पर सेट करने के लिए सभी संभव सबसे कम समय पर सेट है, लेकिन यह मदद नहीं करता है। मैंने एक स्क्रिप्ट भी रखी जो स्वचालित रूप से स्विच से कनेक्ट करने और कैश को रीसेट करने के लिए हर कुछ मिनटों में चलती है। दुर्भाग्य से, यह हमेशा काम नहीं करता है, और यहां तक कि कुछ मशीनों को थोड़े समय के लिए धीमी स्थिति में समाप्त करने का कारण बन सकता है (हालांकि ये कुछ मिनटों के बाद खुद को सही करने लगते हैं)। वर्तमान में हमारे पास एक अनुसूचित नौकरी है जो कोर स्विच को एआरपी कैश को साफ़ करने के लिए मजबूर करने के लिए हर 10 मिनट चलती है, लेकिन यह एकदम सही या वांछनीय है।
प्रजनन
अब हमारे पास एक परीक्षण मशीन है जिसे हम अपनी इच्छा के अनुसार धीमी अवस्था में ले जा सकते हैं। यह हमारे प्रत्येक vlans के लिए स्थापित बंदरगाहों के साथ एक स्विच से जुड़ा हुआ है। हम अलग-अलग vlans से कनेक्ट करके मशीन को धीमा करते हैं, और एक नए कनेक्शन या दो के बाद यह धीमा हो जाएगा।
इस खंड में यह भी ध्यान देने योग्य है कि यह पूर्व की शर्तों के शुरू होने से पहले हुआ है, लेकिन अतीत में समस्या कुछ दिनों के बाद ही दूर हो गई है। इससे पहले कि हम बहुत अधिक नैदानिक कार्य करने का मौका देते, खुद को हल कर लेते ... इसलिए हमने इसे इस समय के दौर में इतना लंबा खींचने की अनुमति दी है; उम्मीद थी कि यह एक अल्पकालिक स्थिति होगी।
अन्य कारक
यह ध्यान देने योग्य बात है कि हमारे पास पिछले वर्ष की तुलना में लगभग आधा दर्जन स्विच हैं। ये मुख्य रूप से 2003/2004-युग 3Coms (ज्यादातर 4200) हैं जो सभी एक ही समय में डाले गए थे। उन्हें अभी भी वारंटी के तहत कवर किया जाना चाहिए, खरीदें एचपी ने सेवा को कुछ हद तक मुश्किल बना दिया है। ज्यादातर बिजली की आपूर्ति में जो विफल रहे हैं, लेकिन कुछ मामलों में हमने एक असफल मेनबोर्ड के साथ एक स्विच से एक बिजली की आपूर्ति का उपयोग किया है, एक असफल बिजली की आपूर्ति के साथ स्विच को जीवन में वापस लाने के लिए। हमारे पास अब यूपीएस डिवाइस हैं, लेकिन तीन में से तीन स्विच करते हैं, लेकिन यह तब नहीं था जब मैंने ढाई साल पहले शुरू किया था। गंभीर बजट बाधाएं (हम कुछ साल पहले एड की आर्थिक रूप से अक्षम संस्थानों की सूची में थे) ने मुझे प्रतिस्थापन के लिए नेटगियर और ट्रेंडनेट की पसंद को देखने के लिए मजबूर किया है।
यह भी उल्लेखनीय है कि हमारे नेटवर्क पर इस साल गर्मियों में एक बड़ा बदलाव एक एकल क्रॉस-कैंपस वायरलेस एसएसआईडी से पहले से उल्लेखित ज़ोनड दृष्टिकोण से पलायन कर रहा था। मुझे नहीं लगता कि यह इस मुद्दे का स्रोत है, जैसा कि मैंने कहा है: हमने इसे पहले देखा है। हालाँकि, यह संभव है कि यह समस्या को बढ़ा रहा है, और इसे अलग करने के लिए बहुत कठिन कारण हो सकता है।
निदान
पहले तो यह हमारे लिए स्पष्ट था, समस्या के समय और लगातार प्रकृति को देखते हुए, कि समस्या का स्रोत एक संक्रमित (या दुर्भावनापूर्ण) छात्र मशीन था जो एआरपी कैश पॉइज़निंग कर रहा था। हालांकि, स्रोत को अलग करने के बार-बार प्रयास विफल रहे हैं। उन प्रयासों में कई वायरशर्क पैकेट निशान शामिल हैं, और यहां तक कि पूरी इमारतों को संक्षिप्त अवधि के लिए ऑफ़लाइन भी ले जाना है। हम एक धूम्रपान बंदूक खराब एआरपी प्रविष्टि खोजने में भी सक्षम नहीं हैं। मेरा वर्तमान सबसे अच्छा अनुमान एक अतिभारित या असफल कोर स्विच है, लेकिन मुझे इस पर यकीन नहीं है कि इसके लिए कैसे परीक्षण करना है, और इसे नेत्रहीन रूप से बदलने की लागत खड़ी है।
फिर, किसी भी विचार की सराहना की।
अद्यतन:
कोर स्विच को बदल दिया गया है। 4 दिनों के बाद, सब कुछ ठीक चल रहा है ... लेकिन मैं इस मुद्दे को हल करने से पहले दो सप्ताह के लिए प्रतीक्षा करूंगा।
mtrयहाँ मददगार हो सकता है।