Re: Losing EIGRP adjacencies w/ DMVPN - Page 2

qnguyen8 · ‎12-23-2004

I am trying a new code, 12.3.11T2 on our routers and every night when traffic is low, the spoke router with the new code on it would lose it EIGRP adjacencies. All the other spoke that are running 12.3.6a run fine. And the only way to get the neighbors back is to reload the router. Even reconfiguring the EIGRP process does not bring it back. Any insight would be appreciated.

qnguyen8 · ‎01-17-2005

I actually got all this stabalized with TAC. The 12.3.(12.10) code was posted for me twice. The first one had a bad checksum. The second one had had some "bad magic number" boot up errors and while it was up, had "CHUNKBADMAGIC" errors, TACACs also didn't work.

The workaround was to disable cef on the tunnel interface. This worked but, it would be nice to have cef up.

Eventually went with 12.3.11T2 and changed the IP MTU on the tunnel interface to 1400. The input queue wedging stopped with this code. We also used 12.3.8T6 which worked but if you are running ip inspect or ip ips, you will run into CSCef58083.

So in short, upgrade to 12.3.11T2 and change ip mtu on tunnel interface to 1400. It has been stable without input queue increasing for the last 72 hours.

noc · ‎01-18-2005

Thank you everyone for posting on this topic. I have been running 12.3(12.10) on the 2691 and it does appear to be fine. The only downside is the tunnel interface has to be shut then no shut to bring it up upon a router reload. The engineer I am working with is trying to find the fix for this problem now. I'm tempted to back down to 12.3.11T2 until Cisco can resolve these issues. Can anyone tell me if there are running the advipservices version or advsecurity and what the difference may be? Also I have a Cisco 1712 experiencing the same problem with input queue wedge but I am using CBAC and NAT route maps on the router so I do come across the bug mentioned in previous messages. Is there going to be a fix for this as well? Thanks again.

-Jake Gibb (noc@krollworldwide.com)

noc · ‎01-18-2005

I did a compare of the two images 12.3.11T2 advsecurity and advipservices. It appears they both support standard VPN, QOS, IDS, etc. but ipservices includes support for BGP, VoIP, and MPLS functions. Hope that helps anyone that may have been curious as I was. Thanks.

-Jake Gibb

noc · ‎01-18-2005

I have just reloaded my 2691 with 12.3.11T2 and disabled IP CEF. The input queue wedge problem did stop on the tunnel interface. How much of an impact does this pose on the router and passing traffic? Is it substantial?

qnguyen8 · ‎01-18-2005

I didn't see much of a performance hit but, you can enable cef. You just need to take your IP MTU size down to 1400 on both hub and spoke tunnel interfaces and that should stop the wedging problem.

gfullage · ‎01-18-2005

Confirmed with the developers that this bug is fixed in 12.3(12.10)T also, the bug has been updated to reflect that now.

Disabling CEF is not the way we would want you to go towards fixing this issue. your router may run fine without CEF but there will be a bigger hit on the CPU, so it's all dependent on how much traffic it is processing as to how the performance will be affected. On a busy router disabling CEF may bring the router to its knees.

What features are contained in your different releases is detailed here:

http://www.cisco.com/warp/customer/620/1.html#4-1

noc · ‎01-19-2005

I changed the MTU to 1400 on both the remote tunnel interface and the local. With IP CEF enabled this did indeed stop the input queue wedge problem but I could not get some applications to connect across the tunnel(remote desktop, etc..). I also have the command ip tcp adjust-mss 1436 on the remote router tunnel interface. I discovered this was needed for some website access across the connection to the main site.

I'm fairly sure I need to go with the advsecurity version of the IOS as we do not need advanced routing capabilities etc. I just need to settle on a revision that works. I have two more DMVPN sites coming up within a month and would love to have this problem resolved. Thanks for the ongoing support.

qnguyen8 · ‎01-19-2005

I'm also running advsecurity. With my current config, things are running stable. RDP and other applications work fine.

Are you running DSL on any of the sites?

Also, TAC recommended that it there were connectivity problems or a lot of output drops, to adjust the tcp mss to 1360.

noc · ‎01-19-2005

These are both leased line connections to ISP's. Looks like that adjustment in tcp adjust-mss did it. Does the ip tcp adjust-mss command have to be applied on both ends or just one? I'm not sure I understand where to place it. Thanks.

-Jake Gibb

gfullage · ‎01-20-2005

The "ip tcp adjust-mss" command changes the MSS value in incoming OR outgoing TCP SYN packets. Theoretically you can just configure it on one end cause it'll see all the SYN packets and adjust the MSS value accordingly, but having it on both ends won't matter either.

noc · ‎01-21-2005

Thank you. It looks like everything is stable now running 12.3(11)T2. I appreciate your help.

-Jake