Steelhead Appliance

[Ray]

We have DMVPN set up as our reduntancy between our six sites which have
point to point T1 lines as the primary link.
If a T1 goes down, the routers send the traffic to the firewalls and subsequently over their DMVPN.
So, for me too, SH is on the LAN side of these routers in each location, so no problem with
optimizing traffic in either link scenario.

For your listening pleasure, I enclose a short wav file of a VoIP Voice Mail test over this
configuration where I purposely kill the T1 to test the redundant configuration. No relation to
SH of course. But I think it was a neat test.

Ray

Message Edited by bgilbert on 01-28-2009 04:10 PM

[rr0bins0n]

Exactly. They are all connected to the router's LAN port so they never see the DMVPN GRE tunnels.

[Craig]

Have you got them on your WAN side or LAN side of your router?

I would of thought as DMVPN is encrypted tunnels that it wouldn't make much sense putting them on the WAN side. You cannot see inside the packets to work out if it is CIFS etc.

However if they were on the LAN side then the DMVPN tunnels just look like some sort of link or path to a remote site.

[rr0bins0n]

QUOTE(NeilM @ Aug 17 2007, 09:32 AM) 401

We are currently looking at deploying a DMVPN (Dynamic Multipoint VPN) for around 200 sites .

I would like to know if the SH product would have any problems operating over this type of network.

My initial concern is that
- The auto configure facility could initiate and keep up VPN's connections between spoke sites , as these are dynamically created based on traffic flow

So far, we've deployed about 30 steelheads in a DMVPN network that has hub to spoke, as well as spoke to spoke traffic patterns. They don't seem to have any problems with the DMVPN setup. As to tunnels being kept alive, we haven't really looked at that. It was never a concern or requirement for us to limit tunnel connections.

The only caveat we've seen so far is that the hub steelhead required the "in-path simplified routing dest-source" command. Check to see if that would be appropriate for your configuration.

[marshnei]

Blanco

Thanks for the Reply.

I would just like to clarify a couple of points to confirm my understanding.

Am I correct in saying:

1. The Auto configuration facility can be switched off and replaced with fixed-target rules.
2. Keepalives will ONLY be sent between the SH devices configured in these rules.
3. Any traffic between sites with SH devices, but not configured in the rule set , will just be treated as pass through traffic .

If this is the case SH + DMVPN would still be an option , as 80-90% of traffic flow is to the hub site. The remaining spoke to spoke traffic will not be optimised, unless , a specfic rule is added to the SH creating a spoke to spoke association .

Result
Only VPN tunnels that have specific spoke to spoke or hub to spoke rules will be held up due to keepalives.

Regards

Neil

[blancolam]

Neil,

Even if you configure fixed-target rules on the SH, the SH will still send keep-alives between them and it's not possible to turn this off. However, you can try increasing the time interval and reduce the number of keep-alives as to prevent the SH from keeping the link up. However, doing so will also mean that the SH will take longer to detect a peer failure.

regards,

Blanco

[marshnei]

We are currently looking at deploying a DMVPN (Dynamic Multipoint VPN) for around 200 sites .

I would like to know if the SH product would have any problems operating over this type of network.

My initial concern is that
- The auto configure facility could initiate and keep up VPN's connections between spoke sites , as these are dynamically created based on traffic flow

If this is the case , can this facility be switched off and association manualy configured?

We would only need the hub and a small number of associations for each spoke.

Can you forsee any other issues

Thanks

Neil