OSPF maršruta tips VPN ietvaros: ne vienmēr ārējs

Klienta prefikss šķērso pakalpojumu sniedzēja mākoni kā BGP VPN maršruts un nonāk attālajā vietā, izskatoties kā ārējs OSPF maršruts, ko daudzi inženieri sagaida, un tas nav vienīgais iespējamais iznākums. Tas, ko redz attālais CE, ir atkarīgs no OSPF domēna, no kura prefikss nāca, un no tā sākotnējā maršruta tipa, un abi ceļo kopā ar VPN maršrutu. Pieņēmums, ka katrs pārdalītais prefikss kļūst par tipu 5, noved pie prioritātes izmaiņām, kas nevar darboties. Vispirms salīdziniet domēna identifikatoru, nevis administratīvo attālumu.

PE-CE modelis nes pietiekami daudz konteksta, lai saņēmējais PE varētu rekonstruēt OSPF paziņojumu, nevis to izdomāt.

Kas ceļo kopā ar maršrutu

RFC 4577 definē OSPF atribūtus, kas pavada VPN maršrutu: domēna identifikatoru, metriku un izcelsmes vietas maršruta tipu. Saņēmējais PE tos izmanto, lai izlemtu, kā piemērotam prefiksam būtu jāizskatās tā vietējam OSPF procesam. Bez šiem atribūtiem attālajam PE nebūtu nekāda pamata nekam citam kā vien ārējai pārdalei. Tāpēc maršruts var ierasties kā starpzonu LSA, lai gan BGP to starplaikā pārvadāja.

Arī zonas tipam ir nozīme. Stub vai NSSA zona ierobežo, kuras LSA drīkst iekļūt, tāpēc viens un tas pats VPN maršruts var tikt pasniegts citādi atkarībā no tā, kur atrodas saņēmējā OSPF instance. Konfigurētā eksporta politika var arī ignorēt noklusējuma pasniegšanu, un tas ir apzināta izvēle, nevis blakusefekts.

Tas pats domēns, cita pasniegšana

Tā paša domēna iekšzonas vai starpzonu maršruts parasti ierodas attālajā vietā kā starpzonu maršruts, tas ir, LSA ar tipu 3. Cita domēna prefikss, izcelsme, kas nekad nav runājusi OSPF, vai sākotnēji ārējs OSPF paziņojums tā vietā seko ārējiem noteikumiem, un tieši tur parādās tips 5 un tā NSSA ekvivalents. Abas uzvedības ir pareizas; ievade atšķiras. Pirms pieskarties prioritātes vērtībām, salīdziniet domēnu identifikatorus un paziņotos atribūtus.

Administratīvais attālums izvēlas starp avotiem vienā maršrutētājā. Tas nepārraksta LSA tipu un neizveido trūkstošo domēna saistību.

Kad sham saite ir pareizā atbilde

Iedomājieties divas vietas vienā zonā, kas savienotas ar tiešu aizmugures durvju saiti. OSPF saglabā šo iekšzonas ceļu, nevis starpzonu ceļu, ko piedāvā pakalpojumu sniedzējs, pat ja konfigurētās izmaksas padarītu pakalpojumu sniedzēja ceļu pievilcīgu. Sham saite attēlo iekšzonas attiecības VPN ietvaros, lai izmaksas varētu piedalīties lēmumā. Tā pastāv tieši šai konkrētajai ceļa izvēles problēmai, nevis lai katrs tā paša domēna maršruts izskatītos iekšējs.

Sham saitei ir vajadzīgi sasniedzami galapunkti un abpusēja konfigurācija abos PE. Uzstādot to tikai vienā pusē, rodas attiecības, kas nekad neveidojas, un maršrutēšanas tabula saglabā savu veco prioritāti, kas izskatās tā, it kā funkcija neko nebūtu izdarījusi.

Nelauziet cilpas aizsardzību

PE-CE modelis uzstāda DN bitu maršrutiem, ko tas izplata, lai prefikss nevarētu atgriezties caur citu CE un tikt pārdalīts otro reizi. Tieši šī aizsardzība neļauj prefiksam cilpot starp vietām, kas dala OSPF domēnu. Tās noņemšana vai ignorēšana, lai maršruts izskatītos iekšējs, var radīt tieši to cilpu, kuras novēršanai tā tika izstrādāta. Kad prefikss izskatās nepareizs, izturieties pret DN bitu kā pret informāciju, nevis šķērsli.

Tāda pati piesardzība attiecas uz pārdales filtriem un maršrutu kartēm, kas noņem kopienas. Katrs no tiem noņem kontekstu, kas vajadzīgs attālajai pusei, un iegūtais paziņojums var izskatīties ticams, kamēr tas ir nepareizs. Mainiet vienu atribūtu vienlaikus un pārbaudiet, ko attālais CE patiešām uzstāda.

Pēc tam pārbaudiet no attālās vietas: LSA tipu, paziņojošo maršrutētāju un izvēlēto ceļu. Šie pierādījumi atbild uz biļetē uzdoto jautājumu.