From: Scott Vermillion (scott_ccie_list.com@it-ag.com)
Date: Fri Sep 14 2007 - 13:51:40 ART
Hi Mihai,
Well again, "Large Scale DMVPN" is not something I can claim to know from
personal experience. The presentation in the original link suggests the
limitation has to do with the security association DB in mid and low-end
platforms. Also, I believe there is some concern for the CPU and having
500+ IGP peers on a single box, presumably with some flapping going on with
that great a number of spokes. Having said all that, the presentation is
nearly three years old, so perhaps a query into your local account team is
in order. If so, please post back what they tell you, I'd be interested in
hearing of any updates as to limitations and novel solutions that might have
been devised since that presentation in 2004...
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
sheherezada@gmail.com
Sent: Friday, September 14, 2007 1:22 AM
To: Scott Vermillion
Cc: Joseph Brunner; Cisco certification
Subject: Re: DMVPN limitation
Thank you all for your input.
The spokes only need to communicate with the two hubs. The reason for
choosing DMVPN is indeed lack of fixed IPs at the spoke (they just use
cheap ADSL links) and simplified head office configuration. I don't
even need encryption (the payload is encrypted already) and the
traffic is very very low (with certain strict RTT constraints though).
I do not care too much of a spoke going off line occasionally either.
The problem is indeed the number of spokes and the reference design
from Cisco for large scale DMVPN is overkill to me. That's why I
needed to understand the root cause of the limitation that Cisco
wanted to overcome.
Mihai
On 9/14/07, Scott Vermillion <scott_ccie_list.com@it-ag.com> wrote:
> Hey Joe,
>
> If I read Mihai correctly, his issue is the sheer volume of spokes. I
think
> in your best practice architecture, he would still be facing 500 spokes on
a
> given router. Thus, my stab in the dark was to simply split the load
across
> four HE routers (250 spokes to 1 & 2 and 250 spokes to 3 & 4). The SLB
> thing looks slick but might be overly complex/expensive for what he's
trying
> to accomplish. Looks like just spokes reaching into a centralized hub,
sans
> any spoke-to-spoke requirement (speculation on my part). Perhaps DMVPN in
> this case is attractive simply because he doesn't want to hassle with
fixed
> IPs at all of the spokes (NHRP) or he just wants to simplify his HE
configs,
> or likely even both. I dunno.
>
> Static routing might allow for more spokes on a single box, but I don't
> think Cisco is in favor of that approach, so there's likely nothing
> documented on CCO about just how many spokes you could climb to going that
> route.
>
> Nice DMVPN page BTW - dig the drawing...
>
> Regards,
>
> Scott
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Joseph Brunner
> Sent: Thursday, September 13, 2007 2:55 PM
> To: 'Scott Vermillion'; sheherezada@gmail.com; 'Cisco certification'
> Subject: RE: DMVPN limitation
>
> You need spoke-to-spoke to routing to use EIGRP; the secondary HUB acts
like
> a spoke too! The real spokes will need to route to that spoke if the HUB
is
> down.
>
> Or use OSPF, then you don't need to disable split horizon; it just
> happens...
>
> -Joe
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Scott Vermillion
> Sent: Thursday, September 13, 2007 4:22 PM
> To: sheherezada@gmail.com; 'Cisco certification'
> Subject: RE: DMVPN limitation
>
> There might be some spoke-to-spoke implications in the below, but it
doesn't
> sound like that's a requirement for you (inferring from the terminal
> emulator part)...
>
> -----Original Message-----
> From: Scott Vermillion [mailto:scott_ccie_list.com@it-ag.com]
> Sent: Thursday, September 13, 2007 2:16 PM
> To: 'sheherezada@gmail.com'; 'Cisco certification'
> Subject: RE: DMVPN limitation
>
> I should have added that even if you don't do the SLB thing, I fail to see
> why you couldn't just do perhaps four 3800s at your hub; configure half
your
> spokes to go to Hubs 1 and 2 and the other half to go to Hubs 3 and 4.
I've
> not deployed DMVPN on such a large scale, so that's largely just
> off-the-top-of-my-head speculation. However, I have deployed a DMVPN
> scenario where the spokes needed redundant connectivity to each of two
> redundant Head End locations. Thus, four tunnels from each spoke to the
> four distinct HE routers (and they were all 3845s). In your case it would
> only be two tunnels at any given spoke...
>
>
> -----Original Message-----
> From: Scott Vermillion [mailto:scott_ccie_list.com@it-ag.com]
> Sent: Thursday, September 13, 2007 2:03 PM
> To: 'sheherezada@gmail.com'; 'Cisco certification'
> Subject: RE: DMVPN limitation
>
> Check out "Large-Scale DMVPN" in this link, I think you'll find it
> helpful...
>
>
http://www.cisco.com/en/US/products/ps6658/products_ios_protocol_option_home
> .html
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> sheherezada@gmail.com
> Sent: Thursday, September 13, 2007 1:46 PM
> To: Cisco certification
> Subject: OT: DMVPN limitation
>
> Hi,
>
> Sorry for this off topic, but maybe some of you can redirect me to an
> useful resource.
>
> I am planning to deploy from scratch a DMVPN setup and want to
> understand the limitations regarding the number of tunnels.
>
> In short:
>
> - 500 spokes - Cisco 877, no physical backup circuits
> - 2 hubs, daisy chaining. Basically, I want to ensure that a hub is
> always available.
> - 3-4 Mbps aggregate bandwidth (that's right, each spoke user has only
> a terminal emulator, so it's low bandwidth consumption)
>
> I am planning to use Cisco 3845 for the hubs, but as far as I can read
> on the Internet, even a Cisco 7200 with NPE-G1 is limited to 350 DMVPN
> tunnels?! Is this because of CPU usage when a major re-convergence
> occurs or something else relative to EIGRP? I can't imagine using a
> larger box only for several megabits of traffic...
>
> Thanks,
>
> Mihai Dumitru
> CCIE #16616 (SP, R&S)
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Oct 06 2007 - 12:01:11 ART