Har VPNv4 brug for MPLS i kernen? Ikke nødvendigvis
BGP VPNv4 forhandler en rutedistributionskontekst, ikke en videresendelsesvej. Adskil import, næste-hop-opløsning og den indkapsling, du kan køre.
At aktivere VPNv4-adressefamilien mellem to routere skaber kun en rutedistributionskontekst og intet mere. Det installerer ikke en videresendelsesvej og fortæller ikke, hvilken indkapsling der skal bære en kundepakke til det fjerne endepunkt. Når disse to fakta er adskilt, bliver spørgsmålet »kræver det MPLS i kernen« et snævrere spørgsmål, der kan besvares, om den dataplan, platformen understøtter.
Hvad adressefamilien egentlig forhandler
Multiprotokol-BGP bærer VPNv4-netværkslagets tilgængelighedsoplysninger under AFI 1 og SAFI 128, og hver post parrer en rutedistinguisher med et præfiks og en etiket. Sessionen forhandler, at begge parter kan kode og afkode disse oplysninger. Det, den ikke forhandler, er en dataplan. Alt efter dette afsnit handler om videresendelse, og intet af det afgøres af, at sessionen kommer op.
Så en vellykket session er bevis på kontrolplanens formåen, ikke på videresendelse. En router kan have tusindvis af VPNv4-poster og alligevel tabe hver kundepakke, og det er derfor, de to fejlklasser bliver forvekslet i første omgang.
Bemærk etiketten i NLRI. Det er en serviceetiket, bundet til et præfiks inde i en VRF, og den har en videresendelsesrolle, når pakken når det udgående endepunkt. Om nogen transit-enhed læser den, er en separat designbeslutning.
Modtagelse, import og videresendelse er tre trin
At modtage en rute, at have tilladelse til at bruge den og at kunne videresende med den udføres af forskellige dele af enheden. BGP gemmer det, den hører; importpolitik og rute-target-match afgør, hvilken VRF der må overveje den; derefter skal videresendelsesplanen opløse det annoncerede næste hop til noget, den faktisk kan sende ud 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 trin, de mest overraskende fejl bor. En rute kan være til stede i BGP-tabellen, gyldig og endda bedst, mens VRF-rutetabellen forbliver tom, fordi intet rute-target matchede importlisten. Intet logger en protokolfejl, fordi der ikke opstod nogen protokolfejl.
Det sidste trin er der, hvor platformsunderstøttelsen viser sig. Et næste hop, der er nåbart i underlaget, er ikke automatisk opløseligt som VPN-servicetransport, og enheden kan kræve en bestemt tunneltype, en bestemt etiketoperation eller begge dele. At læse opløsningsstatus er mere informativt end at læse ruteantallet.
En IP-kerne kan bære en stak, den aldrig skifter
Den skelnen, der er værd at bevare, er mellem »kernen kører ikke MPLS« og »der findes ingen etiket noget sted i tjenesten«. Det er forskellige påstande, og kun den første er en udtalelse om transit-enheder. RFC 4023 definerer at bære MPLS gennem IP- eller GRE-tunneler, og det er den mekanisme, der gør den anden påstand mulig på en ren IP-kerne.
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 meaningfulTransit-routere videresender efter den ydre IP-destination og har hverken brug for kundepræfikserne eller indbygget etiketskift. I den fjerne ende fjernes den ydre tunnel, og serviceetiketten genoptager sit arbejde. Kernen flyttede en uigennemsigtig nyttelast, hvilket er præcis, hvad et IP-netværk er godt til.
Det, dette design ikke giver dig, er en universel garanti. Det er ikke bevis for, at enhver router opløser ethvert VPNv4-næste-hop over enhver GRE-grænseflade, og det er ikke en grund til at slette en fungerende indbygget MPLS-konfiguration. Det er et modeksempel på den universelle påstand, og det praktiske spørgsmål forbliver lokalt for platformen. Noter det spørgsmål som en platformsbegrænsning frem for en protokolregel.
Gå kæden igennem på boksen, indtil den brækker
Start ved den modtagne rute, og stop ved det første trin, der fejler, fordi de senere trin ikke kan diagnosticeres, mens et tidligere er brækket. Fire kommandoer dækker det meste af det 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_ALæs dem som en sekvens og ikke som fire uafhængige kontroller. Den første bekræfter, at familien er aktiv, og at peer'en udveksler ruter; den anden viser, om præfikset ankom med et brugbart næste hop; den tredje beviser importberettigelse; den fjerde viser, om videresendelsesplanen bandt en etiket eller tunnel til den.
Test derefter arbejdsbelastningens vej i begge retninger, med en MTU, der overlever indkapsling. GRE tilføjer headerbytes, og en vej, der består små prober, kan fejle på fuldstore pakker i kun én retning, hvilket ligner en applikationsfejl snarere end en transportfejl.
To driftsnoter lukker kredsløbet. GRE er indkapsling, ikke fortrolighed, så et utroværdigt transitnetværk har brug for en understøttet sikkerhedsordning ovenpå i stedet for en antagelse. Og noter, hvilken indkapsling platformen faktisk understøtter, før designgennemgangen, fordi det ene svar afgør, om en ren IP-kerne er et gyldigt valg eller en plan, der ikke kan videresende.