LDP Authentication
Load isis.cfg
Configure LDP on all routers using LDP IGP autoconfig.
Configure R1 and R2 to use LDP authentication with a password of “LDP12”
Configure XR1 and R6 to use an LDP password of “LPD619”
Configure R3 and R4 to use LDP authentication with a keychain called “KC34” and password of “LDP34”
Configure all other LDP sessions to use a password of “LDPDEFAULT”
Answer
Explanation
LDP authentication uses the same mechanism as BGP authentication - TCP option 19 in the TCP header. This only authenticates the LDP TCP session, not the UDP discovery Hellos.
LDP authentication on IOS-XE has quite a few options which can be a little confusing. Let’s first look at IOS-XR, as it is much more straightforward.
On IOS-XR, you set the password for all neighbors as follows:
You set the password per-neighbor as follows:
When you make this change, the change is disruptive. The session is torn down and re-established using the new TCP MD5 auth password.
On IOS-XE, we set the default neighbor password using the “fallback” password. The idea is that, if we don’t have a specific neighbor password already, we “fallback” to the “fallback” password.
To set the password per-neighbor, we use the following command:
By default, LDP sessions are not torn down on IOS-XE when you make this change. The password isn’t required until the session is reset. To change this behavior, you can use the following command. With this command, IOS-XE acts like IOS-XR, and reestablishes the session with the TCP authentication password. Note that even without this command, the password is still required whenever the session is reset after you make a change to the LDP password.
We also have the ability to use a keychain for LDP authentication. You can apply this to the fallback password using the following command:
However, you can’t directly apply this to a specific neighbor. Instead, you have to create a standard ACL which matches the remote LDP neighbor’s RID (not transport address) and sets the key-chain using a “password option.”
On IOS-XE, we also have the ability to do password rollover. This can allow you to gracefully change the password, without the new password taking effect right away. For example, we can do this:
The above password won’t take effect for three minutes after entering the command. However, the router will still accept this password. This gives you a “grace period” to change the LDP password on all routers.
Verification
We’ll start with verification on IOS-XR, as that is the simplest. We can simply look at LDP neighbors and verify that “MD5 on” is seen. On IOS-XR, the password is always “required.”
On IOS-XE we must look at the detailed LDP neighbor output. Below we see that on R3, all of the passwords are “not required.” This means that the command mpls ldp password required was not entered. But don’t be fooled - these passwords are “required” if the session is ever re-established! Next, we can see whether the password for the peer is using the “fallback” password, a per-neighbor password, or a password option. Finally, we see whether the password is actually being used or, if it is stale, meaning it will be used whenever the session is next reset.
Above, we see that R3’s LDP sessions with R2 and R6 are “stale,” meaning they are not using the configured fallback password yet. If we reset one of these sessions, we should see it move to “in use.”
Last updated
