RD vs RT in ’n MPLS VPN: uniekheid teen invoerbeleid

’n Roete-distinguisher maak oorvleuelende voorvoegsels onderskeibaar; ’n roete-target bepaal watter roetes ’n VRF mag invoer. Volg een MPLS-roete deur albei rolle.

Twee klientpersele kan 10.20.0.0/24 adverteer en albei bly geldig binne een diensverskaffernetwerk. Die route distinguisher hou daardie advertensies apart; die route target besluit watter klant-VRF ’n kopie mag neem. Hulle staan langs mekaar in die konfigurasie en doen heeltemal verskillende take. Om die twee te verwar lei tot veranderinge wat redelik lyk en niks regmaak nie.

Volg een roete van die klientrand tot by ’n afgeleë VRF en die verdeling word konkreet: identiteit word aangeheg voordat die roete BGP binnegaan, en verspreidingsbeleid word geëvalueer wanneer die roete die ontvangende diensverskafferrand bereik.

’n VPN-IPv4-roete is ’n RD plus ’n IPv4-voorvoegsel

RFC 4364 definieer die VPN-IPv4-adresfamilie as ’n agtbyte-route-distinguisher gevolg deur ’n vierbyte-IPv4-adres. Die RD word voor die klientvoorvoegsel geplaas, sodat twee identiese voorvoegsels van verskillende persele twee verskillende BGP-roetes word.

Daardie konstruksie is die hele uniekheidsmeganisme. Die diensverskaffer het nie nodig dat kliente oor nie-oorvleuelende adresruimte saamstem nie, en ’n roete van een perseel kan nie stilweg ’n identiese voorvoegsel van ’n ander perseel vervang nie.

Die RD-formaat self is ’n waarde wat die administrateur kies, gewoonlik ’n outonome stelselnommer en ’n plaaslike nommer. Die numeriese vorm daarvan is ’n konvensie, nie ’n teken dat die twee velde ’n betekenis deel met ’n route target wat toevallig dieselfde syfers gebruik nie.

Die RD maak oorvleuelende voorvoegsels onderskeibaar

Oorweeg twee advertensies vir dieselfde voorvoegsel. Perseel A dra RD 65000:101 en perseel B dra RD 65000:202, albei vir 10.20.0.0/24. BGP hou nou twee VPN-IPv4-roetes wat onafhanklik vergelyk, gefiltreer en gekies kan word.

Die RD sê nie watter VRF een van die roetes moet ontvang nie, en dit identifiseer nie ’n klient of ’n diens nie. Dit is ’n identiteitsveld vir die roete, nie ’n lidmaatskapslys nie. ’n VRF se eie RD hoef nie te pas by die RD van ’n roete wat hy invoer nie.

Daarom maak dit niks reg om ’n RD te verander sodat dit by ’n ander perseel se nommer pas nie. As ’n roete aan die ander kant ontbreek, skep dieselfde syfers ’n ander identiteitsprobleem eerder as om die invoerbesluit te herstel.

Die RT is ’n BGP-eienskap, nie ’n pakketmerker nie

’n Uitvoerbeleid heg een of meer route targets aan die roete as uitgebreide gemeenskapkenmerke van BGP. Die ontvangende diensverskafferrand vergelyk daardie kenmerke met die invoerbeleid van elke VRF. Die RT reis saam met die roete deur die beheervlak. Die vergelyking gebeur heeltemal in die roetebeleid, voordat enige klientpakket gestuur word.

Klientdatapakkette dra nie die RT nie. Sodra ’n roete in ’n VRF geïnstalleer is, gebruik die aanstuurproses daardie VRF se tabel en die MPLS-etiketstapel wat die argitektuur toeken. Die diensverskafferrand lees nie ’n route target uit elke klientpakket nie.

’n Roete kan verskeie RT's dra, en ’n VRF kan verskeie invoer. Die konfigurasie lyk dikwels soos ’n kort blok:

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

Lees daardie blok as twee afsonderlike stellings. Die uitvoerlyn bepaal wat aan roetes geheg word wanneer hulle hierdie VRF verlaat; die invoerlyn bepaal wat hierdie VRF bereid is om te oorweeg. Dieselfde syfers is gerieflik, nie verpligtend nie.

Invoerbaarheid is nie installasie nie

’n Roete kan vir ’n VRF in aanmerking kom en tog nie in sy aanstuurtabel verskyn nie. Geskiktheid is ’n filter; die normale BGP-besluitproses vergelyk dan geskikte roetes en kies een. ’n Ouer of minder verkose roete kan teen ’n ander geskikte pad verloor.

Kontroleer die gekose roete, nie net die invoerbeleid nie. ’n VRF wat RT 65000:500 invoer en geen roete vir 10.20.0.0/24 wys nie, het die roete dalk ontvang en tydens keuse verwerp, of het dit dalk nooit ontvang nie.

Hierdie onderskeid maak ook saak wanneer ’n onverwagte voorvoegsel opduik. ’n Te breë invoerbeleid kan roetes intrek wat die perseel nie van plan was om te gebruik nie, en die uniekheid van die RD keer dit glad nie. Die verspreidingsomvang is ’n RT-beleidsvraag.

Spoor ’n ontbrekende roete in beheervlakorde op

Begin by die advertensie: voer die oorsprong-VRF die beoogde RT uit, en bestaan die roete as ’n VPN-IPv4-roete op die roete-reflektor of die ontvangende PE? Kontroleer dan die kenmerk soos ontvang, nie soos op die sender gekonfigureer nie.

Vergelyk daarna die ontvangende VRF se invoerlys met die roete se werklike RT-waardes. Ondersoek laastens die gekose roete in daardie VRF en die etiketbinding. Elke stap antwoord ’n ander vraag, en om na die RD te spring slaan gewoonlik die verkeerde een oor.

Teken die RD, die uitgevoerde RT, die ingevoerde RT en die gekose volgende sprong aan vir die werkende en die foutiewe perseel. Vier waardes langs mekaar verander ’n vae “die VPN gee nie roetes deur nie” in die presiese beheervlakstap wat verskil.

Verwante artikels