तपाईं सत्र उठिरहेको देख्न सक्नुहुन्छ, रुट देखा पर्दै गरेको देख्न सक्नुहुन्छ, र तैपनि गलत सेवा पढिरहनुभएको हुन सक्छ। प्रत्येक घोषणाको सुरुमा रहेको सङ्ख्याको जोडी, ठेगाना परिवार पहिचायक र अर्को ठेगाना परिवार पहिचायकले कुन पार्सरले पेलोड पढ्छ र कुन तालिकाले नतिजा राख्छ भन्ने निर्धारण गर्छ। जोडी गलत भयो भने आयात नीति, रुट-लक्ष्य मिलान र अर्को हपको खोजी सबै कसैले घोषणा नगरेको संरचनाविरुद्ध चल्छन्। तलको यात्रा त्यही जोडीबाट सुरु भई फर्वार्डिङ नतिजामा टुंगिन्छ।

रुट कुन तालिकामा पर्छ भन्ने दुई सङ्ख्याले निर्धारण गर्छन्

जोडी दुई पटक देखिन्छ: बहुप्रोटोकल क्षमताभित्र, जहाँ वक्ताले परिवार घोषणा गर्छ, र त्यो परिवारले बोक्ने हरेक 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

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

डेटा प्लेन सबैभन्दा अन्तमा पुष्टि गर्नुहोस्, किनभने तालिकाको रुट दाबी हो, वितरण होइन। तीही चार अवस्था हरेक परिवारमा लागू हुन्छन्; आदेश र तालिकाका नाम मात्र बदलिन्छन्।

परिवार-जोडीले कहिल्यै के प्रमाणित गर्दैन

जोडी सही पढ्नुले त्यसपछिको रुटिङ जानकारी कसरी व्याख्या गर्ने भन्ने बताउँछ, र त्यो नै सम्पूर्ण दाबी हो। यसले पहुँच, नीति वा डेटा प्लेनको स्वास्थ्यबारे केही भन्दैन। दुवै मिसाउँदा कसैले पनि प्रमाणित नगरेको सञ्जालबारे आत्मविश्वासी भनाइ बन्छ। रुट-लक्ष्य बेमेल र तोडिएको अर्को हप जोडीबाट मात्र हेर्दा उस्तै देखिन्छन्। जोडी पढ्ने निर्देश हो, कहिल्यै फैसला होइन।

एस्केलेट गर्दा जोडी, रुट लक्ष्य र समाधान भएको अर्को हप एउटै टिप्पणीमा राख्नुहोस्। त्यसपछि अर्को इन्जिनियरसँग सेवाको नाम पुनः व्याख्या गर्नुको सट्टा जाँच्न तीन स्वतन्त्र कुरा हुन्छन्। वार्ता छैन भने उनीहरूले तुरुन्तै देख्छन्, गलत लक्ष्यले आयात स्पष्ट रूपमा अनुपस्थित राख्छ, र नसमाधान भएको अर्को हपले रुट उपस्थित तर अप्रयोग्य राख्छ।

सम्बन्धित लेखहरू