L3VPN-overdracht: privéroutes, een standaardroute of een volledige tabel?
Wat de CE moet ontvangen, volgt uit waar verkeer dat nergens op past naar buiten gaat. Loop de overdracht door, spreek het faalgeval af en discussieer pas daarna over de tabelgrootte.
Je circuit is in bedrijf, de VRF is geconfigureerd en de provider stelt een korte vraag die de rest van het ontwerp bepaalt: wat de customer edge moet ontvangen? Drie antwoorden zijn gangbaar en geen ervan volgt uit het feit dat er een labelstack bestaat. Het zijn dienstbeslissingen over waar verkeer de vestiging verlaat.
De overdracht op volgorde doorlopen is de goedkoopste manier om dit goed te doen. Je begint bij wat er gebeurt met verkeer dat nergens op past, schrijft daarna de privéprefixen en hun faalgedrag op, en pas daarna praat je over hoe groot een feed is die je bereid bent te dragen.
Begin bij het verkeer waar niemand op had gerekend
Stel één vraag voordat er een prefixlijst verschijnt: waar moet een pakket heen als het op geen enkele privéroute past? Een vestiging met een eigen internetcircuit houdt meestal een lokale standaardroute, zodat gewoon webverkeer via de lokale firewall naar buiten gaat en de provider nooit raakt. In dat ontwerp draagt de VPN alleen de externe privésites, en de specifiekere prefixen doen de selectie.
Een vestiging die een centrale uitgang moet gebruiken is het omgekeerde geval. Daar wijst de standaardroute het dienstverband in, en de provider of de centrale site bezit de doorsturing, de retourroutering en eventuele vertaling. "Standaard naar de VPN" zeggen zonder die eigenaar levert een vestiging op die namen oplost en niets bereikt.
De twee ontwerpen verschillen in hoe een routeringsfout eruitziet, en daarom is gissen duur. Met een lokale standaardroute stuurt een verloren privéroute dat verkeer naar het internet, waar de firewall het weggooit of, erger, iets antwoordt dat je niet bedoelde. Met een centrale standaardroute haalt hetzelfde verlies de internettoegang volledig weg en komt het ticket binnen als "de hele vestiging ligt eruit". Geen van beide fouten is op zichzelf verkeerd, maar slechts één past bij de dienst die je verkocht, en een BGP-configuratie alleen vertelt je niet welke je hebt gebouwd.
Schrijf de privéprefixen op met hun faalgeval
Noem de prefixen die de vestiging moet bereiken en noteer welke daarvan zijn samengevat. Een aggregatie die één bit te breed is, trekt onbekende bestemmingen de VPN in, en dat is alleen goed als de andere kant ze werkelijk bezit en doorstuurt.
Beschrijf daarna het bedoelde gedrag wanneer de privédienst uitvalt. Een aangehouden discard-route houdt verkeer van een ongeoorloofd pad af en levert een schone, verwachte storing op. Een zwevende standaardroute kan de beschikbaarheid behouden door naar een back-uppad te verschuiven, maar alleen als dat back-uppad gemachtigd is om dat verkeer te dragen.
Houd beschikbaarheid en toegestane terugval als twee afzonderlijke eisen in het overdrachtsdocument. Teams die ze samenvoegen, discussiëren uiteindelijk of de vestiging had moeten uitvallen, in plaats van te controleren of het afgesproken beleid is uitgevoerd.
Controleer wat de CE werkelijk heeft geïnstalleerd
Configuratiebedoeling en doorstuurstaat lopen vaak genoeg uiteen dat verificatie in de overdracht hoort, niet in de incidentreview. Op een IOS-XE-customer-edge beantwoorden de drie onderstaande commando's drie verschillende vragen: wat is aangeboden, wat is geaccepteerd en wat wordt werkelijk gebruikt.
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
Voer alle drie uit op de dag van de overdracht en niet een maand later, terwijl iemand zich nog herinnert wat is afgesproken. De eerste uitvoer hangt af van soft-reconfiguration inbound of een opgeslagen route refresh; zonder een van beide kan de CE je niet laten zien wat hij heeft geweigerd. De tweede toont geaccepteerde en beste routes na beleid. De derde vertelt waar de standaardroute werkelijk heen gaat, en dat is de nuttigste regel in de hele overdracht.
Voer dezelfde controles uit op een tweede CE als de site dual-homed is. Asymmetrische acceptatie tussen twee edges is een veelvoorkomende oorzaak van "het werkt vanaf de ene server en niet vanaf de andere", en het is onzichtbaar in een configuratieverschil dat symmetrisch lijkt.
Kwalificeer een grotere feed in plaats van hem aan te nemen
Soms heeft de klant echt internetrouteringsinformatie nodig binnen de VRF, voor policy routing of voor een centrale uitgang die op prefix stuurt. Dat is een eis die je moet benoemen, afbakenen en beprijzen, geen verborgen standaardroute. Er hoort geheugen voor RIB en FIB bij, CPU voor updates, filteronderhoud en een eigenaar voor de resulterende tabel.
Capaciteitsargumenten gaan in beide richtingen mis. Een volledige tabel is binnen een VRF niet verboden, en hij is ook niet gratis. Net zo min kun je de kosten van vandaag afleiden uit een oud routenummer, en een kleinere labeltoewijzing haalt de kosten van het opslaan van routes niet weg.
De specificatie BGP/MPLS IP VPN bespreekt verschillende internettoegangsarrangementen naast de VPN-dienst zelf en verklaart een volledige tabel noch een standaardroute verplicht voor elke klant, en dat is de sectie die je moet aanwijzen wanneer een bewering over "standaardpraktijk" opduikt: RFC 4364.
Sluit de overdracht af door de geadverteerde set, de ontvangen set en de geselecteerde set naast het afgesproken uitgangsbeleid vast te leggen, en door één privébestemming, één bedoelde openbare bestemming en één geval van routeverlies te testen. Een ondertekend verslag van die drie tests beslecht meer discussies dan welke uitspraak dan ook over wat de meeste netwerken doen.