Behöver VPNv4 MPLS i kärnan? Inte nödvändigtvis

Att slå på VPNv4-adressfamiljen mellan två routrar skapar bara en ruttfördelningskontext och inget mer. Det installerar inte en vidarebefordringsväg och säger inte vilken inkapsling som ska bära ett kundpaket till den avlägsna ändpunkten. När dessa två fakta har separerats blir frågan «behöver detta MPLS i kärnan» en snävare och besvarbar fråga om det dataplan som plattformen stöder.

Vad adressfamiljen egentligen förhandlar

Multiprotokoll-BGP bär tillgänglighetsinformationen för VPNv4-nätverkslagret under AFI 1 och SAFI 128, och varje post parar en ruttutskiljare med ett prefix och en etikett. Sessionen förhandlar att båda parterna kan koda och avkoda den informationen. Det den inte förhandlar är ett dataplan. Allt efter detta stycke handlar om vidarebefordran, och inget av det avgörs av att sessionen kommer upp.

Så en lyckad session är bevis på kontrollplanets förmåga, inte på vidarebefordran. En router kan hålla tusentals VPNv4-poster och ändå släppa varje kundpaket, och det är därför de två felklasserna blandas ihop från början.

Lägg märke till etiketten i NLRI. Det är en tjänsteetikett, bunden till ett prefix inne i en VRF, och den har en vidarebefordringsroll när paketet når den utgående ändpunkten. Om någon transitutrustning läser den är en separat designbeslut.

Mottagning, import och vidarebefordran är tre steg

Att ta emot en rutt, att ha tillstånd att använda den och att kunna vidarebefordra med den utförs av olika delar av enheten. BGP lagrar det den hör; importpolicy och ruttmål-matchning avgör vilken VRF som får överväga den; därefter måste vidarebefordringsplanet lösa upp nästa hopp som annonseras till något det faktiskt kan skjuta ut på en ledning.

Det är i detta mellersta steg de mest överraskande felen bor. En rutt kan finnas i BGP-tabellen, vara giltig och till och med bäst, medan VRF-rutttabellen förblir tom eftersom inget ruttmål matchade importlistan. Ingenting loggar ett protokollfel, eftersom inget protokollfel inträffade.

Det sista steget är där plattformsstödet visar sig. Ett nästa hopp som är nåbart i underlaget är inte automatiskt upplösbart som VPN-tjänstetransport, och enheten kan kräva en viss tunneltyp, en viss etikettoperation eller båda. Att läsa upplösningsstatusen är mer informativt än att läsa antalet rutter.

En IP-kärna kan bära en stack som den aldrig switchar

Den åtskillnad som är värd att behålla är mellan «kärnan kör inte MPLS» och «det finns ingen etikett någonstans i tjänsten». Det är olika påståenden, och bara det första handlar om transitutrustning. RFC 4023 definierar att bära MPLS genom IP- eller GRE-tunnlar, och det är mekanismen som gör det andra påståendet möjligt på en ren IP-kärna.

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

Transitroutrar vidarebefordrar efter den yttre IP-destinationen och behöver varken kundprefixen eller inbyggd etikettväxling. I den bortre änden tas den yttre tunneln bort och tjänsteetiketten återupptar sitt arbete. Kärnan flyttade en ogenomskinlig nyttolast, och det är precis vad ett IP-nätverk är bra på.

Det denna design inte ger dig är en universell garanti. Det är inte bevis för att varje router löser upp varje VPNv4-nästa-hopp över vilket GRE-gränssnitt som helst, och det är inte skäl att radera en fungerande inbyggd MPLS-konfiguration. Det är ett motexempel på det universella påståendet, och den praktiska frågan förblir lokal för plattformen. Anteckna den frågan som en plattformsbegränsning och inte som en protokollregel.

Gå igenom kedjan på lådan tills den brister

Börja vid den mottagna rutten och stanna vid det första steget som misslyckas, eftersom de senare stegen inte kan diagnostiseras medan ett tidigare är trasigt. Fyra kommandon täcker det mesta av detta 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_A

Läs dem som en sekvens och inte som fyra oberoende kontroller. Den första bekräftar att familjen är aktiv och att peern utbyter rutter; den andra visar om prefixet anlände med ett användbart nästa hopp; den tredje bevisar importbehörighet; den fjärde visar om vidarebefordringsplanet band en etikett eller tunnel till det.

Testa sedan arbetsbelastningens väg i båda riktningarna, med en MTU som överlever inkapsling. GRE lägger till rubrikbyte, och en väg som klarar små prober kan misslyckas på paket i full storlek bara i en riktning, vilket ser ut som ett applikationsfel snarare än ett transportfel.

Två driftanteckningar stänger kretsen. GRE är inkapsling, inte konfidentialitet, så ett icke betrott transitnätverk behöver en stödd säkerhetsordning ovanpå i stället för ett antagande. Och anteckna vilken inkapsling plattformen faktiskt stöder före designgranskningen, eftersom det enda svaret avgör om en ren IP-kärna är ett giltigt val eller en plan som inte kan vidarebefordra.