ICMP echo packets leave and comes back but still unreachable outcome.

[RicardoSN]

Hi guys, I'm experiencing an strange behavior on a L3VPN MPLS enviorment, and i was hoping you could throw me some ideas on what you think could be going on here.

As of security reasons i've changed the ip addresses, maybe a little bit exaggerated on my side considering this is a private and not public network but anyways... this is what is happening:

As part of a troubleshooting session, we were trying from Router-A to ping the IP address: 15.250.10.5 of Router-B (those are different nodes of the MPLS), the ping was being sourced from from Router's-A interface address: 10.3.190.30. We are certain that the routing all over the MPLS PE-Routers is OK, and we are also sure those IPs should be reachable, but the ping tests are not being succesful.

Trying to get a closer look at what could be happening we configured in Router-A an ip flow monitor to try the unsuccesful ping again and see if at least the traffic was leaving Router-A. The results were quite interesting, not only does the ICMP from ping leaves the Router's-A WAN interface Gi0/0/1, We could also see that Router-A actually does get a response, but still, ping outcome is unreachable 100% packet loss.

Router-A#ping 15.250.10.5 source 10.3.190.30
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 15.250.10.5, timeout is 2 seconds:
Packet sent with a source address of 10.3.190.30
.....
Success rate is 0 percent (0/5)

This is what the flow monitor looks like when we filter for traffic comming from the IP addres 15.250.10.5 to check if there's returning traffic from the ping originated from the same Router-A, and as you can see, there's 5 packets returning.

Router-A#show flow monitor NETFLOW-MONITOR cache filter ipv4 source address 15.250.10.5
  Cache type:                               Normal (Platform cache)
  Cache size:                               200000
  Current entries:                              12
  High Watermark:                               17

  Flows added:                                1474
  Flows aged:                                 1462
    - Active timeout      (   320 secs)        107
    - Inactive timeout    (    15 secs)       1355

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  INTF INPUT            INTF OUTPUT           FLOW DIRN  IP TOS  IP PROT            bytes long             pkts long
===============  ===============  =============  =============  ====================  ====================  =========  ======  =======  ====================  ====================
15.250.10.5     10.3.190.30                  0              0  Gi0/0/0               Null                  Input      0x00          1                   500                     5

i'd very much appretiate what are you thoughts on this, thanks again for your help and ideas in advance.

[Harold Ritter · Accepted solution]

Hi @RicardoSN ,

> we were trying from Router-A to ping the IP address: 15.250.10.5

Is this address part of a specific VRF? If so, you need to use the command "ping vrf <vrf-name> 15.250.10.5".

> the ping was being sourced from from Router's-A interface address: 10.3.190.30

If the ping is to a VRF address, it needs to be sourced from an address inside a VRF.

Regards,

[RicardoSN]

The source interface/IP address is not part of a VRF, the configuration is very straight forward.

[Harold Ritter]

Hi @RicardoSN ,

Try sourcing the packets from the loopback interface of RouterA instead of 10.3.190.30. Also, is 15.250.10.5 RouterB loopback address? I would suggest pinging from loopback to loopback, as in general, in an MPLS L3VPN network, the most important thing is to have connectivity between PEs loopback addresses.

Regards,

[MHM Cisco World · Accepted solution]

can you draw the topology ?
can you share the show ip route ?

[RicardoSN]

Thanks for trying to help. I marked you both as solution. The problem has now been solved.
Sadly it was impossible for you to solve it because i totally omited a key element. In this MPLS environment, there's also GETVPN involved for encryption between the various nodes (or GMs), I so wrongly assumed the GETVPN configuration had no issues because the service was suppose to be working just fine with the same configuration before it was reported and "no one has made any changes recently" (nothing but lies u.u). As it only could be... the issue ended up being that we had the GETVPN crypto map configured in two interfaces, where it should only be applied to the interface facing the MPLS, deleted the crypto map from the wrong interface and problem solved. When will i learn to not take anything for granted while troubleshooting, hehe... anyways, thanks again for trying to help. have a good one guys.

[Harold Ritter]

Hi @RicardoSN ,

Glad you found the issue and thanks for the update.

Happy new year to you and your family!