जब राउटर लोड को संभाल नहीं सकता है

मैं दूरसंचार अभ्यास से एक मामला साझा करूंगा।

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

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





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

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

सबसे अधिक संभावना है, उन्होंने एक नए, अधिक उत्पादक राउटर की खरीद को मंजूरी नहीं दी होगी, विशेष रूप से क्योंकि शेल्फ पर 48-पोर्ट उत्प्रेरक और एक और 26 वाँ टिस्का था। और उसके पास शारीरिक रूप से आने का समय नहीं होगा। कैटलिस्ट 3550 एक L3 स्विच है और रूटिंग को संभाल सकता है। इसके अलावा, आप इस पर L3 इंटरफेस को कॉन्फ़िगर कर सकते हैं, अर्थात, उन्हें VLANs से न बांधें, बल्कि उन्हें IP असाइन करें।

दो बंदरगाहों के साथ 26 वीं श्रृंखला का दूसरा tsiska, जो सभी ट्रैफ़िक को एक छेद से जाने से रोकेगा: स्थानीय ग्राहकों को एक पोर्ट से कनेक्ट करें, और दूसरे अपलिंक को दूरस्थ सीमा पर आवंटित करें।

समाधान आम तौर पर सरल है:

1) हम NAT को एक अलग राउटर पर निकालते हैं। (वह नैट और रूटिंग व्हाइट आईपी से विशेष रूप से निपटेंगे)

2) हम सभी उप-केंद्रों को कटालिस्ट के पास ले जाते हैं (यह स्थानीय नेटवर्क पर डेटा के हस्तांतरण की सुविधा देगा और अपलिंक को बंद कर देगा)

3) पुरानी tsiska केवल टेलीफोन पारगमन के लिए बनी हुई है।

आरेख में, इसे इस तरह व्यक्त किया जा सकता है:





इंटरनेट पर भेजे गए पैकेट का मार्ग गुलाबी रंग में प्रदर्शित होता है, नेटवर्क से गंतव्य के साथ आंतरिक पैकेट 172.16.0.0/16 बकाइन मार्ग का अनुसरण करता है। ग्रीन टेलीफोन कॉल पथ है।

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



लोहे के उपयोग के संदर्भ में यह योजना बहुत तर्कसंगत नहीं है। लेकिन यह कितना अस्थायी होगा।

इससे उपकरणों पर भार बहुत कम हो गया - एनएटीआर के लिए राउटर प्रोसेसर का औसत भार 20-30% है, और यहां तक ​​कि कैटेलिसिस के साथ भी कम है। समस्याएं खत्म हो गई हैं।

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

इसलिए, कोई फर्क नहीं पड़ता कि हम कितनी खूबसूरती से स्थिति से बाहर निकलते हैं, आपको एक सामान्य, उत्पादक राउटर खरीदने और एक क्लासिक सर्किट बनाने की आवश्यकता है।

PS यदि आप नई योजना के कार्यान्वयन या किसी भी प्रश्न के तकनीकी विवरण में रुचि रखते हैं, तो मैं उन्हें विषय में जोड़ दूंगा।