RSVP-TE-tunnelen er oppe, men kundens L3VPN har ingen rute
Transport og tjeneste er to separate beslutninger. Les etikettstakken, sjekk neste-hopp-oppslag og VRF-tilknytning hver for seg, og test deretter én reell kundeflyt.
To team kan begge ha rett når kunden rapporterer at VPN-et er nede, og transportteamet rapporterer at tunnelen er i orden. En trafikktekniske LSP og et MPLS L3VPN svarer på forskjellige spørsmål: den ene flytter merkede pakker gjennom kjernen, den andre avgjør hvilken rutekontekst en pakke tilhører. Når de blandes sammen, går diskusjonen i sirkel, fordi hver side måler et forskjellig objekt, og begge målinger er gyldige.
Transport oppe og tjeneste nede er en normal tilstand
En LSP kan være etablert, føre trafikk og være synlig i alle overvåkingssystemer, mens kundetjenesten forblir ubrukelig. Ingenting ved den kombinasjonen er selvmotsigende, fordi tunnelen ikke har noen mening om hvorvidt et fjernt prefiks finnes, om en importpolicy godtok det, eller om den tilknyttede kretsen slipper gjennom rammer.
Symptomet som vanligvis avslører forvirringen, er asymmetrisk: ping fra PE-loopback lykkes mens en vert på kundens LAN ikke får noe, eller omvendt. Skriv ned hvilke adresser som virket før du danner en teori. Når du først merker at du tester to forskjellige objekter, er neste steg å lese etikettstakken i stedet for å diskutere hvilken graf som er riktig. To adresser, to eiere og vanligvis to forskjellige personer som hver tror at den andre har ødelagt noe.
Les stakken som to ansvar
Den nederste etiketten tilhører tjenesten, og den øverste etiketten tilhører ruten. RFC 4364 beskriver rekkefølgen enkelt: først påføres VPN-ruteetiketten, deretter tunneleres den merkede pakken mot BGP-nestehopp, hvor en trafikkteknisk tunnel skyver sin egen etikett på toppen.
| 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 velger tjenesteetiketten behandlingen, som kan være et VRF-oppslag eller en tilknytningsbeslutning. Den etiketten kan ikke byttes ut med en som bare krysser kjernen, og de to er ikke utskiftbare selv når begge opptrer i samme stakk på samme grensesnitt.
Hva RSVP-suksess beviser og ikke beviser
RSVP-TE etablerer eksplisitt rutete LSP-er, med eller uten ressursreservasjoner, noe som er en konkret og nyttig garanti om veien en pakke tar gjennom kjernen. Det er ikke en uttalelse om kunderuter, og et konfigurert tunnelnavn er slett ikke en rute.
Tilstedeværelsen av RSVP gir heller ikke et løfte om ytelse ende-til-ende. Båndbreddereservasjon på én LSP sier ingenting om den tilknyttede kretsen, kundens egen aksesslinje eller køoppførselen ved den fjerne kanten. Å behandle det som en garanti gir selvsikre svar på spørsmål ingen stilte. Hvis kravet virkelig er en båndbreddeforpliktelse, må den settes sammen av delene som faktisk håndhever en slik forpliktelse, og LSP-en er bare midten av den kjeden.
Kontroller i rekkefølge, og stopp deretter
Arbeid fra transporten og utover og stopp ved det første trinnet som feiler, fordi hvert senere trinn forutsetter at de tidligere holdt. Bekreft først at LSP-en er etablert, og at videresendingsoppføringen for tjenesteprefikset faktisk peker på den. Bekreft deretter at VPN-ruten finnes i riktig tabell, at etikettbindingen er til stede, og at importpolicyen godtok den. Bekreft deretter tilknytningen: grensesnittet, innkapslingen og, der det gjelder, VLAN-identifikatoren som tilhører den kontrakten.
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 etter plattform, så behandle de fire linjene som de fire spørsmålene og ikke som et skript. Det viktige er at hver av dem avhører et forskjellig objekt, og det er det som får en feil til å peke på en bestemt eier.
Følg én tillatt forespørsel og ta vare på de gode bevisene
Avslutt med én enkelt reell kundeforespørsel, tillatt av policyen, og svaret på den. Én fungerende flyt ende-til-ende avgjør mer enn en side med telleravlesninger, og den prøver kombinasjonen i stedet for hver del isolert.
Når et senere trinn feiler, bevar den vellykkede LSP-observasjonen i stedet for å bygge transporten på nytt. Å bygge en fungerende tunnel på nytt kan ikke reparere et manglende fjernt prefiks, en feil VRF-tilknytning eller en tilgangsregel for destinasjonen, og det ødelegger beviset som opprinnelig fortalte deg at transporten var sunn.