OSPF maximal metrik: motverka transit genom en filial utan att ta bort den

Två kontor är sammankopplade via en filial som ska bära sin egen trafik och väldigt lite annat. Filialen behöver rutter till båda platserna, och ingen av de två platserna bör föredra den som vägen mellan dem. Att ta bort filialen från topologin skulle lösa transitproblemet och bryta kravet, eftersom filialen fortfarande måste nå båda platserna och båda platserna fortfarande måste nå filialen.

Det du vill ha är en preferens, uttryckt i routingprotokollet, som lämnar filialen fullt nåbar och gör den till ett dåligt val för allt som passerar genom den. Gå igenom problemet i den ordning som routrarna ser det.

Börja med vägen du vill undvika

Rita topologin som protokollet ser den, inte som diagrammet ser den. Vilka gränssnitt bildar grannskap, vilka ligger i samma område, och vilka av dessa grannskap skulle bära trafik mellan de två kontoren om filialen föredrogs? Det är tre separata frågor, och ett diagram besvarar ingen av dem pålitligt.

Hitta sedan den alternativa vägen. Om den enda rutten mellan kontoren går genom filialen kan ingen metrik flytta trafiken därifrån, eftersom trafiken inte har någonstans att ta vägen. Redundans är inte en detalj i den här designen; det är förutsättningen. En andra väg som bara finns på papperet räknas inte.

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

Dessa tre vyer besvarar olika frågor: vem som är granne, vilka gränssnitt som deltar och till vilket pris, och vilken väg enheten väljer just nu. En tunnelutrullning lägger till en fjärde: en linje på ett diagram är inte bevis för att grannskapet bildades över den, och ett bildat grannskap är inte bevis för att vidarebefordran följer samma väg. Det är i tunnellösningar den luckan oftast syns.

Vad den maximala metriken annonserar

RFC 6987 beskriver en router som annonserar sina icke-stub-länkar med den maximala länkmetriken, definierad som 0xffff. Routern beskriver fortfarande sig själv och sina länkar; den prissätter dem bara i toppen av intervallet, så varje annan router beräknar en väg genom den som dyr.

Detta är en router-LSA-ändring, inte en borttagning av topologin. Skillnaden är viktig: att flusha router-LSA:n drar tillbaka själva topologiinformationen, vilket också kan dra tillbaka de relationer som behövs för att nå routern och prefixen bakom den. Att behålla annonseringen och höja dess pris bevarar dessa relationer. Det är hela skillnaden mellan den här tekniken och borttagning.

Mekanismen RFC 6987 har inte heller något att göra med områdestyper eller med val av utsedd router. Ett stubområde blockerar en kategori länktillståndsannonseringar vid en områdesgräns, och en stubrouter prissätter sina egna länkar. Liknande ord, orelaterad maskin.

Varför nåbarheten överlever och transiten inte

Andra routrar har fortfarande en rutt till filialens anslutna prefix, eftersom filialen fortfarande annonserar dem och länkarna fortfarande finns. Det som ändras är det totala priset för varje väg som passerar genom filialen på väg någon annanstans. Prefixen flyttar sig inte; bara priset för att korsa routern ändras.

För trafik vars källa eller mål är filialen själv ligger den dyra länken fortfarande på den enda förnuftiga vägen, så den används. För trafik mellan de två kontoren vinner den alternativa vägen nu på pris, och filialen faller ur vidarebefordringsbeslutet utan att försvinna från topologin. Två riktningar, två olika svar, och båda är mekanismen som fungerar.

Det är beteendet att verifiera i stället för att anta. Titta på router-LSA:n som filialen genererar, sedan på vägen som en annan router väljer för ett mål bakom filialen och för ett mål i det andra kontoret. De två svaren bör skilja sig, och om de inte gör det når metrikändringen inte det beslut du tror.

Problemet med den sista vägen

Samma RFC är tydlig med att tekniken inte förbjuder användning. När den alternativa vägen fallerar faller routrarna tillbaka på den dyra vägen genom filialen, eftersom den fortfarande är en giltig väg och protokollet föredrar en dyr rutt framför ingen rutt.

Om den återgången är acceptabel är en policyfråga du måste besvara före utrullning. En filial på en liten upplänk som plötsligt bär trafik mellan kontoren kan vara värre än ett avbrott, och det kan vara precis vad du vill under ett underhållsfönster. Båda svaren är legitima; tystnad är det inte.

Om kravet är ett strikt förbud i stället för en preferens kommer metrikdesign ensam inte att ge det. Du behöver verkställande av vidarebefordran som matchar avsikten, plus ett definierat beteende för fallet då trafiken ändå anländer. Att annonsera en väg som användbar och sedan släppa trafiken skapar ett svart hål som är svårare att diagnostisera än en routingloop.

För OSPFv3 diskuterar RFC:n R-biten som ett annat sätt att utesluta transitdeltagande. Anta inte att den ärver samma beteende för den sista vägen som maximimetriktekniken, och kopiera inte inställningar mellan de två adressfamiljerna som om de vore samma funktion.

Bevisa det under normala och felande förhållanden

Testa två gånger: en gång med båda vägarna tillgängliga och en gång med den föredragna vägen borttagen. Det första testet visar att preferensen fungerar, och det andra visar vad nätverket gör när preferensen inte kan respekteras. Att hoppa över det andra testet lämnar den viktiga halvan oundersökt.

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

Databasvyn visar den annonserade metriken, ruttuppslaget visar nästa hopp som valts, och spåret visar vart paketen faktiskt tog vägen. När de tre stämmer överens har du en verifierad design i stället för en konfiguration som ser rätt ut.

Återställ sedan den föredragna vägen och bekräfta att filialen återgår till att bära bara sin egen trafik. Återställningssteget hör till testet och inte till städningen, eftersom en design som bara fungerar till nästa ändring inte är en design. Skriv ned båda utfallen, inklusive återgången, eftersom det andra är svaret som någon kommer att behöva klockan tre på natten.