VPNv4 tussen AS'en: wat het contract voor labeldoorgifte vereist

Een VPNv4-label op een AS-grensrouter lezen zegt u weinig tot u weet welk inter-AS-model de overdracht implementeert. Het label is geen eigenschap van de route op zichzelf; het legt een afspraak vast over inkapseling en aflevering tussen twee routers. Stel het model vast voordat u de weergave leest. Anders debugt u een contract dat niemand heeft opgeschreven.

Welk model de grens implementeert

De VRF-naar-VRF-opstelling verbindt overeenkomende VRF's via gerouteerde aansluitingen. Elke kant ziet de andere als een klantrand-buur en ze wisselen gewone IPv4-routes uit, dus niets aan die grens heeft MPLS nodig.

Een tweede opstelling wisselt gelabelde VPNv4-routes uit tussen de grensrouters zelf. Dat werkt alleen met een samenhangend labelgeschakeld pad over de interconnect en een route-target-distributie plus vertrouwensmodel dat beide kanten accepteren. Ontbreekt een van beide stukken, dan is het model niet in gebruik, wat de configuratie ook suggereert.

De derde verdeelt gelabelde PE-bereikbaarheid terwijl de VPN-routes tussen eindpunten of route-reflectors over AS'en reizen. Elk van de drie laat ander werk aan de grens achter, en het controlevlak van de een mengen met de interfaceaannames van de ander is de klassieke fout. Die mismatch komt meestal naar voren als een label dat aan de ene kant klopt en aan de andere kant verdwijnt.

Lees een prefix van begin tot eind

Neem een geautoriseerd klantprefix en loop het na. Kijk wat er aangekondigd is, wat er aankwam, de volgende hop, het label en het importbeleid dat het toeliet. Kijk daarna naar hoe de router de doorgifte naar die volgende hop oplost, want daar wordt een label een pakket. Slaat u een van beide helften over, dan beschrijft u een controlevlak dat mogelijk geen verkeer verplaatst. De twee lezingen betekenen alleen samen iets.

Het nummer is lokaal. Het betekent iets ten opzichte van de router die het toekende en het pad dat pakketten daarheen draagt, en daarom kan dezelfde waarde twee keer voorkomen en twee verschillende dingen betekenen. Vergelijk het met wat de ontvangende kant zegt te hebben ontvangen.

Het label is lokaal, en de belofte ook

De capaciteit wordt aan beide uiteinden van de interconnect gecontroleerd, niet aan een. Een commando op uw interface doet niets met de interface van de naburige provider, en een route die BGP accepteerde verplicht de buur op zichzelf niet om een gelabeld pakket door te geven.

RFC 4364 beperkt gelabelde VPNv4-peering tot betrouwbare opstellingen en waarschuwt tegen het accepteren van labels die nooit aan die peer zijn aangekondigd. Dat is evenzeer een beveiligingsuitspraak als een protocoluitspraak. Houd de routeringsrelatie van het publieke internet weg van de uitwisseling van privé-VPN-routes. Is de interconnect gewoon IP, verwacht dan niet dat een label die overleeft. En waar de link gelabeld is, bevestig dat het buitenste transportlabel bij elke hop correct wordt omgewisseld.

Een label dat aan de ene kant klopt en aan de andere kant verdwijnt, is meestal die mismatch, geen routeringsfout.

Wat u bij acceptatie opschrijft

Acceptatie is een pakkettest, geen tabelcontrole. Volg een klantpakket tot in de externe VRF en volg het antwoord terug, en schrijf dan op welk model de overdracht implementeert. Voeg de overdrachtsverantwoordelijken aan beide kanten toe en of de grens gewoon IP of gelabeld verkeer draagt.

Die notitie is wat de volgende operator dezelfde labelweergave correct laat lezen. Zonder die notitie wordt het model uit de configuratie afgeleid, en afgeleide aannames zijn de manier waarop dezelfde fout zich herhaalt. De inter-AS-sectie van RFC 4364 is de plek om te bepalen welk model bedoeld was.