RD pret RT MPLS VPN: unikalitāte pret importa politiku

Maršruta atšķirējs padara pārklājošos prefiksus unikālus, un maršruta mērķis nosaka, kurus maršrutus VRF drīkst importēt. Izsekojiet vienu MPLS maršrutu abās lomās.

Divi klientu objekti var reklamēt 10.20.0.0/24, un abi paliek derīgi vienā pakalpojumu sniedzēja tīklā. Maršruta atšķirējs šos reklamējumus tur atsevišķi, bet maršruta mērķis nosaka, kura klienta VRF drīkst paņemt kopiju. Tie konfigurācijā atrodas blakus un veic pilnīgi atšķirīgus darbus. Abu sajaukšana noved pie izmaiņām, kas izskatās saprātīgas un neko nelabo.

Izsekojiet vienu maršrutu no klienta malas līdz attālam VRF un sadalījums kļūst konkrēts: identitāte tiek pievienota pirms maršruts nonāk BGP, un izplatīšanas politika tiek novērtēta, kad maršruts sasniedz saņēmēja pakalpojumu sniedzēja malu.

VPN-IPv4 maršruts ir RD plus IPv4 prefikss

RFC 4364 definē VPN-IPv4 adrešu saimi kā astoņu baitu maršruta atšķirēju, kam seko četru baitu IPv4 adrese. RD tiek pievienots klienta prefiksa priekšā, tāpēc divi identiski prefiksi no dažādiem objektiem kļūst par diviem dažādiem BGP maršrutiem.

Šī konstrukcija ir viss unikalitātes mehānisms. Pakalpojumu sniedzējam nav vajadzīga klientu vienošanās par nepārklājošos adrešu telpu, un viena objekta maršruts nevar klusi aizstāt cita objekta identisku prefiksu.

Pats RD formāts ir administratora izvēlēta vērtība, parasti autonomās sistēmas numurs un lokālais numurs. Tā skaitliskā forma ir vienošanās, nevis signāls, ka abiem laukiem ir kopīga nozīme ar maršruta mērķi, kas nejauši izmanto tos pašus ciparus.

RD padara pārklājošos prefiksus atšķiramus

Apsveriet divus reklamējumus vienam prefiksam. Objektam A ir RD 65000:101, bet objektam B ir RD 65000:202, abi 10.20.0.0/24. Tagad BGP ir divi VPN-IPv4 maršruti, kurus var neatkarīgi salīdzināt, filtrēt un atlasīt.

RD nepasaka, kurai VRF jāsaņem kāds no šiem maršrutiem, un tas neidentificē ne klientu, ne pakalpojumu. Tas ir maršruta identitātes lauks, nevis dalības saraksts. VRF pašam RD nav jāsakrīt ar maršruta RD, ko tā importē.

Tāpēc RD maiņa, lai tas atbilstu cita objekta numuram, neko nelabo. Ja maršruts otrā pusē trūkst, ciparu sakritība rada citu identitātes problēmu, nevis izlabo importa lēmumu.

RT ir BGP atribūts, nevis iezīme paketē

Eksporta politika pievieno maršrutam vienu vai vairākus maršruta mērķus kā paplašinātus BGP kopienas atribūtus. Saņēmēja pakalpojumu sniedzēja mala salīdzina šos atribūtus ar katras VRF importa politiku. RT ceļo kopā ar maršrutu caur vadības plakni. Salīdzināšana notiek pilnībā maršrutēšanas politikā, pirms tiek pārsūtīts jebkurš klienta pakets.

Klienta datu paketes nenes RT. Kad maršruts ir instalēts VRF, pārsūtīšana izmanto šī VRF tabulu un MPLS etiķešu steku, ko piešķir arhitektūra. Pakalpojumu sniedzēja mala nelasa maršruta mērķi no katras klienta paketes.

Maršruts var nest vairākus RT, un VRF var importēt vairākus. Konfigurācija bieži izskatās kā īss bloks:

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

Lasiet šo bloku kā divus atsevišķus apgalvojumus. Eksporta rinda nosaka, kas tiek pievienots maršrutiem, kas atstāj šo VRF, bet importa rinda nosaka, ko šī VRF ir gatava apsvērt. Sakrītoši numuri ir ērti, nevis obligāti.

Importa tiesības nav instalācija

Maršruts var būt piemērots VRF un tomēr neparādīties tās pārsūtīšanas tabulā. Piemērotība ir filtrs; pēc tam parastais BGP lēmumu pieņemšanas process salīdzina piemērotos maršrutus un izvēlas vienu. Vecāks vai mazāk vēlams maršruts var zaudēt citam piemērotam ceļam.

Pārbaudiet atlasīto maršrutu, ne tikai importa politiku. VRF, kas importē RT 65000:500 un neuzrāda maršrutu 10.20.0.0/24, varēja saņemt maršrutu un to noraidīt atlases laikā, vai arī to nekad nav saņēmusi.

Šī atšķirība ir svarīga arī tad, kad parādās negaidīts prefikss. Pārāk plaša importa politika var piesaistīt maršrutus, ko objekts neplānoja izmantot, un RD unikalitāte to nemaz neaptur. Izplatīšanas apjoms ir RT politikas jautājums.

Atrodiet trūkstošo maršrutu vadības plaknes secībā

Sāciet ar reklamējumu: vai avota VRF eksportē paredzēto RT, un vai maršruts pastāv kā VPN-IPv4 maršruts maršrutu atstarotājā vai saņēmējā PE? Pēc tam pārbaudiet atribūtu tādu, kāds tas saņemts, nevis kāds tas konfigurēts sūtītājā.

Pēc tam salīdziniet saņēmēja VRF importa sarakstu ar maršruta faktiskajām RT vērtībām. Visbeidzot apskatiet atlasīto maršrutu šajā VRF un etiķetes saistījumu. Katrs solis atbild uz citu jautājumu, un lēciens pie RD parasti izlaiž tieši to soli, kas ir nepareizs.

Pierakstiet RD, eksportēto RT, importēto RT un atlasīto nākamo lēcienu strādājošajam un bojātajam objektam. Četras vērtības blakus pārvērš neskaidro “VPN nepārsūta maršrutus” tieši tajā vadības plaknes solī, kas atšķiras.

Saistītie raksti