Failback sa ASA: ano talaga ang gumagalaw kapag bumalik ang ruta
Ang pagbabalik ng ruta sa pangunahing landas ay hindi nangangahulugang gumalaw ang lumang daloy. Obserbahan nang sabay ang uplink, tunnel, talahanayan ng koneksyon at resulta ng aplikasyon.
Sa isang ASA na may dalawang uplink, ang failback ay hindi kabaligtaran ng failover. Nagbabago ang ruta papunta sa peer, at pagkatapos ay kailangang pag-ugnayin ng platform ang tatlong magkakahiwalay na state machine: ang talahanayan ng ruta, ang mga security association ng IKE at IPsec, at ang talahanayan ng koneksyon. Maaaring mahuli ang bawat isa sa iba, at ang pagkahuling iyon ang tinatawag ng karamihan na tunnel na hindi bumabalik.
Ano talaga ang binabago ng failback
Ang paghahanap ng ruta ang nakikitang bahagi. Kapag bumuti ang binabantayang bagay, bumabalik ang binabantayang ruta patungo sa panlabas na address ng peer, at ang susunod na packet na ipinapadala ng ASA ay sumusunod muli sa pangunahing link. Ang lahat pagkatapos nito ay nakasalalay sa kung tugma ang umiiral na estado sa bagong landas.
Ang ARP at NAT ang tahimik na dependencies. Kailangan ng bagong next hop ng malulutas na gateway at ng pagsasalin na tugma pa rin sa malayong dulo, kung hindi ay walang pupuntahan ang mga unang packet pagkatapos ng failback at mukhang maayos ang ruta habang walang gumagana.
Apat na pananaw sa isang timeline
Itala ang parehong apat na bagay bago, habang at pagkatapos ng paglipat, dahil hindi masasabi ng isang snapshot kung aling layer ang gumalaw.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
Ang rutang hindi kailanman nagbago at ang rutang nagbago habang pinanatili ng lumang koneksyon ang estado ng pagpapasa nito ay nagbubunga ng parehong reklamo at ganap na magkaibang ebidensya.
Bakit nananatili ang lumang koneksyon sa backup na landas
Hindi pinapatid ng ASA ang isang daloy dahil nagbago ang ruta. Pinapanatili ng mga naitatag na koneksyon ang desisyon sa pagpapasa kung saan sila ginawa, at nag-aalok ang platform ng magkahiwalay na kontrol sa kung gaano katagal ito pinapayagan: floating-connection timeout at connection holddown. Itinuturing ng ang gabay sa mga setting ng koneksyon ng ASA 9.24 ng Cisco ang mga ito bilang magkaibang tanong, at ganoon talaga ang ugali nila. Ang isa ay namamahala sa pagpapatuloy ng umiiral na daloy; ang isa ay namamahala kung kailan maaaring gamitin ng mga bagong daloy ang ginustong landas.
Basahin ang mga epektibong halaga para sa iyong release bago baguhin ang alinman sa dalawa. Ang pagbaba sa mga ito ay nagsasara ng mga session na ginagamit pa ng mga tao. Ang pagtaas sa mga ito ay nagpapakita na parang hindi nangyari ang failback, dahil patuloy na kinukuha ng mga bagong koneksyon ang lumang landas sa buong panahon.
Hindi muling nakikipag-usap ang tunnel sa mga key dahil bumalik ang ruta
May sariling napagkasunduang habang-buhay ang mga security association ng IPsec at nakakaligtas sila sa pagbabago ng rutang nagdala sa kanila. Kaya maaaring manatiling nakataas ang tunnel sa panahon ng failback habang hindi na tugma ang panlabas na addressing nito sa ginagamit na landas, at ito ang argumento para sa DPD at sa mga disenyong nagpapako sa address ng peer sa halip na hayaang lumutang ito.
Iba ang pag-uugali ng mga disenyong crypto-map at VTI dito, at inilalarawan ng dokumentasyon ng Cisco para sa 9.24 VTI ang opsyong nakabatay sa ruta. Ang lumang pangkalahatang pag-aangkin na hindi kayang magpatakbo ng rutang nakabatay na VPN ang ASA ay hindi totoo para sa mga sinusuportahang release.
Basahin ang ebidensya sa ayos na ito
Simulan sa control plane: show route para sa piniling landas, show interface para sa estado ng link at ang mga counter ng SLA monitor para sa binabantayang bagay. Pagkatapos ay basahin ang show crypto ikev2 sa, o ang katumbas ng IKEv1, upang makita kung aling peer ang buhay, na sinusundan ng show crypto ipsec sa para sa mga protektadong daloy. Pagkatapos ay paliitin ang talahanayan ng koneksyon gamit ang show conn address <host> at ihambing ang column ng interface sa luma at bagong entry. Isulat ang mga output na may timestamp, dahil ang ayos nila ang diagnosis.
Tapusin sa isang pagsubok ng aplikasyon: isang daloy na dati nang umiiral at isa na ginawa pagkatapos bumalik ang ruta. Kung bumagsak ang lumang daloy at gumana ang bago, mayroon kang kuwento ng estado ng koneksyon. Kung parehong bumagsak, mali ang tunnel o patakaran at ang talahanayan ng koneksyon ay isang abala.
Panatilihin ang rekord na iyon sa parehong anyo sa lahat ng tatlong yugto at itala ang eksaktong release. Kapag patuloy na tumuturo ang timeline sa isang paglipat lamang, ipadala ang rekord sa suporta sa halip na hulaan ang isang bug ID.