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...
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.
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.
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
description VPN sitea to siteb
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
traffic-shape rate 1536000 8192 8192 2048
tunnel source a.a.a.a
tunnel destination b.b.b.b
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...)
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...