Tarvitseeko VPNv4 MPLS:ää ytimessä? Ei välttämättä
BGP VPNv4 neuvottelee reittien jakelukontekstin, ei edelleenlähetyspolkua. Erota tuonti, seuraavan hypyn ratkaisu ja kapselointi, jota voit käyttää.
VPNv4-osoiteperheen kytkeminen päälle kahden reitittimen välillä luo vain reittien jakelukontekstin eikä mitään muuta. Se ei asenna edelleenlähetyspolkua eikä kerro, mikä kapselointi kuljettaa asiakaspaketin etäiseen päätepisteeseen. Kun nämä kaksi tosiasiaa on erotettu, kysymys ”tarvitseeko tämä ytimessä MPLS:ää” muuttuu kapeammaksi ja vastattavaksi kysymykseksi alustan tukemasta datatasosta.
Mitä osoiteperhe oikeastaan neuvottelee
Moniprotokolla-BGP kuljettaa VPNv4-verkkokerroksen tavoitettavuustietoa AFI 1:n ja SAFI 128:n alla, ja jokainen merkintä pariuttaa reitinerottelijan etuliitteeseen ja leimaan. Istunto neuvottelee, että molemmat osapuolet pystyvät koodaamaan ja dekoodaamaan kyseisen tiedon. Sitä se ei neuvottele, mikä on datataso. Kaikki tämän kappaleen jälkeen koskee edelleenlähetystä, eikä mitään siitä ratkaista istunnon nousemisella.
Onnistunut istunto on siis todiste ohjaustason kyvykkyydestä, ei edelleenlähetyksestä. Reititin voi pitää tuhansia VPNv4-merkintöjä ja silti pudottaa jokaisen asiakaspaketin, ja juuri siksi nämä kaksi vikaluokkaa sekoitetaan aluksi.
Huomaa NLRI:n leima. Se on palveluleima, joka on sidottu VRF:n sisäiseen etuliitteeseen, ja sillä on edelleenlähetysrooli, kun paketti saavuttaa lähtöpäätepisteen. Lukeeko jokin transiittilaite sen, on erillinen suunnittelupäätös.
Vastaanotto, tuonti ja edelleenlähetys ovat kolme vaihetta
Reitin vastaanottamisen, sen käyttöön oikeuttamisen ja sillä edelleenlähettämisen kyvyn hoitavat laitteen eri osat. BGP tallentaa sen, mitä kuulee; tuontikäytäntö ja reittikohteen täsmäytys päättävät, mikä VRF saa ottaa sen huomioon; sen jälkeen edelleenlähetystason on ratkaistava ilmoitettu seuraava hyppy joksikin, jonka se voi todella työntää johtoon.
| 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 |
Juuri tuossa keskimmäisessä vaiheessa asuvat yllättävimmät viat. Reitti voi olla BGP-taulukossa, kelvollinen ja jopa paras, kun taas VRF:n reittitaulukko pysyy tyhjänä, koska mikään reittikohde ei täsmännyt tuontiluettelon kanssa. Mikään ei kirjaa protokollavirhettä, koska protokollavirhettä ei tapahtunut.
Viimeinen vaihe on paikka, jossa alustan tuki näkyy. Aliverkossa tavoitettavissa oleva seuraava hyppy ei ole automaattisesti ratkaistavissa VPN-palvelun kuljetukseksi, ja laite voi vaatia tietyn tunnelityypin, tietyn leimaoperaation tai molemmat. Ratkaisun tilan lukeminen on informatiivisempaa kuin reittien määrän lukeminen.
IP-ydin voi kuljettaa pinoa, jota se ei koskaan kytke
Säilyttämisen arvoinen ero on sen välillä, että ”ydin ei aja MPLS:ää” ja että ”palvelussa ei ole leimaa missään”. Ne ovat eri väitteitä, ja vain ensimmäinen koskee transiittilaitteita. RFC 4023 määrittelee MPLS:n kuljettamisen IP- tai GRE-tunneleiden kautta, ja se on mekanismi, joka tekee toisesta väitteestä mahdollisen täysin IP-pohjaisessa ytimessä.
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 meaningfulTransiittireitittimet välittävät ulomman IP-kohteen perusteella eivätkä tarvitse asiakasetuliitteitä eivätkä natiivia leimakytkentää. Kaukaisessa päässä ulompi tunneli poistetaan ja palveluleima jatkaa työtään. Ydin siirsi läpinäkymätöntä hyötykuormaa, ja juuri siinä IP-verkko on hyvä.
Sen, mitä tämä suunnittelu ei anna sinulle, on yleismaailmallinen tae. Se ei ole todiste siitä, että jokainen reititin ratkaisee jokaisen VPNv4-seuraavan hypyn minkä tahansa GRE-liitännän kautta, eikä syy poistaa toimivaa natiivia MPLS-kokoonpanoa. Se on vastaesimerkki yleismaailmalliselle väitteelle, ja käytännön kysymys pysyy alustakohtaisena. Kirjaa tämä kysymys alustan rajoituksena, ei protokollasääntönä.
Käy ketju läpi laitteella, kunnes se katkeaa
Aloita vastaanotetusta reitistä ja pysähdy ensimmäisessä vaiheessa, joka epäonnistuu, koska myöhempiä vaiheita ei voi diagnosoida, kun aikaisempi on rikki. Neljä komentoa kattaa siitä suurimman osan tyypillisessä toteutuksessa.
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_ALue ne sarjana, älä neljänä itsenäisenä tarkistuksena. Ensimmäinen vahvistaa, että perhe on aktiivinen ja vastapuoli vaihtaa reittejä; toinen näyttää, saapuiko etuliite käyttökelpoisen seuraavan hypyn kanssa; kolmas todistaa tuontikelpoisuuden; neljäs näyttää, sitoiko edelleenlähetystaso siihen leiman tai tunnelin.
Testaa sitten työkuorman polku molempiin suuntiin MTU:lla, joka kestää kapseloinnin. GRE lisää otsikkotavuja, ja polku, joka läpäisee pienet mittaukset, voi epäonnistua täysikokoisissa paketeissa vain yhteen suuntaan, mikä näyttää sovellusvialta eikä kuljetusvialta.
Kaksi käyttöhuomautusta sulkee silmukan. GRE on kapselointia, ei luottamuksellisuutta, joten epäluotettava transiittiverkko tarvitsee päälle tuetun turvajärjestelyn eikä oletusta. Ja kirjaa ennen suunnittelukatselmusta, mitä kapselointia alusta todella tukee, koska se yksi vastaus ratkaisee, onko pelkkä IP-ydin kelvollinen valinta vai suunnitelma, joka ei pysty välittämään.