OSPF maksimalna metrika: odvraćanje tranzita kroz ogranak bez uklanjanja

Dvije kancelarije povezane su preko ogranka koji treba da nosi vlastiti saobraćaj i vrlo malo toga drugog. Ogranku su potrebne rute do oba lokaliteta, i nijedan lokalitet ne treba da ga preferira kao put između njih. Uklanjanje ogranka iz topologije riješilo bi problem tranzita i pokvarilo zahtjev, jer ogranak i dalje mora dosezati oba lokaliteta i oba lokaliteta i dalje moraju dosezati ogranak.

Ono što želite je preferencija, izražena u protokolu za rutiranje, koja ogranak ostavlja potpuno dostupnim i čini ga lošim izborom za sve što prolazi kroz njega. Prođite problemom redoslijedom kojim ga ruteri vide.

Pođite od puta koji želite izbjeći

Nacrtajte topologiju onako kako je protokol vidi, a ne kako je vidi dijagram. Koji interfejsi formiraju susjedstva, koji su u istoj oblasti i koja bi od tih susjedstava nosila saobraćaj između dvije kancelarije da je ogranak preferiran? To su tri odvojena pitanja, a dijagram ni na jedno ne odgovara pouzdano.

Zatim pronađite alternativni put. Ako jedina ruta između kancelarija prolazi kroz ogranak, nijedna metrika ne može premjestiti saobraćaj s njega, jer saobraćaj nema kuda otići. Redundantnost nije detalj ovog dizajna; ona je preduslov. Drugi put koji postoji samo na papiru se ne računa.

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

Ova tri prikaza odgovaraju na različita pitanja: ko je susjed, koji interfejsi učestvuju i po kojoj cijeni, te koji put uređaj trenutno bira. Primjena tunela dodaje četvrto: linija na dijagramu nije dokaz da je susjedstvo formirano preko nje, a formirano susjedstvo nije dokaz da prosljeđivanje slijedi isti put. Upravo se u tunelskim dizajnima ta praznina najčešće pokazuje.

Šta maksimalna metrika oglašava

RFC 6987 opisuje ruter koji oglašava svoje ne-stub veze s maksimalnom metrikom veze, definisanom kao 0xffff. Ruter i dalje opisuje sebe i svoje veze; samo ih cijeni na vrhu raspona, pa svaki drugi ruter izračunava put kroz njega kao skup.

Ovo je promjena router-LSA, a ne uklanjanje topologije. Razlika je važna: brisanje router-LSA povlači same informacije o topologiji, što može povući i odnose potrebne za dosezanje rutera i prefiksa iza njega. Zadržavanje oglasa i podizanje njegove cijene čuva te odnose. To je cijela razlika između ove tehnike i uklanjanja.

Mehanizam RFC 6987 također nema nikakve veze s tipovima oblasti ni s izborom označenog rutera. Stub oblast blokira kategoriju oglasa stanja veze na granici oblasti, a stub ruter cijeni vlastite veze. Slične riječi, nepovezana mašinerija.

Zašto dostupnost preživljava, a tranzit ne

Drugi ruteri i dalje imaju rutu do prefiksa povezanih s ogrankom, jer ih ogranak i dalje oglašava i veze i dalje postoje. Ono što se mijenja je ukupna cijena svakog puta koji prolazi kroz ogranak na putu negdje drugdje. Prefiksi se ne pomjeraju; mijenja se samo cijena prelaska preko rutera.

Za saobraćaj čiji je izvor ili odredište sam ogranak, skupa veza je i dalje na jedinom razumnom putu, pa se koristi. Za saobraćaj između dvije kancelarije alternativni put sada pobjeđuje po cijeni, a ogranak ispada iz odluke o prosljeđivanju, a da ne nestaje iz topologije. Dva smjera, dva različita odgovora, i oba su mehanizam koji radi.

To je ponašanje koje treba provjeriti, a ne pretpostaviti. Pogledajte router-LSA koji ogranak generiše, zatim put koji drugi ruter bira za odredište iza ogranka i za odredište u drugoj kancelariji. Dva odgovora treba da se razlikuju, a ako se ne razlikuju, promjena metrike ne doseže odluku za koju mislite da doseže.

Problem posljednjeg puta

Isti RFC izričito navodi da tehnika ne zabranjuje upotrebu. Kada alternativni put zakaže, ruteri se vraćaju na skupi put kroz ogranak, jer je on i dalje valjan put i protokol preferira skupu rutu umjesto nikakve rute.

Da li je taj povratak prihvatljiv, pitanje je politike na koje morate odgovoriti prije primjene. Ogranak na malom uzlaznom linku koji odjednom nosi međukancelarijski saobraćaj može biti gori od prekida, a može biti i upravo ono što želite tokom prozora za održavanje. Oba odgovora su legitimna; tišina nije.

Ako je zahtjev stroga zabrana, a ne preferencija, sam dizajn metrike to neće proizvesti. Potrebno vam je provođenje prosljeđivanja koje odgovara namjeri, plus definisano ponašanje za slučaj kada saobraćaj ipak stigne. Oglašavanje puta kao upotrebljivog i zatim odbacivanje saobraćaja stvara crnu rupu koju je teže dijagnostikovati od petlje rutiranja.

Za OSPFv3 RFC razmatra R-bit kao drugi način isključivanja učešća u tranzitu. Ne pretpostavljajte da nasljeđuje isto ponašanje posljednjeg puta kao tehnika maksimalne metrike, i ne kopirajte postavke između dvije adresne porodice kao da su ista karakteristika.

Dokažite to u normalnim i neuspjelim uslovima

Testirajte dvaput: jednom s oba dostupna puta i jednom s uklonjenim preferiranim putem. Prvi test pokazuje da preferencija radi, a drugi pokazuje šta mreža radi kada se preferencija ne može ispoštovati. Preskakanje drugog testa ostavlja važnu polovinu neispitanom.

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

Prikaz baze podataka pokazuje oglašenu metriku, pretraga rute pokazuje odabrani sljedeći hop, a trace pokazuje gdje su paketi zaista otišli. Kada se ta tri slože, imate provjeren dizajn, a ne konfiguraciju koja izgleda ispravno.

Zatim vratite preferirani put i potvrdite da se ogranak vraća nošenju samo vlastitog saobraćaja. Korak vraćanja pripada testu, a ne čišćenju, jer dizajn koji radi samo do sljedeće promjene nije dizajn. Zapišite oba ishoda, uključujući povratak, jer drugi je odgovor koji će nekome trebati u tri sata ujutro.