05-01-2023 03:25 PM
We are migrating some offices to new C8200-1N-4T routers and in the process we are changing our architecture. We are experiencing an issue where only one of the DMVPN tunnels will function at a time despite both being on separate ISPs and in separate VRFs. Each tunnel goes to a separate hub as well.
Previously, we only have one ISP at these sites and only one VRF for both tunnels and this was all working fine. It wasn't until we introduced the new router with an additional ISP with the two VRFs where this issue occurred, so it's not an issue with the hub routers (who also have other spokes connected). Here is the general setup for this:
2 ISPs with each ISP in its own VRF.
2 DMVPN spoke tunnels, each pointing to a different hub router. Each tunnel is in it's corresponding VRF as well and using the correct tunnel source information.
Now for the odd part. We can only get 1 of the DMVPN tunnels to function at a time. The other tunnel is perpetually stuck in the IKE state. If we shut down the tunnel that is working and then do a shut / no shut on the tunnel that is not working, that tunnel then comes up and works. If we no shut the original one that was working, that one will get stuck in the IKE state until we manually run the same process previously mentioned again.
Thus far, TAC hasn't been able to decipher the issue.
I've attached the relevant parts of the config. Hoping someone can take a look and point us in the right direction.
Thanks!
05-01-2023 08:23 PM
All config from first view is ok but
Dont use shared keyword in tunnel protection ipsec profile' here the two tunnel not use same source.
05-01-2023 08:25 PM
Hello @jonathanw84 ,
From your configuration the problem seems related to shared SADB caused by the shared keyword in this command :
" tunnel protection ipsec profile SDM_Profile1 shared"
It does share the IPSEC SA between multiple tunnels that has the same "tunnel source interface" which is not the case for your deployment
Try to apply on Tunnel 1 and Tunnel 2 the command without shared keyword :
"tunnel protection ipsec profile SDM_Profile1"
You may need shut no shut the tunnel interface.
Another thing that catch my attention is under interface tunnel you did not specify which vrf it does belong to, applying the ip vrf forwarding "name vrf" will delete the ip address line so you need to re-apply it.
Hope that helps!
Regards!
05-02-2023 05:33 AM
Thank you both.
We have tried removing the "shared" from the "tunnel protection" command but still no change.
With regard to the "ip vrf forwarding" command, we want the tunnels to be in the global routing table but the source of the tunnel is going to come from the corresponding vrf, hence the "tunnel vrf EXT1" and "tunnel vrf EXT2" commands. So we wouldn't want to change that.
Thanks!
05-02-2023 08:40 AM
remove shared but still not work
you need after remove the shared keyword to shut/no shut the tunnel interface and clear iskamp & IPsec SA
try this and check again
thanks
MHM
05-02-2023 02:10 PM
Hello @jonathanw84 ,
@jonathanw84 wrote:"We have tried removing the "shared" from the "tunnel protection" command but still no change. "
Did you shutdown both tunnels simultaneously ? to clear the shared SADB try to shutdown them both and no shut one at a time.
Regards!
05-03-2023 06:12 AM
Hi All,
You were correct on the shared protection profile. I ended up removing the tunnel interface all together to clear everything out and then I reapplied it without the shared tunnel protection and both tunnels are now up and working as expected.
Thank you all for the assistance!
05-03-2023 06:23 AM
You are so so welcome.
Happy ending
Have a nice day
MHM
05-03-2023 01:55 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide