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-ը ցույց են տալիս՝ արդյոք նախածանցը գոյություն ունի և արդյոք դրա հետևում լուծված 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-ը նպատակակետ նախածանցներից՝ մոդելը, որը նկարագրված է RFC 3031-ում։ Եթե ձեր լաբորատորիան LDP-ի փոխարեն օգտագործում է RSVP-TE կամ BGP-ին հարակից պիտակներ, ստուգեք այդ մեխանիզմի սեփական վիճակը՝ ենթադրել, որ LDP-ն բաշխում է ստորին շերտի յուրաքանչյուր պիտակ, հոգևոր սխալի հետևից ընկնելու սովորական ձև է։ Կոտրված պիտակների ուղին ավելի ուշ սովորաբար ի հայտ է գալիս որպես VPN երթուղի, որը գոյություն ունի, բայց անօգտագործելի է։

Երրորդ ստուգման կետը. VPN երթուղին ժամանել է անձեռնմխելի

Նայեք ճշգրիտ հաճախորդի նախածանցի VPNv4 կամ VPNv6 երթուղուն, ոչ թե սեսիայի ամփոփմանը։ show bgp vpnv4 unicast all 10.10.1.0/24-ը պետք է ցույց տա route distinguisher-ը, հեռավոր PE-ի loopback-ին դրված next hop-ը և պիտակ։ Եթե նախածանցը բացակայում է, առաջին կասկածյալը սկզբնական PE-ի արտահանման քաղաքականությունն է կամ ընդունող PE-ի ներմուծման քաղաքականությունը, և 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-ը պետք է այն թվարկի ճիշտ instance-ի տակ։ Սա այն ստուգման կետն է, որտեղ պատճենված կոնֆիգուրացիան ամենից հաճախ սխալվում է, որովհետև VRF բլոկը ամբողջական է երևում, մինչդեռ interface-ը դեռ նստած է գլոբալ աղյուսակում։

Այնուհետև հաստատեք, որ PE-ն սովորել է տեղական հաճախորդի նախածանցը այդ VRF-ում, և որ CE-ն ունի վերադարձի երթուղի միացման միջով։ CE-ի վրա PE-ին ուղղված ստատիկ default-ը բավարար է լաբորատորիայի համար, պայմանով որ PE-ի VRF-ում երթուղի կա դեպի CE-ի LAN։ Եթե երկու կեսերից որևէ մեկը բացակայում է, ping-ը ձախողվում է նախքան որևէ պիտակ դնելը։

Հինգերորդ ստուգման կետը. պատասխանը տուն տանող ճանապարհ է գտնում

Հետևեք առաջ գնացող փաթեթին, ապա վերադարձող փաթեթին, որովհետև նրանք տարբեր աղյուսակներ են օգտագործում։ Մուտքի PE-ի վրա հաճախորդի աղբյուրը պետք է լուծվի VRF-ի ներսում դեպի հեռավոր նախածանցը հեռավոր պիտակով։ Ելքի PE-ի վրա նպատակակետը պետք է լուծվի նույն VRF-ի ներսում դեպի CE-ի կողմի interface-ը։ PE-ից հենց իրենից ուղարկված ping-ը ապացույց չէ՝ այն կարող է դուրս գալ գլոբալ աղյուսակով կամ այլ աղբյուրի հասցեով, և դրա համար է, որ ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1-ը այն թեստն է, որը պետք է գործարկել։

Հոսթերի firewall-ները, reverse-path filtering-ը և CE-ի access ցանկերը դեռ գործում են։ Եթե առաջ գնացող ուղին աշխատում է, իսկ պատասխանը մահանում է, խնդիրը վերադարձի կողմի երթուղու կամ զտիչի մեջ է, ոչ թե MPLS տրանսպորտում։

Յուրաքանչյուր ստուգման կետի համար պահեք մեկ տող, որը նշում է առաջին ձախողված կախվածությունը։ Այդ տողը հաճախորդի՝ ping չկարողանալու բողոքը դարձնում է կոնկրետ հարց հասանելիության, պիտակների վիճակի, երթուղու ներմուծման, interface-ի անդամակցության կամ վերադարձի ուղու մասին, և թույլ չի տալիս, որ հաջորդ վրիպազերծման սեսիան կրկնի նույն հինգ հրամանները նույն հերթականությամբ։