Hetzelfde /24 voor twee klanten? VPNv4 heeft een RD en een label nodig

Twee huurders nummeren hun vestiging met hetzelfde 10.50.0.0/24, en na een wijziging verdwijnt de route van de ene huurder bij de provider-edge terwijl die van de andere blijft werken. De vereenvoudiging achter dat ticket is meestal de route distinguisher weglaten omdat „het label de klant al identificeert“. Dat doet het niet. De RD en het label beantwoorden twee verschillende vragen, en de kloof wordt pas zichtbaar als overlappende adressen die afdwingen.

Eén route waar er twee zouden moeten zijn

Gewone IPv4-unicast vergelijkt twee paden naar hetzelfde prefix en installeert de beste. 10.50.0.0/24 van huurder A en 10.50.0.0/24 van huurder B zijn één sleutel, dus één wint en de andere overleeft alleen als back-uppad. Het protocol deed wat hem gezegd was; het control plane kreeg de opdracht twee verschillende routes onder één identificatie op te slaan.

Het resultaat ziet eruit als een ontbrekende route in plaats van een fout: de PE die de competitie verloor, stuurt zijn eigen huurder nog lokaal door, dus een ping binnen de locatie slaagt en de test tussen locaties faalt. Tel de vermeldingen voor dat prefix in de VPNv4-tabel voordat je welk beleid dan ook aanraakt.

De RD maakt van één sleutel twee

Een route distinguisher van acht byte wordt voor het IPv4-prefix geplaatst, en het object dat BGP vervoert wordt een VPN-IPv4-adres in plaats van een IPv4-prefix. Twee huurders kunnen dezelfde 32 bits houden omdat de 64 bits ervoor verschillen. Er bestaan formaattypen voor een op AS gebaseerde RD en voor een op adres gebaseerde, en de keuze ligt bij de oorspronkelijke PE. Een op AS gebaseerde RD is gebruikelijk als de PE's een AS delen, en een op adres gebaseerde als ze dat niet doen.

Lees de RD niet als lidmaatschapslabel. Route-targets beheren import en export en bepalen welke VRF's de route mogen installeren; de RD garandeert alleen dat de route een eigen identiteit heeft. Elke VRF zijn eigen RD geven is de gangbare praktijk omdat het die toewijzing leesbaar houdt in een routeoverzicht.

Het label is een lokale doorstuurinstructie

Elke aankondiging draagt ook een MPLS-label, en de betekenis ervan is beperkt tot de router die het heeft toegekend. Een andere PE kan hetzelfde nummer uitgeven voor een ongerelateerde bestemming. Juist daarom kan het label de identiteit van de klant niet vervangen: het nummer is alleen correct naast de volgende hop en de doorstuurstaat die het heeft geïnstalleerd.

De granulariteit van de toekenning verschilt per implementatie en ontwerp: sommige platforms kennen één label per VRF toe, andere per prefix, en het label kan een doorstuuractie aanduiden in plaats van een klant. Twee verschillende labels die dezelfde bestemming bereiken zijn geen tegenspraak, en hetzelfde labelnummer op twee PE's ook niet.

Waarom het ene het andere niet kan vervangen

Een aankondiging lezen betekent vier dingen tegelijk bekijken: het door RD gekwalificeerde prefix, de route-targets, de volgende hop en het label. Een gebruikerspakket lezen betekent de stack bekijken die uit die informatie is geïnstalleerd. Een gezond ontwerp laat beide kanten overeenkomen, en een kapot ontwerp heeft meestal één kant goed en de andere verouderd. Die vergelijking scheidt een identiteitsprobleem van een doorstuurprobleem.

Het nette contrast tussen control plane en data plane is een leermiddel, geen beschrijving van de codering. RFC 8277 plaatst het label binnen de gelabelde NLRI, zodat de aankondiging zelf de binding draagt; het voor doorsturen gebruiken is de latere, aparte stap.

Als een huurdersroute ontbreekt, controleer dan in deze volgorde: twee VPNv4-vermeldingen voor het prefix, het juiste route-target op elk, een oplosbare volgende hop, en een label waarvoor de ontvangende PE staat heeft. Identiteit repareren met een doorstuurwaarde, of omgekeerd, slaagt voor de ene controle en faalt voor de volgende.