×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

DMVPN and Eigrp SIA issues

Unanswered Question

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
martindesrosiers Mon, 12/18/2006 - 18:00
User Badges:

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.

roluce Tue, 12/19/2006 - 10:46
User Badges:

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




roluce Fri, 12/22/2006 - 11:28
User Badges:

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


Actions

This Discussion