AFI और SAFI: सेवा के नाम से पहले जोड़ी पढ़ें
AFI 25 के साथ SAFI 65 वही सेवा नहीं है जो AFI 25 के साथ SAFI 70 है। जोड़ी पढ़ें, फिर परिवार विनिमय, मार्ग और अग्रेषण परिणाम जाँचें।
आप एक सत्र को उठते देख सकते हैं, एक मार्ग को प्रकट होते देख सकते हैं, और फिर भी गलत सेवा पढ़ रहे हों। हर घोषणा के आरंभ में संख्याओं की जोड़ी, पता परिवार पहचानकर्ता और अगला पता परिवार पहचानकर्ता, तय करती है कि कौन सा पार्सर पेलोड पढ़ेगा और कौन सी तालिका परिणाम रखेगी। जोड़ी गलत हुई तो आयात नीति, मार्ग-लक्ष्य मिलान और अगले हॉप की खोज सब ऐसी संरचना के विरुद्ध चलती हैं जिसे किसी ने घोषित नहीं किया। नीचे की यात्रा उसी जोड़ी से शुरू होती है और अग्रेषण परिणाम पर समाप्त होती है।
दो संख्याएँ तय करती हैं कि मार्ग किस तालिका में है
जोड़ी दो बार दिखती है: बहुप्रोटोकॉल क्षमता के भीतर, जहाँ वक्ता परिवार की घोषणा करता है, और उस परिवार द्वारा ले जाए गए हर NLRI के सामने। इससे यह मूल बॉक्स की सेटिंग नहीं, बल्कि मार्ग का गुण बन जाती है। निर्माता इसे Address family VPNv4 Unicast जैसे नाम के रूप में छापते हैं, और संख्याएँ यथावत रहती हैं जबकि शब्दावली संस्करणों के बीच बदलती है।
| Where you meet it | Family pair | Boundary of what it proves |
|---|---|---|
| VPNv4 unicast capability on a neighbour | 1 / 128 | the peer will signal labelled VPN-IPv4, nothing about import |
| VPNv6 unicast capability on a neighbour | 2 / 128 | the peer will signal VPN-IPv6, silent about the transport below |
| VPLS NLRI with a VE ID and a label base | 25 / 65 | a pseudowire is signalled, not that a bridge learned a MAC |
| EVPN MAC/IP advertisement route | 25 / 70 | a binding is advertised, not that the host answers |
चार एन्कोडिंग लगभग हर उद्यम मामले को कवर करती हैं: MPLS-लेबल वाले VPN-IPv4 के लिए 1 के साथ 128, IPv6 समकक्ष के लिए 2 के साथ 128, BGP-संकेतित VPLS के लिए 25 के साथ 65, और EVPN के लिए 25 के साथ 70। पहली गलती यह मानना है कि हर Layer 2 सेवा 25 के साथ 65 के पीछे है, जो EVPN को छिपाता है। दूसरी यह है कि दो IP परिवारों को लंबे पते वाला एक परिवार मान लिया जाए, जबकि उन पर अलग-अलग बातचीत होती है और वे अलग-अलग पीयर पर स्वीकार किए जा सकते हैं। तीसरी तब प्रकट होती है जब किसी ऐसे संस्करण से टेम्पलेट कॉपी किया जाए जो केवल एक को जानता है। रजिस्ट्री में देखना सेवा के नाम पर बनी अनुमान से तीनों को तेज़ी से सुलझाता है।
चार पंक्तियों को IANA रजिस्ट्री के उदाहरण मानें, स्वयं रजिस्ट्री नहीं। जब कोई संख्या किसी ज्ञात चीज़ से मेल न खाए, तो उसके चारों ओर नीति बनाने से पहले उसे देखें।
AFI 25 दो असंबद्ध NLRI प्रारूप ले जाता है
दोनों Layer 2 परिवार AFI 25 के अंतर्गत बैठते हैं, और समानता वहीं समाप्त होती है। RFC 4761 section 3.2.2 में VPLS NLRI लंबाई, मार्ग विभेदक, VE ID, VE ब्लॉक ऑफ़सेट, VE ब्लॉक आकार और लेबल आधार ले जाता है, जो मिलकर pseudowire अंत बिंदु और उसके लेबल का नाम देते हैं। EVPN AFI 25 रखता है और SAFI 70 पर जाता है, जहाँ पेलोड मार्ग प्रकार है: ईथरनेट स्वतः खोज, MAC/IP घोषणा, समावेशी मल्टीकास्ट, ईथरनेट खंड, IP उपसर्ग। इसलिए वही बाइट ऑफ़सेट दोनों परिवारों में अलग अर्थ रखता है। एक के लिए लिखा पार्सर दूसरे को बिना शिकायत पढ़ता है और बकवास उत्पन्न करता है। जोड़ी ही एकमात्र चेतावनी है कि व्याख्या गलत है।
एक परिवार में VE ब्लॉक ऑफ़सेट का अर्थ रखने वाले क्षेत्र का दूसरे में कोई समकक्ष नहीं है, और MAC/IP घोषणा मार्ग केवल EVPN में मौजूद है। किसी विशेषता को ऐसे उद्धृत करना जैसे वह दोनों पर लागू हो, कैप्चर समीक्षा के बिगड़ने का तरीका है।
जब कोई आपको कैप्चर या विक्रेता की तालिका दे, तो पूछें कि विशेषता किस परिवार की है। फिर पुष्टि करें कि प्राप्त करने वाला कार्यान्वयन उस परिवार का समर्थन करता है, डेटाशीट पर दिए सेवा नाम का नहीं। दो प्लेटफ़ॉर्म VPLS समर्थन का दावा कर सकते हैं जबकि वे अलग सिग्नलिंग परिवार लागू करते हों। जोड़ी उन्हें अलग करती है; उत्पाद लेबल नहीं।
सत्र का अपना पता परिवार अलग प्रश्न है
VPN-IPv6 नियमित रूप से ऐसे सत्र पर घोषित होता है जिसका TCP कनेक्शन IPv4 पर चलता है, और यह समर्थित डिज़ाइन है, दोष नहीं। इसलिए केवल सत्र सारांश पढ़ना यह नहीं बताता कि पीयर किन VPN परिवारों का विनिमय करते हैं।
NLRI परिवार, परिवहन परिवार और अग्रेषण परिवार तीन स्वतंत्र निर्णय हैं। एक राउटर अपने पीयर से IPv4 बोल सकता है, VPN-IPv6 की पहुँच स्वीकार कर सकता है, और ऐसा मार्ग स्थापित कर सकता है जिसका अगला हॉप वह IPv6 पता है जो आपके इरादे से भिन्न मार्ग से पहुँच योग्य है। हर परत को अपनी पुष्टि चाहिए। जो साइटें घोषणाएँ सही दिखते हुए भी IPv6 गंतव्यों तक न पहुँचने की सूचना देती हैं, उन्होंने आमतौर पर अगले हॉप का समाधान खो दिया है, परिवार वार्ता नहीं।
सत्र के पता परिवार को अलग जाँचें, फिर जिन परिवारों को वह ले जाता है, फिर जो कोर अग्रेषित कर सकता है। तीनों को अलग रखना उस सामान्य गलत निदान को रोकता है जिसमें सही घोषणा को इस प्रमाण के रूप में पढ़ा जाता है कि IPv6 छोर से छोर तक काम करता है। यह केवल यह सिद्ध करती है कि एक पीयर ने दूसरे को उपसर्ग के बारे में बताया।
बातचीत हुई, प्राप्त हुआ, आयात हुआ, स्थापित हुआ
एक अपेक्षित मार्ग के लिए चार स्थितियाँ क्रम में होनी चाहिए, और हर एक प्रेक्षणीय है। परिवार पर उस पीयर के साथ बातचीत होनी चाहिए, मार्ग पहुँचना चाहिए, कोई मार्ग लक्ष्य उसे इच्छित संदर्भ में आयात करना चाहिए, और अगले हॉप का समाधान होना चाहिए ताकि मार्ग स्थापित हो। पहली स्थिति छोड़ने से बाकी तीन अनुत्तरित हो जाती हैं, क्योंकि बिना बातचीत वाला परिवार निरीक्षण के लिए कोई मार्ग उत्पन्न नहीं करता। Cisco शैली के प्लेटफ़ॉर्म पर परिवार सारांश और प्रति-पीयर क्षमताएँ अलग कमांड हैं।
show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address familyबातचीत प्रति पीयर छपे क्षमता विनिमय में दिखती है, और कोई परिवार सूचीबद्ध न होने वाला स्थापित सत्र आपके माँगे में से कुछ नहीं ले जाता। आयात का निर्णय विस्तारित समुदायों के रूप में ले जाए गए मार्ग लक्ष्यों से होता है, इसलिए सही जोड़ी गलत टाइप किए लक्ष्य के साथ तालिका खाली छोड़ देती है। फिर स्थापन इस पर निर्भर है कि अगले हॉप का समाधान प्राप्तकर्ता संदर्भ में हो, जो हर घोषणा के सही दिखते हुए भी विफल हो सकता है।
डेटा प्लेन की पुष्टि अंत में करें, क्योंकि तालिका में मार्ग एक दावा है, वितरण नहीं। वही चार स्थितियाँ हर परिवार पर लागू हैं; केवल कमांड और तालिका नाम बदलते हैं।
परिवार-जोड़ी कभी क्या सिद्ध नहीं करती
जोड़ी को सही पढ़ना आपको बताता है कि उसके बाद आने वाली रूटिंग जानकारी को कैसे समझें, और यही पूरा दावा है। यह पहुँच, नीति या डेटा प्लेन के स्वास्थ्य के बारे में कुछ नहीं कहता। दोनों को मिलाने से ऐसे नेटवर्क के बारे में आत्मविश्वासी कथन बनते हैं जिसे किसी ने सत्यापित नहीं किया। मार्ग-लक्ष्य बेमेल और टूटा अगला हॉप केवल जोड़ी से एक जैसे दिखते हैं। जोड़ी पढ़ने का निर्देश है, कभी फैसला नहीं।
जब आप एस्केलेट करें, तो जोड़ी, मार्ग लक्ष्य और हल हुआ अगला हॉप एक ही नोट में रखें। तब अगले इंजीनियर के पास फिर से व्याख्या करने के लिए सेवा-नाम के बजाय परखने को तीन स्वतंत्र चीज़ें होती हैं। यदि बातचीत नहीं है तो वे तुरंत देखते हैं, गलत लक्ष्य आयात को स्पष्ट रूप से अनुपस्थित छोड़ देता है, और अनसुलझा अगला हॉप मार्ग को मौजूद पर अनुपयोगी छोड़ देता है।