LDP Implicit Withdraw
Load isis.cfg
Configure LDP between R1 and R2 using interface commands
Configure R2 so that any existing FEC bindings with a new label are advertised and withdrawn using a single label mapping message
Answer
Explanation
In IOS, the old method for advertising a new label for an existing FEC was to implicitly withdraw the label by simply advertising a new label for that FEC. This is similar to BGP’s behavior, in which a new Update for the same prefix from a peer is considered as “replacing” the existing route. This is why BGP AddPath functionality requires a path ID - to keep paths separate and not implement implicit withdraw.
In IOS-XE, the new style for LDP was to first withdraw the label explicitly, and then advertise a new label binding. To restore the old method we can use the following command. This functionality does not appear to be supported on IOS-XR in version 6.x.x.
To test this out, we can create a static label binding on R2. This allows us to easily change the label associated with the FEC. First we create a static route:
R2 will advertise this FEC binding with a dynamic label to R1. Next we create a static label range on R2.
We can now allocate a static local label for this FEC on R2.
R2 has not yet configured implicit-withdraw for R1. On R1, we can see that R2 sends two messages: a withdraw and then a label mapping:
Next, we set R2 for implicit-withdraw, and change the local static label for the FEC:
On R1 we now see only the new mapping message. This is an implicit withdraw for the old binding, instead of an explicit withdraw as we saw before.
Last updated
