DMVPN: Spoke QoS Challenge

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.

More Information

DMVPN QoS is also described in the DMVPN New Features webinar. You get it as part of the yearly subscription.

5 comments:

  1. If Service Provider is willing to cooperate, DSCP marking can be used for QoS policies on provider PE routers. This relies on copying of DSCP bits from inner IP header to GRE header, and then to outer IP header. If SP is not willing to help, then there's not much you can do.

    Interesting idea would be to implement plain RSVP for bandwidth reservation over DMVPN...
  2. RSVP-over-DMVPN helps only if you strictly enforce it (not sure you can do that with IOS). Otherwise definitely an interesting idea.

    RSVP-under-DMVPN doesn't scale.
  3. Heh, I was wondering the reason for the sudden spike in traffic! :)
  4. Your article is still the best description of inbound QoS challenges I found ;) Thanks again for writing it!
  5. I am working on the transport network, we have 3 options:
    A first is CEoDWDM, where architecture consists of carrier Ethernet switch/routers (CESRs) with connection-oriented Ethernet (COE), which can be combined with a separate WDM layer
    A second Pure IPoDWDM is integrated transponders on Layer 3 routers, typically referred to as IP over DWDM (IPoDWDM)
    And 3rd is Hybrid
Add comment
Sidebar