💎 🕵🏻 🍅 NETCONF। शुरुआत 👨🏾‍🏫 🏂🏻 🤵🏾

कुछ ने सुना है, और कुछ यह भी सुनिश्चित करते हैं, कि " सरल नेटवर्क प्रबंधन प्रोटोकॉल " है, जिसे एसएनएमपी (सरल नेटवर्क प्रबंधन प्रोटोकॉल) के रूप में जाना जाता है।
लेकिन मैं लगभग कभी ऐसे लोगों से नहीं मिला जो NETCONF के बारे में जानते थे, जो कि इसके रचनाकारों को उम्मीद है, SNMP के लिए एक प्रतिस्थापन बन जाएगा।

वह क्या पसंद है? यह SNMP का एक एनालॉग है? क्या यह प्रबंधन का विकास है? या यह एक मृत अंत शाखा है?

संक्षेप में NETCONF के बारे में

तो, NETCONF नेटवर्क कॉन्फ़िगरेशन प्रोटोकॉल है (हाँ, कोई शब्द "सरल" नहीं है, जाहिर है यह उसकी समस्या है)। इसे IETF NETCONF वर्किंग ग्रुप द्वारा विकसित किया जा रहा है। उनका "जीवन" RFC 4741 के साथ दिसंबर 2006 में शुरू हुआ, और जून 2011 में, RFC 6241 को रोलआउट किया गया।
यह कंपनी जुनिपर के धनुष से आया है, और अधिक सटीक रूप से एक डब फाइल फ़ाइल जूनोस एक्सएमएल एपीआई है।

एसएनएमपी खराब क्यों है?

और वास्तव में, NETCONF को फिर से क्यों बढ़ाया जाए? आखिरकार, SNMP अभी भी काफी "ताज़ा" प्रोटोकॉल है, जो 80 के दशक के अंत में (1988 में SNMPv1) में दिखाई दिया था। तुलना के लिए: टेलनेट को 1969 में विकसित किया गया था, और अब भी इसका उपयोग किया जाता है। वे भी SNMPv3 के साथ एन्क्रिप्शन के साथ आए थे।

और फिर भी, 2002 में इंटरनेट आर्किटेक्चर बोर्ड (IAB) नेटवर्क प्रबंधन कार्यशाला की एक बैठक हुई, जिसके परिणामस्वरूप RFC 3535 था । विशेष रूप से, यह नेटवर्क प्रबंधन प्रौद्योगिकियों (पैराग्राफ 2) के पेशेवरों और विपक्षों को रेखांकित करता है, जिसमें शामिल हैं एसएनएमपी (खंड 2.1)।

मैं अपनी राय में SNMP के नुकसानों में से कुछ को स्पष्ट करूंगा:

अधिकांश कार्यान्वयन परिवहन प्रोटोकॉल के रूप में यूडीपी का उपयोग करते हैं। अगर रास्ते में कुछ खो गया है, तो आप क्या कर सकते हैं।
एक समय में केवल एक विशिष्ट मूल्य लिखा / पढ़ा जा सकता है। आप एक ही लेन-देन में कई मान नहीं भेज सकते हैं।
कॉन्फ़िगरेशन रोलबैक / बैकअप की कोई संभावना नहीं है: स्नैम्प सेट सक्रिय कॉन्फ़िगरेशन में तुरंत परिवर्तन करता है।
एसएमआई में प्रतिबंध (उदाहरण के लिए, कुछ क्षेत्रों की लंबाई)।
MIB चिड़ियाघर में एक विक्रेता भी है, यहां तक कि एक प्रकार के उपकरण में भी, उदाहरण के लिए, स्विच।
पुराने एमआईबी में नई सुविधाओं का समर्थन करने में देरी हुई है। उदाहरण के लिए, CISCO-BGP-MIB, जहां तक मुझे पता है, अभी भी IPv6 के बारे में नहीं पता है।

NETCONF की तैयारी

मेरी राय में, प्रोटोकॉल बहुत सरल है, और RFC बहुत अच्छी तरह से लिखा गया है।

वैचारिक रूप से, NETCONF इस तरह दिखता है:

मैंने यहां की तस्वीर ली।

वर्तमान में, 4 विकल्प परिवहन के रूप में परिभाषित किए गए हैं:

SSH
सोप
बीप
टीएलएस

एक्सएमएल में दर्शाए गए आरपीसी अनुरोधों में संचालन "लिपटे" हैं।

निम्नलिखित बुनियादी कार्यों को परिभाषित किया गया है:

< get > , < get-config > , < edit-config > , < copy-config > , < delete-config > , < lock > , < unlock > , < close-session > , < kill-session > .

क्लाइंट-सर्वर प्रोटोकॉल मॉडल का उपयोग किया जाता है। जब तक आप चाहें तब तक एक स्थापित सत्र आयोजित किया जा सकता है (जब तक कि कनेक्टिविटी है और सर्वर अभी भी जीवित है)।

जब कोई कनेक्शन स्थापित होता है, तो क्लाइंट और सर्वर समर्थित पैरामीटर (RPC सूचनाओं का उपयोग करके) का आदान-प्रदान करते हैं।

हम क्या कर सकते हैं? और हम कर सकते हैं, उदाहरण के लिए:

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

मुझे लगता है कि NETCONF के साथ काम करने का सबसे आसान तरीका एक उदाहरण के रूप में है।

जुनिपर पर NETCONF उदाहरण

NETCONF चालू करें:

सिस्टम सेवाएं सेट करें netconf ssh

और कनेक्ट करने का प्रयास करें:

ssh उपयोगकर्ता नाम @ होस्ट -s netconf

पासवर्ड दर्ज करने (या कुंजी की जांच करने के बाद) हमें "सर्वर" से हैलो मिलता है:

< hello > < capabilities > < capability > urn:ietf:params:xml:ns:netconf:base:1.0 </ capability > < capability > urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 </ capability > < capability > urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 </ capability > < capability > urn:ietf:params:xml:ns:netconf:capability:validate:1.0 </ capability > < capability > urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file </ capability > < capability > xml.juniper.net/netconf/junos/1.0 </ capability > < capability > xml.juniper.net/dmi/system/1.0 </ capability > </ capabilities > < session-id > 666 </ session-id > </ hello > ]] > ]] > * This source code was highlighted with Source Code Highlighter .

सर्वर ने हमें इसकी क्षमताओं की एक सूची के साथ सूचित किया।
लाश के बारे में - यह एक मजाक है, यह जूनो में कभी-कभी होता है। उदाहरण के लिए, हाइकु दिखाने वाला एक छिपा हुआ आदेश भी है:

संस्करण और हाइकू दिखाएं

हैलो के जवाब में, ग्राहक को अपनी क्षमताओं की सूची के साथ अपने हैलो का जवाब देना चाहिए, उदाहरण के लिए, वही:

< hello > < capabilities > < capability > urn:ietf:params:xml:ns:netconf:base:1.0 </ capability > < capability > urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 </ capability > < capability > urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 </ capability > < capability > urn:ietf:params:xml:ns:netconf:capability:validate:1.0 </ capability > < capability > urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file </ capability > < capability > xml.juniper.net/netconf/junos/1.0 </ capability > < capability > xml.juniper.net/dmi/system/1.0 </ capability > </ capabilities > </ hello > ]] > ]] > * This source code was highlighted with Source Code Highlighter .

वह सब है। अब आप सर्वर के साथ काम कर सकते हैं। उदाहरण के लिए, वर्तमान कॉन्फ़िगरेशन का हिस्सा पूछें:

< rpc message-id ="100" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" > < get-config > < source > < running /> </ source > < filter type ="subtree" > < configuration > < protocols /> </ configuration > </ filter > </ get-config > </ rpc > * This source code was highlighted with Source Code Highlighter .

हमें क्या जवाब मिलेगा:

< rpc-reply message-id ="100" xmlns:junos ="http://xml.juniper.net/junos/11.2R5/junos" > < configuration junos:commit-seconds ="1311003260" junos:commit-localtime ="2012-06-06 11:21:40 UTC" junos:commit-user ="test" > < protocols > SKIPPED </ protocols > </ configuration > </ rpc-reply > * This source code was highlighted with Source Code Highlighter .

संदेश-आईडी = "100" अनुरोध में निर्दिष्ट प्रतिक्रिया में भी संग्रहीत है। इस प्रकार आप विभिन्न उत्तरों के बीच अंतर कर सकते हैं जो एक अलग क्रम में प्राप्त हो सकते हैं।

आरपीसी-रिप्लाई के अलावा, क्लाइंट से रिक्वेस्ट को प्रोसेस करते समय कोई त्रुटि होने पर आप आरपीसी-एरर पकड़ सकते हैं। RFC से उदाहरण:

< rpc-reply message-id ="110" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" > < rpc-error > < error-type > rpc </ error-type > < error-tag > missing-attribute </ error-tag > < error-severity > error </ error-severity > < error-info > < bad-attribute > message-id </ bad-attribute > < bad-element > rpc </ bad-element > </ error-info > </ rpc-error > </ rpc-reply > * This source code was highlighted with Source Code Highlighter .

सफलतापूर्वक निष्पादित अनुरोध के मामले में, जिसमें आउटपुट की आवश्यकता नहीं होती है (उदाहरण के लिए, एक कमांड), सर्वर उदाहरण के लिए ओके के साथ प्रतिक्रिया करता है:

< rpc-reply message-id ="201" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" > < ok /> </ rpc-reply > * This source code was highlighted with Source Code Highlighter .

काम खत्म करने के लिए, हमें सत्र बंद करना होगा:

< rpc message-id ="100500" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" > < close-session /> </ rpc > * This source code was highlighted with Source Code Highlighter .

NETCONF कहाँ काम करता है?

यह अफवाह है कि उपकरणों पर जुनिपर, ब्रोकेड, सिस्को, हुआवेई और कुछ अन्य।

... लेकिन

इतना ठीक नहीं है। NETCONF द्वारा अच्छी तरह से प्रलेखित और अनुरक्षित मैंने केवल जुनिपर पर देखा है। दुर्भाग्य से, मैंने इसे हुआवेई पर परीक्षण नहीं किया, क्योंकि कोई ज़रूरत नहीं थी, और ब्रोकेड के मामले में कोई प्रायोगिक विषय नहीं थे। लेकिन सिस्को ...

कम से कम iOS संस्करण 15 तक उत्प्रेरक लाइन पर NETCONF के संचालन के बारे में:

अनुरोधों के उत्तर बहुत अधिक सीपीयू को खा जाते हैं। XML फॉर्मेटिंग के साथ रनिंग-कॉन्फिगरेशन, सीपीयू के 100% पर लोड होने पर आप 5 मिनट इंतजार कर सकते हैं।
RFC (sic!) का उपयोग करके स्थितियां लागू नहीं की जाती हैं: उदाहरण के लिए, "इंट स्टेटस दिखाएं" के जवाब में, सिस्को हमेशा पूर्ण रनिंग-कॉन्फ़िगरेशन जोड़ता है।
कोई XML स्कीमा नहीं हैं और कभी-कभी आउटपुट अजीब रूप से क्लिप हो जाता है। उदाहरण के लिए, सिस्को इस तरह से "sh run int vlan777" अनुरोध का जवाब देता है:
<? xml version ="1.0" encoding ="UTF-8" ? >< rpc-reply message-id ="101" xmlns =" urn:ietf:params:netconf:base:1 . 0 &# 60 ;/ cmd > a >< cli-config-data >< cmd > ! </ cmd > nterface Vlan777 </ cmd > description TEST </ cmd > ip address 192.168.0.1 255.255.255.0 </ cmd ></ cli-config-data ></ data ></ rpc-reply > ]] > ]] > * This source code was highlighted with Source Code Highlighter .

शब्द "इंटरफ़ेस" में पहला अक्षर कहीं गायब हो गया।

मेरी राय में, सिस्को कार्यान्वयन काम के लिए दिखाने के लिए अधिक है।

निष्कर्ष

मैं संक्षेप में NETCONF के बारे में बात करना चाहता था, क्योंकि होबे पर भी उसका उल्लेख नहीं मिला।
मुझे लगता है कि प्रोटोकॉल जीवन जीने और लाभ देने में काफी सक्षम है।
मैं टिप्पणियों में अन्य राय भी सुनना चाहूंगा, विशेष रूप से विभिन्न उपकरणों के साथ दिलचस्प प्रदर्शन।

NETCONF। शुरुआत