Really bad IPSEC bug ?

[dtushing123]

I was trying to debug why an IPSEC tunnel from a 3700 router to a 1841 router would not come up.

I found an interface on the 3700 router with the SAME DESTINATION IP address of the original tunnel BUT in an administratively shutdown state so - administratively down down.

When I deleted the config for this interface the tunnel came back up.

Is this a documented "feature" with an

ID that I can give to my management ?

Running c7100-ik9s-mz.123-12d.bin

I should add that I am trying to find this with Cisco Bug tracker but not having luck at the moment.

Thanks

Darren

[ajagadee]

Are you able to recreate this problem. I did a quick test on a 2821 running 12.4(13d) and do not see the issue that you ran into.

When you experienced this issue, were you able to ping or traceroute to the actual destination IP Address. The only thing that I can think of is, the routing entry or CEF was somehow corrupted and the router was thinking that he was the destination and address and sending the IPSEC Proposals to himself. But, this is very rare because as soon as you shut down the interface, the CEF Entry is cleared from the database. Let us know what you find with your testing.

Regards,

Arul

** Please rate all helpful posts **

[dtushing123]

Arul, thanks for your response.

I received the following response from the Cisco TAC,

more than a bug this is expected behavior if both tunnel interfaces have the same tunnel destination, which is not very common scenario. The problem is that without a unique identifier for each tunnel (such as tunnel key or different source/destination address, etc) the Router gets confused as to how to properly decapsulate the GRE packet.

You can add an identifier on each tunnel interface, such as a tunnel key:

http://www.cisco.com/en/US/docs/ios/12_2/interface/command/reference/irfshoip.html#wp1022758

....

I do get your point. But as I said, you need to have an identifier that makes one tunnel interface different from the other. The GRE is not even taking place yet in this case; is just a configuration issue that causes the Router not to know which one to use. A tunnel interface is not as a physical interface that you can shut and will completely go down, is just a logical interface. I've been looking for similar issues, possible bugs with no luck. Should be expected behavior.

So there you go - the official response.

Again thanks Arul.

Darren