DMVPN WAN-failover: ruttpolicy eller stänga tunneln?

En DMVPN-hubb med två WAN växlar till reserv på ett av två sätt, och skillnaden är större än den ser ut. Den ena ändrar vilket nästa hopp en ruttpolicy väljer, så paketen fortsätter flöda och bara deras utgång ändras. Den andra stänger tunneln administrativt, vilket tar ned varje tjänst på det gränssnittet. Båda kan vara rätt, eftersom de svarar på olika frågor.

Beslutet kommer före konfigurationen

Tre villkor avgör detta åt dig. Beror något annat på att tunnelgränssnittet är uppe, som en andra DMVPN-profil eller en övervakare som läser dess status? Bär trafiken som måste växla över en egen policy, eller förlitar den sig på den globala routingtabellen? Och behöver operatören en omisskännlig tillståndsändring, eller är ett tyst vägbyte acceptabelt? Svara på de tre och valet gör sig oftast självt.

Om en stängning skulle ta ned tjänster som fungerade, är ruttpolicyn den mindre åtgärden. Om kravet är att tunneln inte får finnas medan det primära WAN-et är nere, kan ingen policy-post uttrycka det.

Skriv ned svaret, för konfigurationen är den lätta delen.

Vad ruttpolicyn faktiskt ändrar

Med policybaserad routing kan ett spårat objekt styra ett nästa hopp. Ruttkartposten namnger ett kandidat-nästa-hopp och det spårade objektet som måste vara uppe för att det ska användas, och det spårningstillståndet kommer från en IP SLA-sond. När objektet går ned slutar posten matcha och paketet utvärderas av nästa post eller av den vanliga routingtabellen.

Den sista detaljen förvånar folk: en policy som slutar välja nästa hopp tillåter oftast normal routing i stället för att blockera trafik. Om du behöver ett svart hål vid fel, måste du skriva ett.

Syntaxen skiljer sig mellan plattformar och versioner, så kontrollera guiden för den version du faktiskt kör.

Vad det ändrar att stänga tunneln

Att stänga ett gränssnitt ändrar administrativt tillstånd. Varje tunnel, rutt och session som beror på det går ned på en gång, vilket är exakt vad du vill om tunneln är det som ska försvinna. Det är också så en EEM-applet gör ett WAN-problem till ett avbrott som omfattar orelaterade tjänster.

Om du väljer den vägen, begränsa appletten till ett gränssnitt och en utlösare, spara föregående administrativa tillstånd, definiera återställningsåtgärden och se till att upprepade flapp inte kan driva den i loop.

Ett hårdkodat återställningskommando kan också åsidosätta en underhållsstängning som någon annan gjort.

Låt sonden färdas den väg du tror

En sond som följer den aktuella bästa rutten flyttar till reserv-WAN-et tillsammans med allt annat och rapporterar sedan den primära som frisk eftersom den inte längre använder den.

Fäst sonden vid gränssnittet eller källadressen för den väg du testar. Kontrollera också vad den siktar på, eftersom att nå leverantörens nästa hopp bevisar mindre än att nå tjänsten tunneln finns för. Sätt upp- och nedfördröjningarna med avsikt: en kort nedfördröjning reagerar snabbt och flappar, medan en lång rider ut korta störningar och döljer verkliga fel. Ciscos guide för spårning och policyrouting i IOS XE dokumenterar de kombinationer som stöds, och funktionsuppsättningen på din plattform avgör vilka av dem du kan använda.

Anteckna båda fördröjningsvärdena bredvid det spårade objektet, annars vet ingen varför det betedde sig så.

Bestäm återställning och verifiera sedan

Återställning förtjänar ett eget beslut. En länk som ständigt korsar tröskeln kan flytta sessioner oftare än en som tydligt har misslyckats, och varje flytt kostar ny nyckelutväxling och nya applikationsförsök. Välj ett stabilitetskrav och låt fördröjningen uttrycka det. Verifiera sedan i ett ändringsfönster med sondens väg synlig: vald rutt, yttre peer-väg och vad applikationen faktiskt gjorde.

Om failovern fungerar men applikationen fortfarande går sönder, sitter problemet ovanför routinglagret och ingen mängd spårning kommer att fixa det.

Spara bevisen från det fönstret, eftersom nästa ändring kommer att jämföras med dem.