Lab ng MPLS L3VPN, hindi nagpi-ping? Suriin ang limang puntong ito

Dalawang router ng kostumer, isang pares ng provider edge box, at isang ping na namamatay nang walang error message. Sa maliit na lab ng MPLS L3VPN, halos palaging nasa isa sa limang checkpoint ang sira, at bawat isa ay may command na nagpapakita kung gumagana o kulang ang dependency. Ang pagkakamali ay i-restart ang BGP tuwing nabibigo ang ping sa halip na subukan ang mga dependency nang sunod-sunod. Kapag dumiretso ka sa configuration ng VRF, mauubos mo ang isang oras sa problemang nagsimula sa hindi naresolbang next hop dalawang device ang layo.

Pangunahan ang listahan mula sa ibaba pataas. Ang checkpoint na pumasa ay nananatiling pasado, at ang unang pagkabigo ang siyang dapat i-debug.

Unang checkpoint: nakakaabot ang mga PE sa isa't isa

Kailangan ng bawat PE ang ruta papunta sa loopback ng kabilang PE, at ang rutang iyon ay dapat maresolba sa isang tunay na bagay. Ang interior gateway protocol ang karaniwang paraan, ngunit gumagana rin ang static route hangga't napapadpad ang recursive lookup sa isang buhay na adjacency. Sa mga device na tulad ng IOS, ang show ip route 10.0.0.2 at pagkatapos ang show ip cef 10.0.0.2 ay magsasabi kung umiiral ang prefix at kung may naresolbang adjacency ito. Ang ruta sa table na walang adjacency sa likod ay hindi reachability.

Suriin ang dalawang direksyon. Ang asimetrikong IGP cost, passive interface sa maling panig, o distribute list na nagfi-filter ng loopback ay bawat isa ay sumisira lamang sa isang direksyon, at sapat na ang isang direksyon para patayin ang session. Kung nagpi-ping ang mga loopback pero nakaupo sa Active ang BGP session, tingnan ang update source bago hawakan ang anupaman.

Ikalawang checkpoint: may label path

Ang IP route papunta sa remote loopback ay hindi nagpapatunay na magtutulak ng label ang transport. Sa disenyong LDP, tiyakin na may lokal at remote na binding ang remote loopback, at lumilitaw sa forwarding table ang outgoing label. Ipinapakita ng show mpls ldp bindings 10.0.0.2 32 ang mga pares ng label, at ipinapakita ng show mpls forwarding-table 10.0.0.2 kung ano talaga ang ilalagay ng line card. Kapag ang pangalawang command ay nagpapakita ng „no label“ o nagpapa-punt sa IP, hindi dinadala ng transport ang trapiko ng VPN ayon sa inaasahan ng disenyo.

Nagmumula ang pagkakaiba sa paraan ng paghihiwalay ng MPLS sa forwarding state mula sa mga destinasyong prefix, at iyon ang modelong inilarawan sa RFC 3031. Kung ang lab mo ay gumagamit ng RSVP-TE o mga label na katabi ng BGP sa halip na LDP, suriin ang sariling estado ng mekanismong iyon; ang ipagpalagay na ipinamahagi ng LDP ang bawat underlay label ay karaniwang paraan ng paghabol sa multong bug. Ang sirang label path ay karaniwang lumilitaw mamaya bilang rutang VPN na naroroon ngunit hindi magamit.

Ikatlong checkpoint: dumating nang buo ang rutang VPN

Tingnan ang rutang VPNv4 o VPNv6 para sa eksaktong prefix ng kostumer, hindi ang buod ng session. Dapat ipakita ng show bgp vpnv4 unicast all 10.10.1.0/24 ang route distinguisher, ang next hop na itinakda sa remote PE loopback, at isang label. Kung kulang ang prefix, ang export policy sa originating PE o ang import policy sa receiving PE ang unang suspek, at ang route target ang karaniwang salarin.

Basahin ang pagsusuri ng route target nang hiwalay sa pagtanggap ng BGP. Maaaring dumating ang ruta na may tamang next hop at hindi pa rin makapasok sa VRF dahil hindi tugma ang import target. Sa receiving PE, ang show ip route vrf CUSTOMER 10.10.1.0 ang mahalagang pagsubok; pinatutunayan lamang ng BGP table na tumawid ang ruta sa control plane.

Ikaapat na checkpoint: nasa VRF ang interface

Ang VRF definition na may route distinguisher at route target ay hindi naglilipat ng anumang interface papasok dito. Kailangan ng interface na nakaharap sa CE ang VRF assignment, at dapat ilista ito ng show ip vrf interfaces o show ip interface brief sa ilalim ng tamang instance. Ito ang checkpoint kung saan pinakamadalas magkamali ang kinopyang configuration, dahil mukhang kumpleto ang VRF block habang nakaupo pa rin ang interface sa global table.

Pagkatapos, tiyakin na natutunan ng PE ang lokal na prefix ng kostumer sa VRF na iyon, at may ruta pabalik ang CE sa pamamagitan ng attachment. Ang static default sa CE na nakaturo sa PE ay sapat na para sa lab, basta may ruta ang VRF ng PE papunta sa LAN ng CE. Kung kulang ang alinmang kalahati, nabibigo ang ping bago pa mailagay ang anumang label.

Ikalimang checkpoint: nakakahanap ng daan pauwi ang tugon

I-trace ang papasok na packet at pagkatapos ang pabalik na packet, dahil magkaibang table ang ginagamit nila. Sa ingress PE, dapat maresolba ang source ng kostumer sa loob ng VRF papunta sa remote prefix na may remote label. Sa egress PE, dapat maresolba ang destinasyon sa loob ng parehong VRF papunta sa interface na nakaharap sa CE. Ang ping mula sa PE mismo ay hindi ebidensya: maaaring lumabas ito sa global table o sa ibang source address, kaya ang ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 ang pagsubok na dapat gawin.

Nalalapat pa rin ang mga firewall ng host, reverse-path filtering, at access list ng CE. Kung gumagana ang papasok na landas at namamatay ang tugon, ang problema ay ruta o filter sa panig ng pagbabalik, hindi ang MPLS transport.

Magtago ng isang linyang tala para sa bawat checkpoint na nagpapangalan sa unang dependency na nabigo. Binabago ng talang iyon ang „hindi makapag-ping ang kostumer“ tungo sa tiyak na tanong tungkol sa reachability, estado ng label, import ng ruta, pagiging miyembro ng interface, o landas ng pagbabalik, at pinipigilan nito ang susunod na debugging session na ulitin ang parehong limang command sa parehong pagkakasunod-sunod.