From: Scott Vermillion (scott_ccie_list.com@it-ag.com)
Date: Thu Sep 13 2007 - 19:07:15 ART
Wow, that's surprising. My spokes have thus far been variations of the
Mobile Access Router (MAR). I have seen pretty impressive performance with
multiple voice and video applications running, whiteboard, file sharing,
etc. We have only ever been limited by our bandwidth to the spokes, which
are often mobile and thus on "bandwidth disadvantaged" connectivity.
I have a project coming up in two weeks that's DMVPN and the spokes are in
fact 2811s (customer choice for a couple of good reasons). WorkerBee, can
you expand a bit perhaps on "pretty high?" All ears to others w/ 2811 DMVPN
experience...
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
WorkerBee
Sent: Thursday, September 13, 2007 3:53 PM
To: Scott Vermillion
Cc: Joseph Brunner; sheherezada@gmail.com; Cisco certification
Subject: Re: DMVPN limitation
I have done some ground work on DMVPN using 877 as spoke router.
The cpu load when transfering a 80M file using CIFS/Windows share between
spokes
causing the cpu to go almost 80%. I'm sure I enable onboard IPSec
accelerator
(switch to sw based, the transfer is many times slower) and using the
ip tcp adjust-mss to around 1400 bytes at the tunnel interface. The
tunnel mtu is set to 1416 bytes.
Even using 2811 as the spoke, the cpu can go up pretty high with multiple
files
transfer. I have also did a quick check, "Show ip traffic", no packet
fragmentation
because I have enable PMTUD and TCP Adjust MSS.
Anyone has some experience to share?
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