Het VPNv4 MPLS in die kern nodig? Nie noodwendig nie
BGP VPNv4 onderhandel ’n roeteverspreidingskonteks, nie ’n aanstuurpad nie. Skei invoer, volgende-hop-resolusie en die enkapsulering wat jy kan gebruik.
Om die VPNv4-adresfamilie tussen twee routers aan te skakel, skep net ’n roeteverspreidingskonteks en niks meer nie. Dit installeer nie ’n aanstuurpad nie en sê nie watter enkapsulering ’n klantpakket na die afgeleë eindpunt sal dra nie. Sodra daardie twee feite geskei is, word die vraag “het dit MPLS in die kern nodig” ’n smaller en beantwoordbare vraag oor die platform se ondersteunde data-vlak.
Wat die adresfamilie werklik onderhandel
Multiprotokol-BGP dra die VPNv4-netwerklaagbereikbaarheidsinligting onder AFI 1 en SAFI 128, en elke inskrywing paar ’n roete-onderskeier met ’n voorvoegsel en ’n etiket. Die sessie onderhandel dat beide sprekers daardie inligting kan enkodeer en dekodeer. Wat dit nie onderhandel nie, is ’n data-vlak. Alles na hierdie paragraaf handel oor aanstuur, en niks daarvan word deur die sessie wat opkom besleg nie.
Dus is ’n suksesvolle sessie bewyse van beheervlakvermoë, nie van aanstuur nie. ’n Router kan duisende VPNv4-inskrywings hou en steeds elke klantpakket laat val, en dit is waarom die twee foutklasse in die eerste plek verwar word.
Let op die etiket in die NLRI. Dit is ’n diensetiket wat aan ’n voorvoegsel binne ’n VRF gebind is, en dit het ’n aanstuurrol sodra die pakket die uitgang-eindpunt bereik. Of enige deurvoerder dit lees, is ’n aparte ontwerpbesluit.
Ontvangs, invoer en aanstuur is drie stappe
Om ’n roete te ontvang, dit te mag gebruik en daarmee te kan aanstuur, word deur verskillende dele van die toestel gedoen. BGP stoor wat dit hoor; invoerbeleid en roete-teiken-passing besluit watter VRF dit mag oorweeg; die aanstuurvlak moet dan die geadverteerde volgende hop oplos in iets wat dit werklik op ’n draad kan stoot.
| 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 |
Daardie middelste stap is waar die meeste verrassende foute woon. ’n Roete kan in die BGP-tabel teenwoordig wees, geldig en selfs die beste, terwyl die VRF-roetetabel leeg bly omdat geen roete-teiken by die invoerlys gepas het nie. Niks teken ’n protokolfoon aan nie, want geen protokolfoon het voorgekom nie.
Die laaste stap is waar platformondersteuning wys. ’n Volgende hop wat in die onderlaag bereikbaar is, is nie outomaties oplosbaar as ’n VPN-diensvervoer nie, en die toestel kan ’n spesifieke tonneltipe, ’n spesifieke etiketbewerking of albei vereis. Om die resolusietoestand te lees, is meer insiggewend as om die roetetelling te lees.
’n IP-kern kan ’n stapel dra wat dit nooit skakel nie
Die onderskeid wat die moeite werd is om te hou, is tussen “die kern loop nie MPLS nie” en “geen etiket bestaan enige plek in die diens nie”. Dit is verskillende bewerings, en slegs die eerste is ’n stelling oor deurvoertoestelle. RFC 4023 definieer die dra van MPLS deur IP- of GRE-tonnels, wat die meganisme is wat die tweede bewering op ’n alles-IP-kern moontlik maak.
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 meaningfulDeurvoerrouters stuur op die buitenste IP-bestemming aan en het nóg die klantvoorvoegsels nóg inheemse etiketwisseling nodig. Aan die verre kant word die buitenste tonnel verwyder en die diensetiket hervat sy werk. Die kern het ’n ondeursigtige vrag geskuif, wat presies is waarvoor ’n IP-netwerk goed is.
Wat hierdie ontwerp jou nie gee nie, is ’n universele waarborg. Dit is nie bewys dat elke router elke VPNv4-volgende-hop oor enige GRE-koppelvlak oplos nie, en dit is nie ’n rede om ’n werkende inheemse MPLS-konfigurasie te skrap nie. Dit is ’n teenvoorbeeld vir die universele bewering, en die praktiese vraag bly plaaslik by die platform. Teken daardie vraag aan as ’n platformbeperking eerder as ’n protokolreël.
Stap die ketting op die toestel deur tot dit breek
Begin by die ontvangde roete en stop by die eerste stap wat faal, want die latere stappe kan nie gediagnoseer word terwyl ’n vroeëre een gebreek is nie. Vier opdragte dek die meeste daarvan op ’n tipiese 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_ALees hulle as ’n reeks eerder as vier onafhanklike kontroles. Die eerste bevestig dat die familie aktief is en dat die eweknie roetes uitruil; die tweede wys of die voorvoegsel met ’n bruikbare volgende hop aangekom het; die derde bewys invoerbaarheid; die vierde wys of die aanstuurvlak ’n etiket of tonnel daaraan gebind het.
Toets dan die werklaspad in albei rigtings, met ’n MTU wat enkapsulering oorleef. GRE voeg koptekstebytes by, en ’n pad wat klein peilings slaag, kan op volgrootte-pakkette in slegs een rigting faal, wat soos ’n toepassingsfout lyk eerder as ’n vervoerfout.
Twee operasionele notas sluit die kring. GRE is enkapsulering, nie vertroulikheid nie, so ’n onvertroude deurvoernetwerk het ’n ondersteunde sekuriteitsreëling bo-op nodig eerder as ’n aanname. En teken aan watter enkapsulering die platform werklik ondersteun voor die ontwerphersiening, want daardie enkele antwoord besluit of ’n slegs-IP-kern ’n geldige keuse is of ’n plan wat nie kan aanstuur nie.