Ĉu VPNv4 bezonas MPLS en la kerno? Ne nepre
BGP VPNv4 interkonsentas itineran distribuan kuntekston, ne plusendan vojon. Apartigu importadon, solvon de la sekva salto kaj la enkapsuligon, kiun vi povas uzi.
Ŝalti la adresan familion VPNv4 inter du enkursigiloj kreas nur itineran distribuan kuntekston kaj nenion pli. Ĝi ne instalas plusendan vojon kaj ne diras, kiu enkapsuligo portos klientan paketon al la malproksima finpunkto. Post kiam tiuj du faktoj estas apartigitaj, la demando «ĉu tio bezonas MPLS en la kerno» fariĝas pli mallarĝa kaj respondebla demando pri la datumtavolo, kiun la platformo subtenas.
Kion la adresa familio efektive interkonsentas
Multprotokola BGP portas la atingeblan informon de la VPNv4-rettavolo sub AFI 1 kaj SAFI 128, kaj ĉiu rikordo parigas itineran distingilon kun prefikso kaj etikedo. La sesio interkonsentas, ke ambaŭ flankoj povas kodi kaj malkodi tiun informon. Kion ĝi ne interkonsentas, estas datumtavolo. Ĉio post ĉi tiu alineo koncernas plusendadon, kaj nenio el ĝi estas decidita per la ekfunkciigo de la sesio.
Do sukcesa sesio estas pruvo pri kapablo de la regtavolo, ne pri plusendado. Enkursigilo povas teni milojn da VPNv4-rikordoj kaj tamen forĵeti ĉiun klientan paketon, kaj tial la du klasoj de fiasko estas konfuzitaj unuavice.
Rimarku la etikedon en la NLRI. Ĝi estas serva etikedo, ligita al prefikso ene de VRF, kaj ĝi havas plusendan rolon, kiam la paketo atingas la eligan finpunkton. Ĉu iu ajn transita aparato legas ĝin, estas aparta dezajna decido.
Ricevo, importado kaj plusendado estas tri paŝoj
Ricevi itineron, rajtis uzi ĝin, kaj povi plusendi per ĝi estas plenumataj de diversaj partoj de la aparato. BGP konservas tion, kion ĝi aŭdas; importa politiko kaj kongruo de itinera celo decidas, kiun VRF rajtas konsideri ĝin; poste la plusenda tavolo devas solvi la anoncitan sekvan salton en ion, kion ĝi povas efektive puŝi sur draton.
| 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 |
Ĝuste en tiu meza paŝo loĝas la plej surprizaj fiaskoj. Itinero povas ĉeesti en la BGP-tabelo, valida kaj eĉ la plej bona, dum la VRF-itinertabelo restas malplena ĉar neniu itinera celo kongruis kun la importa listo. Nenio registras protokolan eraron, ĉar neniu protokola eraro okazis.
La lasta paŝo estas kie montriĝas la subteno de la platformo. Sekva salto atingebla en la suba tavolo ne estas aŭtomate solvebla kiel transporto de VPN-servo, kaj la aparato eble postulas specifan tunelan tipon, specifan etikedan operacion aŭ ambaŭ. Legi la solvan staton estas pli informa ol legi la itineran nombron.
IP-kerno povas porti stakon, kiun ĝi neniam komutas
La distingo inda konservi estas inter «la kerno ne funkciigas MPLS» kaj «nenie en la servo ekzistas etikedo». Tiuj estas malsamaj asertoj, kaj nur la unua estas deklaro pri transitaj aparatoj. RFC 4023 difinas portadon de MPLS tra IP aŭ GRE-tuneloj, kaj tio estas la mekanismo, kiu ebligas la duan aserton sur tute IP-kerno.
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 meaningfulTransitaj enkursigiloj plusendas laŭ la ekstera IP-celo kaj bezonas nek la klientajn prefiksojn nek denaskan etikedan komutadon. Ĉe la malproksima fino la ekstera tunelo estas forigita kaj la serva etikedo rekomencas sian taskon. La kerno movis netravideblan ŝarĝon, kio estas ĝuste tio, por kio IP-reto bonas.
Kion ĉi tiu dezajno ne donas al vi, estas universala garantio. Ĝi ne estas pruvo, ke ĉiu enkursigilo solvas ĉiun sekvan salton VPNv4 tra iu ajn GRE-interfaco, kaj ĝi ne estas kialo forigi funkciantan denaskan MPLS-agordon. Ĝi estas kontraŭekzemplo al la universala aserto, kaj la praktika demando restas loka al la platformo. Notu tiun demandon kiel platforman limigon prefere ol protokolan regulon.
Iru la ĉenon sur la skatolo ĝis ĝi rompiĝos
Komencu de la ricevita itinero kaj haltu ĉe la unua paŝo, kiu malsukcesas, ĉar la postaj paŝoj ne povas esti diagnozitaj dum pli frua estas difektita. Kvar komandoj kovras plejparton de tio en tipa efektivigo.
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_ALegu ilin kiel sinsekvon, ne kiel kvar sendependajn kontrolojn. La unua konfirmas, ke la familio estas aktiva kaj ke la samtavolano interŝanĝas itinerojn; la dua montras, ĉu la prefikso alvenis kun uzebla sekva salto; la tria pruvas importan taŭgecon; la kvara montras, ĉu la plusenda tavolo ligis etikedon aŭ tunelon al ĝi.
Poste testu la laborŝarĝan vojon en ambaŭ direktoj, kun MTU, kiu postvivas enkapsuligon. GRE aldonas kapliniojn bajtojn, kaj vojo, kiu trapasas malgrandajn provojn, povas malsukcesi ĉe plengrandaj paketoj nur en unu direkto, kio aspektas kiel aplikaĵa fiasko, ne transporta.
Du funkciaj notoj fermas la buklon. GRE estas enkapsuligo, ne konfideco, do nefidinda transita reto bezonas subtenatan sekurecan aranĝon supre, ne supozon. Kaj notu, kiun enkapsuligon la platformo vere subtenas antaŭ la dezajna revizio, ĉar tiu sola respondo decidas ĉu nur-IP-kerno estas valida elekto aŭ plano, kiu ne povas plusendi.