[c-nsp] 7206VXRG2 performance question

[Gabriel]

I'll try to provide more details regarding the desired setup (opinions
in favour/against it are welcomed).

As I said, roughly half of the spokes will connect to hub1 while the
other half will connect to hub2. As all servers are in hub1, spokes
connecting to hub2 will reach the servers via a dedicated link between
hub1 and hub2. Hub2 is also a DR site, so this link will also be used
for replicating some of hub1's content there.

Regarding connectivity, spokes will connect to the hubs via two
providers (P1 an P2). The connections will use the provider's internal
network, not over the Internet. So, a spoke will have one tunnel (T1)
to hub1 via P1, one tunnel (T2) to hub1 via P2, one tunnel (T3) to
hub2 via P1 and one tunnel (T4) to hub2 via P2. Depending on which hub
the spoke will connect to, either T1 and T2 will be used (per flow
load balancing) or T3 and T4. Should a hub become unavailable, the
spokes connected to it will failover to the other one, so either hub
must be able to handle all spokes simultaneously.

Regarding bandwidth, I doubt it will exceed 10 mbit/s per provider in
the hubs. Spokes will probably have 128kbps and 256kbps per provider.

I read a bit about VTIs and the most appropriate setup seems to be
with static VTIs on the spokes and dynamic VTIs on the hubs. However,
there are some notes in the document[1] saying that routing with DVTIs
is not supported and SVTI remote to DVTI interfaces are not supported
(I dont know what this means).

Spokes will indeed have static link speeds (values mentioned above are
CIR). If I understand correctly the link you gave, I would need two
nhrp groups (one for 128kbps and the other one for 256kbps) which I
will further divide as required. Besides that, we'll also need shaping
to limit the outgoing physical interface to 10 mbps (or whatever we'll
get from the provider). The spokes would then be configured with the
proper nhrp-group.

So, as I said in the original message, my main concern is whether or
not the 7206 will be able to handle this, but, from the replies I got,
I understand it shouldn't be a problem.

Gabriel

[1] http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_ipsec_virt_tunnl.html#wp1110852

On Sun, Jul 26, 2009 at 6:17 AM, Rodney Dunn<rodunn at cisco.com> wrote:
> For those low rates a 7206VXR with a NPE-G2 would be a plenty.
>
> You should look at dynamic VTI's I think it is to get "per spoke" QOS.
>
> You don't need an external box especially if your link speeds at the spokes
> are static.
>
> There are different ways to do "per spoke" QOS but it's a bit more complex
> with dmvpn.
>
> http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_per_tunnel_qos.html
>
> Rodney
>
>
>
> Gabriel wrote:
>>
>> Hi all,
>>
>> the company I work for is involved in a WAN redesing process, so we
>> got in touch with a few Cisco partners to help us. We're considering a
>> dual-hub and spoke topology (about 100 spokes, more in the future)
>> with both hubs active (half of the spokes will connect to one hub, the
>> other half to the other).
>>
>> As I said, we contacted some Cisco partners (as we don't have the
>> necessary expertise to do this on our own) and one of them recommended
>> that, besides using the 7206 (with NPE-G2 and VSA) as the hub router,
>> we should also get a SCE1010 box to handle the QoS.
>>
>> One of the aspects I'd like your feedback on is whether this SCE box
>> is required or not (from the docs and design guides I read, it was
>> only present in SP networks). I'll try to give more details (please
>> let me know if they are relevant or not and what others have I
>> missed):
>>
>> - DMVPN (although one tunnel/branch was also suggested) over IPSec
>> - spokes connect to hubs via two providers (with per-flow load-balancing)
>> - hub bandwith will probably not exceed 10 mbit/provider
>> - spoke bandwith will be 256kbps/provider for roughly half of the
>> spokes and 128kbps/provider for the other half
>> - EIGRP as routing protocol
>> - no VoIP at the moment, but it could appear sometime in the future
>>
>> Traffic is not latency-sensitive (as I said, no VoIP yet) and will be
>> split into four QoS classes (in the future, others might appear).
>>
>> So, based on the above, can you comment on the capabilities of the
>> 7206 alone to handle everything without issues?
>>
>> Thanks,
>> Gabriel
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>