MPLS VPN में RD बनाम RT: विशिष्टता बनाम आयात नीति

दो ग्राहक साइटें 10.20.0.0/24 की घोषणा कर सकती हैं और दोनों एक ही प्रदाता नेटवर्क के अंदर मान्य रहती हैं। रूट डिस्टिंग्विशर उन घोषणाओं को अलग रखता है; रूट टारगेट तय करता है कि कौन-सी ग्राहक VRF उसकी एक प्रति ले सकती है। कॉन्फ़िगरेशन में ये एक-दूसरे के बगल में दिखते हैं और बिल्कुल अलग काम करते हैं। दोनों को आपस में मिला देना ऐसे बदलावों की ओर ले जाता है जो उचित दिखते हैं और कुछ ठीक नहीं करते।

ग्राहक किनारे से दूरस्थ VRF तक एक रूट का अनुसरण करें और विभाजन ठोस हो जाता है: पहचान रूट के BGP में प्रवेश करने से पहले जोड़ी जाती है, और वितरण नीति का मूल्यांकन तब होता है जब रूट प्राप्त करने वाले प्रदाता किनारे तक पहुँचता है।

VPN-IPv4 रूट एक RD और एक IPv4 प्रीफ़िक्स है

RFC 4364 VPN-IPv4 पता परिवार को आठ बाइट का रूट डिस्टिंग्विशर और उसके बाद चार बाइट का IPv4 पता के रूप में परिभाषित करता है। RD ग्राहक प्रीफ़िक्स के आगे जोड़ा जाता है, इसलिए अलग-अलग साइटों से आने वाले दो समान प्रीफ़िक्स दो अलग BGP रूट बन जाते हैं।

यही रचना पूरी विशिष्टता-व्यवस्था है। प्रदाता को इसकी आवश्यकता नहीं कि ग्राहक गैर-अतिव्यापी पता स्थान पर सहमत हों, और एक साइट का रूट दूसरी साइट के समान प्रीफ़िक्स को चुपचाप नहीं बदल सकता।

RD का स्वरूप ही प्रशासक द्वारा चुना गया मान है, सामान्यतः एक स्वायत्त सिस्टम संख्या और एक स्थानीय संख्या। उसका संख्यात्मक आकार एक परिपाटी है, यह संकेत नहीं कि दोनों फ़ील्ड उस रूट टारगेट के साथ अर्थ साझा करते हैं जो संयोगवश वही अंक उपयोग करता है।

RD अतिव्यापी प्रीफ़िक्स को अलग-अलग पहचानने योग्य बनाता है

एक ही प्रीफ़िक्स के दो विज्ञापन लें। साइट A पर RD 65000:101 है और साइट B पर RD 65000:202 है, दोनों 10.20.0.0/24 के लिए। अब BGP के पास दो VPN-IPv4 रूट हैं जिनकी स्वतंत्र रूप से तुलना, छँटाई और चयन किया जा सकता है।

RD यह नहीं बताता कि किस VRF को इनमें से कोई रूट मिलना चाहिए, और यह किसी ग्राहक या सेवा की पहचान नहीं करता। यह रूट के लिए पहचान फ़ील्ड है, सदस्यता सूची नहीं। किसी VRF का अपना RD उस रूट के RD से मेल खाने के लिए बाध्य नहीं है जिसे वह आयात करता है।

इसीलिए किसी RD को दूसरी साइट की संख्या से मिलाने के लिए बदलना कुछ ठीक नहीं करता। यदि दूसरी ओर रूट गायब है, तो अंकों का मेल आयात निर्णय सुधारने के बजाय एक अलग पहचान समस्या पैदा करता है।

RT एक BGP विशेषता है, पैकेट का टैग नहीं

निर्यात नीति एक या अधिक रूट टारगेट को BGP विस्तारित समुदाय विशेषताओं के रूप में रूट से जोड़ती है। प्राप्त करने वाला प्रदाता किनारा उन विशेषताओं की तुलना हर VRF की आयात नीति से करता है। RT नियंत्रण तल से होकर रूट के साथ यात्रा करता है। यह तुलना पूरी तरह रूटिंग नीति में होती है, किसी भी ग्राहक पैकेट के अग्रेषित होने से पहले।

ग्राहक के डेटा पैकेट RT नहीं ले जाते। किसी रूट के VRF में स्थापित होने के बाद, अग्रेषण उस VRF की तालिका और उस MPLS लेबल ढेर का उपयोग करता है जो संरचना निर्धारित करती है। प्रदाता किनारा हर ग्राहक पैकेट से रूट टारगेट नहीं पढ़ता।

एक रूट कई RT ले जा सकता है, और एक VRF कई आयात कर सकता है। कॉन्फ़िगरेशन अक्सर एक छोटे ब्लॉक जैसा दिखता है:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

उस ब्लॉक को दो अलग कथनों के रूप में पढ़ें। निर्यात पंक्ति तय करती है कि इस VRF से निकलने वाले रूट से क्या जोड़ा जाता है; आयात पंक्ति तय करती है कि यह VRF क्या विचार करने को तैयार है। संख्याओं का मेल सुविधाजनक है, अनिवार्य नहीं।

आयात पात्रता स्थापना नहीं है

एक रूट किसी VRF के लिए पात्र हो सकता है और फिर भी उसकी अग्रेषण तालिका में न दिखे। पात्रता एक फ़िल्टर है; उसके बाद BGP की सामान्य निर्णय प्रक्रिया पात्र रूटों की तुलना करके एक चुनती है। पुराना या कम पसंदीदा रूट किसी अन्य पात्र पथ से हार सकता है।

चयनित रूट की जाँच करें, केवल आयात नीति की नहीं। जो VRF RT 65000:500 आयात करता है और 10.20.0.0/24 के लिए कोई रूट नहीं दिखाता, उसने रूट प्राप्त करके चयन के दौरान अस्वीकार किया हो सकता है, या उसे कभी प्राप्त ही न हुआ हो।

यह अंतर तब भी मायने रखता है जब कोई अप्रत्याशित प्रीफ़िक्स प्रकट होता है। बहुत व्यापक आयात नीति ऐसे रूट खींच सकती है जिन्हें साइट उपयोग नहीं करना चाहती थी, और RD की विशिष्टता उसे रोकती नहीं है। वितरण का दायरा RT नीति का प्रश्न है।

नियंत्रण तल के क्रम में गायब रूट को डीबग करें

घोषणा से शुरू करें: क्या स्रोत VRF इच्छित RT निर्यात करता है, और क्या रूट रूट रिफ़्लेक्टर या प्राप्त करने वाले PE पर VPN-IPv4 रूट के रूप में मौजूद है? फिर विशेषता की जाँच वैसे करें जैसे वह प्राप्त हुई, न कि जैसे वह प्रेषक पर कॉन्फ़िगर है।

इसके बाद प्राप्त करने वाले VRF की आयात सूची की तुलना रूट के वास्तविक RT मानों से करें। अंत में उस VRF में चयनित रूट और लेबल बंधन की जाँच करें। हर चरण अलग प्रश्न का उत्तर देता है, और RD की ओर कूदना आमतौर पर वही चरण छोड़ देता है जो गलत है।

कार्यशील और विफल साइट के लिए RD, निर्यात किया गया RT, आयात किया गया RT और चयनित अगला हॉप दर्ज करें। चार मान साथ-साथ एक अस्पष्ट “VPN रूट नहीं भेज रहा” को उस सटीक नियंत्रण तल चरण में बदल देते हैं जो अलग है।