RD tsjin RT yn in MPLS VPN: eigenheid tsjin ymportbelied

Twa klantsites kinne 10.20.0.0/24 oankundigje en beide bliuwe jildich binnen ien netwurk fan in oanbieder. De rûte-ûnderskieder hâldt dy oankundigings skieden; it rûte-doel beslút hokker klant-VRF in kopy nimme mei. Se steane njonkeninoar yn ’e konfiguraasje en dogge folslein ferskillende taken. It trochelsmyt fan de twa laat ta feroarings dy’t ridlik lykje en neat reparearje.

Folgje ien rûte fan de klantrâne nei in fiere VRF en de ferdieling wurdt konkreet: identiteit wurdt tafoege foar’t de rûte BGP yngiet, en it distribúsjebelied wurdt beoardiele as de rûte de ûntfangende râne fan de oanbieder berikt.

In rûte VPN-IPv4 is in RD plus in IPv4-prefiks

RFC 4364 definiearret de adresfamylje VPN-IPv4 as in rûte-ûnderskieder fan acht byte, folge troch in IPv4-adres fan fjouwer byte. De RD wurdt foar it klantprefiks pleatst, sadat twa identike prefiksen fan ferskillende sites twa ferskillende BGP-rûtes wurde.

Dy konstruksje is it hiele meganisme foar eigenheid. De oanbieder hoecht net dat klanten it iens wurde oer adresromte sûnder oerlap, en in rûte fan ien site kin in identyk prefiks fan in oare site net stil ferfange.

It RD-formaat sels is in wearde dy’t de behearder kiest, meastentiids in autonoom systeemnûmer en in lokaal nûmer. De numerike foarm is in konvinsje, net in teken dat de twa fjilden in betsjutting diele mei in rûte-doel dat tafallich deselde sifers brûkt.

De RD makket oerlappende prefiksen ûnderskiedber

Tink oan twa oankundigings foar itselde prefiks. Site A draacht RD 65000:101 en site B draacht RD 65000:202, beide foar 10.20.0.0/24. BGP hat no twa rûtes VPN-IPv4 dy’t ûnôfhinklik ferlike, filtere en keazen wurde kinne.

De RD seit net hokker VRF ien fan de rûtes ûntfange moat, en hy identifisearret gjin klant of tsjinst. It is in identiteitsfjild foar de rûte, gjin lidmaatskiplist. De eigen RD fan in VRF hoecht net te passen by de RD fan in rûte dy’t er ymportearret.

Dêrom reparearret it neat om in RD te feroarjen sadat er by it nûmer fan in oare site past. As in rûte oan ’e oare kant ûntbrekt, meitsje deselde sifers in oar identiteitsprobleem yn stee fan it ymportbeslút te reparearjen.

De RT is in BGP-kenmerk, net in pakketlabel

In eksportbelied foeget ien of mear rûte-doelen ta oan ’e rûte as útwreide mienskipskenmerken fan BGP. De ûntfangende râne fan de oanbieder ferliket dy kenmerken mei it ymportbelied fan elke VRF. De RT reizget mei de rûte troch it bestjoeringsflak. De ferliking bart folslein yn it rûtebelied, foar’t hokker klantpakket dan ek trochstjoerd wurdt.

Klantdatapakketten drage de RT net. Sadree’t in rûte yn in VRF ynstallearre is, brûkt it trochstjoeren de tabel fan dy VRF en de MPLS-labelstapel dy’t de arsjitektuer tawiist. De râne fan de oanbieder lêst gjin rûte-doel út elk klantpakket.

In rûte kin ferskate RT’s drage, en in VRF kin ferskate ymportearje. De konfiguraasje liket faak op in koart blok:

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

Lês dat blok as twa aparte útspraken. De eksportrigel regelet wat tafoege wurdt oan rûtes dy’t dizze VRF ferlitte; de ymportrigel regelet wat dizze VRF ree is te beskôgjen. Deselde nûmers binne handich, net ferplicht.

Ymportrjocht is gjin ynstallaasje

In rûte kin geskikt wêze foar in VRF en dochs net yn syn trochstjoertabel ferskine. Geskiktheid is in filter; dêrnei ferliket it normale BGP-beslútproses de geskikte rûtes en kiest ien. In âldere of minder foarkomme rûte kin ferlieze fan in oare geskikte paad.

Kontrolearje de keazen rûte, net allinnich it ymportbelied. In VRF dy’t RT 65000:500 ymportearret en gjin rûte foar 10.20.0.0/24 sjen lit, hat de rûte miskien ûntfongen en by de kar wegere, of hat him miskien nea ûntfongen.

Dat ferskil is ek fan belang as der in ûnferwachts prefiks opkomt. In te breed ymportbelied kin rûtes lûke dy’t de site net fan plan wie te brûken, en de eigenheid fan de RD foarkomt dat hielendal net. De omfang fan distribúsje is in kwestje fan RT-belied.

Spoarje in ûntbrekkende rûte op yn ’e folchoarder fan it bestjoeringsflak

Begjin by de oankundiging: eksportearret de boarn-VRF de bedoelde RT, en bestiet de rûte as in VPN-IPv4-rûte op de rûte-reflektor of op de ûntfangende PE? Kontrolearje dan it kenmerk sa’t it ûntfongen is, net sa’t it by de stjoerder konfigurearre is.

Fergelykje dêrnei de ymportlist fan de ûntfangende VRF mei de werklike RT-wearden fan de rûte. Besjoch ta beslút de keazen rûte yn dy VRF en de labelbining. Eltse stap beantwurdet in oare fraach, en springe nei de RD slacht meastentiids dejinge oer dy’t ferkeard is.

Skriuw de RD, de eksportearre RT, de ymportearre RT en de keazen folgjende hop op foar de site dy’t wurket en dy’t mislearret. Fjouwer wearden njonkeninoar feroarje in ûndúdlik “it VPN jout gjin rûtes troch” yn ’e krekte stap fan it bestjoeringsflak dy’t ferskilt.