CE-இல் உள்ள RIP வழியிலிருந்து தொலை VRF வரை: export எங்கே நடக்கிறது

ஒரு RIPv2 update provider edge-ஐ அடைந்து, VRF routing அட்டவணையில் நுழைந்து, ஏதேனும் அதை வெளிப்படையாக export செய்யாவிட்டால் அங்கேயே நிற்கிறது. மூன்று முடிவுகள் வரிசையாக நடக்கின்றன, ஒவ்வொன்றும் அதன் சொந்த காரணத்திற்காக முன்னொட்டை மறுக்கலாம். அவற்றை ஒரே நிகழ்வாகப் படிப்பதே, தொலை தளம் CE தெளிவாக அறிவிக்கும் ஒரு வலையை அடைய முடியாதபோது மக்கள் தவறான சாதனத்தைத் தேடுவதற்குக் காரணம். PE வழியாக வழியைப் பின்தொடருங்கள், வரிசை தெளிவாகும்.

RIP update-உடன் PE என்ன செய்கிறது

PE, VRF interface-இல் update-ஐப் பெற்று, மூலம் அனுமதிக்கப்பட்ட அண்டை சாதனமா எனச் சரிபார்த்து, அறிவிப்பிலிருந்து பெறப்பட்ட hop எண்ணிக்கையுடன் முன்னொட்டை VRF routing அட்டவணையில் நிறுவுகிறது. அந்த அட்டவணை அதன் சொந்த administrative distance-களும் சொந்த சிறந்த வழி தேர்வும் கொண்ட சாதாரண routing அட்டவணை. CE அதே முன்னொட்டை வெவ்வேறு metric-களுடன் இருமுறை அறிவித்தால், சிறந்ததே அட்டவணையில் தங்கும். இந்தப் படியில் எதுவும் சேவை வழங்குநரின் backbone-ஐ சம்பந்தப்படுத்தவில்லை.

இப்போது முன்னொட்டு ஒரு வாடிக்கையாளரின் routing சூழலுக்குள் உள்ளது, இது வேறெங்கும் அடையக்கூடியதாக இருப்பதிலிருந்து மிகத் தொலைவில் உள்ளது.

Export என்பது கொள்கைச் செயல், protocol-இன் விளைவு அல்ல

VRF-ஐ விட்டு வெளியேற, ஒரு வழி VPN வழிகளைச் சுமக்கும் MP-BGP செயல்முறைக்கு மறுபகிர்வு செய்யப்பட வேண்டும், மேலும் எந்தத் தொலை VRF-கள் அதை import செய்யலாம் என்பதை அடையாளம் காட்டும் route target extended community தேவை. RFC 4364-இல் உள்ள கட்டமைப்பு இதே காரணத்திற்காக அந்தப் பரிமாற்றங்களை CE-PE protocol-இலிருந்து தனியாக வைத்திருக்கிறது. விளிம்பில் RIP-ஐப் பயன்படுத்துவது சேவை வழங்குநரின் வலையைக் கடக்க வேண்டியது என்ன என்பதைப் பற்றி எதுவும் கூறாது.

எதையும் configure செய்வதற்கு முன் export ஒப்பந்தத்தை எழுதுங்கள்: தொலைவிலிருந்து அடையக்கூடியதாக இருக்க வேண்டிய வாடிக்கையாளர் முன்னொட்டுகள், உள்ளூரில் இருக்க வேண்டிய வழிகள், மேலும் ஏதேனும் default, மிகக் குறிப்பிட்ட வழிகள் அல்லது பகிரப்பட்ட சேவை விதிவிலக்குகள். அந்த ஒப்பந்தத்தை உண்மையான VRF-உடன் ஒப்பிடுங்கள், வேறு வாடிக்கையாளருக்குச் சொந்தமான அதே பெயருள்ள VRF-உடன் அல்ல.

Import பக்கம் அதன் சொந்த route target-களைக் கொண்ட இரண்டாவது கொள்கை, பொருந்தும் export ஒரு பொருந்தாத import-உடன் சேர்ந்து backbone-இல் இருக்கும் ஆனால் எந்தத் தொலை அட்டவணையிலும் தோன்றாத ஒரு முன்னொட்டை உருவாக்குகிறது.

Redistribution-உம் explicit origination-உம் வெவ்வேறாக நடந்துகொள்கின்றன

Redistribution, VRF அட்டவணையில் ஏற்கனவே உள்ள வழிகளை எடுத்து route map-ஆல் வடிகட்டி BGP-க்கு நகலெடுக்கிறது. Map எந்த முன்னொட்டுகள் தகுதியானவை, அவை எந்த attribute-களைச் சுமக்கின்றன என்பதைத் தீர்மானிக்கிறது, மேலும் metric வெளிப்படையாக அமைக்கப்பட வேண்டும், ஏனெனில் RIP hop எண்ணிக்கைக்கு BGP metric ஆக அர்த்தம் இல்லை. நீங்கள் அமைக்காமல் விடுவது எதுவும், ஆறு மாதங்கள் கழித்து config-ஐப் படிக்கும் நபரைப் பொதுவாக ஆச்சரியப்படுத்தும் வகையில் மரபுரிமையாக வரும்.

Mutual redistribution என்பது அமைதியான சேதம் நடக்கும் இடம். BGP-க்கு export செய்யப்பட்ட ஒரு முன்னொட்டு இரண்டாவது redistribution புள்ளி வழியாகத் திரும்பி வரலாம், tag-கள் அல்லது filter-கள் இல்லாவிட்டால் இரு அட்டவணைகளும் எந்த நொடியிலும் நம்பத்தகுந்ததாகத் தெரியும்போது வழி ஊசலாடுகிறது. திரும்பும் வழியைத் தடுக்க topology-ஐ நம்புவதற்குப் பதிலாக விளிம்பில் பயன்படுத்தப்படும் tag-களில் வடிகட்டுங்கள்.

Explicit origination மிகச் சுத்தமாகத் தெரிகிறது, நிபந்தனையற்றது அல்ல. Network statement ஒரு முன்னொட்டு origination செய்யப்படுவதற்கு முன் routing அட்டவணையில் பொருந்தும் வழி தேவைப்படும், எனவே CE அதை அறிவிப்பதை நிறுத்தும் நொடியில் அறிவிப்பு மறைந்துவிடும். இது பெரும்பாலும் நீங்கள் விரும்பும் நடத்தை, எப்போதும் configure செய்யப்பட்டிருக்கும் static வழியைப் போல அல்ல. இரு நடத்தைகளில் ஒன்றை ஊகிப்பதற்குப் பதிலாக platform-இன் உண்மையான விதியைச் சரிபாருங்கள்.

எப்படியிருந்தாலும், ஒவ்வொரு முன்னொட்டைப் பற்றியும் கேட்க வேண்டிய கேள்வி என்னவென்றால், எந்தச் செயலில் உள்ள மூலம் அதைத் தகுதியாக்குகிறது, அந்த மூலம் மறைந்தால் என்ன நடக்கும் என்பதே.

சங்கிலியை நான்கு இடங்களில் சரிபாருங்கள்

CE அறிவிப்பு, VRF routing அட்டவணை, route target-உடன் கூடிய VPN வழி அட்டவணை, தொலை VRF-இல் உள்ள import ஆகியவற்றை அந்த வரிசையில் பாருங்கள். IOS-இல் இது CE அண்டை வெளியீடு, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, மற்றும் தொலை PE-இல் அதே கட்டளை என்பதைக் குறிக்கிறது. IOS-XR-இல் இணையான வெளியீடு show bgp vrf CUSTOMER ipv4 unicast கீழ் உள்ளது. கட்டளைப் பெயர்கள் வேறுபடுகின்றன, நான்கு சரிபார்ப்புப் புள்ளிகள் வேறுபடுவதில்லை.

நிராகரிக்கப்பட வேண்டிய ஒரு முன்னொட்டை, கடக்க வேண்டிய ஒன்றைப் போலவே கவனமாகச் சரிபாருங்கள், ஏனெனில் எல்லாவற்றையும் அனுமதிக்கும் கொள்கை முதல் விதிவிலக்கு வரும்வரை சரியான ஒன்றைப் போலவே தெரிகிறது. பின்னர் ஒரு withdrawal-ஐப் பாருங்கள்: CE interface-ஐ மூடி, தொலைப் பதிவு எதிர்பார்க்கப்பட்ட timer-க்குள் மறைவதை உறுதிப்படுத்துங்கள், தங்கியிருப்பதை அல்ல.

ஒவ்வொரு கொள்கையையும் யார் வைத்திருக்கிறார்கள் என்பதைப் பதிவு செய்யுங்கள். சேவை வழங்குநர் CE-ஐ இயக்கும்போது, வழங்கப்படும் நடத்தை சேவை ஒப்பந்தத்திற்குச் சொந்தம், நிர்வகிக்கப்படும் சாதனத்தில் வேறு protocol அல்லது withdrawal கொள்கை இருப்பது முதலில் ஆவணச் சிக்கல், பின்னரே routing சிக்கல்.