MPLS L3VPN लॅब पिंग करत नाही? हे पाच हॉप तपासा

ग्राहकाचे दोन राउटर, provider edge उपकरणांची एक जोडी आणि त्रुटी संदेशाशिवाय मरणारा पिंग। छोट्या MPLS L3VPN लॅबमध्ये बिघाड जवळजवळ नेहमी पाच चेकपॉइंटपैकी एकावर बसतो, आणि प्रत्येकाकडे असे कमांड आहे जे अवलंबन कार्यरत आहे की अनुपस्थित आहे हे दाखवते। चूक ही आहे की प्रत्येक वेळी पिंग अयशस्वी झाल्यावर 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 पिंग करतात पण 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 सह येऊ शकतो आणि तरीही VRF मध्ये न उतरू कारण importtarget जुळत नाही। स्वीकारणाऱ्या 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 पर्यंत मार्ग असेल। दोनपैकी कोणताही अर्धा भाग नसल्यास, पिंग कोणतेही लेबल लागण्यापूर्वीच अयशस्वी होतो।

पाचवा चेकपॉइंट: उत्तर घराचा मार्ग शोधते

पुढे जाणारे पॅकेट आणि नंतर परत येणारे पॅकेट पाहा, कारण ते वेगळी टेबल वापरतात। प्रवेश PE वर ग्राहक स्रोत VRF च्या आत दूरच्या prefix पर्यंत दूरच्या लेबलसह सुटला पाहिजे। निर्गम PE वर गंतव्य त्याच VRF च्या आत CE कडील interface पर्यंत सुटले पाहिजे। स्वतः PE मधून पाठवलेला पिंग पुरावा नाही: तो जागतिक टेबल किंवा दुसऱ्या स्रोत पत्त्यातून बाहेर जाऊ शकतो, म्हणूनच ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 ही चाचणी चालवायची आहे।

यजमानांचे फायरवॉल, reverse-path filtering आणि CE वरील access याद्या अजूनही लागू आहेत। जर पुढचा मार्ग चालतो आणि उत्तर मरते, तर समस्या परतीच्या बाजूच्या मार्गात किंवा फिल्टरमध्ये आहे, MPLS वहनात नाही।

प्रत्येक चेकपॉइंटसाठी एक ओळ ठेवा जी पहिल्या अपयशी अवलंबनाचे नाव घेते। ती ओळ ग्राहक पिंग करू शकत नाही या तक्रारीचे पोहोचक्षमता, लेबलची स्थिती, मार्ग आयात, interface सदस्यत्व किंवा परतीचा मार्ग याबद्दलच्या ठोस प्रश्नात रूपांतर करते आणि पुढील डीबग सत्राला तेच पाच कमांड त्याच क्रमाने पुन्हा करण्यापासून रोखते।