[cisco-voip] DMVPN for remote sites in CCM cluster

[Andre Beck]

Hi,

On Mon, Jan 08, 2007 at 11:27:03AM -0600, Kris Seraphine wrote:
> 
> Is anyone successfully using DMVPN in a Call Manager environment?

Its predecessor, a dynamically routed hub-and-spoke VPN utilizing GRE
tunnels on top of IPsec. For historic reasons, it even has dedicated
boxes for IPsec (PIXen and ASAs as well as 8xx class routers), while
other boxes terminate the GRE. As this was the *only* way to establish
proper QoS in this VPN, the deployment is quite successful. Some links
don't have a single packet loss for weeks.

The most significant drawback is the enourmous bandwidth overhead that
unpredictably depends on packet size. On a 2.3Mbps SDSL we're using
only conservative 1Mbps for voice just for this reason - RTP packets
are small and thus suffer the most overhead...

> We have
> client who's merged with another company and will now have about 30 remote
> locations each with 6 or less phones.  Point to point lines won't be an
> option and  I don't want to deal with a mesh of tunnels between spokes in a
> network this size.
> 
> The V3PN SRND mentions DMVPN as an option so I guess its supported.

Meshing (either manually configured or automatically established by
DMVPN) will contradict with QoS. Even if you manage to control QoS
on egress (in the lucky situation that the egress interface already
establishes the final bandwidth gradient and using preclassification
of the traffic before encryption or using shaping either on the
interface or [what I use] hierarchical MQC on the tunnel interface),
you will not have control over *ingress* on other spokes. Two spokes
can easily overrun the link to a third spoke even when both are
keeping within their QoS profiles, simply because it adds up at the
destination spoke. As it will do so at an interface you don't control,
it will queue up there and lose all delay and jitter quality.

I don't see another way to avoid this but to establish strict star
topologies of tunnels and to prevent any traffic from the spokes
but traffic that is passing the tunnels (they cannot not surf the
internet directly, for instance). For redundancy, the star could
be shadowed, but metrics must be set up so that only one of the
tunnels to either spoke is actually bearing data and voice traffic.
At least until someone implements dynamic multichassis QoS...

HTH,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-