OSPF maksimalusis metrikas: atgrasyti tranzitą per filialą jo nepašalinant

Du biurai jungiasi per filialą, kuris turėtų vežti savo paties srautą ir labai mažai ko kito. Filialui reikia maršrutų į abi vietas, ir nė viena vieta neturėtų jo rinktis kaip kelio tarp jų. Filialo pašalinimas iš topologijos išspręstų tranzito problemą ir sulaužytų reikalavimą, nes filialas vis tiek turi pasiekti abi vietas, o abi vietos vis tiek turi pasiekti filialą.

Ko norite, yra pirmenybė, išreikšta maršrutizavimo protokole, kuri palieka filialą visiškai pasiekiamą ir daro jį blogu pasirinkimu viskam, kas per jį eina. Pereikite problemą ta tvarka, kuria ją mato maršrutizatoriai.

Pradėkite nuo kelio, kurio norite išvengti

Nubrėžkite topologiją taip, kaip ją mato protokolas, o ne taip, kaip ją mato diagrama. Kurios sąsajos sudaro kaimynystes, kurios yra tame pačiame plote ir kurios iš tų kaimynysčių vežtų srautą tarp dviejų biurų, jei filialui būtų teikiama pirmenybė? Tai trys atskiri klausimai, ir diagrama nė į vieną jų neatsako patikimai.

Tada raskite alternatyvų kelią. Jei vienintelis maršrutas tarp biurų eina per filialą, jokia metrika negali srauto iš jo perkelti, nes srautas neturi kur eiti. Pertekliškumas nėra šio projekto smulkmena; tai sąlyga. Antras kelias, egzistuojantis tik popieriuje, nesiskaito.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Šios trys peržiūros atsako į skirtingus klausimus: kas yra kaimynas, kurios sąsajos dalyvauja ir kokia kaina, ir kurį kelią įrenginys dabar renkasi. Tunelio diegimas prideda ketvirtą: linija diagramoje nėra įrodymas, kad kaimynystė susidarė per ją, o susidariusi kaimynystė nėra įrodymas, kad persiuntimas eina tuo pačiu keliu. Būtent tunelių projektuose šis trūkumas pasireiškia dažniausiai.

Ką skelbia didžiausia metrika

RFC 6987 aprašo maršrutizatorių, kuris skelbia savo ne stub nuorodas su didžiausia nuorodos metrika, apibrėžta kaip 0xffff. Maršrutizatorius vis dar aprašo save ir savo nuorodas; jis tiesiog įkainoja jas diapazono viršuje, todėl kiekvienas kitas maršrutizatorius kelią per jį apskaičiuoja kaip brangų.

Tai router-LSA pakeitimas, o ne topologijos pašalinimas. Skirtumas svarbus: išvalius router-LSA atšaukiama pati topologijos informacija, o tai gali atšaukti ir ryšius, reikalingus pasiekti maršrutizatorių ir prefiksus už jo. Skelbimo išlaikymas ir jo kainos pakėlimas išsaugo tuos ryšius. Tai ir yra visas skirtumas tarp šios technikos ir pašalinimo.

Mechanizmas RFC 6987 taip pat neturi nieko bendra su sričių tipais ar paskirtojo maršrutizatoriaus rinkimu. Stub sritis blokuoja vieną nuorodos būsenos skelbimų kategoriją prie srities ribos, o stub maršrutizatorius įkainoja savo pačio nuorodas. Panašūs žodžiai, nesusijusi mechanika.

Kodėl pasiekiamumas išlieka, o tranzitas ne

Kiti maršrutizatoriai vis dar turi maršrutą į filialo prijungtus prefiksus, nes filialas juos vis dar skelbia ir nuorodos vis dar egzistuoja. Keičiasi bet kurio kelio, einančio per filialą pakeliui kitur, bendra kaina. Prefiksai nejuda; keičiasi tik maršrutizatoriaus perėjimo kaina.

Srautui, kurio šaltinis ar paskirties vieta yra pats filialas, brangi nuoroda vis dar yra vieninteliame protingame kelyje, todėl ji naudojama. Srautui tarp dviejų biurų alternatyvus kelias dabar laimi kaina, ir filialas iškrenta iš persiuntimo sprendimo neprapuolęs iš topologijos. Dvi kryptys, du skirtingi atsakymai, ir abu rodo, kad mechanizmas veikia.

Tai elgsena, kurią reikia patikrinti, o ne daryti prielaidas. Pažiūrėkite į router-LSA, kurį generuoja filialas, tada į kelią, kurį kitas maršrutizatorius renkasi paskirties vietai už filialo ir paskirties vietai kitame biure. Du atsakymai turėtų skirtis, o jei nesiskiria, metrikos pakeitimas nepasiekia sprendimo, apie kurį galvojate.

Paskutinio kelio problema

Tas pats RFC aiškiai nurodo, kad technika nereikalauja naudojimo draudimo. Kai alternatyvus kelias sugenda, maršrutizatoriai grįžta prie brangaus kelio per filialą, nes jis vis dar galioja ir protokolas teikia pirmenybę brangiam maršrutui, o ne jokiam maršrutui.

Ar toks grįžimas priimtinas, yra politikos klausimas, į kurį turite atsakyti prieš diegdami. Filialas mažoje išėjimo linijoje, kuri staiga veža srautą tarp biurų, gali būti blogesnis už sutrikimą, ir gali būti būtent tai, ko norite techninės priežiūros lango metu. Abu atsakymai yra teisėti; tyla ne.

Jei reikalavimas yra griežtas draudimas, o ne pirmenybė, vien metrikos projektas jo nesuteiks. Jums reikia persiuntimo vykdymo, atitinkančio ketinimą, ir apibrėžtos elgsenos atvejui, kai srautas vis tiek atvyksta. Skelbti kelią kaip tinkamą ir tada mesti srautą sukuria juodąją skylę, kurią diagnozuoti sunkiau nei maršrutizavimo kilpą.

OSPFv3 atveju RFC aptaria R bitą kaip kitą būdą pašalinti dalyvavimą tranzite. Nemanote, kad jis paveldi tokią pačią paskutinio kelio elgseną kaip didžiausios metrikos technika, ir nekopijuokite nustatymų tarp dviejų adresų šeimų taip, lyg tai būtų ta pati funkcija.

Įrodykite tai normaliomis ir sutrikusiomis sąlygomis

Išbandykite du kartus: vieną kartą, kai abu keliai prieinami, ir vieną kartą, kai pageidaujamas kelias pašalintas. Pirmasis bandymas rodo, kad pirmenybė veikia, o antrasis rodo, ką tinklas daro, kai pirmenybės neįmanoma laikytis. Praleidus antrąjį bandymą, svarbioji pusė lieka neištirta.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

Duomenų bazės rodinys rodo skelbiamą metriką, maršruto paieška rodo pasirinktą kitą šuolį, o sekimas rodo, kur paketai iš tikrųjų nuvyko. Kai šie trys sutampa, turite patikrintą projektą, o ne teisingai atrodančią konfigūraciją.

Tada atkurkite pageidaujamą kelią ir patvirtinkite, kad filialas grįžta vežti tik savo srauto. Atkūrimo žingsnis priklauso bandymui, o ne valymui, nes projektas, veikiantis tik iki kito pakeitimo, nėra projektas. Užrašykite abu rezultatus, įskaitant grįžimą, nes antrasis yra atsakymas, kurio kam nors prireiks trečią valandą nakties.