L3VPN-luovutus: yksityiset reitit, oletusreitti vai täysi taulu?

Piirisi on ylhäällä, VRF on määritetty ja palveluntarjoaja esittää lyhyen kysymyksen, joka ratkaisee lopun suunnittelusta: mitä asiakaspään pitää vastaanottaa? Kolme vastausta on tavallisia, eikä mikään niistä seuraa siitä, että leimapino on olemassa. Ne ovat palvelupäätöksiä siitä, mistä liikenne poistuu haarakonttorista.

Luovutuksen läpikäyminen järjestyksessä on halvin tapa tehdä tämä oikein. Aloitat siitä, mitä tapahtuu liikenteelle, joka ei täsmää mihinkään, kirjaat sitten yksityiset etuliitteet ja niiden vikakäyttäytymisen, ja vasta sen jälkeen puhut siitä, kuinka isoa syötettä olet valmis kantamaan.

Aloita liikenteestä, jota kukaan ei suunnitellut

Esitä yksi kysymys ennen kuin mikään etuliiteluettelo ilmestyy: kun paketti ei täsmää mihinkään yksityiseen reittiin, minne sen pitää mennä? Haaralla, jolla on oma internet-piiri, on yleensä paikallinen oletusreitti, joten tavallinen verkkoliikenne poistuu paikallisen palomuurin kautta eikä kosketa palveluntarjoajaa koskaan. Siinä suunnittelussa VPN kuljettaa vain kaukaiset yksityiset kohteet, ja valinnan tekevät tarkemmat etuliitteet.

Haara, jonka on tarkoitus käyttää keskitettyä uloskäyntiä, on päinvastainen tapaus. Siellä oletusreitti osoittaa palveluun, ja palveluntarjoaja tai keskussivusto omistaa edelleenkuljetuksen, paluureitityksen ja mahdollisen käännöksen. "Oletus VPN:ään" ilman tätä omistajaa tuottaa haaran, joka ratkaisee nimiä eikä tavoita mitään.

Kaksi suunnittelua eroavat siinä, miltä reititysvika näyttää, ja siksi arvaaminen on kallista. Paikallisella oletusreitillä kadonnut yksityinen reitti lähettää liikenteen internetiin, jossa palomuuri pudottaa sen tai, pahempaa, jotain vastaa siihen, mitä et tarkoittanut. Keskitetyllä oletusreitillä sama menetys poistaa internet-yhteyden kokonaan ja tiketti saapuu muodossa "koko haara on alhaalla". Kumpikaan vika ei ole itsessään väärin, mutta vain toinen vastaa myymääsi palvelua, eikä pelkkä BGP-kokoonpano kerro, kumman rakensit.

Kirjaa yksityiset etuliitteet ja niiden vikatilanne

Luettele etuliitteet, joihin haaran on päästävä, ja merkitse, mitkä niistä on tiivistetty. Yhden bitin liian leveä aggregaatti vetää tuntemattomat kohteet VPN:ään, mikä on kunnossa vain jos kaukopuoli todella omistaa ne ja välittää ne edelleen.

Kuvaa sitten aiottu käyttäytyminen, kun yksityinen palvelu pettää. Säilytetty hylkäysreitti pitää liikenteen poissa luvattomalta polulta ja tuottaa puhtaan, odotetun katkoksen. Kelluva oletusreitti voi säilyttää käytettävyyden siirtymällä varapolulle, mutta vain jos varapolulla on lupa kuljettaa tätä liikennettä.

Pidä käytettävyys ja sallittu varautuminen kahtena erillisenä vaatimuksena luovutusasiakirjassa. Tiimit, jotka sulauttavat ne, päätyvät väittelemään siitä, olisiko haaran pitänyt kaatua, sen sijaan että tarkistaisivat, toteutettiinko sovittu käytäntö.

Tarkista, mitä CE oikeasti asensi

Kokoonpanon tarkoitus ja edelleenkuljetuksen tila eroavat riittävän usein, jotta tarkistus kuuluu luovutukseen eikä häiriöselvitykseen. IOS-XE-asiakaspäässä alla olevat kolme komentoa vastaavat kolmeen eri kysymykseen: mitä tarjottiin, mitä hyväksyttiin ja mitä tosiasiassa käytetään.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Aja kaikki kolme luovutuspäivänä eikä kuukautta myöhemmin, kun joku vielä muistaa, mitä sovittiin. Ensimmäinen tuloste riippuu soft-reconfiguration inbound-asetuksesta tai tallennetusta reittien päivityksestä; ilman kumpaakaan CE ei voi näyttää, mitä se hylkäsi. Toinen näyttää hyväksytyt ja parhaat reitit käytännön jälkeen. Kolmas kertoo, minne oletusreitti todella menee, ja se on koko luovutuksen hyödyllisin rivi.

Aja samat tarkistukset toisella CE:llä, jos sivustolla on kaksi yhteyttä. Epäsymmetrinen hyväksyntä kahden reunan välillä on tavallinen syy lauseelle "toimii toiselta palvelimelta eikä toiselta", eikä se näy kokoonpanon erossa, joka näyttää symmetriseltä.

Perustele isompi syöte sen sijaan että olettaisit sen

Joskus asiakas todella tarvitsee internetreittien tiedot VRF:n sisällä, käytäntöperusteiseen reititykseen tai keskitettyyn uloskäyntiin, joka ohjaa etuliitteen mukaan. Se on vaatimus, joka pitää ilmoittaa, rajata ja hinnoitella, ei piilotettu oletus. Sen mukana tulevat muisti RIB:lle ja FIB:lle, suoritinteho päivityksille, suodattimien ylläpito ja syntyvän taulun omistaja.

Kapasiteettiargumentit menevät pieleen molempiin suuntiin. Täysi taulu ei ole VRF:n sisällä kielletty, eikä se ole ilmainenkaan. Samoin et voi päätellä nykyistä kustannusta vanhasta reittimäärästä, eikä pienempi leimojen jako poista reittien tallennuksen kustannusta.

BGP/MPLS IP VPN -määritys käsittelee useita internet-yhteyden järjestelyjä VPN-palvelun ohella eikä julista täyttä taulua tai oletusreittiä pakolliseksi jokaiselle asiakkaalle, ja juuri se kohta kannattaa osoittaa, kun väite "vakiokäytännöstä" ilmestyy: RFC 4364.

Sulje luovutus kirjaamalla ilmoitettu joukko, vastaanotettu joukko ja valittu joukko sovitun uloskäyntikäytännön viereen ja testaamalla yksi yksityinen kohde, yksi aiottu julkinen kohde ja yksi reitin menetys. Kolmen testin allekirjoitettu kirjaus ratkaisee enemmän väittelyitä kuin mikään väite siitä, mitä useimmat verkot tekevät.