No CE RIP maršruta līdz attālam VRF: kur notiek eksports

RIPv2 atjauninājums ierodas pie pakalpojumu sniedzēja malas, nonāk VRF maršrutēšanas tabulā un tur apstājas, ja vien kaut kas to nav skaidri eksportējis. Trīs lēmumi notiek secīgi, un katrs var noraidīt prefiksu sava iemesla dēļ. To lasīšana kā viena notikuma ir iemesls, kāpēc cilvēki meklē nepareizo ierīci, kad attāla vieta nevar sasniegt tīklu, ko CE skaidri reklamē. Sekojiet maršrutam caur PE, un secība kļūst acīmredzama.

Ko PE dara ar RIP atjauninājumu

PE saņem atjauninājumu VRF saskarnē, pārbauda, vai avots ir atļauts kaimiņš, un ievieto prefiksu VRF maršrutēšanas tabulā ar lēcienu skaitu, kas iegūts no reklāmas. Šī tabula ir parasta maršrutēšanas tabula ar saviem administratīvajiem attālumiem un savu labākā ceļa izvēli. Ja CE vienu un to pašu prefiksu reklamē divreiz ar atšķirīgām metrikām, tabulā paliek tikai labākais. Šajā solī pakalpojumu sniedzēja mugurkauls nav iesaistīts.

Prefikss tagad pastāv viena klienta maršrutēšanas kontekstā, kas ir tālu no sasniedzamības jebkur citur.

Eksports ir politikas akts, nevis protokola sekas

Lai atstātu VRF, maršruts ir jāpārdala MP-BGP procesā, kas pārvadā VPN maršrutus, un tam ir vajadzīga paplašinātā maršruta mērķa kopiena, kas norāda, kuri attālie VRF to drīkst importēt. RFC 4364 arhitektūra tieši šī iemesla dēļ tur šīs apmaiņas atsevišķi no CE–PE protokola. RIP izmantošana malā neko nepasaka par to, kam jāšķērso pakalpojumu sniedzēja tīkls.

Pierakstiet eksporta līgumu pirms kaut ko konfigurējat: klienta prefiksi, kuriem jābūt sasniedzamiem no attāluma, maršruti, kuriem jāpaliek vietējiem, un jebkuri noklusējuma, konkrētāki vai koplietotā servisa izņēmumi. Salīdziniet šo līgumu ar faktisko VRF, nevis ar tāda paša nosaukuma cita klienta VRF.

Importa puse ir otra politika ar saviem maršruta mērķiem, un atbilstošs eksports ar neatbilstošu importu rada prefiksu, kas pastāv mugurkaulā un neparādās nevienā attālā tabulā.

Pārdale un skaidra izcelsme darbojas atšķirīgi

Pārdale ņem maršrutus, kas jau ir VRF tabulā, un kopē tos BGP, filtrējot ar maršrutu karti. Karte nosaka, kuri prefiksi ir piemēroti un kādus atribūtus tie nes, un metrika ir jānosaka skaidri, jo RIP lēcienu skaitam kā BGP metrikai nav nozīmes. Viss, ko atstājat nenorādītu, tiek mantots tā, kas parasti pārsteidz to, kurš konfigurāciju izlasa pēc sešiem mēnešiem.

Savstarpējā pārdale ir vieta, kur notiek klusais kaitējums. BGP eksportēts prefikss var atgriezties caur otru pārdales punktu, un bez atzīmēm vai filtriem maršruts svārstās, kamēr abas tabulas jebkurā brīdī izskatās ticamas. Filtrējiet pēc malā uzliktām atzīmēm, nevis paļaujieties uz topoloģiju, lai novērstu atgriešanās ceļu.

Skaidra izcelsme izskatās kārtīgāka un nav bez nosacījumiem. Tīkla paziņojumam parasti vajag atbilstošu maršrutu maršrutēšanas tabulā, pirms prefikss tiek izveidots, tāpēc reklāma pazūd tajā brīdī, kad CE pārstāj to reklamēt. Tas bieži ir vēlamā uzvedība, un tas nav tas pats, kas statisks maršruts, kas paliek konfigurēts mūžīgi. Pārbaudiet platformas faktisko noteikumu, nevis pieņemiet kādu no uzvedībām.

Lai kā būtu, jautājums par katru prefiksu ir, kurš aktīvais avots padara to piemērotu un kas notiek, kad šis avots pazūd.

Pārbaudiet ķēdi četrās vietās

Apskatiet CE reklāmu, VRF maršrutēšanas tabulu, VPN maršrutu tabulu ar tās maršruta mērķi un importu attālajā VRF, šajā secībā. IOS tas nozīmē CE kaimiņa izvadi, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, un to pašu komandu attālajā PE. IOS-XR atbilstošā izvade atrodas zem show bgp vrf CUSTOMER ipv4 unicast. Komandu nosaukumi atšķiras, četri pārbaudes punkti ne.

Pārbaudiet prefiksu, kas būtu jānoraida, tikpat rūpīgi kā to, kam būtu jāiziet, jo politika, kas atļauj visu, izskatās identiska pareizajai, līdz pienāk pirmais izņēmums. Pēc tam novērojiet atsaukšanu: izslēdziet CE saskarni un apstipriniet, ka attālais ieraksts pazūd paredzētajā taimerī, nevis paliek.

Pierakstiet, kam pieder katra politika. Kad pakalpojumu sniedzējs pārvalda CE, piegādātā uzvedība pieder pakalpojuma līgumam, un cits protokols vai atsaukšanas politika pārvaldītajā ierīcē ir dokumentācijas problēma pirms maršrutēšanas problēmas.