Got the following question with an invalid return address, so I’m broadcasting the reply ;)
I am running a DMVPN network and recently got a requirement for spoke-to-spoke communication. We currently shape traffic on a per spoke basis on the hub, and have a single shaper at the remote site. However, if a spoke is receiving a large amount of traffic from the hub and another spoke site, how will the sites sending traffic know that the remote port is congested?
Short answer – they won’t. You have a mission-impossible problem (very similar to ADSL QoS), but there might be some slight silver lining:
- TCP traffic adapts to congestion. If most of your traffic is TCP, you’ll do fine. If you have voice in the mix, you have a real problem. Even though TCP will eventually back off, congestion on the Internet-to-site link causes increased latency making VoIP users unhappy.
- To keep voice latency within reasonable bounds, you have to shape TCP traffic to approximately two thirds of your access bandwidth. Jared Valentine wrote a great article describing his adaptive ADSL QoS solution. You could do something similar on your DMVPN spoke routers.
- You can always use appliances like PacketShaper/Packeteer or Ipanema – but make sure you understand what they do and don’t buy the snake oil. If your problem involves a combination of inbound traffic streams from multiple sites, you need on-site appliance, not something like emulated tele|engine.
- Worst case, buy two Internet access links for each spoke – one for data, one for voice. At $50/month, this solution just might be cheaper than an on-site appliance.
- I wrote about DMVPN QoS before. Read QoS in Large-Scale DMVPN Networks.
- DMVPN QoS issues are similar to those faced by DSL users. Read ADSL QoS Basics.
- You can implement adaptive QoS with EEM, but it won’t be reacting to fast changes in line utilization (here’s an update).