[c-nsp] Influence VTI tunnel QoS based on remote site bw change?
Good morning, I would like to ask you all for some suggestions. In my scenario there are several hundreds of remote sites and 2 central sites. We're using IPSec VTI tunnels between the remote and central sites. Each remote site has a primary and a backup circuit with different BW. We were trying to figure out if there is a way to keep only 1 tunnel between each remote and central site, while if the primary circuit goes down on a remote site, the QoS policies are afected also on the central site VTI tunnel. In other words, if there a way (or feature) that the central site notices that the remote end is now using a backup link, so the VTI tunnel uses another QoS policy effectively adapting to the new receiver BW? With 2 tunnels per remote site, we could force each tunnel to only form itself on a specific circuit, but we were trying to avoid getting thousands of tunnels on the central sites. Any input is appreciated. Thanks! Regards, Fernando ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Influence VTI tunnel QoS based on remote site bw change?
[resending using cisco-nsp subscribed address] On Mar 6, 2013 5:13 AM, Dale Shaw dale.s...@gmail.com wrote: Hi Fernando, On Mar 5, 2013 9:52 PM, Fernando Santos fernandomiguelsan...@gmail.com wrote: […] We were trying to figure out if there is a way to keep only 1 tunnel between each remote and central site, while if the primary circuit goes down on a remote site, the QoS policies are afected also on the central site VTI tunnel. This is just an untested idea but perhaps you could combine EEM on the spoke side with the per-tunnel QoS NHRP feature available for DMVPN? http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_per_tunnel_qos.html Maybe using EEM to change the NHRP parameters on the spoke's VTI when it switches to the backup link is enough to signal to the hub that it should use a different outbound service-policy. I'm not sure if you'd have to be running DMVPN to make this work -- it'd have to be tested. Cheers, Dale ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Influence VTI tunnel QoS based on remote site bw change?
Thanks for the suggestion Dale, I'll have a look into that. In the meantime, if anybody has any more ideas please let me know. Regards, Fernando On 05/03/2013, at 18:13, Dale Shaw dale.s...@gmail.com wrote: Hi Fernando, On Mar 5, 2013 9:52 PM, Fernando Santos fernandomiguelsan...@gmail.com wrote: […] We were trying to figure out if there is a way to keep only 1 tunnel between each remote and central site, while if the primary circuit goes down on a remote site, the QoS policies are afected also on the central site VTI tunnel. This is just an untested idea but perhaps you could combine EEM on the spoke side with the per-tunnel QoS NHRP feature available for DMVPN? http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_per_tunnel_qos.html Maybe using EEM to change the NHRP parameters on the spoke's VTI when it switches to the backup link is enough to signal to the hub that it should use a different outbound service-policy. I'm not sure if you'd have to be running DMVPN to make this work -- it'd have to be tested. Cheers, Dale ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
