Cisco Nexus 7000 Series NX-OS MPLS Configuration Guide

How Messages Are Exchanged in MPLS LDP Lossless MD5 Session Authentication

MPLS LDP messages (discovery, session, advertisement, and notification messages) are exchanged between LDP peers through two channels:

• LDP discovery messages are transmitted as User Datagram Protocol (UDP) packets to the well-known LDP port.
• Session, advertisement, and notification messages are exchanged through a TCP connection established between two LDP peers. These messages can be protected against spoofed TCP segments by using the TCP MD5 signature option.

The MPLS LDP lossless MD5 session authentication feature allows an LDP session to incur a password change without tearing down and reestablishing the LDP session.

Benefits of MPLS LDP Lossless MD5 Session Authentication

MPLS LDP MD5 session authentication allows you to set up password requirements for a set of LDP neighbors to help prevent unauthorized peers from establishing LDP sessions and to block spoofed TCP messages.

The MPLS LDP lossless MD5 session authentication feature provides these benefits:

• Enables you to specify peers for which password protection is required in order to prevent the establishment of LDP sessions with unexpected peers.
• Enables you to activate or change LDP MD5 session authentication without interrupting the LDP session.
• Enables you to configure multiple passwords so one password can be used now and other passwords later.

Note LDP passwords cannot be configured on interfaces. You can configure one password per peer or per peer group. To configure multiple passwords, you must use keychains. The key-chain command allows different key strings to be used at different times according to the keychain configuration.

• Enables you to configure asymmetric passwords, which allows one password to be used for incoming TCP segments and a different password to be used for outgoing TCP segments.
• Enables you to configure passwords so that they overlap for a period of time. This functionality is beneficial when the clocks on two LSRs are not synchronized.
• If the neighboring nodes support graceful restart, then LDP sessions are gracefully restarted. The LDP MD5 password configuration is checkpointed to the standby route processors (RPs). The LDP MD5 password is used by the router when the new active RP attempts to establish LDP sessions with neighbors after the switchover.

Note Passwords can be configured to change over time, but they are not guaranteed to be lossless unless keychains are used with overlapping send and accept lifetimes for the transmit and receive keys.

Keychain Use with MPLS LDP Lossless MD5 Session Authentication

The MPLS LDP lossless MD5 session authentication feature allows keychains to be used to specify different MD5 keys to authenticate LDP traffic exchanged in each direction.

In the following example, three passwords are configured:

• Key 1 specifies the lab password. The send-lifetime command enables the lab password to authenticate the outgoing TCP segments from April 2, 2010, at 10:00:00 a.m. until May 2, 2010, at 10:00:00 a.m. The accept-lifetime command is configured so that the lab password is never used to authenticate incoming TCP segments. The accept-lifetime command enables the lab password for 1 second on January 1, 1970. By setting the date to the past and by enabling a duration of 1 second, the password for incoming TCP segments immediately expires. If the accept-lifetime command is omitted from the keychain configuration, then the password is always valid for incoming TCP segments.
• Key 2 and key 3 specify the lab2 and lab3 passwords, respectively. The send-lifetime commands enable the passwords for 1 second on January 1, 1970. By setting the date to the past and by enabling a duration of 1 second, the passwords for outgoing TCP segments immediately expire. If the send-lifetime commands are omitted from the keychain configuration, the passwords are always valid for outgoing TCP segments. The accept-lifetime commands for key 2 and key 3 enable the passwords to authenticate the incoming TCP segments from April 2, 2010, at 10:00:00 a.m. until April 17, 2010, at 10:00:00 a.m. and from April 17, 2010, at 10:00:00 a.m. until May 2, 2010, at 10:00:00 a.m., respectively.

Application of Rules to Overlapping Passwords

Overlapping passwords can be useful when two LSRs have clocks that are not synchronized. The overlapping passwords provide a window to ensure that TCP packets are not dropped. The following rules apply to overlapping passwords:

• If the send-lifetime value for the next password begins before the send-lifetime value of the current password expires, the password with the shorter key ID is used during the overlap period. The send-lifetime value of the current password can be shortened by configuring a shorter send-lifetime value. Similarly, the send-lifetime value of the current password can be lengthened by configuring a longer send-lifetime value.
• If the accept-lifetime value for the next password begins before the accept-lifetime value of the current password expires, both the next password and the current password are used concurrently. The next password information is passed to TCP. If TCP fails to authenticate the incoming segments with the current password, it tries authenticating with the next password. If TCP authenticates a segment using the new password, it discards the current password and uses the new password from that point on.
• If a password for incoming or outgoing segments expires and no additional valid password is configured, one of the following actions occurs:

– If a password is required for the neighbor, LDP drops the existing session.

– If a password is not required for the neighbor, LDP attempts to roll over to a session that does not require authentication. This attempt also fails unless the password expires on both LSRs at the same time.

Resolving LDP Password Problems

LDP displays error messages when an unexpected neighbor attempts to open an LDP session or the LDP password configuration is invalid.

When a password is required for a potential LDP neighbor but no password is configured for it, the LSR ignores LDP hello messages from that neighbor. When the LSR processes the hello message and tries to establish a TCP connection with the neighbor, it displays the error message and stops establishing the LDP session with the neighbor. The error is rate-limited and has the following format:

The output of the show sockets connection detail command shows a summary of TCP connection failures.

Configuring MPLS LDP Lossless MD5 Session Authentication Using a Keychain

You configure MPLS LDP lossless MD5 session authentication using a keychain. Keychains allow a different key string to be used at different times according to the keychain configuration. MPLS LDP gives TCP the keychain information, and TCP queries the appropriate keychain to obtain the current live key and key ID for the specified keychain.

If the sessions to be protected are not already using your keychain, the configuration changes take effect the next time that each session is reestablished. For sessions already using this keychain, the configuration changes take effect immediately. For LDP sessions not already using the keychain, the preexisting authentication remains in effect until the next session is reestablished. A session reestablishment might be forced (with a temporary loss of label switching if LDP graceful restart is not enabled on the session) by using the clear mpls ldp neighbor ip-address command.

If you are not already using authentication, you must make all the required changes on all peers and then force them into action with the password required for prefix-list command so that the sessions using the specified the prefix list are reestablished using the lossless MD5 session authentication you have defined in your configurations.

Prerequisites

Ensure that you are in the correct VDC (or use the switchto vdc command).

Ensure that MPLS LDP is enabled.

SUMMARY STEPS

1. configure terminal

2. ip prefix-list prefix-list permit network/length

3. key chain keychain-name

4. key key-id

5. key-string key
(If you plan to configure a fallback keychain in Step 13, repeat Steps 3 through 5 to configure a backup keychain.)

6. accept-lifetime { start-time | local start-time } { duration seconds | end-time | infinite }

7. send-lifetime { start-time | local start-time } { duration seconds | end-time | infinite }

8. exit

9. exit

10. mpls ldp configuration

11. (Optional) password required [ for p refix-list ]

12. password option number for prefix-list key-chain keychain-name

13. (Optional) password fallback key-chain keychain-name

14. (Optional) show mpls ldp neighbor [ ip-address | interface slot/port ] [ detail ]

15. (Optional) copy running-config startup-config

DETAILED STEPS

Configuring a Fallback Password within a Keychain

You can change MD5 passwords for LDP session authentication without having to close and reestablish an existing LDP session by configuring a fallback password within a keychain.

This addition of a fallback password is nondisruptive when done with peers already using the keychain.

Prerequisites

Ensure that you are in the correct VDC (or use the switchto vdc command).

Ensure that MPLS LDP is enabled.

SUMMARY STEPS

1. configure terminal

2. key chain keychain-name

3. key key-id

4. key-string key

5. send-lifetime { start-time | local start-time } { duration seconds | end-time | infinite }

6. accept-lifetime { start-time | local start-time } { duration seconds | end-time | infinite }

7. exit

8. key key-id

9. key-string key

10. (Optional) show mpls ldp neighbor [ ip-address | interface slot/port ] [ detail ]

11. (Optional) copy running-config startup-config

DETAILED STEPS

Enabling the Display of MPLS LDP Password Changes

You can enable the display of events related to password configuration changes and rollover events.

Note When a password is required for a neighbor but no password is configured for the neighbor, an error message is logged as shown in the “Resolving LDP Password Problems” section.

Prerequisites

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. configure terminal

2. mpls ldp configuration

3. logging password configuration [ rate-limit number ]

4. logging password rollover [ rate-limit number ]

5. (Optional) copy running-config startup-config

DETAILED STEPS

Examples: Configuring MPLS LDP Lossless MD5 Session Authentication Using a Keychain

The following example shows how to configure two peer LSRs that use symmetrical MD5 keys:

LSR1 (with Router ID 10.1.1.1)

LSR2 (with Router ID 10.2.2.2)

The following example shows how to configure two peer LSRs that use asymmetrical MD5 keys:

LSR1 (with Router ID 10.1.1.1)

LSR2 (with Router ID 10.2.2.2)

Examples: Using a Fallback Password within a Keychain

The following example shows how to configure a fallback password within a keychain. For example, because 65535 is the largest key value allowed for a keychain, the “SampleKeyChain” keychain provides a fallback send and receive password of “fallback-password” for times outside the specified send and accept lifetimes for the specified keystrings (passwords).

Examples: Common Misconfigurations When Changing an MPLS LDP Lossless MD5 Session Authentication Password

The following examples show common misconfigurations that can occur when the MD5 password is migrated in a lossless way. Misconfigurations can lead to undesired behavior in an LDP session.

• Example: Incorrect Keychain LDP Password Configuration
• Example: Reconfiguring a Keychain to Prevent TCP Authentication and LDP Session Failures
• Avoiding Prefix List Configuration Problems

Example: Incorrect Keychain LDP Password Configuration

Possible misconfigurations can occur when keychain-based commands are used with the password option for key-chain command. If the accept-lifetime and send-lifetime commands are not specified in this configuration, then a misconfiguration can occur when more than two keys are in a keychain.

The following example shows an incorrect keychain configuration with three passwords for LSR A and LSR B in the keychain:

LSR A Incorrect Keychain LDP Password Configuration

LSR B Incorrect Keychain LDP Password Configuration

In the examples above for LSR A and LSR B during the period of the third send-lifetime 10:30:00 Feb 1 2010 10:30:00 Mar 1 2010 command, all three configured keys are valid as receive keys, and only the last configured key is valid as a transmit key. The keychain resolution rules dictate that keys 10 and 11 are used as receive keys, and only the last key (key 12) can be used as the transmit key. Because the transmit and receive keys are mismatched, the LDP session will not stay active.

Note When more than two passwords are configured in a keychain, the configuration needs to have both the accept-lifetime and send-lifetime commands configured correctly.

LSR A Correct Keychain LDP Password Configuration

LSR B Correct Keychain LDP Password Configuration

In the examples above for LSR A and LSR B during the period of the third send-lifetime 10:30:00 Feb 1 2010 10:30:00 Mar 1 2010 command, only the last key (key 12) is valid as the transmit and receive key. Therefore, the LDP session remains active.

Example: Reconfiguring a Keychain to Prevent TCP Authentication and LDP Session Failures

If the configuration needs to specify the last key in the keychain to always be valid, then configure the keychain to have at least two keys. Each key must be configured with both the send and accept lifetime period.

If the configuration needs to specify the first keychain for the time interval, then use the second key forever after that interval. You can do so by configuring the start time for the second key to begin shortly before the end time of the first key and by configuring the second key to be valid forever after that interval. For example:

If the configuration needs to specify the two keys in the order of the second key, first key, and second key again, then specify three keys in that order. For example:

Avoiding Prefix List Configuration Problems

Use caution when modifying or deleting a prefix list. Any empty prefix list implies “permit any” by default. When you use the password option for key-chain command for MPLS LDP lossless MD5 session authentication, and if the prefix list specified in the command becomes empty as a result of a modification or deletion, then all LDP sessions on the router expect a password. This configuration might cause undesired behavior in LDP sessions. To avoid this scenario, ensure that the proper prefix list is specified for each LSR.

Related Documents

MIBs