RD versus RT in een MPLS VPN: uniekheid versus importbeleid

Twee klantsites kunnen 10.20.0.0/24 adverteren en beide blijven geldig binnen één providernetwerk. De route distinguisher houdt die advertenties gescheiden; de route target bepaalt welke klant-VRF een kopie mag nemen. Ze staan naast elkaar in de configuratie en doen volledig verschillende taken. Ze met elkaar verwarren leidt tot wijzigingen die redelijk lijken en niets oplossen.

Volg één route van de klantrand naar een VRF op afstand en de verdeling wordt concreet: de identiteit wordt toegevoegd voordat de route BGP binnenkomt, en het distributiebeleid wordt geëvalueerd wanneer de route de ontvangende providerrand bereikt.

Een VPN-IPv4-route is een RD plus een IPv4-prefix

RFC 4364 definieert de VPN-IPv4-adressenfamilie als een route distinguisher van acht bytes, gevolgd door een IPv4-adres van vier bytes. De RD wordt vóór het klantprefix geplaatst, zodat twee identieke prefixen van verschillende sites twee verschillende BGP-routes worden.

Die constructie is het volledige uniekheidsmechanisme. De provider heeft niet nodig dat klanten het eens worden over niet-overlappende adresruimte, en een route van de ene site kan een identiek prefix van een andere site niet stilzwijgend vervangen.

Het RD-formaat zelf is een door de beheerder gekozen waarde, meestal een autonoom systeemnummer en een lokaal nummer. De numerieke vorm is een conventie, geen signaal dat de twee velden betekenis delen met een route target dat toevallig dezelfde cijfers gebruikt.

De RD maakt overlappende prefixen onderscheidbaar

Bekijk twee advertenties voor hetzelfde prefix. Site A draagt RD 65000:101 en site B draagt RD 65000:202, beide voor 10.20.0.0/24. BGP heeft nu twee VPN-IPv4-routes die onafhankelijk kunnen worden vergeleken, gefilterd en geselecteerd.

De RD zegt niet welke VRF een van beide routes moet ontvangen, en hij identificeert geen klant of dienst. Het is een identiteitsveld voor de route, geen ledenlijst. De eigen RD van een VRF hoeft niet overeen te komen met de RD van een route die hij importeert.

Daarom lost het niets op om een RD te wijzigen zodat hij bij het nummer van een andere site past. Als een route aan de andere kant ontbreekt, creëren de overeenkomende cijfers een ander identiteitsprobleem in plaats van de importbeslissing te repareren.

De RT is een BGP-attribuut, geen label in het pakket

Een exportbeleid hangt een of meer route targets als uitgebreide BGP-community-attributen aan de route. De ontvangende providerrand vergelijkt die attributen met het importbeleid van elke VRF. De RT reist met de route mee door het controleplan. De vergelijking gebeurt volledig in het routingbeleid, voordat er een klantpakket wordt doorgestuurd.

Klantdatapakketten dragen de RT niet. Zodra een route in een VRF is geïnstalleerd, gebruikt de doorsturing de tabel van die VRF en de MPLS-labelstapel die de architectuur toekent. De providerrand leest geen route target uit elk klantpakket.

Een route kan meerdere RT's dragen, en een VRF kan er meerdere importeren. De configuratie ziet er vaak uit als een kort blok:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Lees dat blok als twee afzonderlijke uitspraken. De exportregel bepaalt wat aan routes wordt gehangen die deze VRF verlaten; de importregel bepaalt wat deze VRF bereid is te overwegen. Overeenkomende nummers zijn handig, niet verplicht.

Importgeschiktheid is geen installatie

Een route kan geschikt zijn voor een VRF en toch niet in de doorstuurtabel verschijnen. Geschiktheid is een filter; daarna vergelijkt het normale BGP-besluitvormingsproces de geschikte routes en selecteert er één. Een oudere of minder gewenste route kan verliezen van een andere geschikte route.

Controleer de geselecteerde route, niet alleen het importbeleid. Een VRF die RT 65000:500 importeert en geen route voor 10.20.0.0/24 toont, heeft de route mogelijk ontvangen en bij de selectie verworpen, of nooit ontvangen.

Dit onderscheid is ook van belang wanneer een onverwacht prefix opduikt. Een te breed importbeleid kan routes binnenhalen die de site niet wilde gebruiken, en de uniekheid van de RD voorkomt dat allerminst. De distributieomvang is een kwestie van RT-beleid.

Debug een ontbrekende route in de volgorde van het controleplan

Begin bij de advertentie: exporteert de oorspronkelijke VRF de bedoelde RT, en bestaat de route als VPN-IPv4-route op de route reflector of de ontvangende PE? Controleer daarna het attribuut zoals het is ontvangen, niet zoals het op de zender is geconfigureerd.

Vergelijk vervolgens de importlijst van de ontvangende VRF met de werkelijke RT-waarden van de route. Bekijk ten slotte de geselecteerde route in die VRF en de labelbinding. Elke stap beantwoordt een andere vraag, en naar de RD springen slaat meestal precies de stap over die fout is.

Noteer de RD, de geëxporteerde RT, de geïmporteerde RT en de gekozen volgende hop voor de werkende en de falende site. Vier waarden naast elkaar veranderen een vaag “de VPN geeft geen routes door” in de precieze stap in het controleplan die afwijkt.