Treng VPNv4 MPLS i kjernen? Ikkje nødvendigvis

Å slå på VPNv4-adressefamilien mellom to rutarar skaper berre ein rutedistribusjonskontekst og ikkje noko meir. Det installerer ikkje ein videresendingsveg og seier ikkje kva innkapsling som skal bera ein kundepakke til det fjerne endepunktet. Når desse to fakta er skilde, blir spørsmålet «treng dette MPLS i kjernen» eit snevrare spørsmål som kan svarast på, om dataplanet plattforma støttar.

Kva adressefamilien eigentleg forhandlar om

Multiprotokoll-BGP ber tilgjengelegheitsinformasjonen for VPNv4-nettverkslaget under AFI 1 og SAFI 128, og kvar oppføring parar ein rutedistinguisher med eit prefiks og ei etikett. Sesjonen forhandlar om at begge partar kan kode og dekode denne informasjonen. Det han ikkje forhandlar om, er eit dataplan. Alt etter dette avsnittet handlar om videresending, og ingen av det blir avgjort av at sesjonen kjem opp.

Så ein vellukka sesjon er prov på kontrollplanet si evne, ikkje på videresending. Ein ruter kan halda tusenvis av VPNv4-oppføringar og likevel sleppa kvar kundepakke, og det er derfor dei to feilklassane blir blanda saman i utgangspunktet.

Legg merke til etiketten i NLRI. Det er ei tenesteetikett, bunden til eit prefiks inne i ein VRF, og ho har ei videresendingsrolle når pakken når det utgåande endepunktet. Om noka transit-eining les ho, er ei separat designavgjerd.

Mottak, import og videresending er tre trinn

Å ta imot ein rute, å ha løyve til å bruka ho og å kunna videresenda med ho blir utført av ulike delar av eininga. BGP lagrar det han høyrer; importpolitikk og rute-mål-samsvar avgjer kva VRF som kan vurdera ho; deretter må videresendingsplanet løysa opp det annonserte neste hoppet til noko det faktisk kan dytte ut på ein leidning.

Det er i dette midterste trinnet dei mest overraskande feila bur. Ein rute kan vera til stades i BGP-tabellen, gyldig og til og med best, medan VRF-rutetabellen blir verande tom fordi ingen rute-mål samsvara med importlista. Ingenting loggar ein protokollfeil, fordi det ikkje oppstod nokon protokollfeil.

Det siste trinnet er der plattformstøtta viser seg. Eit neste hopp som er nåbart i underlaget, er ikkje automatisk oppløyseleg som VPN-tenestetransport, og eininga kan krevja ein bestemd tunneltype, ein bestemd etikettoperasjon eller begge delar. Å lesa oppløysingsstatusen er meir informativt enn å lesa ruteantalet.

Ein IP-kjerne kan bera ein stabel han aldri svitsjar

Det skiljet som er verdt å halda på, er mellom «kjernen køyrer ikkje MPLS» og «det finst inga etikett nokon stad i tenesta». Det er ulike påstandar, og berre den første handlar om transit-einingar. RFC 4023 definerer å bera MPLS gjennom IP- eller GRE-tunnelar, og det er mekanismen som gjer den andre påstanden mogleg på ein rein 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 meaningful

Transittrutarar videresender etter den ytre IP-destinasjonen og treng verken kundeprefiksa eller innebygd etikettsvitsjing. I den fjerne enden blir den ytre tunnelen fjerna, og tenesteetiketten held fram med jobben sin. Kjernen flytta ei ugjennomsiktig nyttelast, og det er akkurat det eit IP-nettverk er godt til.

Det denne designen ikkje gir deg, er ei universell garanti. Det er ikkje prov for at kvar ruter løyser opp kvart VPNv4-nestehopp over kva som helst GRE-grensesnitt, og det er ikkje ein grunn til å sletta ein fungerande innebygd MPLS-konfigurasjon. Det er eit moteksempel på den universelle påstanden, og det praktiske spørsmålet blir verande lokalt for plattforma. Noter det spørsmålet som ei plattformavgrensing framfor ein protokollregel.

Gå kjeden gjennom på boksen til han ryker

Start ved den mottatte ruta og stopp ved det første trinnet som feilar, fordi dei seinare trinna ikkje kan diagnostiserast medan eit tidlegare er øydelagt. Fire kommandoar dekkjer det meste av dette i ei 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_A

Les dei som ein sekvens og ikkje som fire uavhengige kontrollar. Den første stadfester at familien er aktiv og at peer-en utvekslar ruter; den andre viser om prefikset kom med eit brukbart neste hopp; den tredje provar importrett; den fjerde viser om videresendingsplanet batt ei etikett eller ein tunnel til det.

Test deretter vegen til arbeidslasta i begge retningar, med ein MTU som overlever innkapsling. GRE legg til header-byte, og ein veg som klarar små prober, kan feila på fullstore pakkar i berre éi retning, noko som ser ut som ein applikasjonsfeil snarare enn ein transportfeil.

To driftsnotat lukkar krinsen. GRE er innkapsling, ikkje konfidensialitet, så eit ikkje-klarert transittnettverk treng ei støtta tryggingsordning oppå i staden for ei antaking. Og noter kva innkapsling plattforma faktisk støttar før designgjennomgangen, fordi det eine svaret avgjer om ein rein IP-kjerne er eit gyldig val eller ein plan som ikkje kan videresenda.