OSPF-maksimuma metriko: malinstigi transiton tra filio sen forigi ĝin

Du oficejoj konektiĝas tra filio, kiu devus porti sian propran trafikon kaj tre malmulte alian. La filio bezonas vojojn al ambaŭ ejoj, kaj neniu el la du ejoj devus preferi ĝin kiel la vojon inter ili. Forigi la filion el la topologio solvus la problemon de transito kaj rompus la postulon, ĉar la filio ankoraŭ devas atingi ambaŭ ejojn, kaj ambaŭ ejoj ankoraŭ devas atingi la filion.

Kion vi volas, estas prefero, esprimita en la enkursigada protokolo, kiu lasas la filion plene atingebla kaj igas ĝin malbona elekto por io ajn, kio pasas tra ĝi. Trairu la problemon en la ordo, en kiu la enkursigiloj vidas ĝin.

Komencu de la vojo, kiun vi volas eviti

Desegnu la topologion tiel, kiel la protokolo vidas ĝin, ne tiel, kiel la diagramo vidas ĝin. Kiuj interfacoj formas najbarecojn, kiuj estas en la sama areo, kaj kiuj el tiuj najbarecoj portus trafikon inter la du oficejoj, se la filio estus preferata? Tiuj estas tri apartaj demandoj, kaj diagramo fidinde respondas al neniu el ili.

Poste trovu la alternativan vojon. Se la sola vojo inter la oficejoj trapasas la filion, neniu metriko povas movi trafikon for de ĝi, ĉar la trafiko havas nenie iri. Redundo ne estas detalo de ĉi tiu dizajno; ĝi estas la antaŭkondiĉo. Dua vojo, kiu ekzistas nur surpapere, ne validas.

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

Ĉi tiuj tri vidoj respondas al malsamaj demandoj: kiu estas najbara, kiuj interfacoj partoprenas kaj kun kia kosto, kaj kiun vojon la aparato nun elektas. Tunela deplojo aldonas kvaran: linio sur diagramo ne estas pruvo, ke la najbareco formiĝis super ĝi, kaj formiĝinta najbareco ne estas pruvo, ke plusendado sekvas la saman vojon. Ĝuste en tunelaj dizajnoj tiu breĉo plej ofte aperas.

Kion anoncas la maksimuma metriko

RFC 6987 priskribas enkursigilon, kiu anoncas siajn ne-stubajn ligojn kun la maksimuma liga metriko, difinita kiel 0xffff. La enkursigilo ankoraŭ priskribas sin kaj siajn ligojn; ĝi simple prezigas ilin ĉe la supro de la gamo, tiel ke ĉiu alia enkursigilo komputas vojon tra ĝi kiel multekosta.

Ĉi tio estas ŝanĝo de router-LSA, ne forigo de topologio. La distingo gravas: forviŝi la router-LSA-on retiras la topologian informon mem, kio ankaŭ povas retiri la rilatojn necesajn por atingi la enkursigilon kaj la prefiksojn malantaŭ ĝi. Konservi la anoncon kaj altigi ĝian prezon konservas tiujn rilatojn. Tio estas la tuta diferenco inter ĉi tiu tekniko kaj forigo.

La mekanismo RFC 6987 ankaŭ havas nenion komunan kun areaj tipoj aŭ kun elekto de la difinita enkursigilo. Stub-areo blokas kategorion de ligostataj anoncoj ĉe area limo, kaj stub-enkursigilo prezigas siajn proprajn ligojn. Similaj vortoj, nerilata maŝinaro.

Kial atingeblo pluvivas kaj transito ne

Aliaj enkursigiloj ankoraŭ havas vojon al la konektitaj prefiksoj de la filio, ĉar la filio ankoraŭ anoncas ilin kaj la ligoj ankoraŭ ekzistas. Kio ŝanĝiĝas, estas la totala kosto de iu ajn vojo, kiu pasas tra la filio survoje aliloken. La prefiksoj ne moviĝas; nur la prezo de trapaso de la enkursigilo ŝanĝiĝas.

Por trafiko, kies fonto aŭ celo estas la filio mem, la multekosta ligo ankoraŭ estas sur la sola prudenta vojo, do ĝi estas uzata. Por trafiko inter la du oficejoj, la alternativa vojo nun venkas per kosto, kaj la filio elfalas el la plusenda decido sen malaperi el la topologio. Du direktoj, du malsamaj respondoj, kaj ambaŭ estas la mekanismo funkcianta.

Tio estas la konduto por kontroli anstataŭ supozi. Rigardu la router-LSA-on, kiun la filio generas, poste la vojon, kiun alia enkursigilo elektas por celo malantaŭ la filio kaj por celo en la alia oficejo. La du respondoj devus malsami, kaj se ili ne malsamas, la metrika ŝanĝo ne atingas la decidon, kiun vi pensas.

La problemo de la lasta vojo

La sama RFC estas klara, ke la tekniko ne malpermesas uzon. Kiam la alternativa vojo fiaskas, la enkursigiloj reiras al la multekosta vojo tra la filio, ĉar ĝi ankoraŭ estas valida vojo kaj la protokolo preferas multekostan vojon ol neniun vojon.

Ĉu tiu retroiro estas akceptebla, estas politika demando, kiun vi devas respondi antaŭ deplojo. Filio sur malgranda suprenligo, kiu subite portas interoficejan trafikon, povas esti pli malbona ol interrompo, kaj ĝi povas esti ĝuste tio, kion vi volas dum bontena fenestro. Ambaŭ respondoj estas legitimaj; silento ne estas.

Se la postulo estas strikta malpermeso anstataŭ prefero, metrika dizajno sola ne produktos ĝin. Vi bezonas plusendan devigon, kiu kongruas kun la intenco, plus difinita konduto por la kazo, kiam trafiko tamen alvenas. Anonci vojon kiel uzebla kaj poste forigi la trafikon kreas nigran truon, kiun estas pli malfacile diagnozi ol enkursigan buklon.

Por OSPFv3 la RFC diskutas la R-biton kiel alian manieron ekskludi transitan partoprenon. Ne supozu, ke ĝi heredas la saman lastvojan konduton kiel la maksimum-metrika tekniko, kaj ne kopiu agordojn inter la du adresaj familioj kvazaŭ ili estus la sama trajto.

Pruvu ĝin sub normalaj kaj fiaskaj kondiĉoj

Testu dufoje: unufoje kun ambaŭ vojoj disponeblaj kaj unufoje kun la preferata vojo forigita. La unua testo montras la preferon funkcii, kaj la dua montras, kion la reto faras, kiam la prefero ne povas esti honorata. Preterlasi la duan teston lasas la gravan duonon neekzamenita.

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

La datumbaza vido montras la anoncitan metrikon, la vojserĉo montras la elektitan sekvan salteton, kaj la spuro montras, kien la pakaĵoj efektive iris. Kiam tiuj tri kongruas, vi havas kontrolitan dizajnon anstataŭ agordon, kiu aspektas ĝusta.

Poste restarigu la preferatan vojon kaj konfirmu, ke la filio revenas al portado de nur sia propra trafiko. La restariga paŝo apartenas al la testo, ne al la purigado, ĉar dizajno, kiu funkcias nur ĝis la sekva ŝanĝo, ne estas dizajno. Skribu ambaŭ rezultojn, inkluzive de la retroiro, ĉar la dua estas la respondo, kiun iu bezonos je la tria matene.