cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3274
Views
0
Helpful
7
Replies

Another IPsec/CEF bug in 15.0

paolo bevilacqua
Hall of Fame
Hall of Fame

I setup a 1801 with 15.0(1)M3, also tried M4.

It has the simplest VPN client termination config ever. Yet, it fails to forward from VLAN1 to the client, unless "no ip cef" is configured. I wonder how a customer needed full performances from the box would do.

Seems like we're back 10 years, or 3, when I had found the very identical issue.

And 15.0 is supposed to be a "MD" level version

3 Accepted Solutions

Accepted Solutions

xabrouck
Cisco Employee
Cisco Employee

Hi Paolo,


I guess an unfortunate regression happened.  Could you provide your configs or open a TAC case, so we can assist you properly?

thanks,
Xavier

View solution in original post

Hi,

You could be running into an issue with RRI installing an incorrect FIB entry on a multi-access interface for the peer. If you do a "show adj", do you see any incomplete adjacency entries off of FastEthernet0 when you try to ping? If so, the workaround is to use "reverse-route remote-peer next_hop_ip" command instead of just "reverse-route" under the crypto map.

Thanks,

Wen

View solution in original post

Hi,

Sorry I wasn't clear. The address you use in the "reverse-route" command is not the peer address, but rather the next hop ip from your WAN interface. Using your specific configuration, that would be X.X.X.Z. The bug id is CSCtg41606, and we will try to get the fix into our next 15.0(1)M5 release.

Thanks,

Wen

View solution in original post

7 Replies 7

xabrouck
Cisco Employee
Cisco Employee

Hi Paolo,


I guess an unfortunate regression happened.  Could you provide your configs or open a TAC case, so we can assist you properly?

thanks,
Xavier

Thank you for responding.

Abridged configuration below. The only thing that come to my mind, is that I have enabled LZS in transfrom-set, BTW appears to work fine.

I may try without compression later.

With CEF enabled, VPN packets going into VLAN1 are absorbed without evident trace of being processed anywhere.


no ip cef

!
no ipv6 cef
!
!
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 2
crypto isakmp keepalive 10
!
crypto isakmp client configuration group aaf
key SourDough4Ever
pool default
acl 101
save-password
!
!
crypto ipsec transform-set my-set esp-aes esp-md5-hmac comp-lzs
!
crypto dynamic-map dynmap 10
set transform-set my-set
reverse-route
!
!
crypto map cm isakmp authorization list xx
crypto map cm client configuration address respond
crypto map cm 65535 ipsec-isakmp dynamic dynmap
!
!
!
interface FastEthernet0
description 01/LM--/131367/ /GCN/
ip address X.X.X.X 255.255.255.224
no ip unreachables
ip nat outside
no ip virtual-reassembly
speed auto
full-duplex
crypto map cm
!
!
interface FastEthernet1
spanning-tree portfast
!
!
interface FastEthernet2
spanning-tree portfast
!
!
interface FastEthernet3
spanning-tree portfast
!
!
interface FastEthernet4
spanning-tree portfast
!
!
interface FastEthernet5
spanning-tree portfast
!
!
interface FastEthernet6
spanning-tree portfast
!
!
interface FastEthernet7
spanning-tree portfast
!
!
interface FastEthernet8
spanning-tree portfast
!
!
interface Vlan1
ip address 192.168.0.3 255.255.255.0
ip nat inside
no ip virtual-reassembly
!
!
!
ip local pool default 192.168.5.1 192.168.5.10
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip nat inside source list 100 interface FastEthernet0 overload
ip route 0.0.0.0 0.0.0.0 X.X.X.Z
!
access-list 100 deny   ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
access-list 100 permit ip 192.168.0.0 0.0.255.255 any
access-list 101 permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255

I have tried removing LZS compression, same issue.

Hi,

You could be running into an issue with RRI installing an incorrect FIB entry on a multi-access interface for the peer. If you do a "show adj", do you see any incomplete adjacency entries off of FastEthernet0 when you try to ping? If so, the workaround is to use "reverse-route remote-peer next_hop_ip" command instead of just "reverse-route" under the crypto map.

Thanks,

Wen

Wen, thank you for your punctual suggestion.

Indeed I see an incomplete adjacency when CEF is enabled:

IP       FastEthernet0             93.40.113.108(5) (incomplete)

However, I cannot apply the workaround you suggested, because for VPN client connections, we never  know in advance what is the remote peer address.

Is there a bug ID for this issue ?

Hi,

Sorry I wasn't clear. The address you use in the "reverse-route" command is not the peer address, but rather the next hop ip from your WAN interface. Using your specific configuration, that would be X.X.X.Z. The bug id is CSCtg41606, and we will try to get the fix into our next 15.0(1)M5 release.

Thanks,

Wen

Wen,

Thank you for the clarification, the workaround is 100% effective.

Having been a Test Engineer at Cisco, I also especially appreciated your note above about regression.


Cheers, Paolo.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco