OSPF-maksimumsmetrik: undgå transit gennem en filial uden at fjerne den

To kontorer forbindes gennem en filial, der skal bære sin egen trafik og meget lidt andet. Filialen har brug for ruter til begge steder, og ingen af de to steder bør foretrække den som vejen mellem dem. At fjerne filialen fra topologien ville løse transitproblemet og bryde kravet, fordi filialen stadig skal nå begge steder, og begge steder stadig skal nå filialen.

Det, du vil have, er en præference udtrykt i routingprotokollen, som lader filialen være fuldt tilgængelig og gør den til et dårligt valg for alt, der passerer igennem. Gå problemet igennem i den rækkefølge, routerne ser det.

Start med den vej, du vil undgå

Tegn topologien, som protokollen ser den, ikke som diagrammet ser den. Hvilke interfaces danner naboforhold, hvilke er i samme område, og hvilke af disse naboforhold ville bære trafik mellem de to kontorer, hvis filialen blev foretrukket? Det er tre separate spørgsmål, og et diagram besvarer ingen af dem pålideligt.

Find derefter den alternative vej. Hvis den eneste rute mellem kontorerne går gennem filialen, kan ingen metrik flytte trafik væk fra den, fordi der ikke er noget sted, trafikken kan gå hen. Redundans er ikke en detalje i dette design; det er forudsætningen. En anden vej, der kun findes på papiret, tæller ikke.

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

De tre visninger besvarer forskellige spørgsmål: hvem der er nabo, hvilke interfaces der deltager og til hvilken pris, og hvilken vej enheden vælger i øjeblikket. En tunneludrulning tilføjer en fjerde: en linje på et diagram er ikke bevis for, at naboforholdet blev dannet over den, og et dannet naboforhold er ikke bevis for, at videresendelsen følger samme vej. Det er i tunnelløsninger, at dette gab oftest viser sig.

Hvad maksimumsmetrikken annoncerer

RFC 6987 beskriver en router, der annoncerer sine ikke-stub-links med den maksimale linkmetrik, defineret som 0xffff. Routeren beskriver stadig sig selv og sine links; den prissætter dem blot i toppen af området, så enhver anden router beregner en vej igennem den som dyr.

Dette er en router-LSA-ændring, ikke en fjernelse af topologien. Forskellen er vigtig: at flushe router-LSA’en trækker selve topologiinformationen tilbage, hvilket også kan trække de relationer tilbage, der er nødvendige for at nå routeren og præfikserne bag den. At beholde annonceringen og hæve dens pris bevarer disse relationer. Det er hele forskellen mellem denne teknik og fjernelse.

Mekanismen RFC 6987 har heller intet at gøre med områdetyper eller med valg af udpeget router. Et stubområde blokerer en kategori af link-state-annonceringer ved en områdegrænse, og en stubrouter prissætter sine egne links. Lignende ord, urelateret maskineri.

Hvorfor tilgængelighed overlever, og transit ikke gør

Andre routere har stadig en rute til filialens tilsluttede præfikser, fordi filialen stadig annoncerer dem, og linkene stadig findes. Det, der ændrer sig, er den samlede pris for enhver vej, der passerer gennem filialen på vej til et andet sted. Præfikserne flytter sig ikke; kun prisen for at krydse routeren ændrer sig.

For trafik, hvis kilde eller destination er filialen selv, er det dyre link stadig på den eneste fornuftige vej, så det bruges. For trafik mellem de to kontorer vinder den alternative vej nu på pris, og filialen falder ud af videresendelsesbeslutningen uden at forsvinde fra topologien. To retninger, to forskellige svar, og begge er mekanismen, der virker.

Det er den adfærd, der skal verificeres frem for antages. Se på den router-LSA, filialen genererer, og derefter på den vej, en anden router vælger til en destination bag filialen og til en destination i det andet kontor. De to svar bør være forskellige, og hvis de ikke er, når metrikændringen ikke den beslutning, du tror.

Problemet med den sidste vej

Den samme RFC er klar over, at teknikken ikke forbyder brug. Når den alternative vej fejler, falder routerne tilbage til den dyre vej gennem filialen, fordi den stadig er en gyldig vej, og protokollen foretrækker en dyr rute frem for ingen rute.

Om det tilbagefald er acceptabelt, er et politikspørgsmål, du skal besvare, før du udruller. En filial på et lille uplink, der pludselig bærer kontortrafik, kan være værre end et udfald, og det kan være præcis, hvad du vil under et vedligeholdelsesvindue. Begge svar er legitime; tavshed er ikke.

Hvis kravet er et strengt forbud frem for en præference, vil metrikdesign alene ikke give det. Du har brug for håndhævelse af videresendelsen, der matcher hensigten, plus en defineret adfærd for det tilfælde, hvor trafikken alligevel ankommer. At annoncere en vej som brugbar og derefter droppe trafikken skaber et sort hul, der er sværere at diagnosticere end en routingløkke.

For OSPFv3 diskuterer RFC’en R-bitten som en anden måde at udelukke transitdeltagelse. Antag ikke, at den arver den samme adfærd for den sidste vej som maksimumsmetrikteknikken, og kopier ikke indstillinger mellem de to adressefamilier, som om de var den samme funktion.

Bevis det under normale og fejlede forhold

Test to gange: en gang med begge veje tilgængelige og en gang med den foretrukne vej fjernet. Den første test viser, at præferencen virker, og den anden viser, hvad netværket gør, når præferencen ikke kan overholdes. Springer du den anden test over, forbliver den vigtige halvdel uundersøgt.

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

Databasevisningen viser den annoncerede metrik, ruteopslaget viser det valgte næste hop, og sporet viser, hvor pakkerne faktisk gik. Når de tre er enige, har du et verificeret design i stedet for en konfiguration, der ser rigtig ud.

Gendan derefter den foretrukne vej, og bekræft at filialen vender tilbage til kun at bære sin egen trafik. Gendannelsestrinnet hører til testen og ikke til oprydningen, fordi et design, der kun virker indtil næste ændring, ikke er et design. Skriv begge udfald ned, inklusive tilbagefaldet, fordi det andet er det svar, nogen får brug for klokken tre om natten.