Re: EIGRP unstable with DMVPN (2 HUB routers)

gvos · ‎05-13-2004

I've a branch DMVPN network with 70 spoke routers and 2 hub routers. To create redundancy the hub routers are installed at different locations: if one hub router fails, eigrp & bgp routes the traffic via the other hub router.

The DMVPN is based on DSL (Internet). After the HUB router a firewall is installed. BGP is used to get the EIGRP routing data through the firewall (which is working correctly). The branches communicate only with the HUB locations.

In the beginning everything was working correctly but with the increasing number of spokes EIGRP became instable:

- Lot's of SIA (Stuck In Active)

- Lot's of EIGRP Neighbor Up, Down, New Adjacency, Interface Goodbye received, ...

(If an EIGRP neighbor is down, it is still possible to ping it's tunnel address!!)

Below part of config HUB1:

interface Tunnel1000

description --- Rps-Net DMVPN 1 ---

ip address 10.132.128.1 255.255.192.0

no ip redirects

ip mtu 1432

ip hello-interval eigrp 1 30

ip hold-time eigrp 1 65

ip nhrp authentication aaa

ip nhrp map multicast dynamic

ip nhrp network-id 1000

ip nhrp holdtime 300

ip nhrp server-only

delay 1000

tunnel source x.y.z.25

tunnel mode gre multipoint

tunnel key 1000

tunnel protection ipsec profile profile_rps_1

router eigrp 1

redistribute static

redistribute bgp 65400

passive-interface FastEthernet0/0

passive-interface FastEthernet0/1

offset-list 32 out 20

network 10.32.0.0 0.0.255.255

network 10.132.128.0 0.0.63.255

default-metric 10000 100 255 1 1500

distribute-list 33 out

no auto-summary

access-list 30 remark adverise bgp to rps-bb-TH01

access-list 30 permit 10.72.0.0 0.7.255.255

access-list 32 remark change eigrp cost

access-list 32 permit 10.32.133.0 0.0.0.255

access-list 33 remark distribute EIGRP to DMVPN clients

access-list 33 deny 10.32.143.5

access-list 33 permit 10.32.133.0 0.0.0.255

access-list 33 permit 10.32.137.0 0.0.0.255

access-list 33 permit 10.32.143.0 0.0.0.255

HUB 2: is the same only IP-addresses are different:

ip address 10.132.192.1 255.255.192.0

Spoke config:

interface Tunnel1

description --- DMVPN tunnel to HUB1 ---

ip address 10.132.129.1 255.255.192.0

no ip redirects

ip mtu 1432

ip nhrp authentication aaa

ip nhrp map 10.132.128.1 x.y.z.25

ip nhrp network-id 1000

ip nhrp holdtime 300

ip nhrp nhs 10.132.128.1

ip hello-interval eigrp 1 30

ip hold-time eigrp 1 65

qos pre-classify

tunnel source Dialer1

tunnel destination x.y.z.25

tunnel key 1000

tunnel protection ipsec profile profile_rps

!

interface Tunnel2

description --- DMVPN tunnel to HUB2 ---

ip address 10.132.193.1 255.255.192.0

no ip redirects

ip mtu 1432

ip nhrp authentication aaa

ip nhrp map 10.132.192.1 a.b.c.155

ip nhrp network-id 1000

ip nhrp holdtime 300

ip nhrp nhs 10.132.192.1

ip hello-interval eigrp 1 30

ip hold-time eigrp 1 65

qos pre-classify

tunnel source Dialer1

tunnel destination a.b.c.155

tunnel key 1000

tunnel protection ipsec profile profile_rps

interface Dialer1

description --- Internet Interface ---

ip address negotiated

ip mtu 1492

encapsulation ppp

ip tcp adjust-mss 1452

dialer pool 1

dialer-group 1

...

router eigrp 1

passive-interface default

no passive-interface Tunnel1

no passive-interface Tunnel2

network 10.73.0.32 0.0.0.15

network 10.132.128.0 0.0.63.255

network 10.132.192.0 0.0.63.255

distribute-list 30 out

no auto-summary

eigrp stub connected

!

access-list 30 remark advertise LAN in EIGRP

access-list 30 permit 10.73.0.32 0.0.0.15

Questions:

1) EIGRP timers: I've increased the values to reduce traffic, experiences with eigrp timers?

2) Is it better to use 2 EIGRP AS's (EIGRP 1 with HUB1 & EIGRP 2 with HUB2)? Will it incease stability and/or reduce EIGRP traffic?

3) Is RIP a better solution (the spoke routers are Cisco 8xx ADSL)?

4) Other suggestions?

Cheers

vmoopeung · ‎05-19-2004

Instead of changing the whole in senario , you can check whether hub routers are overloaded. You have sufficent memory in those router. check the ultization of the router and find the reasons why you get SIA. This document might help you in it.

http://www.cisco.com/en/US/tech/tk365/tk207/technologies_white_paper09186a0080094cb7.shtml#tshootsia

ruwhite · ‎05-20-2004

Which timers have you increased to reduce EIGRP traffic? The hold and hello timers? Note that a lot of your stuck in actives could be coming from a high hold timer--I would make certain my hold timer is under three minutes, preferrably in the 90 second range, with a maximum hello time of about 30 seconds. This doesn't increase traffic on your links by any serious amount, and it will help to prevent stuck in actives (it will cause poor neighbor relationships to fail before an SIA is declared elsewhere in your network).

I definitely wouldn't touch the sia timer at all. Make certain you are running code with the SIA rewrite, which is 12.1(4.0.3)T and 12.1(4.1).

Using multiple AS' will only make the problems worse, not better, so that's not really an option.... It sounds like you have a lot of dirty links, as well, or EIGRP is having problems getting its traffic over these links. It doesn't sound like you have a lot to send, just a default in one direction, and some connected routes in the other, which means it can only be a handful of EIGRP packets.

Do you have the bandwidths on these links set to what they really are? If you have the bandwidth set higher than it really is, then EIGRP could be overrunning the links, and dropping traffic.

:-)

Russ.W

gvos · ‎05-24-2004

Hello,

The routers are using less then 10% cpu and memory: Total: 47309536, Used: 10693080, Free: 36616456

The HUB's are running:12.3(5a) (12.3(5c) wasn't better) The spokes run 12.3(4)T3

Summary of the problems:

- SIA

- Neighbors down, Up, ...

When a neighbor is down it is still possible to ping the neighbor's tunnel IP-address. so the mGRE/VPN tunnel stays connected!!!! Is it possible to test it's multicast address?

EIGRP hold & hello timers were original 150 & 60sec I decreased them (only on the HUB jet) to 45 & 15sec. But this doesn't help. The timer values are different on hub & spoke. I read that it isn't a problem, is this correct?

The bandwith (HUB) is set to BW 9 Kbit, DLY 10000 usec (SDSL is 1Mb/S) Last Wednesday I added the command: "ip bandwidth-percent eigrp 1 500" so EIGRP can use up to 45 kbit/s.

We do have dirty links! The VPN tunnels are based on ADSL links and there are ISP's changing the IP-address multiple times a day.

But I read in the Cisco documentation DMVPN with EIGRP is designed for spoke locations with rotating IP-addresses.

The spokes advertise the LAN Networks, The HUB doesn't advertise a default gateway because The Internet is default gateway. The HUB advertises 5 routes (redistribute BGP in EIGRP)

The spokes are configured as "stub connected"

RYAN BARNES · ‎05-25-2004

If all your stub routers are configured as STUB Connected, then there shouldn't be any directed queries from your hub router for lost routes. Essentially, the only two routers EIGRP can query is each other...right? And given that you're redistributing from EIGRP into BGP, your hub routers likely don't see each other at all as EIGRP neighbors due to two seperate mGRE/IPsec tunnels..so there shouldn't be ANYONE to query. Does that sound right?

"Any neighbor that receives a packet informing it of the stub status will not query the stub router for any routes, and a router that has a stub peer will not query that peer. The stub router will depend on the distribution router to send the proper updates to all peers."

That said, if for some reason you lose a DSL route, and EIGRP goes active for that network, the only queries that should go out (in theory) should be from the distribution (hub) routers. And the only devices they can query are each other (if in fact they see each other, which they shouldn't unless one of your stubs is not configured stub, and is advertising that network back on it's second Tunnel interface), since all other attached EIGRP neighbors are configured stub.

Are you logging EIGRP neighbor changes along with the SIA state? Maybe you can track through the logs (if you're syslogging) and find a session reset next to a neighbor that was SIA...

Wouldn't suprise me if there is a bug somewhere that's ultimately causing this to occur...

wtstone · ‎07-26-2004

Yeah, I had this same problem....

EIGRP uses the bandwidth value on the tunnel interfaces for packet pacing. The default value is 9 Kbps. If you wind this up to 1000 this should sort all your problems. I just did a search around for information on metrics and EIGRP. You should just need to do this on the Hub routers, as i can imagine it'll take you a while to change 70 spoke routers!

hbroich · ‎08-09-2004

Hello,

i have also the same Problem with not so many Spokes.

How can i wind the Bandwith from EIGRP from 9 to 1000 (which command)

Best Regards

Hartmut

spremkumar · ‎08-09-2004

Hi

Bandwidth can be changed to 1000 using

bandwidth command under interface tunnel config mode.

regds

prem

hbroich · ‎08-09-2004

Hello,

thank you, but i have allways the same Problem that the Spokes will connecting over the hub and not between the Spokes. I can see it with a traceroute.

So i beleave, that the hub will not send the correct routing Information to the Spokes.

Is it neccessary, that i must configure the hub as "ip nhrp server-only" and the Spokes as "eigrp stub" ?

The IOS for all the Router is the 12.3(8)T.

regards

Hartmut