Stejná /24 pro dva zákazníky? VPNv4 potřebuje RD a label
Dva nájemci mohou inzerovat stejnou /24 jen proto, že RD dává každé trase vlastní identitu. Label odpovídá na jinou otázku: jak přeposílat.
Dva nájemci číslují svou pobočku stejnou 10.50.0.0/24 a po změně jedna trasa zmizí z okraje poskytovatele, zatímco druhá dál funguje. Zjednodušení, které za takovým ticketem stojí, obvykle spočívá ve vyřazení rozlišovače trasy (RD), protože „label už zákazníka identifikuje“. Neidentifikuje. RD a label odpovídají na dvě různé otázky a rozdíl se ukáže, teprve když ho vynutí překrývající se adresy.
Jedna trasa tam, kde mají být dvě
Běžný IPv4 unicast porovná dvě cesty ke stejnému prefixu a nainstaluje lepší. 10.50.0.0/24 od nájemce A a 10.50.0.0/24 od nájemce B jsou jeden klíč, takže jeden vyhraje a druhý přežije jen jako záložní cesta. Protokol udělal, co mu bylo řečeno; řídicí rovina byla požádána, aby uložila dvě různé trasy pod jedním identifikátorem.
Výsledek vypadá jako chybějící trasa, ne jako chyba: PE, který soutěž prohrál, stále přeposílá svého nájemce lokálně, takže ping v rámci lokality uspěje a test mezi lokalitami selže. Než se dotknete jakékoli politiky, spočítejte záznamy pro tento prefix v tabulce VPNv4.
RD mění jeden klíč na dva
Osmi bajtový rozlišovač trasy se vkládá před prefix IPv4 a objekt, který BGP nese, se stává adresou VPN-IPv4 místo prefixu IPv4. Dva nájemci mohou držet stejných 32 bitů, protože 64 bitů vpředu se liší. Existují typy formátu pro RD založený na AS a pro RD založený na adrese a volba patří výchozímu PE. RD založený na AS je obvyklý, když PE sdílejí AS, a ten adresní, když ho nesdílejí.
Nečtěte RD jako značku členství. Cíle trasy řídí import a export a rozhodují, které VRF smějí trasu nainstalovat; RD jen zaručuje, že trasa má vlastní identitu. Dát každému VRF vlastní RD je běžná praxe, protože udržuje toto mapování čitelné v náhledu tras.
Label je místní pokyn k přeposílání
Každé oznámení nese také label MPLS a jeho význam je omezen na router, který ho přidělil. Jiný PE může vydat stejné číslo pro nesouvisející cíl. Právě proto label nemůže zastoupit identitu zákazníka: číslo je správné jen vedle dalšího skoku a stavu přeposílání, který ho nainstaloval.
Granularita přidělování se liší podle implementace a návrhu: některé platformy přidělují jeden label na VRF, jiné na prefix a label může označovat akci přeposílání, nikoli zákazníka. Dva různé labely vedoucí ke stejnému cíli nejsou rozpor a stejné číslo labelu na dvou PE také ne.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
Proč jedno nemůže nahradit druhé
Číst oznámení znamená dívat se na čtyři věci společně: prefix s RD, cíle trasy, další skok a label. Číst uživatelský paket znamená dívat se na zásobník nainstalovaný z těchto informací. Zdravý návrh ukazuje shodu obou stran a ten porouchaný má obvykle jednu stranu správnou a druhou zastaralou. Toto srovnání odděluje problém identity od problému přeposílání.
Úhledný protiklad mezi řídicí a datovou rovinou je učební pomůcka, ne popis kódování. RFC 8277 vkládá label dovnitř označeného NLRI, takže samotné oznámení nese svazek; použití pro přeposílání je pozdější, samostatný krok.
Když trasa nájemce chybí, kontrolujte v tomto pořadí: dva záznamy VPNv4 pro prefix, správný cíl trasy na každém, rozlišitelný další skok a label, pro který má přijímající PE stav. Oprava identity pomocí hodnoty přeposílání, nebo naopak, projde jednou kontrolou a selže u další.