Unable to ping ospf routes over VTI

[k.modarresi]

Hi,

I have a simple topology trying to secure the Layer 3 links using VTI profile between DCA to OFFiCECORE1 and OFFICECORE2 to DCB

The tunnel is up on both ends and I receive routes, however not able to ping.

DCA#sh ip route ospf

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
O IA 10.23.127.80/32 [110/2002] via 10.23.152.6, 00:01:52, Tunnel311
O 10.23.135.160/30 [110/1001] via 10.23.152.6, 00:01:52, Tunnel311
O IA 10.23.135.177/32 [110/1001] via 10.23.152.6, 00:01:52, Tunnel311
O IA 10.23.135.178/32 [110/1002] via 10.23.152.6, 00:01:52, Tunnel311
O 10.23.152.20/30 [110/2001] via 10.23.152.6, 00:01:52, Tunnel311

DCA#sh cry session
Crypto session current status

Interface: Tunnel311
Session status: UP-ACTIVE
Peer: 10.23.152.2 port 500
Session ID: 0
IKEv1 SA: local 10.23.152.1/500 remote 10.23.152.2/500 Active
Session ID: 0
IKEv1 SA: local 10.23.152.1/500 remote 10.23.152.2/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

Ping from DCA loopback 0 to DCB fails

DCA#ping 10.23.127.80 so l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.23.127.80, timeout is 2 seconds:
Packet sent with a source address of 10.23.111.79
.....
Success rate is 0 percent (0/5)

Ping works from OFFICECORE 1 to DCA loopback0

OFFICECORE1#ping 10.23.111.79 so l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.23.111.79, timeout is 2 seconds:
Packet sent with a source address of 10.23.135.177
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

OFFICECORE2#ping 10.23.127.80 so l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.23.127.80, timeout is 2 seconds:
Packet sent with a source address of 10.23.135.178
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

DCA#sh cry ip sa

interface: Tunnel311
Crypto map tag: Tunnel311-head-0, local addr 10.23.152.1

protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.23.152.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 157, #pkts encrypt: 157, #pkts digest: 157
#pkts decaps: 150, #pkts decrypt: 150, #pkts verify: 150

====

DCB#sh ip route ospf

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
O IA 10.23.111.79/32 [110/2002] via 10.23.152.22, 00:03:20, Tunnel314
O 10.23.135.160/30 [110/1001] via 10.23.152.22, 00:03:21, Tunnel314
O IA 10.23.135.177/32 [110/1002] via 10.23.152.22, 00:03:21, Tunnel314
O IA 10.23.135.178/32 [110/1001] via 10.23.152.22, 00:03:21, Tunnel314
O 10.23.152.4/30 [110/2001] via 10.23.152.22, 00:03:21, Tunnel314

DCB#sh crypto session
Crypto session current status

Interface: Tunnel314
Session status: UP-ACTIVE
Peer: 10.23.152.18 port 500
Session ID: 0
IKEv1 SA: local 10.23.152.17/500 remote 10.23.152.18/500 Active
Session ID: 0
IKEv1 SA: local 10.23.152.17/500 remote 10.23.152.18/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

Attched are config for 4 devices.

 Any hints  are appreciated

[k.modarresi]

Attaching topology

[MHM Cisco World]

MHM 

[k.modarresi]

Thanks,but I don't think the ips are the issue,10.23.152.1 and 10.23.152.2 are WAN ips and 10.23.152.5 and 10.23.152.6 are tunnel ips. on the other side 10.23.152.18 and 10.23.152.17 are WAN ips and 10.23.152.22 and 10.23.152.21 are tunnel ip addresses.

[MHM Cisco World]

Try tracoute from DCA to DCB use LO as source 

Share traceroute here you need to know in which hop the traceroute stop

Thanks

MHM

[k.modarresi]

Extended traceroute fails

DCA#traceroute
Protocol [ip]:
Target IP address: 10.23.127.80
Ingress traceroute [n]:
Source address or interface: 10.23.111.79
DSCP Value [0]:
Numeric display [n]: n
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.23.127.80
VRF info: (vrf in name/id, vrf out name/id)
1 10.23.152.6 0 msec 1 msec 0 msec
30 * * *

[k.modarresi]

As a test, I removed the vti commands under the tunnel interface and was able to ping  from DCA to DCB using L0 as a source:

DCA#ping 10.23.127.80 so l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.23.127.80, timeout is 2 seconds:
Packet sent with a source address of 10.23.111.79
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
DCA#

Debug on DCB shows the response:

DCB#
*Sep 6 01:11:39.287: ICMP: echo reply sent, src 10.23.152.21, dst 10.23.152.5, topology BASE, dscp 0 topoid 0
*Sep 6 01:11:39.288: ICMP: echo reply sent, src 10.23.152.21, dst 10.23.152.5, topology BASE, dscp 0 topoid 0
*Sep 6 01:11:39.288: ICMP: echo reply sent, src 10.23.152.21, dst 10.23.152.5, topology BASE, dscp 0 topoid 0
*Sep 6 01:11:39.289: ICMP: echo reply sent, src 10.23.152.21, dst 10.23.152.5, topology BASE, dscp 0 topoid 0
*Sep 6 01:11:39.289: ICMP: echo reply sent, src 10.23.152.21, dst 10.23.152.5, topology BASE, dscp 0 topoid 0

Perhaps something to do with porcess switching or MTU size,once Encryption applied?

[MHM Cisco World]

same issue I face in my lab 

let me check why IPsec IPv4 drop the packet 

update you soon 

thanks for waiting 

MHM

[MHM Cisco World]

still want to know solution for this case ?

MHM

[k.modarresi]

Yes, if you have identified the issue.

[MHM Cisco World · Accepted solution]

sure 

do you still use 
tunnel mode ipsec ipv4 <<- under tunnel ?

if Yes 
then in officecore1/2 disable CEF globally and check ping 

MHM

[k.modarresi]

I just tested and ping was successful. Thank you for your effort.

[MHM Cisco World]

You are so welcome 

MHM