तुम्ही सत्र वर येताना पाहू शकता, मार्ग दिसू शकतो, आणि तरीही चुकीची सेवा वाचत असू शकता. प्रत्येक घोषणेच्या सुरुवातीची संख्यांची जोडी, पत्ता कुटुंब ओळखकर्ता आणि पुढील पत्ता कुटुंब ओळखकर्ता, कोणता पार्सर पेलोड वाचतो आणि कोणता तक्ता निकाल ठेवतो हे ठरवते. जोडी चुकली तर आयात धोरण, मार्ग-लक्ष्य जुळणी आणि पुढील हॉपचा शोध हे सर्व अशा रचनेविरुद्ध चालतात जी कोणीही घोषित केली नाही. खालील प्रवास त्या जोडीपासून सुरू होतो आणि अग्रेषण निकालावर संपतो.

मार्ग कोणत्या तक्त्यात आहे हे दोन संख्या ठरवतात

जोडी दोन वेळा दिसते: बहुप्रोटोकॉल क्षमतेच्या आत, जिथे वक्ता कुटुंब घोषित करतो, आणि त्या कुटुंबाने वाहून नेलेल्या प्रत्येक NLRIच्या समोर. यामुळे ती मूळ बॉक्सवरील सेटिंग नसून मार्गाचा गुणधर्म बनते. उत्पादक ती Address family VPNv4 Unicast सारख्या नावाने छापतात, आणि संख्या जागच्या जागी राहताना शब्दरचना आवृत्त्यांमध्ये बदलते.

Where you meet itFamily pairBoundary of what it proves
VPNv4 unicast capability on a neighbour1 / 128the peer will signal labelled VPN-IPv4, nothing about import
VPNv6 unicast capability on a neighbour2 / 128the peer will signal VPN-IPv6, silent about the transport below
VPLS NLRI with a VE ID and a label base25 / 65a pseudowire is signalled, not that a bridge learned a MAC
EVPN MAC/IP advertisement route25 / 70a 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

बोलणी प्रत्येक पीअरसाठी छापल्या जाणाऱ्या क्षमता देवाणघेवाणीत दिसते, आणि कोणतेही कुटुंब सूचीबद्ध नसलेले प्रस्थापित सत्र तुम्ही मागितलेल्यापैकी काहीही वाहत नाही. आयात विस्तारित समुदाय म्हणून वाहिल्या जाणाऱ्या मार्ग लक्ष्यांकडून ठरते, त्यामुळे बरोबर जोडी चुकीच्या टाइप केलेल्या लक्ष्यासह तक्ता रिकामा ठेवते. नंतर स्थापना स्वीकारणाऱ्या संदर्भात पुढील हॉपच्या निराकरणावर अवलंबून असते, जे प्रत्येक घोषणा परिपूर्ण दिसत असतानाही अयशस्वी होऊ शकते.

डेटा प्लेन सर्वात शेवटी पुष्टी करा, कारण तक्त्यातील मार्ग हा दावा आहे, वितरण नाही. त्या चार अवस्था प्रत्येक कुटुंबाला लागू आहेत; फक्त आज्ञा आणि तक्त्यांची नावे बदलतात.

कुटुंब-जोडी कधीही काय सिद्ध करत नाही

जोडी बरोबर वाचल्याने तुम्हाला पुढील मार्ग माहितीचा अर्थ कसा लावायचा ते कळते, आणि हाच संपूर्ण दावा आहे. ती पोहोच, धोरण किंवा डेटा प्लेनच्या आरोग्याबद्दल काहीही सांगत नाही. दोन्ही मिसळल्याने कोणीही पडताळणी न केलेल्या नेटवर्कबद्दल आत्मविश्वासू विधाने तयार होतात. मार्ग-लक्ष्य विसंगती आणि तुटलेला पुढील हॉप फक्त जोडीवरून सारखेच दिसतात. जोडी ही वाचन सूचना आहे, कधीही निवाडा नाही.

एस्कलेट करताना जोडी, मार्ग लक्ष्य आणि निराकरण झालेला पुढील हॉप एकाच टिपेत ठेवा. मग पुढील अभियंत्याकडे सेवेचे नाव पुन्हा अर्थ लावण्याऐवजी तपासण्यासाठी तीन स्वतंत्र गोष्टी असतात. बोलणी नसेल तर त्यांना लगेच दिसते, चुकीचे लक्ष्य आयात स्पष्टपणे गैरहजर ठेवते, आणि निराकरण न झालेला पुढील हॉप मार्ग उपस्थित पण निरुपयोगी ठेवतो.

संबंधित लेख