cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
481
Views
2
Helpful
12
Replies

Unable to ping ospf routes over VTI

k.modarresi
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

sure 

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

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

MHM

View solution in original post

12 Replies 12

k.modarresi
Level 1
Level 1

Attaching topology

MHM 

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.

Try tracoute from DCA to DCB use LO as source 

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

VTI-topology.PNG

Thanks

MHM

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 * * *

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?

same issue I face in my lab 

let me check why IPsec IPv4 drop the packet 

update you soon 

thanks for waiting 

MHM

still want to know solution for this case ?

MHM

Yes, if you have identified the issue.

sure 

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

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

MHM

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

You are so welcome 

MHM