Failover WAN în DMVPN: politică de rutare sau închiderea tunelului?

Un hub DMVPN cu două WAN-uri face failover într-unul din două moduri, iar diferența este mai mare decât pare. Unul schimbă ce următor salt alege o politică de rutare, așa că pachetele continuă să curgă și doar ieșirea lor se schimbă. Celălalt închide tunelul administrativ, ceea ce coboară cu el fiecare serviciu de pe acea interfață. Ambele pot fi corecte, pentru că răspund la întrebări diferite.

Decizia vine înaintea configurației

Trei condiții decid acest lucru pentru dumneavoastră. Depinde altceva de faptul că interfața tunelului este activă, cum ar fi un al doilea profil DMVPN sau un monitor care îi citește starea? Traficul care trebuie să facă failover poartă o politică proprie sau se bazează pe tabela de rutare globală? Și operatorul are nevoie de o schimbare de stare fără echivoc, sau este acceptabilă o comutare silențioasă a căii? Răspundeți la aceste trei și alegerea se face de obicei singură.

Dacă o închidere ar coborî servicii care funcționau, politica de rutare este acțiunea mai mică. Dacă cerința este ca tunelul să nu existe cât timp WAN-ul principal este căzut, nicio intrare de politică nu poate exprima asta.

Scrieți răspunsul, pentru că configurația este partea ușoară.

Ce schimbă de fapt politica de rutare

Cu rutarea bazată pe politici, un obiect urmărit poate controla următorul salt. Intrarea din harta de rute numește un următor salt candidat și obiectul urmărit care trebuie să fie activ pentru a fi folosit, iar starea de urmărire provine dintr-o sondă IP SLA. Când obiectul cade, intrarea nu mai corespunde și pachetul este evaluat de următoarea intrare sau de tabela de rutare obișnuită.

Ultimul detaliu îi surprinde pe oameni: o politică ce nu mai alege următorul salt permite de obicei rutarea normală în loc să blocheze traficul. Dacă aveți nevoie de o gaură neagră la defecțiune, trebuie să scrieți una.

Sintaxa diferă între platforme și versiuni, așa că verificați ghidul pentru versiunea pe care o rulați efectiv.

Ce schimbă închiderea tunelului

Închiderea unei interfețe schimbă starea administrativă. Fiecare tunel, rută și sesiune care depinde de ea cad deodată, ceea ce este exact ce doriți dacă tunelul este lucrul care trebuie să dispară. Tot așa un applet EEM transformă o problemă WAN într-o întrerupere care include servicii nelegate.

Dacă alegeți această cale, limitați applet-ul la o interfață și un declanșator, salvați starea administrativă anterioară, definiți acțiunea de recuperare și asigurați-vă că oscilațiile repetate nu îl pot duce într-o buclă.

O comandă de recuperare codificată poate anula și o închidere de mentenanță făcută de altcineva.

Faceți sonda să meargă pe calea pe care o credeți

O sondă care urmează cea mai bună rută actuală se mută pe WAN-ul de rezervă împreună cu tot restul și apoi raportează principalul ca sănătos pentru că nu îl mai folosește.

Fixați sonda la interfața sau la adresa sursă a căii pe care o testați. Verificați și ce țintește, deoarece a ajunge la următorul salt al furnizorului dovedește mai puțin decât a ajunge la serviciul pentru care există tunelul. Setați întârzierile de urcare și coborâre în mod deliberat: o întârziere scurtă de coborâre reacționează repede și oscilează, în timp ce una lungă suportă fluctuații scurte și ascunde defecțiuni reale. Ghidul Cisco despre urmărire și rutare bazată pe politici în IOS XE documentează combinațiile acceptate, iar setul de funcții al platformei dumneavoastră decide pe care le puteți folosi.

Notați ambele valori de întârziere lângă obiectul urmărit, altfel nimeni nu va ști de ce s-a comportat astfel.

Decideți recuperarea, apoi verificați

Recuperarea merită o decizie proprie. O legătură care traversează pragul continuu poate muta sesiuni mai des decât una care a eșuat clar, iar fiecare mutare costă renegocierea cheilor și reîncercări ale aplicației. Alegeți o cerință de stabilitate și lăsați întârzierea să o exprime. Apoi verificați într-o fereastră de schimbare cu calea sondei vizibilă: ruta selectată, calea partenerului extern și ce a făcut de fapt aplicația.

Dacă failover-ul funcționează dar aplicația încă se rupe, problema este deasupra stratului de rutare și nicio cantitate de urmărire nu o va rezolva.

Păstrați dovezile din acea fereastră, pentru că următoarea schimbare va fi comparată cu ele.