OAM with SR
Load basic.isis.sr.enabled.cfg
From R1, use OAM to verify two items:
Ensure an MPLS packet with the a custom list of prefix SIDs and Adj-SIDs can be steered along the path R1-R3-R4-R6-R7. Perform this check from R1, with R7 as the destination.
Ensure the end-to-end LSP between R1 and R2 is ECMP
Answer
Explanation
First, MPLS traceroute requires that MPLS OAM is enabled on all routers. This is enabled by default on IOS-XE, but not IOS-XR, so we must simply use the command mpls oam on each IOS-XR router.
The only way to verify a custom label stack with MPLS OAM is to use the nil-fec. This allows us to program an arbitrary label stack on top of the exp-null label or router-alert label. From RFC 4379:
This is used because a custom SID list (for TE purposes) has no actual FEC that we can use as the target FEC. Instead we can use a Nil or “null” FEC and put our custom SID list ontop of that. The Nil FEC must use explicit-null or router alert. For this reason, we will see exp-null as the bottom label in our mpls traceroute for every hop.
To program our SID list, we must find two Adj-SIDs: R3’s Adj to R4 and R6’s Adj to R7. This can be found using the ISIS LSPDB or using show isis adj int detail.
So our label stack is 24007/16006/24014.
The mpls traceroute with nil-fec requires two other parameters: and outgoing interface and an outgoing nexthop. Additionally, we need to specify the loopback IPv4 address as the source in this case, because we have supressed the transit prefixes within ISIS in this topology. (By default, R1 will use the outgoing interface address as the source).
We can now run the mpls traceroute:
Notice in the first MPLS Echo Request that the target FEC is “Nil-FEC” with expnull. R1 uses its entire label stack as the downstream mapping.
When R3 receives this, since the FEC is Nil FEC, it does not need to verify that the mapping is correct for the FEC. Instead, it replies with its own downstream mapping for the given label stack. The instruction for an Adj-SID is to pop the label and forward out that interface. So the nexthop is now 10.3.4.4, and the top label has been swapped for imp-null.
Let’s now verify that the unidirectional LSP from R1 to R2 is ECMP. To do this, we enable the multipath parameter on the mpls traceroute. This time, we don’t need to use nil-fec. We can simply use the 2.2.2.1/32 prefix as the FEC.
Below we clearly see two separate paths. R3 uses either R5 or R6 as the nexthop. Remember that you must include the verbose keyword with traceroute mpls multipath to see each hop for each path.
By specifying the multipath parameter, R1 sets the multipath type in the downstream mapping for the Echo Request packet. This is normally set to 0, which means no multipath.
R3, seeing that the multipath type is set, gives R1 its two downstream mappings. Instead of just one.
R1 can now branch off two separate paths. One uses R3’s first downstream mapping as seen below:
Another echo request uses R3’s other downstream mapping. It has the same MPLS TTL=2, however it has a different 127.0.0.X destination IP. This appears to be a technique to force the correct path to be used based on the L3 hashing of the packet header.
R3’s Echo Replies contain the matching multipath mask, as another way to keep the paths separated at the source.
Last updated
