12-18-2006 01:15 PM - edited 03-09-2019 05:04 PM
I have over 250 sites in a hub-and-spoke desing, each remote site has a frame-relay and an IPSec tunnel to the office, we are running Eigrp but ever since we deployed DMVPN we've been getting many SIA messages...is this a normal behavior for a DMVPN design? should I just decrease how often EIGRP queries are sent or increase EIGRP timers, or should I just leave it alone...has anyone seen DMVPN in over 200 sites working flawlessly using eigrp? just curious...
12-18-2006 06:00 PM
It's pretty strange
I have about 200 sites, but soon we gonna have 300 sites and I've just had this kind of issue. We took about 2 months to solve this issue.
You have to be careful because the multicast hello packet are duplicates by the number of spokes that you have. But these packets are sent in a timeline of about 2 or 3 hundredth of second. On a frame relay the tick interval is about eighth of second. You have many things that you can do to help your Hubs site's Frame relay connection.
But first of all, have you access to your border gateway's Frame Relay router ?
You can check if there is packet drops on the Output Interface or Overrun in the Input Interface.
A thing is sure, it's a hardware issue, but you have to follow the Best Practice of a DMVPN network on WAN link.
12-19-2006 10:46 AM
250 sites with no SIA issues at the moment. Here are the two issues that we've run into in the past that can create an issue.
1. Tweaking the EIGRP hello/TO timers. Be very careful about how you tweak these, if you go too long, you're guarenteed to create SIA's.
2. VPN router with Ethernet outside interfaces. If you have a VPN router hooked up to the Internet with a interface that is much faster than the actual line speed (100mbit FDX FA hooked up to another router that has 512kbit to the Internet), you'll want to put a GTS statement on the VPN router's outside interface to slow down the actual output to something closer to the outside line speed. Don't use rate limiting, only use GTS.
You can also put the GTS on the tunnel interface, which provides some additional benefits of smoothing your WAN traffic, but you'll need to account for the IPSec overhead in the GTS statement.
Rob
12-21-2006 10:13 AM
Thanks Rob, what is a GTS? do you mean adjusting the TCP mss?
12-22-2006 11:28 AM
GTS = Generic Traffic Shaping.
We just use the easier to use, traffic-shape rate command, but the likely cisco answer would be to create policy-map/class-maps for the tunnel interfaces.
Our Tunnel interfaces have the following additional commands. cut-edited-paste.
Site with a T1
interface Tunnel111
description VPN sitea to siteb
bandwidth 1536
ip unnumbered Loopback0
ip access-group whattoblockin in
ip access-group whattoblockout out
ip mtu 1600
ip hello-interval eigrp 111 2
ip hold-time eigrp 111 8
ip pim sparse-mode
ip route-cache flow
ip tcp adjust-mss 1280
load-interval 30
delay 1001
traffic-shape rate 1536000 8192 8192 2048
cdp enable
tunnel source a.a.a.a
tunnel destination b.b.b.b
end
The traffic-shape command is just there to keep the outside interface from being over run and dropping packets after encryption. This isn't "QOS" by Cisco's book, but when we implemented this, Cisco didn't have a pre-qualify that worked properly with DMVPN.
If we start having problems with a site having heavy utilization, we'll change the traffic-shape statement to smooth out the traffic and control the heavy users. (refer to effects of WFQ).
Do a search for WFQ and GTS on Cisco.com
(oh, and if anyone tells you that the ip mtu command is a bad idea, tell 'em to stick it in their ear...)
Rob
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: