Trenger VPNv4 MPLS i kjernen? Ikke nødvendigvis
BGP VPNv4 forhandler om en rutedistribusjonskontekst, ikke en videresendingsbane. Skill import, neste-hopp-oppslag og innkapslingen du kan kjøre.
Å slå på VPNv4-adressefamilien mellom to rutere skaper bare en rutedistribusjonskontekst og ikke noe mer. Det installerer ikke en videresendingsbane og sier ikke hvilken innkapsling som skal bære en kundepakke til det fjerne endepunktet. Når disse to faktaene er skilt, blir spørsmålet «trenger dette MPLS i kjernen» et snevrere spørsmål som kan besvares, om dataplanet plattformen støtter.
Hva adressefamilien egentlig forhandler om
Multiprotokoll-BGP bærer tilgjengelighetsinformasjonen for VPNv4-nettverkslaget under AFI 1 og SAFI 128, og hver oppføring parer en rutedistinguisher med et prefiks og en etikett. Sesjonen forhandler om at begge parter kan kode og dekode denne informasjonen. Det den ikke forhandler om, er et dataplan. Alt etter dette avsnittet handler om videresending, og ingenting av det avgjøres av at sesjonen kommer opp.
Så en vellykket sesjon er bevis på kontrollplanets evne, ikke på videresending. En ruter kan holde tusenvis av VPNv4-oppføringer og likevel slippe hver kundepakke, og det er derfor de to feilklassene blandes sammen i utgangspunktet.
Legg merke til etiketten i NLRI. Det er en tjenesteetikett, bundet til et prefiks inne i en VRF, og den har en videresendingsrolle når pakken når det utgående endepunktet. Om noen transittenhet leser den, er en separat designbeslutning.
Mottak, import og videresending er tre trinn
Å motta en rute, å ha tillatelse til å bruke den og å kunne videresende med den utføres av ulike deler av enheten. BGP lagrer det den hører; importpolitikk og rute-mål-samsvar avgjør hvilken VRF som kan vurdere den; deretter må videresendingsplanet løse opp det annonserte neste hoppet til noe det faktisk kan dytte ut på en ledning.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
Det er i dette midterste trinnet de mest overraskende feilene bor. En rute kan være til stede i BGP-tabellen, gyldig og til og med best, mens VRF-rutetabellen forblir tom fordi ingen rute-mål samsvarte med importlisten. Ingenting logger en protokollfeil, fordi det ikke oppsto noen protokollfeil.
Det siste trinnet er der plattformstøtten viser seg. Et neste hopp som er nåbart i underlaget, er ikke automatisk oppløselig som VPN-tjenestetransport, og enheten kan kreve en bestemt tunneltype, en bestemt etikettoperasjon eller begge deler. Å lese oppløsningsstatusen er mer informativt enn å lese ruteantallet.
En IP-kjerne kan bære en stabel den aldri svitsjer
Det skillet som er verdt å beholde, er mellom «kjernen kjører ikke MPLS» og «det finnes ingen etikett noe sted i tjenesten». Det er forskjellige påstander, og bare den første handler om transittenheter. RFC 4023 definerer å bære MPLS gjennom IP- eller GRE-tunneler, og det er mekanismen som gjør den andre påstanden mulig på en ren IP-kjerne.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulTransittrutere videresender etter den ytre IP-destinasjonen og trenger verken kundeprefiksene eller innebygd etikettsvitsjing. I den fjerne enden fjernes den ytre tunnelen, og tjenesteetiketten gjenopptar jobben sin. Kjernen flyttet en ugjennomsiktig nyttelast, og det er akkurat det et IP-nettverk er godt til.
Det dette designet ikke gir deg, er en universell garanti. Det er ikke bevis for at enhver ruter løser opp ethvert VPNv4-nestehopp over enhver GRE-grensesnitt, og det er ikke en grunn til å slette en fungerende innebygd MPLS-konfigurasjon. Det er et moteksempel på den universelle påstanden, og det praktiske spørsmålet forblir lokalt for plattformen. Noter det spørsmålet som en plattformbegrensning fremfor en protokollregel.
Gå kjeden gjennom på boksen til den ryker
Start ved den mottatte ruten og stopp ved det første trinnet som feiler, fordi de senere trinnene ikke kan diagnostiseres mens et tidligere er ødelagt. Fire kommandoer dekker det meste av dette i en typisk implementering.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_ALes dem som en sekvens og ikke som fire uavhengige kontroller. Den første bekrefter at familien er aktiv og at peer-en utveksler ruter; den andre viser om prefikset ankom med et brukbart neste hopp; den tredje beviser importberettigelse; den fjerde viser om videresendingsplanet bandt en etikett eller tunnel til det.
Test deretter arbeidsbelastningens vei i begge retninger, med en MTU som overlever innkapsling. GRE legger til header-byte, og en vei som består små prober, kan feile på fullstore pakker i bare én retning, noe som ser ut som en applikasjonsfeil snarere enn en transportfeil.
To driftsnotater lukker kretsen. GRE er innkapsling, ikke konfidensialitet, så et ikke-klarert transittnettverk trenger en støttet sikkerhetsordning oppå i stedet for en antakelse. Og noter hvilken innkapsling plattformen faktisk støtter før designgjennomgangen, fordi det ene svaret avgjør om en ren IP-kjerne er et gyldig valg eller en plan som ikke kan videresende.