OSPF maršruto tipas per VPN: ne visada išorinis

Kliento prefiksas kerta paslaugų teikėjo debesį kaip BGP VPN maršrutas ir atvyksta į tolimą svetainę atrodydamas kaip išorinis OSPF maršrutas, ko daugelis inžinierių tikisi, ir tai nėra vienintelis galimas rezultatas. Tai, ką mato tolimas CE, priklauso nuo OSPF domeno, iš kurio atėjo prefiksas, ir nuo pradinio maršruto tipo, ir abu keliauja su VPN maršrutu. Prielaida, kad kiekvienas perskirstytas prefiksas virsta 5 tipu, lemia pirmumo pokyčius, kurie negali veikti. Pirmiausia palyginkite domeno identifikatorių, o ne administracinį atstumą.

PE-CE modelis neša pakankamai konteksto, kad priimantis PE galėtų atkurti OSPF skelbimą, o ne jį išgalvoti.

Kas keliauja su maršrutu

RFC 4577 apibrėžia OSPF atributus, kurie lydi VPN maršrutą: domeno identifikatorių, metriką ir kilmės svetainės maršruto tipą. Priimantis PE naudoja juos nuspręsti, kaip tinkamas prefiksas turėtų atrodyti jo vietiniam OSPF procesui. Be šių atributų tolimas PE neturėtų jokio pagrindo niekam, išskyrus išorinį perskirstymą. Todėl maršrutas gali atvykti kaip tarpzoninė LSA, nors BGP jį pervežė tarp jų.

Zonos tipas taip pat svarbus. Stub arba NSSA zona riboja, kurios LSA gali patekti, todėl tas pats VPN maršrutas gali būti pateikiamas kitaip, priklausomai nuo to, kur yra priimanti OSPF instancija. Sukonfigūruota eksporto politika taip pat gali pakeisti numatytąjį pateikimą, ir tai yra sąmoningas pasirinkimas, o ne šalutinis poveikis.

Tas pats domenas, kitoks pateikimas

To paties domeno vidinės zonos arba tarpzoninis maršrutas paprastai atvyksta į tolimą svetainę kaip tarpzoninis maršrutas, tai yra 3 tipo LSA. Kito domeno prefiksas, šaltinis, kuris niekada nekalbėjo OSPF, arba iš pradžių išorinis OSPF skelbimas vietoj to laikosi išorinių taisyklių, ir būtent ten atsiranda 5 tipas ir jo NSSA atitikmuo. Abi elgsenos yra teisingos; įvestis skiriasi. Palyginkite domenų identifikatorius ir paskelbtus atributus prieš liesdami pirmumo reikšmes.

Administracinis atstumas pasirenka tarp šaltinių viename maršrutizatoriuje. Jis neperrašo LSA tipo ir nesukuria trūkstamo domeno ryšio.

Kada sham nuoroda yra teisingas atsakymas

Įsivaizduokite dvi svetaines toje pačioje zonoje, sujungtas tiesiogine užpakalinių durų nuoroda. OSPF išlaiko tą zonos vidinį kelią, o ne tarpzoninį, siūlomą per teikėją, net kai sukonfigūruotos sąnaudos padarytų teikėjo kelią patrauklų. Sham nuoroda atstovauja zonos vidinį ryšį per VPN, kad sąnaudos galėtų dalyvauti sprendime. Ji egzistuoja dėl šios konkrečios kelio pasirinkimo problemos, o ne tam, kad kiekvienas to paties domeno maršrutas atrodytų vidinis.

Sham nuorodai reikia pasiekiamų galinių taškų ir abipusės konfigūracijos abiejuose PE. Nustačius ją tik vienoje pusėje, susidaro ryšys, kuris niekada nesusiformuoja, o maršrutizavimo lentelė išlaiko seną pirmumą, todėl atrodo, kad funkcija nieko nepadarė.

Nesulaužykite kilpos apsaugos

PE-CE modelis nustato DN bitą maršrutuose, kuriuos platina, kad prefiksas negalėtų grįžti per kitą CE ir būti perskirstytas antrą kartą. Būtent ši apsauga neleidžia prefiksui kilpoti tarp svetainių, bendrinančių OSPF domeną. Jos pašalinimas ar ignoravimas siekiant, kad maršrutas atrodytų vidinis, gali sukurti būtent tą kilpą, kuriai užkirsti kelią ji buvo sukurta. Kai prefiksas atrodo neteisingas, DN bitą laikykite informacija, o ne kliūtimi.

Tas pats atsargumas galioja perskirstymo filtrams ir maršruto žemėlapiams, kurie pašalina bendruomenes. Kiekvienas iš jų pašalina kontekstą, kurio reikia tolimajai pusei, ir gaunamas skelbimas gali atrodyti įtikinamas, nors yra neteisingas. Keiskite po vieną atributą ir tikrinkite, ką tolimas CE iš tikrųjų įdiegia.

Tada patikrinkite iš tolimos svetainės: LSA tipą, skelbiantį maršrutizatorių ir pasirinktą kelią. Šie įrodymai atsako į biliete pateiktą klausimą.