LDP session not UP

 

Transport address chosen is not reachable

Interface is not mpls enabled

Interface is not LDP enabled.

LSR-ID might be same on both the nodes

Use these commands:

Verify status of transport address

Verify IP connectivity to neighbor transport address

Verify interface status.

Verify LDP session state

LDP targeted session not UP

 

Targeted Peer not reachable.

Targeted Peer is not configured on both nodes.

Use these commands:

Verify status of transport address

Verify IP connectivity to neighbor transport address

 

RSVP session is not operationally UP

 

Interface might be shutdown, no label switching, not RSVP enabled.

Incorrect command syntax

Routing information not present in CSPF/RIB

Wrong strict hops in the rsvp-path

Use these commands:

In the output part please check the error code and error value. This will help in narrowing down the problem

Gives the OSPF routes to Egress. (used in case of non-CSPF trunks) / OSPF te-database should hold the LSAs of the egress and the hops to the egress.

Check the interface status.

Details all the path information

Verify the command configured successfully.

DSTE/Diffserv, bandwidth

related problems

 

Mismatch in class types/TE classes between the nodes

Bandwidth constraint for the te class is missing

Use these commands:

In the output part please check the error code and error value. This will help in narrowing down the problem

Details all the DSTE information on that node

Verify if all the required constraints for the class type and te class are configured.

rsvp detour session down

Use this command:

 

Check the error code and error value to narrow down the issue. If CSPF is not able to find a path, check SRLG values of the primary path. Then check if any path is available excluding the SRLG values of the primary's out-going interface.

rsvp secondary session down

Use this command:

 

Check the error code and error value to narrow down the issue. If CSPF is not able to find a path, check SRLG values of the primary path. Then check if any path is available excluding the SRLG values of the primary. Change the SRLG option to preferred value if needed.

 

If re-optimization is running for detour/secondary

Use this command:

 

Check if there is a common SRLG value between the calculated primary session and backup session. If there is a common SRLG value and the SRLG option configured is srlg-disjoint preferred, then re-optimization will be running.

 

If calculated session doesn't include SRLG values though configured

Use this command:

 

 

Verify the TE-LSA of links have SRLG values STLV in them.

Use "show running-configuration interface" to verify SRLG values are configured on correct interface.

 

VC/VPLS is not operationally up

 

Interface might be shut down, no label switching, AC is not bound to VC/VPLS

Use these commands:

 

Verify the command configured successfully

 

Verify the FTN entries are installed

 

Verify the attachment circuit is bound to VC

 

Verify the attachment circuit is bound to VPLS

VPLS Sessions are UP and ACTIVE

End to end traffic loss is observed

Use these commands:

 

Shows the MACs learned on VPLS interfaces (AC/PW). If the MACs are not shown, check the AC binding configuration or vpls type configuration for VPLS.

 

Verify the MPLS commands configured successfully

BGP L3VPN sessions are operationally up but:

If the originating routes are directly connected, check if “redistribute connected” is configured under the “address-family ipv4 vrf NAME” is configured.

If the originating routes are statically configured, check if “redistribute static” is configured under the “address-family ipv4 vrf NAME” is configured.

If the originating routes are received via the OSPF session with the customer edge (CE) node, check if “redistribute ospf” is configured under the “address-family ipv4 vrf NAME” is configured.

Check if the “rd” and “route-target” configured for a particular VRF matches the ones configured at the peer for the same VRF.

 

Check if the neighbors’ identifiers are configured correctly.

 

Validate the labels distributed between the BGP VPNv4 address-family peers:

BGP shows the labels as installed but the L3VPN FTNs are operationally down in NSM

Check if there is at least on MPLS path (LSP/tunnel) to the BGP peer. When there are multiple paths to the BGP peer, there could be a case where the interface used by the MPLS LSP to reach the BGP peer is different from the one that BGP uses to reach its peer. In such cases, check if “label-switching” is enabled on all the interfaces through which BGP could possibly connect to its peer.

Validate the presence of L3VPN FTNs and ILMs in the MPLS FIB:

This shows the all the routes received from the BGP peer with the routes segregated per VRF. The “out label” shows the label to be used for that route. This has to match the “Out Label” shown as an output for the “show ip bgp vpnv4 vrf NAME label” command for that particular route. The “show mpls vrf-table” command also shows the operational state of the L3VPN FTNs.

The “In-Label” shown must match the “In Label” shown as an input for the “show ip bgp vpnv4 vrf NAME label” command for that particular route.

Traffic takes a different queue from what is configured

 

QOS not enabled globally

Conflicting configuration

RSVP session not up in case of elsp-signaled traffic

PHP scenario

Use this command:

 

 

Verify if any policy-map is attached on the interface:

 

 

Verify the match criteria and set action of the policy map:

 

 

Verify the global mapping if policy-map is not attached:

 

 

Verify if RSVP session is up and if the traffic is intended to go via the RSVP trunk. Check for the mapping in the same command if the session is up.

Full rate traffic observed even after applying policer command

 

RSVP session not up

Traffic is not taking the rsvp trunk path

Hardware limitation reached

Use this command:

 

 

Verify if the session is UP and check the policer status. If policer is configured but not applied in hardware, either session would be down or hardware limitation would have reached.

If the traffic is flowing in full rate even when the policer shows as applied in hardware, then the traffic may not be taking RSVP trunk path.

 

Verify if RSVP trunk is selected.

Within MPLS network if the P routers are of other vendors, due to incorrect MTU settings BGP session can flap if services (L2VPN/L3VPN) exchanges exceed the MTU size.

1. Note that on OcNOS device when MTU is configured on L3 interface, it implies only the payload (till L3 headers).

L2 header : 14/18 bytes

MPLS header : Up to 20 bytes if label-switching is enabled on interface

 

2. So if MTU set is 1500, hardware sets MTU as following:

3. So corresponding interop device has to configure MTU considering this increase.

 

4. Also, it is always recommended to configure MTU higher on the network side interface than the access interface, due to following:

(1 tunnel label, 1 service label, 1 LU label, 2 entropy label)