OSPF maksimaalne metrika: haru transiidi heidutamine haru eemaldamata

Kaks kontorit on ühendatud haru kaudu, mis peaks kandma oma liiklust ja väga vähe muud. Haru vajab marsruute mõlemasse kohta ja kumbki koht ei peaks eelistama seda nendevahelise teena. Haru topoloogiast eemaldamine lahendaks transiidiprobleemi ja rikuks nõude, sest haru peab endiselt jõudma mõlemasse kohta ja mõlemad kohad peavad endiselt jõudma haruni.

See, mida soovid, on marsruutimisprotokollis väljendatud eelistus, mis jätab haru täielikult kättesaadavaks ja teeb sellest halva valiku kõigele, mis sellest läbi läheb. Käi probleem läbi selles järjekorras, nagu ruuterid seda näevad.

Alusta teest, mida soovid vältida

Joonista topoloogia nii, nagu protokoll seda näeb, mitte nii, nagu diagramm seda näeb. Millised liidesed moodustavad naabrusi, millised on samas piirkonnas ja millised neist naabrustest kannaksid liiklust kahe kontori vahel, kui haru oleks eelistatud? Need on kolm eraldi küsimust ja diagramm ei vasta ühelegi neist usaldusväärselt.

Seejärel leia alternatiivne tee. Kui ainus marsruut kontorite vahel läbib haru, ei saa ükski metrika liiklust sealt ära liigutada, sest liiklusel pole kuhugi minna. Üleliigsus pole selle kavandi detail; see on eeldus. Teine tee, mis eksisteerib ainult paberil, ei lähe arvesse.

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

Need kolm vaadet vastavad erinevatele küsimustele: kes on naaber, millised liidesed osalevad ja millise kuluga, ning millise tee seade praegu valib. Tunnelipõhine juurutus lisab neljanda: joon diagrammil ei ole tõestus, et naabrus selle kaudu tekkis, ja tekkinud naabrus ei ole tõestus, et edastamine järgib sama teed. Just tunnelikavandites tuleb see lünk kõige sagedamini välja.

Mida maksimaalne metrika teavitab

RFC 6987 kirjeldab ruuterit, mis teavitab oma mitte-stub-linke maksimaalse lingi metrikaga, mis on määratletud kui 0xffff. Ruuter kirjeldab endiselt ennast ja oma linke; ta lihtsalt hindab need vahemiku ülemises otsas, nii et iga teine ruuter arvutab selle kaudu kulgeva tee kalliks.

See on router-LSA muudatus, mitte topoloogia eemaldamine. Vahe on oluline: router-LSA tühjendamine võtab tagasi topoloogiateabe enda, mis võib tagasi võtta ka need seosed, mida on vaja ruuteri ja selle taga olevate prefiksite juurde jõudmiseks. Teate hoidmine ja selle hinna tõstmine säilitab need seosed. See on kogu erinevus selle tehnika ja eemaldamise vahel.

Ka RFC 6987 mehhanismil pole midagi pistmist piirkonnatüüpidega ega määratud ruuteri valimisega. Stub-piirkond blokeerib piirkonna piiril ühe lingi oleku teadete kategooria ja stub-ruuter hindab omaenda linke. Sarnased sõnad, seosetud masinad.

Miks kättesaadavus püsib, aga transiit mitte

Teistel ruuteritel on endiselt marsruut haru ühendatud prefiksitele, sest haru teavitab neid endiselt ja lingid on endiselt olemas. Muutub mis tahes tee kogukulu, mis läbib haru teel kuhugi mujale. Prefiksid ei liigu; muutub ainult ruuteri läbimise hind.

Liikluse puhul, mille allikas või sihtkoht on haru ise, on kallis link endiselt ainsal mõistlikul teel, seega seda kasutatakse. Kahe kontori vahelise liikluse puhul võidab alternatiivne tee nüüd kulu poolest ja haru langeb edastusotsusest välja, kadumata topoloogiast. Kaks suunda, kaks erinevat vastust ja mõlemad on mehhanismi töötamine.

See on käitumine, mida tuleb kontrollida, mitte eeldada. Vaata router-LSA-d, mille haru genereerib, seejärel teed, mille mõni teine ruuter valib haru taga oleva sihtkoha ja teise kontori sihtkoha jaoks. Kaks vastust peaksid erinema ja kui nad ei erine, ei jõua metrika muudatus otsuseni, mida sa arvad.

Viimase tee probleem

Sama RFC ütleb selgelt, et tehnika ei keela kasutamist. Kui alternatiivne tee üles ütleb, langevad ruuterid tagasi haru kaudu kulgevale kallile teele, sest see on endiselt kehtiv tee ja protokoll eelistab kallist marsruuti selle puudumisele.

Kas see tagasilangemine on vastuvõetav, on poliitikaküsimus, millele pead enne juurutamist vastama. Väikesel üleslingil olev haru, mis äkki kannab kontoritevahelist liiklust, võib olla hullem kui katkestus, ja see võib olla täpselt see, mida sa hooldusakna ajal soovid. Mõlemad vastused on legitiimsed; vaikimine ei ole.

Kui nõue on range keeld, mitte eelistus, ei anna metrika kavand üksi seda. Sul on vaja edastuse jõustamist, mis vastab kavatsusele, pluss määratletud käitumine juhuks, kui liiklus siiski saabub. Tee kasutatavana teavitamine ja seejärel liikluse maha viskamine loob musta augu, mida on raskem diagnoosida kui marsruutimistsüklit.

OSPFv3 puhul käsitleb RFC R-bitti teistsuguse viisina transiidis osalemise välistamiseks. Ära eelda, et see pärib sama viimase tee käitumise nagu maksimaalse metrika tehnika, ja ära kopeeri seadeid kahe aadressiperekonna vahel, nagu oleks tegu sama funktsiooniga.

Tõesta seda tavalistes ja ebaõnnestunud tingimustes

Testi kaks korda: üks kord mõlema tee olemasolul ja üks kord eelistatud tee eemaldamisel. Esimene test näitab eelistuse toimimist ja teine näitab, mida võrk teeb, kui eelistust ei saa austada. Teise testi vahelejätmine jätab olulise poole uurimata.

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

Andmebaasi vaade näitab teavitatud metrikat, marsruudi otsing näitab valitud järgmist hüpet ja jälg näitab, kuhu paketid tegelikult läksid. Kui need kolm kattuvad, on sul kontrollitud kavand, mitte õigena näiv konfiguratsioon.

Seejärel taasta eelistatud tee ja kinnita, et haru naaseb ainult oma liikluse kandmise juurde. Taastamise samm kuulub testi, mitte koristamise juurde, sest kavand, mis töötab ainult järgmise muudatuseni, ei ole kavand. Kirjuta üles mõlemad tulemused, sealhulgas tagasilangemine, sest teine on vastus, mida keegi vajab kell kolm öösel.