RSVP-TE-tunnelen er oppe, men kundens L3VPN har ingen rute
Transport og tjeneste er to separate beslutninger. Læs labelstakken, tjek næste-hop-opløsning og VRF-tilknytning hver for sig, og test derefter et rigtigt kundeflow.
To teams kan begge have ret, når kunden rapporterer, at VPN'et er nede, og transportteamet rapporterer, at tunnelen er i orden. En trafikengineering-LSP og et MPLS L3VPN besvarer forskellige spørgsmål: den ene flytter mærkede pakker gennem kernen, den anden afgør, hvilken routingkontekst en pakke hører til. Når de blandes sammen, går diskussionen i ring, fordi hver side måler et forskelligt objekt, og begge målinger er gyldige.
Transport oppe og tjeneste nede er en normal tilstand
En LSP kan være etableret, føre trafik og være synlig i alle overvågningssystemer, mens kundetjenesten forbliver ubrugelig. Intet ved den kombination er selvmodsigende, fordi tunnelen ikke har nogen holdning til, om et fjernt præfiks findes, om en importpolitik accepterede det, eller om den tilknyttede kreds sender rammer videre.
Det symptom, der normalt afslører forvirringen, er asymmetrisk: ping fra PE-loopback lykkes, mens en vært på kundens LAN intet får, eller omvendt. Skriv ned, hvilke adresser der virkede, før du danner en teori. Når du først bemærker, at du tester to forskellige objekter, er næste skridt at læse labelstakken i stedet for at diskutere, hvis graf der er korrekt. To adresser, to ejere og normalt to forskellige personer, der hver tror, at den anden har ødelagt noget.
Læs stakken som to ansvar
Det nederste label tilhører tjenesten, og det øverste label tilhører ruten. RFC 4364 beskriver rækkefølgen enkelt: først pålægges VPN-rutelabelen, derefter tunneleres den mærkede pakke mod BGP-næstehop, hvor en trafikengineering-tunnel skubber sit eget label ovenpå.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
Ved den fjerne PE vælger tjenestelabelen behandlingen, som kan være et VRF-opslag eller en tilknytningsbeslutning. Det label kan ikke udskiftes med et, der blot krydser kernen, og de to er ikke udskiftelige, selv når begge optræder i samme stak på samme interface.
Hvad RSVP-succes beviser, og hvad det ikke beviser
RSVP-TE etablerer eksplicit rutede LSP'er, med eller uden ressourcereservationer, hvilket er en konkret og nyttig garanti for den vej, en pakke tager gennem kernen. Det er ikke en udtalelse om kunderuter, og et konfigureret tunnelnavn er slet ikke en rute.
Tilstedeværelsen af RSVP giver heller ikke et løfte om ende-til-ende-ydeevne. Båndbreddereservation på én LSP siger intet om den tilknyttede kreds, kundens egen adgangslinje eller køadfærden ved den fjerne kant. At behandle det som en garanti giver sikre svar på spørgsmål, som ingen stillede. Hvis kravet virkelig er en båndbreddeforpligtelse, skal den samles af de dele, der faktisk håndhæver en, og LSP'en er kun midten af den kæde.
Kontroller i rækkefølge, og stop så
Arbejd fra transporten og udad og stop ved det første trin, der fejler, fordi hvert senere trin forudsætter, at de tidligere holdt. Bekræft først, at LSP'en er etableret, og at videresendelsesposten for tjenestepræfikset faktisk peger på den. Bekræft derefter, at VPN-ruten findes i den rigtige tabel, at dens labelbinding er til stede, og at importpolitikken accepterede den. Bekræft derefter tilknytningen: interfacet, indkapslingen og, hvor det gælder, VLAN-identifikatoren, der hører til den kontrakt.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERKommandosyntaksen varierer efter platform, så behandle de fire linjer som de fire spørgsmål i stedet for som et script. Det vigtige er, at hver af dem afhører et forskelligt objekt, og det er det, der får en fejl til at pege på en bestemt ejer.
Følg én tilladt anmodning, og gem de gode beviser
Afslut med en enkelt rigtig kundeanmodning, tilladt af politikken, og dens svar. Et fungerende flow ende til ende afgør mere end en side tælleraf læsninger, og det afprøver kombinationen i stedet for hver del isoleret.
Når et senere trin fejler, bevar den vellykkede LSP-observation i stedet for at genopbygge transporten. At genopbygge en fungerende tunnel kan ikke reparere et manglende fjernt præfiks, en forkert VRF-tilknytning eller en adgangsregel for destinationen, og det ødelægger det bevis, der oprindeligt fortalte dig, at transporten var sund.