OSPF maksimumsmetrikk: unngå transit gjennom en filial uten å fjerne den

To kontorer er koblet sammen gjennom en filial som skal bære sin egen trafikk og svært lite annet. Filialen trenger ruter til begge stedene, og ingen av de to stedene bør foretrekke den som veien mellom dem. Å fjerne filialen fra topologien ville løse transitproblemet og bryte kravet, fordi filialen fortsatt må nå begge stedene, og begge stedene må fortsatt nå filialen.

Det du vil ha, er en preferanse uttrykt i rutingsprotokollen, som lar filialen være fullt tilgjengelig og gjør den til et dårlig valg for alt som går gjennom den. Gå gjennom problemet i den rekkefølgen ruterne ser det.

Start med veien du vil unngå

Tegn topologien slik protokollen ser den, ikke slik diagrammet ser den. Hvilke grensesnitt danner naboforhold, hvilke er i samme område, og hvilke av disse naboforholdene ville bære trafikk mellom de to kontorene hvis filialen ble foretrukket? Det er tre separate spørsmål, og et diagram svarer ikke pålitelig på noen av dem.

Finn deretter den alternative veien. Hvis den eneste ruten mellom kontorene går gjennom filialen, kan ingen metrikk flytte trafikk bort fra den, fordi trafikken ikke har noe sted å gå. Redundans er ikke en detalj i dette designet; det er forutsetningen. En andre vei som bare finnes på papiret, teller ikke.

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

Disse tre visningene svarer på forskjellige spørsmål: hvem som er nabo, hvilke grensesnitt som deltar og til hvilken pris, og hvilken vei enheten velger akkurat nå. En tunnelutrulling legger til en fjerde: en linje på et diagram er ikke bevis for at naboforholdet ble dannet over den, og et dannet naboforhold er ikke bevis for at videresendingen følger samme vei. Det er i tunnelløsninger denne forskjellen oftest viser seg.

Hva maksimumsmetrikken annonserer

RFC 6987 beskriver en ruter som annonserer sine ikke-stub-lenker med den maksimale lenkemetrikken, definert som 0xffff. Ruteren beskriver fortsatt seg selv og lenkene sine; den priser dem bare i toppen av området, slik at hver annen ruter beregner en vei gjennom den som dyr.

Dette er en endring i router-LSA, ikke en fjerning av topologien. Forskjellen er viktig: å flushe router-LSA-en trekker selve topologiinformasjonen tilbake, noe som også kan trekke tilbake relasjonene som trengs for å nå ruteren og prefiksene bak den. Å beholde annonseringen og heve prisen bevarer disse relasjonene. Det er hele forskjellen mellom denne teknikken og fjerning.

Mekanismen RFC 6987 har heller ingenting å gjøre med områdetyper eller med valg av utpekt ruter. Et stubområde blokkerer en kategori lenketilstandsannonseringer ved en områdegrense, og en stubruter priser sine egne lenker. Lignende ord, urelatert maskineri.

Hvorfor tilgjengeligheten overlever og transitten ikke

Andre rutere har fortsatt en rute til filialens tilkoblede prefikser, fordi filialen fortsatt annonserer dem, og lenkene fortsatt finnes. Det som endres, er den totale prisen for enhver vei som passerer gjennom filialen på vei et annet sted. Prefiksene flytter seg ikke; bare prisen for å krysse ruteren endres.

For trafikk der kilden eller målet er filialen selv, ligger den dyre lenken fortsatt på den eneste fornuftige veien, så den brukes. For trafikk mellom de to kontorene vinner den alternative veien nå på pris, og filialen faller ut av videresendingsbeslutningen uten å forsvinne fra topologien. To retninger, to forskjellige svar, og begge er mekanismen som virker.

Det er atferden som skal verifiseres i stedet for antas. Se på router-LSA-en filialen genererer, deretter på veien en annen ruter velger for et mål bak filialen og for et mål i det andre kontoret. De to svarene bør være forskjellige, og hvis de ikke er det, når metrikkendringen ikke beslutningen du tror.

Problemet med den siste veien

Den samme RFC-en er tydelig på at teknikken ikke forbyr bruk. Når den alternative veien svikter, faller ruterne tilbake til den dyre veien gjennom filialen, fordi den fortsatt er en gyldig vei og protokollen foretrekker en dyr rute fremfor ingen rute.

Om denne tilbakefallingen er akseptabel, er et policy-spørsmål du må svare på før utrulling. En filial på en liten opplenke som plutselig bærer trafikk mellom kontorene, kan være verre enn et avbrudd, og det kan være akkurat det du vil under et vedlikeholdsvindu. Begge svarene er legitime; stillhet er det ikke.

Hvis kravet er et strengt forbud i stedet for en preferanse, vil metrikkdesign alene ikke gi det. Du trenger håndheving av videresendingen som samsvarer med intensjonen, pluss en definert atferd for tilfellet der trafikken likevel ankommer. Å annonsere en vei som brukbar og deretter droppe trafikken skaper et svart hull som er vanskeligere å diagnostisere enn en rutingsløyfe.

For OSPFv3 diskuterer RFC-en R-biten som en annen måte å utelukke transitdeltakelse på. Ikke anta at den arver samme atferd for den siste veien som maksimumsmetrikkteknikken, og ikke kopier innstillinger mellom de to adressefamiliene som om de var samme funksjon.

Bevis det under normale og feilede forhold

Test to ganger: én gang med begge veiene tilgjengelige og én gang med den foretrukne veien fjernet. Den første testen viser at preferansen virker, og den andre viser hva nettverket gjør når preferansen ikke kan overholdes. Å hoppe over den andre testen lar 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

Databasevisningen viser den annonserte metrikken, ruteoppslaget viser det valgte neste hoppet, og sporet viser hvor pakkene faktisk gikk. Når de tre er enige, har du et verifisert design i stedet for en konfigurasjon som ser riktig ut.

Gjenopprett deretter den foretrukne veien og bekreft at filialen går tilbake til å bære bare sin egen trafikk. Gjenopprettingstrinnet hører til testen og ikke til oppryddingen, fordi et design som bare virker til neste endring, ikke er et design. Skriv ned begge utfallene, inkludert tilbakefallingen, fordi det andre er svaret noen trenger klokken tre om natten.