अपने नेटवर्क बुनियादी ढांचे का नियंत्रण कैसे लें। अध्याय दो। सफ़ाई और दस्तावेज़ीकरण

यह लेख "अपने नेटवर्क के बुनियादी ढांचे पर नियंत्रण कैसे लें" लेखों की श्रृंखला में दूसरा है। श्रृंखला के सभी लेखों की सामग्री और लिंक पाए जा सकते हैं यहां.

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

अब हम सुरक्षा ऑडिट के बारे में बात नहीं करेंगे - यह तीसरे भाग का विषय होगा।

इस स्तर पर सौंपे गए कार्य को पूरा करने की कठिनाई, निश्चित रूप से, कंपनी-दर-कंपनी में बहुत भिन्न होती है।

आदर्श स्थिति वह है जब

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

इस मामले में, आपका कार्य काफी सरल है. आपको दस्तावेज़ों का अध्ययन करना चाहिए और किए गए सभी परिवर्तनों की समीक्षा करनी चाहिए।

सबसे खराब स्थिति में, आपके पास होगा

• बिना परियोजना, बिना योजना, बिना अनुमोदन के, ऐसे इंजीनियरों द्वारा बनाया गया नेटवर्क जिनके पास पर्याप्त स्तर की योग्यता नहीं है,
• अराजक, अप्रलेखित परिवर्तनों के साथ, बहुत सारे "कचरा" और उप-इष्टतम समाधानों के साथ

यह स्पष्ट है कि आपकी स्थिति कहीं बीच में है, लेकिन दुर्भाग्य से, बेहतर-बदतर के इस पैमाने पर, इस बात की बहुत अधिक संभावना है कि आप सबसे खराब अंत के करीब होंगे।

इस मामले में, आपको मन को पढ़ने की क्षमता की भी आवश्यकता होगी, क्योंकि आपको यह समझना सीखना होगा कि "डिजाइनर" क्या करना चाहते थे, उनके तर्क को बहाल करना, जो पूरा नहीं हुआ था उसे पूरा करना और "कचरा" हटाना।
और, निश्चित रूप से, आपको उनकी गलतियों को सुधारने, डिज़ाइन को बदलने (इस स्तर पर यथासंभव न्यूनतम) और योजनाओं को बदलने या फिर से बनाने की आवश्यकता होगी।

यह आलेख किसी भी तरह से पूर्ण होने का दावा नहीं करता। यहां मैं केवल सामान्य सिद्धांतों का वर्णन करूंगा और कुछ सामान्य समस्याओं पर ध्यान केंद्रित करूंगा जिन्हें हल किया जाना है।

दस्तावेज़ों का सेट

चलिए एक उदाहरण से शुरू करते हैं.

नीचे कुछ दस्तावेज़ दिए गए हैं जो डिज़ाइन के दौरान सिस्को सिस्टम्स में कस्टमाइज़ किए जाते हैं।

CR - ग्राहक आवश्यकताएँ, ग्राहक आवश्यकताएँ (तकनीकी विशिष्टताएँ)।
यह ग्राहक के साथ संयुक्त रूप से बनाया जाता है और नेटवर्क आवश्यकताओं को निर्धारित करता है।

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

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

कुछ, उदाहरण के लिए, आईपी पते, एएस नंबर, भौतिक स्विचिंग योजना (केबलिंग), को अलग-अलग दस्तावेज़ों में "बाहर रखा" जा सकता है, जैसे जापानी (नेटवर्क कार्यान्वयन योजना)।

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

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

और मेरी राय में, एक निश्चित पूर्ण न्यूनतम है, जिसके बिना नेटवर्क को प्रभावी ढंग से नियंत्रित करना असंभव है।

ये निम्नलिखित दस्तावेज़ हैं:

• भौतिक स्विचिंग (केबलिंग) का आरेख (लॉग)
• आवश्यक L2/L3 जानकारी के साथ नेटवर्क आरेख या आरेख

भौतिक स्विचिंग आरेख

कुछ छोटी कंपनियों में उपकरण स्थापना और भौतिक स्विचिंग (केबलिंग) से संबंधित कार्य नेटवर्क इंजीनियरों की जिम्मेदारी है।

इस मामले में, समस्या को निम्नलिखित दृष्टिकोण से आंशिक रूप से हल किया गया है।

• इससे क्या जुड़ा है इसका वर्णन करने के लिए इंटरफ़ेस पर विवरण का उपयोग करें
• सभी असंबद्ध नेटवर्क उपकरण पोर्ट को प्रशासनिक रूप से बंद करें

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

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

इस प्रकार की जानकारी के साथ काम करने के लिए डिज़ाइन किए गए एप्लिकेशन का उपयोग करना आदर्श विकल्प है। लेकिन आप स्वयं को सरल तालिकाओं तक सीमित कर सकते हैं (उदाहरण के लिए, एक्सेल में) या वह जानकारी प्रदर्शित कर सकते हैं जिसे आप L1/L2 आरेखों में आवश्यक समझते हैं।

महत्वपूर्ण!

एक नेटवर्क इंजीनियर, निश्चित रूप से, एससीएस की पेचीदगियों और मानकों, रैक के प्रकार, निर्बाध बिजली आपूर्ति के प्रकार, ठंडा और गर्म गलियारा क्या है, उचित ग्राउंडिंग कैसे करें ... अच्छी तरह से जान सकता है, जैसा कि सिद्धांत रूप में वह कर सकता है प्राथमिक कणों या C++ की भौतिकी को जानें। लेकिन फिर भी किसी को यह समझना चाहिए कि यह सब उसके ज्ञान का क्षेत्र नहीं है।

इसलिए, उपकरण की स्थापना, कनेक्शन, रखरखाव के साथ-साथ भौतिक स्विचिंग से संबंधित समस्याओं को हल करने के लिए या तो समर्पित विभाग या समर्पित लोगों का होना अच्छा अभ्यास है। आमतौर पर डेटा सेंटरों के लिए यह डेटा सेंटर इंजीनियर होता है, और किसी कार्यालय के लिए यह हेल्प-डेस्क होता है।

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

नेटवर्क आरेख

चित्र बनाने के लिए कोई सार्वभौमिक दृष्टिकोण नहीं है।

सबसे महत्वपूर्ण बात यह है कि आरेखों को यह समझ प्रदान करनी चाहिए कि ट्रैफ़िक कैसे प्रवाहित होगा, आपके नेटवर्क के किन तार्किक और भौतिक तत्वों के माध्यम से।

भौतिक तत्वों से हमारा तात्पर्य है

• सक्रिय उपकरण
• सक्रिय उपकरणों के इंटरफेस/पोर्ट

तार्किक के अंतर्गत -

• तार्किक उपकरण (N7K VDC, पालो अल्टो VSYS, ...)
• वीआरएफ
• विलन्स
• उपइंटरफ़ेस
• सुरंगों
• क्षेत्र
• ...

साथ ही, यदि आपका नेटवर्क पूरी तरह से प्राथमिक नहीं है, तो इसमें विभिन्न खंड शामिल होंगे।
उदाहरण के लिये

• डेटा सेंटर
• इंटरनेट
• वान
• दूरदराज का उपयोग
• कार्यालय लैन
• DMZ
• ...

ऐसे कई आरेख रखना बुद्धिमानी है जो बड़ी तस्वीर (इन सभी खंडों के बीच ट्रैफ़िक कैसे बहता है) और प्रत्येक व्यक्तिगत खंड का विस्तृत विवरण देते हैं।

चूँकि आधुनिक नेटवर्क में कई तार्किक परतें हो सकती हैं, विभिन्न परतों के लिए अलग-अलग सर्किट बनाना शायद एक अच्छा (लेकिन आवश्यक नहीं) दृष्टिकोण है, उदाहरण के लिए, ओवरले दृष्टिकोण के मामले में यह निम्नलिखित सर्किट हो सकता है:

• ओवरले
• एल1/एल2 बुनियाद
• L3 बुनियाद

बेशक, सबसे महत्वपूर्ण आरेख, जिसके बिना आपके डिज़ाइन के विचार को समझना असंभव है, रूटिंग आरेख है।

रूटिंग योजना

कम से कम, इस आरेख को प्रतिबिंबित करना चाहिए

• कौन से रूटिंग प्रोटोकॉल का उपयोग किया जाता है और कहाँ
• रूटिंग प्रोटोकॉल सेटिंग्स के बारे में बुनियादी जानकारी (क्षेत्र/एएस नंबर/राउटर-आईडी/...)
• पुनर्वितरण किन उपकरणों पर होता है?
• जहां फ़िल्टरिंग और रूट एकत्रीकरण होता है
• डिफ़ॉल्ट मार्ग की जानकारी

साथ ही, L2 योजना (OSI) अक्सर उपयोगी होती है।

एल2 योजना (ओएसआई)

यह आरेख निम्नलिखित जानकारी दिखा सकता है:

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

विशिष्ट डिज़ाइन गलतियाँ

नेटवर्क बनाने के ख़राब दृष्टिकोण का एक उदाहरण.

आइए एक साधारण कार्यालय LAN के निर्माण का एक सरल उदाहरण लें।

छात्रों को टेलीकॉम सिखाने का अनुभव होने के कारण, मैं कह सकता हूँ कि वस्तुतः दूसरे सेमेस्टर के मध्य तक किसी भी छात्र के पास एक साधारण कार्यालय LAN स्थापित करने के लिए आवश्यक ज्ञान (मेरे द्वारा पढ़ाए गए पाठ्यक्रम के भाग के रूप में) होता है।

स्विचों को एक-दूसरे से जोड़ने, वीएलएएन, एसवीआई इंटरफेस (एल3 स्विच के मामले में) और स्टैटिक रूटिंग सेट करने में इतनी मुश्किल क्या है?

सब कुछ काम करेगा।

लेकिन साथ ही इससे जुड़े सवाल भी

• सुरक्षा
• आरक्षण
• नेटवर्क स्केलिंग
• उत्पादकता
• THROUGHPUT
• विश्वसनीयता
• ...

समय-समय पर मैं यह कथन सुनता हूं कि एक कार्यालय LAN एक बहुत ही सरल चीज़ है और मैं इसे आमतौर पर उन इंजीनियरों (और प्रबंधकों) से सुनता हूं जो नेटवर्क के अलावा सब कुछ करते हैं, और वे इसे इतने आत्मविश्वास से कहते हैं कि यदि LAN होगा तो आश्चर्यचकित न हों अपर्याप्त अभ्यास और ज्ञान वाले लोगों द्वारा किया गया और लगभग वही गलतियाँ होंगी जिनका मैं नीचे वर्णन करूँगा।

सामान्य L1 (OSI) डिज़ाइन गलतियाँ

• यदि, फिर भी, आप एससीएस के लिए भी जिम्मेदार हैं, तो सबसे अप्रिय विरासतों में से एक जो आपको प्राप्त हो सकती है वह है लापरवाही और बिना सोचे-समझे स्विच करना।

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

• अपर्याप्त बैंडविड्थ
• उपकरण पर अपर्याप्त टीसीएएम (या इसका अप्रभावी उपयोग)
• अपर्याप्त प्रदर्शन (अक्सर फ़ायरवॉल से संबंधित)

सामान्य L2 (OSI) डिज़ाइन गलतियाँ

अक्सर, जब इस बात की कोई अच्छी समझ नहीं होती है कि एसटीपी कैसे काम करता है और यह अपने साथ क्या संभावित समस्याएं लाता है, तो स्विच अतिरिक्त एसटीपी ट्यूनिंग के बिना, डिफ़ॉल्ट सेटिंग्स के साथ अव्यवस्थित रूप से जुड़े होते हैं।

परिणामस्वरूप, हमारे पास अक्सर निम्नलिखित होते हैं

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

L3 (OSI) डिज़ाइन में गलतियों के उदाहरण

नौसिखिया नेटवर्कर्स की कुछ सामान्य गलतियाँ:

• स्थैतिक रूटिंग का बार-बार उपयोग (या केवल उपयोग)।
• किसी दिए गए डिज़ाइन के लिए उप-इष्टतम रूटिंग प्रोटोकॉल का उपयोग
• उप-इष्टतम तार्किक नेटवर्क विभाजन
• पता स्थान का उप-इष्टतम उपयोग, जो मार्ग एकत्रीकरण की अनुमति नहीं देता है
• कोई बैकअप मार्ग नहीं
• डिफ़ॉल्ट गेटवे के लिए कोई आरक्षण नहीं
• मार्गों का पुनर्निर्माण करते समय असममित रूटिंग (NAT/PAT, स्टेटफुल फ़ायरवॉल के मामले में महत्वपूर्ण हो सकता है)
• एमटीयू के साथ समस्याएं
• जब मार्गों का पुनर्निर्माण किया जाता है, तो ट्रैफ़िक अन्य सुरक्षा क्षेत्रों या यहां तक ​​कि अन्य फ़ायरवॉल से होकर गुजरता है, जिसके कारण यह ट्रैफ़िक ख़त्म हो जाता है
• ख़राब टोपोलॉजी स्केलेबिलिटी

डिज़ाइन की गुणवत्ता का आकलन करने के लिए मानदंड

जब हम इष्टतमता/गैर-इष्टतमता के बारे में बात करते हैं, तो हमें यह समझना चाहिए कि हम इसका मूल्यांकन किन मानदंडों के आधार पर कर सकते हैं। यहां, मेरे दृष्टिकोण से, सबसे महत्वपूर्ण (लेकिन सभी नहीं) मानदंड (और रूटिंग प्रोटोकॉल के संबंध में स्पष्टीकरण) हैं:

• scalability
  उदाहरण के लिए, आप एक अन्य डेटा सेंटर जोड़ने का निर्णय लेते हैं। आप इसे कितना आसान कर सकते हैं?
• उपयोग में आसानी (प्रबंधनीयता)
  नए ग्रिड या फ़िल्टरिंग मार्गों की घोषणा जैसे परिचालन परिवर्तन कितने आसान और सुरक्षित हैं?
• उपलब्धता
  आपका सिस्टम कितने प्रतिशत समय में आवश्यक स्तर की सेवा प्रदान करता है?
• सुरक्षा
  प्रेषित डेटा कितना सुरक्षित है?
• कीमत

परिवर्तन

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

• इस समस्या को कितनी आसानी से ठीक किया जा सकता है
• वह कितना जोखिम उठाती है?

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

इस स्तर पर पूर्णतावाद हानिकारक हो सकता है। डिज़ाइन को संतोषजनक स्थिति में लाएँ और तदनुसार नेटवर्क कॉन्फ़िगरेशन को सिंक्रनाइज़ करें।

स्रोत: www.habr.com