Junos L2VPN: पहिले ग्राहकको संलग्नता करार सही बनाउनुहोस्

कुनै pseudowire छुनुअघि एउटा ग्राहक फ्रेमलाई PE भित्रसम्म पछ्याउनुहोस् र त्यो कहाँ अवतरण गर्नुपर्ने हो हेर्नुहोस्। भौतिक पोर्टले त्यसलाई एउटा तार्किक एकाइमा वर्गीकृत गर्छ, त्यो एकाइले इन्क्याप्सुलेसन बोक्छ, र एकाइ कुनै सेवासँग बाँधिएको हुन्छ। तीन छुट्टै निर्णय, गल्ती गर्ने तीन छुट्टै बाटो। सिग्नलिङ खराबी भनेर माथि पठाइएका अधिकांश घटना वास्तवमा त्यस्तो एकाइमा वर्गीकृत फ्रेम हुन् जुन कसैले त्यो सेवाका लागि कन्फिगर गरेको थिएन। त्यसैले संलग्नताबाट सुरु गर्नुहोस् र बाहिरतिर जानुहोस्।

फ्रेम करार लेख्नुहोस्

कुनै पनि कन्फिगरेसन छान्नुअघि करार अभिलेख गर्नुहोस्: ट्याग नभएको, एउटा सेवा ट्याग, वा स्ट्याक। ग्राहकले पठाउने MTU र प्रत्येक दिशामा अपेक्षित ट्याग व्यवहार थप्नुहोस्, किनकि यी वार्ताबाट तय गरिएका गुण हुन्, स्थानीय रुचि होइन। एकाइ नम्बर केवल पहिचानकर्ता हो र इन्टरफेसले कुन फ्रेम स्वीकार्ने भन्ने केही बताउँदैन।

यो सेवा टिप्पणीमा लेख्नुहोस्, टिकटको टिप्पणीमा होइन। छ महिनापछि यसलाई डिबग गर्ने व्यक्तिले टिप्पणी पढ्नेछ। टिकट उसले पढ्ने छैन।

इन्क्याप्सुलेसनलाई करारसँग मिलाउनुहोस्

एउटा ट्याग भएको सेवाले सामान्यतया VLAN सर्किट इन्क्याप्सुलेसन प्रयोग गर्छ, जस्तै vlan-ccc, जबकि ट्याग नभएका फ्रेमलाई साधारण Ethernet सर्किट स्वरूप चाहिन्छ र स्ट्याकलाई दुई ट्याग बुझ्ने विस्तारित स्वरूप चाहिन्छ। प्रति-एकाइ सेवा इन्क्याप्सुलेसन समर्थन गर्ने प्लेटफर्ममा एउटा भौतिक इन्टरफेसले एकैचोटि धेरैलाई राख्न सक्छ, जुन सुविधाजनक छ र फ्रेम गलत एकाइमा पुग्ने बाटो पनि त्यही हो। जहाँ तपाईंको प्लेटफर्मको गाइडले family ccc, यसलाई पूरा संलग्नताको भागका रूपमा कन्फिगर गर्नुहोस्, राउटेड इन्टरफेसमा जोड्नु होइन। इन्क्याप्सुलेसन गाइड ले कुन संलग्नता प्रकारले कुन आवश्यकता लाद्छ सूचीबद्ध गर्छ।

सावधानीका रूपमा हरेक इन्टरफेसमा family वाक्य नथप्नुहोस्। एउटा सर्किट चलाउने कन्फिगरेसनले अर्कोलाई त्यसका ग्राहकले कहिल्यै नपठाउने फ्रेम स्वीकार्न बाध्य पार्न सक्छ।

संलग्नतालाई सही सेवासँग बाँध्नुहोस्

BGP ले सिग्नल गरिएको तह 2 VPN, LDP ले सिग्नल गरिएको सर्किट र अन्य समर्थित सेवाहरूमध्ये प्रत्येकको आफ्नै इन्टरफेस बाइन्डिङ र सिग्नलिङ कन्फिगरेसन छ, र ती एकअर्काका विकल्प होइनन्। एउटाको संलग्नता शैली अर्काको सिग्नलिङसँग मिसाउँदा त्यस्तो सर्किट बन्छ जसले पीयरको रिपोर्ट गर्छ र कहिल्यै फ्रेम बोक्दैन।

टाढाको छेउलाई नजिकको छेउसँग तुलना गर्नुहोस्, कुनै एकलाई अलग देख्नु होइन: पीयर ठेगाना, सेवा पहिचानकर्ता, इन्क्याप्सुलेसन सहमति, control word अपेक्षा र आकार बजेट। तलको MPLS तह पूर्ण रूपमा स्वस्थ हुन सक्छ जबकि संलग्नता हराएको वा अन्तै वर्गीकृत भएको हुन्छ, त्यसैले केवल तल्लो तह हेर्ने परीक्षणले यहाँ केही प्रमाणित गर्दैन।

फ्रेमले प्रमाणित गर्नुहोस्, स्थितिले होइन

ग्राहकले ट्राफिक पठाइरहँदा स्थानीय इन्टरफेसका काउन्टर पढ्नुहोस्, त्यसपछि सेवाको स्थिति, र त्यसपछि आउने फ्रेम त्यही तय भएको फ्रेम हो भनी पुष्टि गर्नुहोस्, त्यसको ट्यागसहित। मर्मत गरिएको संलग्नताले त्यो फ्रेम पुर्याउँछ; स्थिति मात्र बदलिनु केही प्रमाणित गर्दैन।

जहाँ तपाईंलाई क्याप्चर गर्ने अधिकार छ, फ्रेमलाई दुवै दिशामा हेर्नुहोस्। ट्यागको असमानता स्थितिको दृश्यमा छुट्न सजिलो छ र क्याप्चरमा स्पष्ट हुन्छ। यही असमानताले एक दिशामा चल्ने र अर्कोमा असफल हुने गुनासो पनि व्याख्या गर्छ।

त्यसपछि यो लेख्नुहोस्

सेवा टिप्पणीमा चार मान अभिलेख गर्नुहोस्: करार, इन्क्याप्सुलेसन, एकाइ र सेवा बाइन्डिङ। यी चार नै नयाँ इन्जिनियरलाई चाहिने र कन्फिगरेसन समीक्षाले विरलै स्पष्ट भन्ने कुरा हुन्।

सर्किट छ महिनापछि तुट्दा त्यो टिप्पणी पन्ध्र मिनेटको काम र चलिरहेको कन्फिगरेसनबाट पूरै डिजाइन फेरि निकाल्नेबीचको फरक हुनेछ। अन्तिम प्रमाणीकरणको मिति थप्नुहोस्, ताकि टिप्पणीले यो पनि भनोस् कि त्यो कति पुरानो भयो।