MPLS L3VPN ஆய்வகம் ping செய்யவில்லையா? இந்த ஐந்து ஹாப்களைச் சரிபார்க்கவும்

வாடிக்கையாளரின் இரண்டு ரவுட்டர்கள், ஒரு ஜோடி provider edge சாதனங்கள் மற்றும் பிழைச் செய்தி இல்லாமல் இறக்கும் ஒரு ping. சிறிய MPLS L3VPN ஆய்வகத்தில் கோளாறு எப்போதும் ஐந்து சரிபார்ப்புப் புள்ளிகளில் ஒன்றில் அமர்ந்திருக்கும், ஒவ்வொன்றிலும் சார்பு வேலை செய்கிறதா இல்லையா என்பதைக் காட்டும் கட்டளை உள்ளது. தவறு என்பது ping தோல்வியடையும் ஒவ்வொரு முறையும் BGP-ஐ மீண்டும் தொடங்குவது, சார்புகளை வரிசையாகச் சோதிப்பதற்குப் பதிலாக. நீங்கள் நேராக VRF உள்ளமைவுக்குச் சென்றால், இரு சாதனங்கள் தூரத்தில் தீர்க்கப்படாத அடுத்த ஹாபில் தொடங்கிய சிக்கலில் ஒரு மணி நேரம் செலவழிக்கலாம்.

பட்டியலைக் கீழிருந்து மேலாக வேலை செய்யுங்கள். தேர்ச்சி பெறும் சரிபார்ப்புப் புள்ளி தேர்ச்சியாகவே இருக்கும், முதல் தோல்வியே பிழைத்திருத்தத்திற்குத் தகுந்தது.

முதல் சரிபார்ப்புப் புள்ளி: PE-க்கள் ஒன்றையொன்று அடைகின்றன

ஒவ்வொரு PE-க்கும் மற்ற PE-யின் loopback-க்கு ஒரு வழி தேவை, அந்த வழி ஏதோ உண்மையான ஒன்றின் வழியாகத் தீர்க்கப்பட வேண்டும். interior gateway protocol அங்கு செல்லும் வழக்கமான வழி, ஆனால் மீள்சுழல் தேடல் ஓர் உயிருள்ள adjacency-யில் விழும் வரை நிலையான வழியும் வேலை செய்யும். IOS பாணி சாதனங்களில், show ip route 10.0.0.2 மற்றும் அதைத் தொடர்ந்து show ip cef 10.0.0.2 ஆகியவை prefix உள்ளதா, அதன் பின்னால் தீர்க்கப்பட்ட adjacency உள்ளதா என்பதைக் காட்டும். அட்டவணையில் உள்ள வழி, அதன் பின்னால் adjacency இல்லாவிட்டால், அது அணுகல்தன்மை அல்ல.

இரு திசைகளையும் சரிபார்க்கவும். சமச்சீரற்ற IGP செலவுகள், தவறான பக்கத்தில் உள்ள passive interface அல்லது loopback-ஐ வடிகட்டும் distribute list ஆகியவை ஒவ்வொன்றும் ஒரு திசையை மட்டுமே உடைக்கும், ஒரு திசை அமர்வைக் கொல்ல போதும். loopback-க்கள் ping செய்தாலும் BGP அமர்வு Active-இல் நின்றால், வேறு எதையும் தொடுவதற்கு முன் update source-ஐப் பாருங்கள்.

இரண்டாவது சரிபார்ப்புப் புள்ளி: லேபிள் பாதை உள்ளது

தொலை loopback-க்கு இருக்கும் IP வழி, போக்குவரத்து ஒரு லேபிளை வைக்கும் என்பதை நிரூபிக்காது. LDP வடிவமைப்பில், தொலை loopback-க்கு உள்ளூர் மற்றும் தொலை பிணைப்பு இரண்டும் உள்ளன என்பதையும், வெளிச் செல்லும் லேபிள் forwarding அட்டவணையில் தோன்றுகிறது என்பதையும் உறுதிப்படுத்துங்கள். show mpls ldp bindings 10.0.0.2 32 லேபிள் ஜோடிகளைக் காட்டுகிறது, show mpls forwarding-table 10.0.0.2 line card உண்மையில் என்ன வைக்கும் என்பதைக் காட்டுகிறது. இரண்டாவது கட்டளை எந்த லேபிளையும் காட்டாவிட்டால் அல்லது IP-க்குத் திரும்பினால், வடிவமைப்பு கருதுவது போல போக்குவரத்து VPN போக்குவரத்தை எடுத்துச் செல்லவில்லை.

இந்த வேறுபாடு MPLS forwarding state-ஐ இலக்கு prefix-களிலிருந்து எவ்வாறு பிரிக்கிறது என்பதிலிருந்து வருகிறது, அதுவே RFC 3031-இல் விவரிக்கப்பட்ட மாதிரி. உங்கள் ஆய்வகம் LDP-க்குப் பதிலாக RSVP-TE அல்லது BGP-க்கு அருகிலுள்ள லேபிள்களைப் பயன்படுத்தினால், அந்த இயங்குமுறையின் சொந்த நிலையைச் சரிபார்க்கவும்; LDP ஒவ்வொரு அடிப்படை அடுக்கு லேபிளையும் விநியோகிக்கும் என்று கருதுவது பேய்ப் பிழையைத் துரத்தும் வழக்கமான வழி. உடைந்த லேபிள் பாதை பின்னர் இருக்கும் ஆனால் பயன்படுத்த முடியாத VPN வழியாகத் தோன்றும்.

மூன்றாவது சரிபார்ப்புப் புள்ளி: VPN வழி பாதுகாப்பாக வந்தது

சரியான வாடிக்கையாளர் prefix-இன் VPNv4 அல்லது VPNv6 வழியைப் பாருங்கள், அமர்வுச் சுருக்கத்தை அல்ல. show bgp vpnv4 unicast all 10.10.1.0/24 route distinguisher, தொலை PE-யின் loopback-க்கு அமைக்கப்பட்ட next hop மற்றும் ஒரு லேபிளைக் காட்ட வேண்டும். prefix இல்லாவிட்டால், முதல் சந்தேகம் மூல PE-யில் உள்ள export கொள்கை அல்லது பெறும் PE-யில் உள்ள import கொள்கை, route target-களே வழக்கமான குற்றவாளி.

route target சரிபார்ப்பை BGP பெறுதலிலிருந்து தனியாகப் படியுங்கள். ஒரு வழி சரியான next hop உடன் வந்து, importtarget பொருந்தாததால் VRF-இல் இறங்காமல் போகலாம். பெறும் PE-யில் show ip route vrf CUSTOMER 10.10.1.0 தான் முக்கியமான சோதனை; BGP அட்டவணை வழி கட்டுப்பாட்டுத் தளத்தைக் கடந்தது என்பதை மட்டுமே நிரூபிக்கிறது.

நான்காவது சரிபார்ப்புப் புள்ளி: interface VRF-இல் உள்ளது

route distinguisher மற்றும் route target-கள் கொண்ட VRF வரையறை எந்த interface-ஐயும் அதற்குள் நகர்த்தாது. CE-நோக்கிய interface-க்கு VRF ஒதுக்கீடு தேவை, show ip vrf interfaces அல்லது show ip interface brief அதைச் சரியான நிகழ்வின் கீழ் பட்டியலிட வேண்டும். நகலெடுக்கப்பட்ட உள்ளமைவு அதிகம் தவறு செய்யும் சரிபார்ப்புப் புள்ளி இதுவே, ஏனெனில் VRF தொகுதி முழுமையாகத் தெரிகிறது ஆனால் interface இன்னும் உலகளாவிய அட்டவணையில் அமர்ந்திருக்கிறது.

பிறகு PE உள்ளூர் வாடிக்கையாளர் prefix-ஐ அந்த VRF-இல் கற்றுக்கொண்டது என்பதையும், CE-க்கு இணைப்பு வழியாகத் திரும்பும் வழி உள்ளது என்பதையும் உறுதிப்படுத்துங்கள். CE-யில் PE-ஐ நோக்கும் நிலையான default ஆய்வகத்திற்குப் போதும், PE-யின் VRF-இல் CE-யின் LAN-க்கு வழி இருந்தால். இரு பாதிகளில் ஒன்று இல்லாவிட்டால், எந்த லேபிளும் வைக்கப்படுவதற்கு முன்பே ping தோல்வியடைகிறது.

ஐந்தாவது சரிபார்ப்புப் புள்ளி: பதில் வீட்டுக்கான வழியைக் கண்டுபிடிக்கிறது

முன்னோக்கிச் செல்லும் பாக்கெட்டையும் பின்னர் திரும்பி வரும் பாக்கெட்டையும் கண்காணியுங்கள், ஏனெனில் அவை வெவ்வேறு அட்டவணைகளைப் பயன்படுத்துகின்றன. உள்நுழைவு PE-யில் வாடிக்கையாளர் மூலம் VRF-க்குள் தொலை prefix-க்கு தொலை லேபிளுடன் தீர்க்கப்பட வேண்டும். வெளியேறும் PE-யில் இலக்கு அதே VRF-க்குள் CE-நோக்கிய interface-க்குத் தீர்க்கப்பட வேண்டும். PE-யிலிருந்தே அனுப்பப்படும் ping சான்று அல்ல: அது உலகளாவிய அட்டவணை அல்லது வேறு மூல முகவரி வழியாக வெளியேறலாம், அதனால்தான் ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 இயக்க வேண்டிய சோதனை.

ஹோஸ்ட் ஃபயர்வால்கள், reverse-path filtering மற்றும் CE-யின் access பட்டியல்கள் இன்னும் பொருந்தும். முன்னோக்கிய பாதை வேலை செய்து பதில் இறந்தால், சிக்கல் திரும்பும் பக்கத்தின் வழியில் அல்லது வடிகட்டியில், MPLS போக்குவரத்தில் அல்ல.

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