MPLS L3VPN-lab pingt net? Kontrolearje dizze fiif sprongen
In klantping giet troch fiif aparte ôfhinklikheden. Rin se yn oarder troch, en it earste stikken kontrôlepunt fertelt dy hokker konfiguraasje te reparearjen.
Twa klantrouters, in pear provider edge-kasten en in ping dy’t stjert sûnder flaterberjocht. Yn in lyts MPLS L3VPN-lab sit de fout hast altyd by ien fan fiif kontrôlepunten, en elk hat in kommando dat ofwol sjen lit dat de ôfhinklikheid wurket, of dat se ûntbrekt. De flater is om BGP elke kear op ’e nij te starten as de ping mislearret, ynstee fan de ôfhinklikheden yn oarder te testen. Springst dy streekrjocht nei de VRF-konfiguraasje, dan kinst in oere kwytwêze oan in probleem dat begûn mei in net-oploste folgjende hop twa apparaten fierderop.
Wurkje de list fan ûnderen op. In kontrôlepunt dat slagget bliuwt slagge, en de earste flater is dejinge dy’t it debuggen wurdich is.
Kontrôlepunt ien: de PE's kinne elkoar berikke
Elke PE hat in rûte nei de loopback fan ’e oare PE nedich, en dy rûte moat troch eat wierliks oplost wurde. In interior gateway protocol is de gewoane manier om dêr te kommen, mar in statyske rûte wurket ek, salang’t de rekursive opfrege op in libbene adjacency delkomt. Op IOS-achtige kasten lit show ip route 10.0.0.2 folge troch show ip cef 10.0.0.2 sjen oft it foarheaksel bestiet en oft der in oploste adjacency efter sit. In rûte yn ’e tabel sûnder adjacency der efter is gjin berikberens.
Kontrolearje beide rjochtingen. Asymmetryske IGP-kosten, in passive interface oan ’e ferkearde kant of in distribute list dy’t de loopback filteret, brekke elk mar ien rjochting, en ien rjochting is genôch om de sesje te deadzjen. As de loopbacks pinge mar de BGP-sesje stiet yn Active, sjoch dan nei de update source foardatst eat oars oanrekket.
Kontrôlepunt twa: der bestiet in labelpaad
In IP-rûte nei de fiere loopback bewiist net dat it transport in label opsette sil. Befêstigje yn in LDP-ûntwerp dat de fiere loopback in lokale en in fiere binding hat, en dat it útgeande label yn ’e forwarding-tabel ferskynt. show mpls ldp bindings 10.0.0.2 32 lit de labelpearen sjen, en show mpls forwarding-table 10.0.0.2 lit sjen wat de line card wierwei opsette sil. As it twadde kommando gjin label sjen lit of nei IP weromfalt, dan draacht it transport it VPN-ferkear net sa’t it ûntwerp oannimt.
It ûnderskie komt út hoe’t MPLS forwarding state fan bestimmingsfoarheaksels skiedt, it model dat yn RFC 3031 beskreaun wurdt. As dyn lab RSVP-TE of BGP-grinzende labels brûkt ynstee fan LDP, kontrolearje dan de eigen tastân fan dat meganisme; oannimme dat LDP elk ûnderlaach-label ferspriedt is in gewoane manier om in spoekflater te jeien. In brutsen labelpaad komt letter meastentiids nei foaren as in VPN-rûte dy’t oanwêzich mar net brûkber is.
Kontrôlepunt trije: de VPN-rûte kaam yntakt oan
Sjoch nei de VPNv4- of VPNv6-rûte foar it krekte klantfoarheaksel, net nei de sesjegearfetting. show bgp vpnv4 unicast all 10.10.1.0/24 heart de route distinguisher te toanen, de next hop set op ’e fiere PE-loopback en in label. As it foarheaksel ûntbrekt, is it eksportbelied op ’e boarne-PE of it importbelied op ’e ûntfangende PE de earste fertochte, en route targets binne de gewoane skuldige.
Lês de route target-kontrôle apart fan ’e BGP-ûntfangst. In rûte kin mei de juste next hop oankomme en dochs net yn ’e VRF lânje, om’t it importtarget net oerienkomt. Op ’e ûntfangende PE is show ip route vrf CUSTOMER 10.10.1.0 de test dy’t telt; de BGP-tabel bewiist allinnich dat de rûte it kontrôleflak oerstutsen hat.
Kontrôlepunt fjouwer: it interface sit yn ’e VRF
In VRF-definysje mei in route distinguisher en route targets ferpleatst gjin inkel interface deryn. It interface nei de CE hat de VRF-tawizing nedich, en show ip vrf interfaces of show ip interface brief heart it ûnder de juste ynstânsje te listen. Dit is it kontrôlepunt dêr’t in kopiearre konfiguraasje it meast misgiet, om’t it VRF-blok kompleet liket wylst it interface noch yn ’e globale tabel sit.
Befêstigje dêrnei dat de PE it lokale klantfoarheaksel yn dy VRF leard hat, en dat de CE in rûte werom hat fia de oansluting. In statyske default op ’e CE dy’t nei de PE wiist is genôch foar in lab, mits de VRF fan ’e PE in rûte nei it CE-LAN hat. As ien fan ’e beide helten ûntbrekt, mislearret de ping foardat der in label opset wurdt.
Kontrôlepunt fiif: it antwurd fynt in paad nei hûs
Folch it pakket foarút en dêrnei it weromkommende pakket, want se brûke ferskillende tabellen. Op ’e ingress-PE heart de klantboarne binnen de VRF nei it fiere foarheaksel mei it fiere label op te lossen. Op ’e egress-PE heart de bestimming binnen deselde VRF nei it interface nei de CE op te lossen. In ping fan ’e PE sels is gjin bewiis: dy kin fia de globale tabel of in oar boarne-adres fuortgean, en dêrom is ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 de test dy’tst draaie moatst.
Host-firewalls, reverse-path filtering en accesslisten op ’e CE jilde noch hieltyd. As it paad foarút wurket en it antwurd stjert, sit it probleem yn in rûte of in filter oan ’e weromkant, net yn it MPLS-transport.
Hâld ien rigel per kontrôlepunt by dy’t de earste ôfhinklikheid neamt dy’t mislearre. Dy rigel makket fan ’e klacht dat de klant net pingje kin in konkrete fraach oer berikberens, labeltastân, rûte-import, interface-lidmaatskip of it werompaad, en hy hâldt de folgjende debugsesje tsjin deselde fiif kommando’s yn deselde oarder te werheljen.