Failover i WAN-it në DMVPN: politikë rrugëtimi apo mbyllje e tunelit?

Një hub DMVPN me dy WAN kalon në rezervë në një nga dy mënyrat, dhe ndryshimi është më i madh nga sa duket. Njëra ndryshon cilin hop të ardhshëm zgjedh politika e rrugëtimit, kështu që paketat vazhdojnë të rrjedhin dhe ndryshon vetëm dalja e tyre. Tjetra mbyll tunelin administrativisht, gjë që rrëzon me vete çdo shërbim në atë ndërfaqe. Të dyja mund të jenë të sakta, sepse përgjigjen për pyetje të ndryshme.

Vendimi vjen para konfigurimit

Tre kushte e vendosin këtë për ju. A varet diçka tjetër nga fakti që ndërfaqja e tunelit është aktive, si një profil i dytë DMVPN ose një monitor që lexon gjendjen e tij? A e mban trafiku që duhet të kalojë në rezervë politikën e vet, apo mbështetet në tabelën globale të rrugëtimit? Dhe a ka nevojë operatori për një ndryshim gjendjeje të padiskutueshëm, apo është i pranueshëm një ndërrim i qetë i rrugës? Përgjigjuni këtyre treve dhe zgjedhja zakonisht bëhet vetë.

Nëse mbyllja do të rrëzonte shërbime që punonin, politika e rrugëtimit është veprimi më i vogël. Nëse kërkesa është që tuneli të mos ekzistojë sa kohë WAN-i kryesor është jashtë, asnjë zë politikë nuk mund ta shprehë atë.

Shkruajeni përgjigjen, sepse konfigurimi është pjesa e lehtë.

Çfarë ndryshon në të vërtetë politika e rrugëtimit

Me rrugëtim të bazuar në politika, një objekt i ndjekur mund të kontrollojë hop-in e ardhshëm. Zëri i hartës së rrugëve emërton një hop të ardhshëm kandidat dhe objektin e ndjekur që duhet të jetë aktiv që ai të përdoret, dhe ai status ndjekjeje vjen nga një sondë IP SLA. Kur objekti bie, zëri ndalon së përputhuri dhe paketa vlerësohet nga zëri tjetër ose nga tabela e zakonshme e rrugëtimit.

Ky detaj i fundit i befason njerëzit: një politikë që ndalon zgjedhjen e hop-it të ardhshëm zakonisht lejon rrugëtim normal në vend që të bllokojë trafikun. Nëse keni nevojë për një vrimë të zezë në rast dështimi, duhet ta shkruani vetë.

Sintaksa ndryshon midis platformave dhe versioneve, prandaj konsultoni udhëzuesin për versionin që ekzekutoni vërtet.

Çfarë ndryshon mbyllja e tunelit

Mbyllja e një ndërfaqeje ndryshon gjendjen administrative. Çdo tunel, rrugë dhe sesion që varet prej saj bie menjëherë, gjë që është pikërisht ajo që dëshironi nëse tuneli është gjëja që duhet të zhduket. Kështu edhe një applet EEM e kthen një problem WAN në një ndërprerje që përfshin shërbime të palidhura.

Nëse zgjidhni këtë rrugë, kufizoni appletin në një ndërfaqe dhe një shkaktar, ruani gjendjen administrative të mëparshme, përcaktoni veprimin e rikuperimit dhe sigurohuni që flappet e përsëritura nuk mund ta shtyjnë në një lak.

Një komandë rikuperimi e koduar fort mund të anulojë gjithashtu një mbyllje mirëmbajtjeje që ka bërë dikush tjetër.

Bëjeni sondën të udhëtojë në rrugën që mendoni

Një sondë që ndjek rrugën më të mirë aktuale kalon në WAN-in rezervë bashkë me gjithçka tjetër dhe më pas raporton kryesorin si të shëndetshëm, sepse nuk e përdor më.

Lidheni sondën me ndërfaqen ose adresën burimore të rrugës që po testoni. Kontrolloni edhe çfarë synon, sepse arritja e hop-it të ardhshëm të ofruesit provon më pak sesa arritja e shërbimit për të cilin ekziston tuneli. Vendosni vonesat e ngjitjes dhe zbritjes me qëllim: një vonesë e shkurtër zbritjeje reagon shpejt dhe flappon, ndërsa një e gjatë i përballon lëkundjet dhe fsheh dështimet e vërteta. Udhëzuesi i Cisco për ndjekjen dhe rrugëtimin e bazuar në politika në IOS XE dokumenton kombinimet e mbështetura, dhe grupi i veçorive në platformën tuaj vendos cilat prej tyre mund të përdorni.

Shënoni të dyja vlerat e vonesës pranë objektit të ndjekur, përndryshe askush nuk do të dijë pse u soll kështu.

Vendosni për rikuperimin, pastaj verifikoni

Rikuperimi meriton vendimin e vet. Një lidhje që kalon vazhdimisht pragun mund t'i zhvendosë sesionet më shpesh sesa një që ka dështuar qartë, dhe çdo zhvendosje kushton rinegocim çelësash dhe përpjekje të përsëritura të aplikacionit. Zgjidhni një kërkesë stabiliteti dhe lëreni vonesën ta shprehë atë. Pastaj verifikoni gjatë një dritareje ndryshimi me rrugën e sondës të dukshme: rruga e zgjedhur, rruga e partnerit të jashtëm dhe çfarë bëri vërtet aplikacioni.

Nëse failover funksionon por aplikacioni vazhdon të thyhet, problemi qëndron mbi shtresën e rrugëtimit dhe asnjë sasi ndjekjeje nuk do ta rregullojë.

Ruani provat nga ajo dritare, sepse ndryshimi i radhës do të krahasohet me to.