This Article explains how to verify that the MPLS LSP is Up and carrying traffic in it or not.
Sometimes when we notice that the MPLS LSP is UP however we need to verify whether the traffic is forwarded in the LSP path or not.
Even the MPLS LSP ping fails, the Path would be carrying traffic in it.
Here is how we verify that the the LSP have active traffic in it.
Identify the LSP which you wanted to check.
root@user> show rsvp session lsp name <LSP name>
Ingress RSVP: 6 sessions
To From State Rt Style Labelin Labelout LSPname
<dst IP> <local IP> Up 0 1 FF - 21804 <LSP name>
<dst IP> <local IP> Up 0 1 FF - 21803 <LSP name>
Here you could see the LSP is UP.
Try pinging to the LSP end point.
root@user> ping mpls lsp-end-point <dst IP>
!!!!!
--- lsping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
We could see that MPLS ping also working, It shows that the LSP is UP and active.
However sometime the MPLS LSP will not be working.
.....
This doesn't mean that the LSP is not forwarding the traffic, it could be due to that the egress router might have some filter to block ping.
To verify this, First check whether the LSP end point.
root@user> ping <dst IP> rapid
PING <dst IP> (<dst IP>): 56 data bytes
--- <dst IP> ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 105.678/106.673/107.424/0.678 ms
Then check the route towards the LSP end point.
root@user> show route <dst IP>
inet.0: 1143866 destinations, 5222317 routes (1137921 active, 411048 holddown, 147131 hidden)
+ = Active Route, - = Last Active, * = Both
<dst IP>/32 *[OSPF/10] 13:26:22, metric 44
> to <next-hop IP> via <egress interface>
[BGP/170] 13:26:17, localpref 900, from <bgp peer>
AS path: I, validation-state: unverified
> to <next-hop IP> via <egress interface>, label-switched-path <LSP name>
to <next-hop IP> via <egress interface>, label-switched-path <LSP name>
inet.3: 287 destinations, 290 routes (287 active, 0 holddown, 0 hidden)
<dst IP>/32 *[RSVP/7/1] 13:17:00, metric 44
[LDP/9] 13:26:22, metric 44
Here we can see that the LSP path is installed in routing table.
Run mpls traceroute to find at which node the ping is dropping.
root@user> traceroute mpls rsvp <LSP name>
Probe options: retries 3, exp 7
ttl Label Protocol Address Previous Hop Probe Status
1 21804 RSVP-TE <next-hop IP> (null) Success
FEC-Stack-Sent: RSVP
2 24299 RSVP-TE <current node> <previous IP> Success
3 24372 Unknown <current node> <previous node IP> Success
4 <current node> <previous node IP> No reply >>>>>> LSP end point
5 (null) (null) No reply
6 (null) (null) No reply
From above output we could see that the MPLS ping is reaching the egress router, This means the egress router is not sending the ping response which cause the mpls lsp ping to fail.
Execute below command to check if there is any active traffic in the LSP.
root@user> show mpls lsp name <LSP name> statistics
Ingress LSP: 4 sessions
To From State Packets Bytes LSPname
<dst IP> <local IP> Up 10815113698 13720328359425 <LSP name>
Total 1 displayed, Up 1, Down 0
Egress LSP: 3 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 106 sessions, 6 detours
It shows that the MPLS LSP have active traffic in it.