DMVPN WAN-failover: routebeleid of de tunnel uitschakelen?

Een DMVPN-hub met twee WAN's schakelt op een van twee manieren over, en het verschil is groter dan het lijkt. De ene verandert welke volgende hop een routebeleid kiest, zodat pakketten blijven stromen en alleen hun uitgang verandert. De andere schakelt de tunnel administratief uit, wat elke dienst op die interface meeneemt. Beide kunnen juist zijn, omdat ze verschillende vragen beantwoorden.

De beslissing komt vóór de configuratie

Drie voorwaarden beslissen dit voor u. Hangt er iets anders van af dat de tunnelinterface omhoog is, zoals een tweede DMVPN-profiel of een monitor die de status leest? Draagt het verkeer dat moet overstappen zijn eigen beleid, of vertrouwt het op de globale routetabel? En heeft de operator een ondubbelzinnige statuswijziging nodig, of is een stille padwissel acceptabel? Beantwoord die drie en de keuze maakt zich meestal zelf.

Als een uitschakeling diensten zou neerhalen die werkten, is het routebeleid de kleinere actie. Als de eis is dat de tunnel niet mag bestaan terwijl de primaire WAN omlaag is, kan geen beleidsregel dat uitdrukken.

Schrijf het antwoord op, want de configuratie is het makkelijke deel.

Wat het routebeleid werkelijk verandert

Bij beleidsgebaseerd routeren kan een gevolgd object een volgende hop sturen. De route-map-regel noemt een kandidaat-volgende-hop en het gevolgde object dat omhoog moet zijn om hem te gebruiken, en die volgstatus komt van een IP SLA-probe. Als het object omlaag gaat, stopt de regel met matchen en wordt het pakket beoordeeld door de volgende regel of door de gewone routetabel.

Dat laatste detail verrast mensen: een beleid dat stopt met het kiezen van een volgende hop staat meestal normaal routeren toe in plaats van verkeer te blokkeren. Als u een zwart gat bij uitval nodig hebt, moet u er een schrijven.

De syntaxis verschilt per platform en release, dus raadpleeg de gids voor de versie die u werkelijk draait.

Wat het uitschakelen van de tunnel verandert

Een interface uitschakelen verandert de administratieve status. Elke tunnel, route en sessie die ervan afhangt, gaat in één keer omlaag, wat precies is wat u wilt als de tunnel het ding is dat moet verdwijnen. Zo maakt een EEM-applet ook van een WAN-probleem een storing die losstaande diensten meeneemt.

Als u deze weg kiest, beperk het applet dan tot één interface en één trigger, bewaar de vorige administratieve status, definieer de herstelactie en zorg dat herhaalde flaps het niet in een lus kunnen drijven.

Een hardgecodeerd herstelcommando kan ook een onderhoudsuitschakeling van iemand anders overschrijven.

Laat de probe de weg nemen die u denkt

Een probe die de huidige beste route volgt, verhuist samen met al het andere naar de back-up-WAN en meldt daarna de primaire als gezond omdat hij die niet meer gebruikt.

Zet de probe vast aan de interface of het bronadres van de route die u test. Controleer ook waarop hij richt, want de volgende hop van de provider bereiken bewijst minder dan de dienst bereiken waarvoor de tunnel bestaat. Stel de op- en neerwaartse vertragingen bewust in: een korte neerwaartse vertraging reageert snel en flappt, terwijl een lange schommelingen doorstaat en echte storingen verbergt. Cisco's gids voor tracking en beleidsroutering in IOS XE documenteert de ondersteunde combinaties, en de functieset op uw platform bepaalt welke u kunt gebruiken.

Noteer beide vertragingswaarden naast het gevolgde object, anders weet niemand waarom het zich zo gedroeg.

Bepaal het herstel en verifieer daarna

Herstel verdient zijn eigen beslissing. Een link die steeds de drempel overschrijdt, kan sessies vaker verplaatsen dan een die duidelijk is uitgevallen, en elke verplaatsing kost nieuwe sleutelonderhandeling en nieuwe pogingen van de applicatie. Kies een stabiliteitseis en laat de vertraging die uitdrukken. Verifieer daarna tijdens een wijzigingsvenster met het pad van de probe zichtbaar: gekozen route, pad van de externe peer en wat de applicatie werkelijk deed.

Als de failover werkt maar de applicatie nog steeds breekt, zit het probleem boven de routeringslaag en geen enkele mate van tracking lost dat op.

Bewaar het bewijs uit dat venster, want de volgende wijziging wordt ermee vergeleken.