DMVPN WAN failover: patakaran ng ruta o isara ang tunnel?

Ang DMVPN hub na may dalawang WAN ay nag-failover sa isa sa dalawang paraan, at ang pagkakaiba ay mas malaki kaysa sa nakikita. Binabago ng isa kung aling susunod na hop ang pipiliin ng patakaran ng ruta, kaya patuloy na dumadaloy ang mga packet at ang labasan lamang ang nagbabago. Isinasara ng isa pa ang tunnel nang administratibo, na nagbababa sa lahat ng serbisyo sa interface na iyon. Pareho silang maaaring tama, dahil sumasagot sila sa magkaibang tanong.

Ang desisyon ay dumarating bago ang config

Tatlong kondisyon ang nagpapasya nito para sa iyo. May iba pa bang nakadepende sa pagiging aktibo ng tunnel interface, tulad ng pangalawang DMVPN profile o monitor na nagbabasa ng estado nito? Dinadala ba ng trapikong kailangang mag-failover ang sarili nitong patakaran, o umaasa ito sa pandaigdigang routing table? At kailangan ba ng operator ng hindi mapag-aalinlangang pagbabago ng estado, o katanggap-tanggap ang tahimik na paglilipat ng landas? Sagutin ang tatlong iyon at kadalasan ay kusang nagpapasya ang pagpili.

Kung ang pagsasara ay magbababa ng mga serbisyong gumagana, ang patakaran ng ruta ang mas maliit na aksyon. Kung ang hinihingi ay hindi dapat umiral ang tunnel habang down ang pangunahing WAN, walang entry sa patakaran ang makapagsasabi niyon.

Isulat ang sagot, dahil ang config ang madaling bahagi.

Ano ang talagang binabago ng patakaran ng ruta

Sa routing na nakabatay sa patakaran, ang sinusubaybayang object ay makokontrol ang susunod na hop. Pinapangalanan ng entry sa route map ang kandidatong susunod na hop at ang sinusubaybayang object na dapat aktibo para magamit ito, at ang estado ng pagsubaybay ay galing sa IP SLA probe. Kapag bumaba ang object, tumitigil sa pagtutugma ang entry at sinusuri ang packet ng susunod na entry o ng ordinaryong routing table.

Ang huling detalyeng iyon ay nakakagulat: ang patakarang tumitigil sa pagpili ng susunod na hop ay kadalasang pinapayagan ang normal na routing sa halip na harangin ang trapiko. Kung kailangan mo ng itong itim na butas kapag nabigo, kailangan mong isulat ito.

Nagkakaiba ang syntax sa mga platform at release, kaya tingnan ang gabay para sa bersyong talagang pinapatakbo mo.

Ano ang binabago ng pagsasara ng tunnel

Ang pagsasara ng interface ay nagbabago ng administratibong estado. Bumababa nang sabay ang bawat tunnel, ruta at session na nakadepende rito, na siyang eksaktong gusto mo kung ang tunnel ang bagay na dapat mawala. Ganoon din ginagawa ng EEM applet ang problema sa WAN na isang pagkawala na kasama ang mga serbisyong walang kaugnayan.

Kung tatahakin mo ang daang ito, limitahan ang applet sa isang interface at isang trigger, i-save ang dating administratibong estado, tukuyin ang aksyon sa pagbawi, at tiyakin na hindi ito maidudulot ng paulit-ulit na flap sa loop.

Ang hardcoded na utos sa pagbawi ay maaari ring manaig sa pagsasara para sa maintenance na ginawa ng ibang tao.

Hayaang dumaan ang probe sa landas na iniisip mo

Ang probe na sumusunod sa pinakamahusay na ruta sa kasalukuyan ay lumilipat sa backup na WAN kasama ang lahat ng iba pa, pagkatapos ay iniuulat na malusog ang pangunahin dahil hindi na niya ito ginagamit.

I-pin ang probe sa interface o source address ng landas na sinusubukan mo. Tingnan din kung ano ang pinupuntirya nito, dahil ang maabot ang susunod na hop ng provider ay nagpapatunay ng mas kaunti kaysa maabot ang serbisyong pinaglilingkuran ng tunnel. Itakda nang sadya ang pagkaantala sa pag-akyat at pagbaba: ang maikling pagbaba ay mabilis tumugon at nag-flap, habang ang mahaba ay nakakayanan ang maliliit na pag-alog at nagtatago ng tunay na pagkasira. Ang gabay ng Cisco sa pagsubaybay at routing na nakabatay sa patakaran sa IOS XE ay nagdodokumento ng mga sinusuportahang kombinasyon, at ang set ng feature sa iyong platform ang nagpapasya kung alin sa mga ito ang magagamit mo.

Itala ang parehong halaga ng pagkaantala sa tabi ng sinusubaybayang object, kung hindi ay walang makakaalam kung bakit ganoon ang inasal nito.

Magpasya sa pagbawi, pagkatapos ay i-verify

Ang pagbawi ay may karapatan sa sariling desisyon. Ang link na paulit-ulit na tumatawid sa threshold ay maaaring maglipat ng session nang mas madalas kaysa sa isang malinaw na nabigo, at bawat paglipat ay may halagang muling pakikipagnegosasyon ng key at muling pagsubok ng application. Pumili ng pangangailangan sa stability at hayaang ipahayag ito ng pagkaantala. Pagkatapos ay i-verify sa loob ng window ng pagbabago habang nakikita ang landas ng probe: napiling ruta, landas ng panlabas na peer at ang aktwal na ginawa ng application.

Kung gumagana ang failover pero nasisira pa rin ang application, ang problema ay nasa itaas ng routing layer at walang dami ng pagsubaybay ang makakapag-ayos nito.

Itabi ang ebidensya mula sa window na iyon, dahil ihahambing ang susunod na pagbabago roon.