Error on router to router GRE / IPSec Tunnel

Hi,

I remember reading about this in the forum and they mentioned disabling fast-switching on the relevant interfaces ie "no ip route-cache". Might as well enable CEF as it gives better performance for GRE/IPSEC tunnels.

Rob

Relevant interfaces would mean - Tunnel interface as well as the Source interface of the tunnel, correct?

I did try no ip route-cache, but that didn't stop the errors. I have a TAC case open right now - lets hope they come back with something.

Yeah sorry, tunnel interface and the physical external interface if I'm not mistaken on both sides.

Did not help. Tried it on both sides (tunnel and physical external interface). Still showing up every two to three minutes.

You mention that the tunnel is up so I assume traffic passes through the tunnel as well?

Might be a long shot but how is your match acl setup? Are they mirrored on both sides? and what are your policy settings? Maybe try a different combination of settings regarding the hashing algorithm and DH group.

Like I said a long shot but worth a test.

Rob

ACL's are mirrored. Same as all other. Created two separate ACL's and maps for two subnets even, on both ends of the terminal. Use the same crypto policies and transform-sets for all sites, and it works just fine. Don't see this error anywhere. Tried two different routers, and saw the same problem.

The only thing I can think of is that the rest of the sites are usually one subnet, and not two, so there's only one class C associated with it. This site has two class C's. Which shouldn't matter at all, but who knows.

Cisco is still working on the ticket - saying that the MTU might be different on the other side. Asked me to send the config on the other end - sent it to them. MTU is the same! Anyways, lets see what they come up with.

Nothing from Cisco yet. Not sure what they're doing.

Wonder how long thats going to take!!!

Any chance you could post your crypto/mtu/interface settings so I can try and replicate it. Will be interesting to see what the outcome is.

Sure. Here is the relevant config. Running 12.2.28 Enterprise 3DES.

ip cef, ip route-cache enabled. (did take them off but didn't help, so put them back on)

Set up the same way on the far end, except mirrored acl's. There was one acl with just one crypto map, but just for sh*ts 'n grins, to see if that was causing problems, created two separate acl's. Didn't help. Let me know how it goes.

------------- ! crypto isakmp policy 10 encr 3des hash md5 authentication pre-share crypto isakmp key mykey address x.x.x.x ! ! crypto ipsec transform-set 3DES esp-3des esp-md5-hmac ! crypto map IPSEC local-address Serial2/0 crypto map IPSEC 10 ipsec-isakmp description Tunnel to a set peer x.x.x.x set transform-set 3DES match address TUNNEL_a crypto map IPSEC 20 ipsec-isakmp description Tunnel to a set peer x.x.x.x set transform-set 3DES match address TUNNEL_b ! ! interface Tunnel1 ip address 192.168.0.2 255.255.255.252 ip mtu 1420 ip ospf message-digest-key 10 md5 mykey tunnel source Serial2/0 tunnel destination x.x.x.x crypto map IPSEC ! ! ! ip access-list extended TUNNEL_a permit ip 10.1.1.0 0.0.0.255 10.0.0.0 0.255.255.255 permit ip 10.1.1.0 0.0.0.255 172.16.0.0 0.15.255.255 permit ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255 ip access-list extended TUNNEL_b permit ip 10.1.2.0 0.0.0.255 10.0.0.0 0.255.255.255 permit ip 10.1.2.0 0.0.0.255 172.16.0.0 0.15.255.255 permit ip 10.1.2.0 0.0.0.255 192.168.0.0 0.0.255.255 !

Also, running NAT overload on the serial interface.

However, have an access-list that has deny statements for 10.1.x.0 to