OSPF maksimumsmetrikk: unngå transit gjennom ein filial utan å fjerna han

To kontor er knytte saman gjennom ein filial som skal bera sin eigen trafikk og svært lite anna. Filialen treng ruter til båe stadene, og ingen av dei to stadene bør føretrekkja han som vegen mellom dei. Å fjerna filialen frå topologien ville løysa transitproblemet og bryta kravet, fordi filialen framleis må nå båe stadene, og båe stadene må framleis nå filialen.

Det du vil ha, er ein preferanse uttrykt i rutingsprotokollen, som lèt filialen vera fullt tilgjengeleg og gjer han til eit dårleg val for alt som går gjennom han. Gå gjennom problemet i den rekkjefølgja rutarane ser det.

Start med vegen du vil unngå

Teikn topologien slik protokollen ser han, ikkje slik diagrammet ser han. Kva grensesnitt dannar nabotilhøve, kva ligg i same område, og kva av desse nabotilhøva ville bera trafikk mellom dei to kontora om filialen vart føretrekt? Det er tre separate spørsmål, og eit diagram svarar ikkje påliteleg på noko av dei.

Finn deretter den alternative vegen. Om den einaste ruta mellom kontora går gjennom filialen, kan ingen metrikk flytta trafikk bort frå han, fordi trafikken ikkje har nokon stad å gå. Redundans er ikkje ein detalj i dette designet; det er føresetnaden. Ein andre veg som berre finst på papiret, tel ikkje.

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

Desse tre visingane svarar på ulike spørsmål: kven som er nabo, kva grensesnitt som deltek og til kva pris, og kva veg eininga vel akkurat no. Ein tunnelutrulling legg til ein fjerde: ei linje på eit diagram er ikkje prov på at nabotilhøvet vart danna over ho, og eit danna nabotilhøve er ikkje prov på at videresendinga følgjer same veg. Det er i tunnelløysingar denne skilnaden oftast viser seg.

Kva maksimumsmetrikken annonserer

RFC 6987 skildrar ein rutar som annonserer dei ikkje-stub-lenkene sine med den maksimale lenkemetrikken, definert som 0xffff. Rutaren skildrar framleis seg sjølv og lenkene sine; han prissett dei berre i toppen av området, slik at kvar annan rutar reknar ein veg gjennom han som dyr.

Dette er ei endring i router-LSA, ikkje ei fjerning av topologien. Skilnaden er viktig: å flushe router-LSA-en dreg sjølve topologiinformasjonen tilbake, noko som òg kan dra tilbake relasjonane som trengst for å nå rutaren og prefiksa bak han. Å halda på annonseringa og heva prisen bevarer desse relasjonane. Det er heile skilnaden mellom denne teknikken og fjerning.

Mekanismen RFC 6987 har heller ingenting å gjera med områdetypar eller med val av utpeikt rutar. Eit stubområde blokkerer ein kategori lenkjetilstandsannonseringar ved ei områdegrense, og ein stubrutar prissett sine eigne lenker. Liknande ord, urelatert maskineri.

Kvifor tilgjengelegda overlever og transitten ikkje

Andre rutarar har framleis ei rute til dei tilkopla prefiksa til filialen, fordi filialen framleis annonserer dei, og lenkene finst framleis. Det som endrar seg, er den totale prisen for kvar veg som går gjennom filialen på veg ein annan stad. Prefiksa flyttar seg ikkje; berre prisen for å krysse rutaren endrar seg.

For trafikk der kjelda eller målet er filialen sjølv, ligg den dyre lenka framleis på den einaste rimelege vegen, so ho vert brukt. For trafikk mellom dei to kontora vinn den alternative vegen no på pris, og filialen fell ut av videresendingsavgjerda utan å forsvinna frå topologien. To retningar, to ulike svar, og båe er mekanismen som verkar.

Det er åtferda som skal stadfestast i staden for å verte anteken. Sjå på router-LSA-en filialen genererer, deretter på vegen ein annan rutar vel for eit mål bak filialen og for eit mål i det andre kontoret. Dei to svara bør vera ulike, og om dei ikkje er det, når metrikkendringa ikkje avgjerda du trur.

Problemet med den siste vegen

Den same RFC-en er tydeleg på at teknikken ikkje forbyd bruk. Når den alternative vegen sviktar, fell rutarane tilbake til den dyre vegen gjennom filialen, fordi han framleis er ein gyldig veg og protokollen føretrekk ei dyr rute framfor inga rute.

Om denne tilbakefallinga er akseptabel, er eit politisk spørsmål du må svara på før utrulling. Ein filial på ei lita opplenkje som plutseleg ber trafikk mellom kontora, kan vera verre enn eit avbrot, og det kan vera akkurat det du vil under eit vedlikehaldsvindauge. Båe svara er legitime; stille er det ikkje.

Om kravet er eit strengt forbod i staden for ein preferanse, vil metrikkdesign åleine ikkje gje det. Du treng handheving av videresendinga som svarar til intensjonen, pluss definert åtferd for tilfellet der trafikken likevel kjem. Å annonsera ein veg som brukbar og deretter sleppa trafikken skapar eit svart hol som er vanskelegare å diagnostisera enn ei rutingsløyfe.

For OSPFv3 drøftar RFC-en R-biten som ein annan måte å utelukka transitdeltaking på. Ikkje gå ut frå at han arvar same åtferd for den siste vegen som maksimumsmetrikkteknikken, og ikkje kopier innstillingar mellom dei to adressefamiliane som om dei var same funksjon.

Prov det under normale og feila tilhøve

Test to gonger: éin gong med båe vegene tilgjengelege og éin gong med den føretrekte vegen fjerna. Den første testen viser at preferansen verkar, og den andre viser kva nettverket gjer når preferansen ikkje kan haldast. Å hoppa over den andre testen lèt den viktige halvdelen stå uundersøkt.

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

Databasevisinga viser den annonserte metrikken, ruteoppslaget viser det valde neste hoppet, og sporet viser kvar pakkane faktisk gjekk. Når dei tre er samde, har du eit stadfesta design i staden for ein konfigurasjon som ser rett ut.

Gjenopprett deretter den føretrekte vegen og stadfest at filialen går tilbake til å bera berre sin eigen trafikk. Gjenopprettingstrinnet høyrer til testen og ikkje til oppryddinga, fordi eit design som berre verkar til neste endring, ikkje er eit design. Skriv ned båe utfalla, inkludert tilbakefallinga, fordi det andre er svaret nokon treng klokka tre om natta.