From: Scott Vermillion (scott_ccie_list.com@it-ag.com)
Date: Fri Sep 14 2007 - 18:18:59 ART
Hi Mihai,
Thanks for following up. I forgot that you didn't need encryption. In
considering what they said about IKE keepalives, it's tempting to ponder
non-IKE/IPSec alternatives for neighbor reachability tracking.
Unfortunately, keepalives are not supported on mGRE interfaces. However,
perhaps you could consider Service Level Agreement track objects and policy
routing on your spokes? Then on your hubs just do static routes and
blackhole traffic if the spoke is not up (since these are just terminal
emulators, I presume you don't ever have traffic for a spoke that
*originates* at the hub, only traffic is sent there that is "in reply to"
the spokes, so they would necessarily be up when the hub had traffic for
them anyway). I do believe that you can still do NHRP to solve your dynamic
address issue, sans a full-blown DMVPN deployment.
The question, as they stated, is how quickly you need to fail spokes over.
You probably wouldn't want 500+ spokes each doing ping track objects to your
hub location once/sec. So failover in such a scenario would likely be slow
at best.
The main problem I see with this largely hair-brained scheme is that you are
going to have spokes w/ random public IPs (thus your ACL options are
limited), so how do you deal with authentication of your spokes (not sure if
NHRP authentication would be sufficient)? Anyway, some random thoughts to
kick around. Since it is IGP peering they're concerned about after all, and
you don't need encryption (thus no SADB problem), is there a secure (enough)
solution that doesn't involve the use of IKE/IPSec nor an IGP? I have
implemented SLA and PBR on a much smaller scale than what you're up against,
that's about all I can say as fact...
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
sheherezada@gmail.com
Sent: Friday, September 14, 2007 1:10 PM
To: Scott Vermillion
Cc: Joseph Brunner; Cisco certification
Subject: Re: DMVPN limitation
Here's the official feedback that I have received, assuming a design
with only two Cisco 7200 hubs for 800 spokes. Remember that the
aggregate traffic is quite low and no encryption is needed.
"The solution is good with the one exception of supporting 800
neighbors, that would be
more than recommended. The most we can recommend is 600 on a NPEG2 w/
VSA. If you use four hub routers instead of two that would be a
recommended deployment.
The important design question is, "how quickly must the branch routers
detect a failure and reroute"? If 45-60 seconds is sufficient, you
can rely on IKE keepalive to detect failures. Anything below that time
you will need a routing protocol and have some
limitations on number of neighbors."
So indeed the limitation is the number of neighbors on a single box.
Once again, thanks for the input.
Regards,
Mihai
On 9/14/07, Scott Vermillion <scott_ccie_list.com@it-ag.com> wrote:
> 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
>
> _______________________________________________________________________
> 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