MPLS L3VPN laboratorija nepingo? Pārbaudiet šos piecus punktus

Divi klienta maršrutētāji, pāris pakalpojumu sniedzēja malas kārbu un ping, kas nomirst bez kļūdas ziņojuma. Mazā MPLS L3VPN laboratorijā kļūme gandrīz vienmēr atrodas vienā no pieciem pārbaudes punktiem, un katram no tiem ir komanda, kas parāda, vai atkarība darbojas, vai tās trūkst. Kļūda ir restartēt BGP katru reizi, kad ping neizdodas, tā vietā lai pārbaudītu atkarības pēc kārtas. Ja uzreiz lecat uz VRF konfigurāciju, varat pavadīt stundu pie problēmas, kas sākās ar neatrisinātu next hop divu ierīču attālumā.

Sarakstu strādājiet no apakšas uz augšu. Pārbaudes punkts, kas izturēts, paliek izturēts, un pirmais neizdevums ir tas, ko ir vērts atkļūdot.

Pirmais pārbaudes punkts: PE sasniedz viens otru

Katram PE vajag maršrutu uz otra PE loopback, un šim maršrutam jāatrisinās caur kaut ko reālu. Iekšējās vārtejas protokols ir ierastais ceļš, bet statiskais maršruts arī der, ja rekursīvā meklēšana nokrīt uz dzīvu blakusattiecību. IOS stila ierīcēs show ip route 10.0.0.2 un pēc tam show ip cef 10.0.0.2 parādīs, vai prefikss eksistē un vai tam ir atrisināta blakusattiecība. Maršruts tabulā bez blakusattiecības aiz tā nav sasniedzamība.

Pārbaudiet abus virzienus. Asimetriskas IGP izmaksas, pasīvs interfeiss nepareizajā pusē vai izplatīšanas saraksts, kas filtrē loopback, katrs no tiem salauž tikai vienu virzienu, un ar vienu virzienu pietiek, lai nogalinātu sesiju. Ja loopback atbild uz ping, bet BGP sesija stāv Active stāvoklī, pirms kaut ko aiztikt, paskatieties uz atjauninājumu avotu.

Otrais pārbaudes punkts: pastāv etiķešu ceļš

IP maršruts uz attālo loopback nepierāda, ka transports iespiedīs etiķeti. LDP projektā pārliecinieties, ka attālajam loopback ir lokāla un attāla saistība un ka izejošā etiķete parādās pārsūtīšanas tabulā. show mpls ldp bindings 10.0.0.2 32 parāda etiķešu pārus, un show mpls forwarding-table 10.0.0.2 parāda, ko līnijas karte faktiski ievietos. Kad otrā komanda rāda „no label“ vai nodod IP, transports nepārvadā VPN satiksmi tā, kā projekts pieņem.

Atšķirība izriet no tā, kā MPLS atdala pārsūtīšanas stāvokli no galamērķa prefiksiem, un tas ir modelis, kas aprakstīts RFC 3031. Ja jūsu laboratorija LDP vietā izmanto RSVP-TE vai ar BGP saistītas etiķetes, pārbaudiet šī mehānisma stāvokli; pieņēmums, ka LDP izplata katru underlay etiķeti, ir ierasts veids, kā dzīties pakaļ fantoma kļūdai. Salūzis etiķešu ceļš parasti vēlāk parādās kā VPN maršruts, kas ir, bet nav lietojams.

Trešais pārbaudes punkts: VPN maršruts ieradās vesels

Skatieties VPNv4 vai VPNv6 maršrutu precīzajam klienta prefiksam, nevis sesijas kopsavilkumu. show bgp vpnv4 unicast all 10.10.1.0/24 būtu jāparāda maršruta atšķirējs, next hop, kas iestatīts uz attālo PE loopback, un etiķete. Ja prefikss trūkst, pirmais aizdomās turamais ir eksporta politika sākotnējā PE vai importa politika saņēmējā PE, un route target parasti ir vaininieks.

Route target pārbaudi lasiet atsevišķi no BGP saņemšanas. Maršruts var ierasties ar pareizu next hop un tomēr neiekļūt VRF, jo import target nesakrīt. Saņēmējā PE show ip route vrf CUSTOMER 10.10.1.0 ir tas tests, kam ir nozīme; BGP tabula tikai pierāda, ka maršruts šķērsoja vadības plakni.

Ceturtais pārbaudes punkts: interfeiss ir VRF

VRF definīcija ar maršruta atšķirēju un route target nepārvieto tajā nevienu interfeisu. Uz CE vērstajam interfeisam vajag VRF piešķīrumu, un show ip vrf interfaces vai show ip interface brief tam būtu jāuzskaita zem pareizā instanca. Šis ir pārbaudes punkts, kur nokopēta konfigurācija visbiežāk sabojājas, jo VRF bloks izskatās pabeigts, kamēr interfeiss joprojām sēž globālajā tabulā.

Pēc tam pārliecinieties, ka PE ir iemācījies lokālo klienta prefiksu šajā VRF un ka CE ir ceļš atpakaļ caur pieslēgumu. Statisks noklusējums uz CE, kas norāda uz PE, laboratorijai pietiek, ja PE VRF ir maršruts uz CE LAN. Ja trūkst kādas puses, ping neizdodas, pirms tiek iespiesta jebkāda etiķete.

Piektais pārbaudes punkts: atbilde atrod ceļu mājās

Izsekojiet uz priekšu ejošo paketi un pēc tam atgriešanās paketi, jo tie izmanto dažādas tabulas. Ieejas PE klienta avotam VRF iekšienē jāatrisinās uz attālo prefiksu ar attālo etiķeti. Izejas PE galamērķim tajā pašā VRF jāatrisinās uz CE vērsto interfeisu. Ping no paša PE nav pierādījums: tas var iziet caur globālo tabulu vai citu avota adresi, tāpēc ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 ir tas tests, kas jāizpilda.

Resursdatora ugunsmūri, apgrieztā ceļa filtrēšana un CE piekļuves saraksti joprojām darbojas. Ja ceļš uz priekšu strādā, bet atbilde mirst, problēma ir maršruts vai filtrs atgriešanās pusē, nevis MPLS transports.

Turiet vienas rindas ierakstu katram pārbaudes punktam, nosaucot pirmo neizdevušos atkarību. Šis ieraksts pārvērš „klients nevar pingot“ konkrētā jautājumā par sasniedzamību, etiķešu stāvokli, maršrutu importu, interfeisa piederību vai atgriešanās ceļu un neļauj nākamajai atkļūdošanas sesijai atkārtot tās pašas piecas komandas tajā pašā secībā.