Went on an customer “ride-along” with Advanced Services this week. Customer’s requirement was that the DMVPN headend have 2 physical interfaces for High Availability. These 2 interfaces need to be the same subnet because they are going into 2 firewalls: one active/one standby. So now what?
Tom Kunath (Advanced Services) thought “Well…. what about using backup interface command?” Hmmmm that does seem to be the perfect tool in the Cisco CLI toolbox for this very situation.
Let’s go play in the lab. We will play with
- Having a Primary and Backup Interface under a DMVPN tunnel
- Cause Failure – record loss
- Verify DMVPN Per-Tunnel QoS works
So for those of you who are not yet familiar with DMVPN Per-Tunnel QoS you might want to do a little bit of reading first. 🙂
So now let’s try it and see how per-tunnel QoS will work with it.
Class-Maps and Policy-Maps
NOTE: Snuck these configs from the QoS Chapter of the upcoming CiscoPress IWAN book a super dear friend of mine (David Prall) is co-authoring.
Apply to Tunnels
Okay…. so far so good. Now let’s run some traffic. I’ll send EF and AF41.
Kay… so far so good. I also have both being sent at the same bps from the traffic generator so I wanted to check this also.
Time to Fail Primary Link!
that the DMVPN Per-Tunnel QoS still works.
Max loss on a stream was 1,848 frames. Each stream was sending 200 frames per second.
Hence the time to get to recovery was ~9.2 seconds. Customer was okay with that given that it is a solution to their issue and they are hoping their Active Firewall doesn’t go down often.
Now to see if the per-Tunnel QoS is still working. Yup. Looking good according to the show command. But let’s congest EF to really see if it is working.
With Backup Interface as Active, Congest EF
Okay… going to set the EF traffic to send at a rate of 2 Mbps. Which should easily do the trick.
With Backup Interface as Active, & Congesting EF — No Shut Primary on Core Router
Okay… THAT was FUN!