Dieselfde /24 vir twee klante? VPNv4 het ’n RD en ’n etiket nodig

Twee huurders nommer albei hul tak 10.50.0.0/24, en ná ’n verandering verdwyn een huurder se roete by die provider-edge terwyl die ander een bly werk. Die vereenvoudiging agter daardie kaartjie is gewoonlik om die route distinguisher te laat vaar omdat “die etiket reeds die klant identifiseer”. Dit doen dit nie. Die RD en die etiket beantwoord twee verskillende vrae, en die gaping word eers sigbaar wanneer oorvleuelende adresse dit afdwing.

Een roete waar daar twee behoort te wees

Gewone IPv4-unicast vergelyk twee paaie na dieselfde voorvoegsel en installeer die beste een. 10.50.0.0/24 van huurder A en 10.50.0.0/24 van huurder B is een sleutel, so een wen en die ander oorleef net as ’n rugsteunroete. Die protokol het gedoen wat hom gesê is; die beheervlak is gevra om twee verskillende roetes onder ’n enkele identifiseerder te stoor.

Die resultaat lyk soos ’n vermiste roete eerder as ’n fout: die PE wat die wedstryd verloor het, stuur steeds sy eie huurder plaaslik aan, so ’n binne-terrein-ping slaag en die tussen-terrein-toets misluk. Tel die inskrywings vir daardie voorvoegsel in die VPNv4-tabel voordat jy enige beleid aanraak.

Die RD maak van een sleutel twee

’n Route distinguisher van agt grepe word voor die IPv4-voorvoegsel geplaas, en die objek wat BGP dra word ’n VPN-IPv4-adres in plaas van ’n IPv4-voorvoegsel. Twee huurders kan dieselfde 32 bisse hou omdat die 64 bisse vooraan verskil. Formaat-tipes bestaan vir ’n AS-gebaseerde RD en vir ’n adres-gebaseerde een, en die keuse behoort aan die oorsprong-PE. ’n AS-gebaseerde RD is algemeen wanneer die PE’s ’n AS deel, ’n adres-gebaseerde een wanneer hulle dit nie doen nie.

Moenie die RD as ’n lidmaatskap-etiket lees nie. Roeteteikens beheer invoer en uitvoer, en hulle bepaal watter VRF’s die roete mag installeer; die RD waarborg net dat die roete ’n identiteit van sy eie het. Om aan elke VRF sy eie RD te gee is die algemene praktyk, want dit hou daardie kartering leesbaar in ’n looking glass.

Die etiket is ’n plaaslike aanstuurinstruksie

Elke advertensie dra ook ’n MPLS-etiket, en sy betekenis is beperk tot die router wat dit toegeken het. ’n Ander PE kan dieselfde nommer vir ’n onverwante bestemming uitreik. Dit is juis waarom die etiket nie in die plek van klantidentiteit kan staan nie: die nommer is net korrek naas die volgende sprong en die aansturtoestand wat dit geïnstalleer het.

Toekenningsgranulariteit wissel met implementering en ontwerp: sommige platforms ken een etiket per VRF toe, ander per voorvoegsel, en die etiket kan ’n aanstuurhandeling eerder as ’n klant identifiseer. Twee verskillende etikette wat dieselfde bestemming bereik is nie ’n teenstrydigheid nie, en dieselfde etiketnommer by twee PE’s ook nie.

Waarom die een nie die ander kan vervang nie

Om ’n advertensie te lees beteken om vier dinge saam te bekyk: die RD-gekwalifiseerde voorvoegsel, die roeteteikens, die volgende sprong en die etiket. Om ’n gebruikerspakket te lees beteken om na die stapel te kyk wat uit daardie inligting geïnstalleer is. ’n Gesonde ontwerp wys beide kante wat ooreenstem, en ’n stukkende een het gewoonlik een kant reg en die ander verouderd. Daardie vergelyking skei ’n identiteitsprobleem van ’n aanstuurprobleem.

Die netjiese kontras tussen beheervlak en data-vlak is ’n onderrigmiddel, nie ’n beskrywing van die enkodering nie. RFC 8277 plaas die etiket binne die gemerkte NLRI, so die advertensie self dra die binding; om dit vir aanstuur te gebruik is die latere, aparte stap.

Wanneer ’n huurderroete wegraak, kyk in hierdie volgorde: twee VPNv4-inskrywings vir die voorvoegsel, die korrekte roeteteiken op elkeen, ’n oplosbare volgende sprong, en ’n etiket waarvoor die ontvangende PE toestand het. Om identiteit met ’n aanstuurwaarde reg te maak, of omgekeerd, sal een kontrole slaag en die volgende misluk.