Adjusting RSVP-TE Signaling Parameters
Pre-configuration Tasks
RSVP-TE provides various signaling parameters, which meet the requirements for reliability and network resources.
- Configure a dynamic MPLS TE tunnel. For details, see Configuring a Dynamic MPLS TE Tunnel.
- Configure a dynamic DS-TE tunnel. For details, see Configuring a Dynamic DS-TE Tunnel.
Configuration Procedure
The following configurations are optional and can be performed in any sequence.
- Configuring an RSVP Resource Reservation Style
- Enabling Reservation Confirmation Mechanism
- Configuring RSVP Timers
- Configuring RSVP-TE Refresh Mechanism
- Configuring RSVP Hello Extension
- Configuring the RSVP Message Format
- Configuring RSVP Authentication
- Verifying the Configuration of Adjusting RSVP-TE Signaling Parameters
Configuring an RSVP Resource Reservation Style
Context
If multiple CR-LSPs pass through the same node, the ingress nodes can be configured with an RSVP resource reservation style to allow the CR-LSPs to share reserved resources or use separate reserved resources on the overlapping node.
- Fixed filter (FF): creates an exclusive reservation for each sender. A sender does not share its resource reservation with other senders, and each CR-LSP on a link has a separate resource reservation.
- SE: creates a single reservation for a series of selected upstream senders. CR-LSPs on a link share the same resource reservation.
The SE style is used for tunnels established using the Make-Before-Break mechanism, whereas the FF style is seldom used.
Perform the following configurations on the ingress node of an MPLS TE tunnel.
Procedure
- Run system-view
The system view is displayed.
- Run interface tunnel tunnel-number
The tunnel interface view is displayed.
- Run mpls te resv-style { ff | se }
A resource reservation style is configured.
The default resource reservation style is SE.
- Run mpls te commit
The configuration is committed.
Enabling Reservation Confirmation Mechanism
Context
Receiving an ResvConf message does not mean that the resource reservation succeeds. It means that resources are reserved successfully only on the farthest upstream node where this Resv message arrives. These resources, however, may be preempted by other applications later. You can enable reservation confirmation mechanism to prevent this problem.
Perform the following configurations on the egress node of an MPLS TE tunnel.
Procedure
- Run system-view
The system view is displayed.
- Run mpls
The MPLS view is displayed.
- Run mpls rsvp-te resvconfirm
The reservation confirmation mechanism is enabled.
The reservation confirmation is initiated by the receiver of Path message. An object that requires confirming the reservation is carried along the Resv message sent by the receiver.
Configuring RSVP Timers
Context
If an RSVP node does not receive any Refresh message within a specified period, it deletes the path or reservation state. You can set the interval for sending Path/Resv messages and retry count by setting RSVP timers to change the timeout interval. The default interval and retry count are recommended. The timeout interval is calculated using the following formula:
Timeout interval = (keep-multiplier-number + 0.5) x 1.5 x refresh-interval.
In the formula, keep-multiplier-number specifies the retry count allowed for RSVP Refresh messages; refresh-interval specifies the interval for sending RSVP Refresh messages.
Perform the following configurations on each node of the MPLS TE tunnel.
Procedure
- Run system-view
The system view is displayed.
- Run mpls
The MPLS view is displayed.
- Run mpls rsvp-te timer refresh refresh-interval
The interval for sending RSVP Refresh messages is set.
By default, the interval for sending RSVP Refresh messages is 30 seconds.
If the interval is modified, the modification takes effect after the timer expires.
You are not advised to set a long interval or modify the interval frequently.
- Run mpls rsvp-te keep-multiplier keep-multiplier-number
The retry count allowed for RSVP Refresh messages is configured.
By default, the retry count allowed for RSVP Refresh messages is 3.
Configuring RSVP-TE Refresh Mechanism
Context
Enabling Srefresh in the interface view or the mpls view on two nodes that are the neighbors of each other can reduce the cost and improve the performance of a network. In the interface view, Srefresh can be enabled only on this interface; in the MPLS view, Srefresh can be enabled on the entire device. After Srefresh is enabled, the retransmission of Srefresh messages is automatically enabled on the interface or the device.
The Srefresh mechanism in MPLS view is applied to the TE FRR networking. Srefresh is enabled globally on the Point of Local Repair (PLR) and Merge Point (MP) over an FRR bypass tunnel. This allows efficient use of network resources and improves Srefresh reliability.
Assume that a node initializes the retransmission interval as Rf seconds. If receiving no ACK message within Rf seconds, the node retransmits the RSVP message after (1 + Delta) x Rf seconds. The value of Delta depends on the link rate. The node retransmits the message until it receives an ACK message or the times of retransmission reach the threshold (that is, retransmission increment value).
Perform the following configurations on each node of the MPLS TE tunnel.
Configuring RSVP Hello Extension
Context
The RSVP Hello extension mechanism is used to fast detect reachability of RSVP neighbors. When the mechanism detects that a neighboring RSVP node is unreachable, the MPLS TE tunnel is torn down.
Perform the following configurations on each node of the MPLS TE tunnel.
Procedure
- Run system-view
The system view is displayed.
- Run mpls
The MPLS view is displayed.
- Run mpls rsvp-te hello
RSVP Hello extension function is enabled on this node.
By default, the RSVP hello extension is disabled.
- Run mpls rsvp-te hello-lost times
The permitted maximum number of dropped Hello messages is set.
When the RSVP Hello extension is enabled, by default, Hello ACK messages cannot be received for consecutive three times, exceeding which the link is regarded as faulty, and the TE tunnel is torn down.
- Run mpls rsvp-te timer hello interval
The interval for sending Hello messages is set.
When the RSVP Hello extension is enabled, by default, the interval of Hello message is 3 seconds.
If the interval is modified, the modification takes effect after the timer expires.
- Run quit
Return to the system view.
- Run interface interface-type interface-number
The interface view of the RSVP-TE-enabled interface is displayed.
- Run mpls rsvp-te hello
The RSVP Hello extension function is enabled on the interface.
Configuring the RSVP Message Format
Context
You can adjust object information in RSVP messages by configuring the RSVP message format. In scenarios where an RSVP-TE tunnel is deployed, when devices from other vendors on the RSVP-TE tunnel use different format of RSVP message, you can modify the format of RSVP messages to be sent by the Huawei device to implement interworking.
You can configure the transit and egress nodes to add the down-reason object in an RSVP message to be sent, facilitating fault locating.
Procedure
- Configure the formats of objects in an RSVP message.
Perform the following steps on each node of the MPLS TE tunnel:
- Configure the format of the Record Route Object (RRO) in a Resv message.
When the format in a Resv message sent by a non-Huawei device connected to the Huawei device is different from that on the Huawei device, run the following command to adjust the format of Resv messages on the Huawei device to be the same as that on the non-Huawei device to implement interworking.
Perform the following configurations on the transit and egress nodes of an MPLS TE tunnel.
Configuring RSVP Authentication
Context
RSVP key authentication prevents an unauthorized node from setting up RSVP neighbor relationships with the local node or generating forged packets to attack the local node. By default, RSVP authentication is not configured. Configuring RSVP authentication is recommended to ensure system security.
An unauthorized node attempts to set up a neighbor relationship with the local node.
A remote node generates and sends forged RSVP messages to set up a neighbor relationship with the local node.
RSVP key authentication alone cannot prevent anti-replay attacks or RSVP message mis-sequence during network congestion. RSVP message mis-sequence causes authentication termination between RSVP neighbors. The handshake and message window functions, together with RSVP key authentication, can prevent the preceding problems.
The RSVP authentication lifetime is configured, preventing unceasing RSVP authentication. In the situation where no CR-LSP exists between RSVP neighbors, the neighbor relationship is kept Up until the RSVP authentication lifetime expires.
- Configure RSVP key authentication in the interface view: the RSVP key authentication is performed between directly connected nodes.
- Configure RSVP key authentication in the MPLS RSVP-TE neighbor view: the RSVP key authentication is performed between neighboring nodes, which is recommended.
Perform the following configurations on each node of the MPLS TE tunnel.
The configuration must be complete on two neighboring nodes within three refreshing intervals. If the configuration is not complete on either of the two neighboring nodes after three intervals elapse, the session goes Down.
Procedure
- Run system-view
The system view is displayed.
- Run either of the following commands to enter the interface view or the MPLS RSVP-TE neighbor view:
To enter the interface view of an MPLS TE tunnel, run:
interface interface-type interface-number
RSVP key authentication configured in the interface view takes effect only on the current interface and has the lowest preference.
To enter the MPLS RSVP-TE neighbor view, run:
mpls rsvp-te peer ip-address
- When ip-address is specified as an interface address but not the LSR ID of the RSVP neighbor, key authentication is based on this neighbor's interface address. This means that RSVP key authentication takes effect only on the specified interface of the neighbor, providing high security. In this case, RSVP key authentication has the highest preference.
- When ip-address is specified as an address equal to the LSR ID of the RSVP neighbor, key authentication is based on the neighbor's LSR ID. This means that RSVP key authentication takes effect on all interfaces of the neighbor. In this case, this RSVP key authentication has the higher preference than that configured in the interface view, but has the lower preference than that configured based on the neighbor interface address.
If a neighbor node is identified by its LSR-ID, CSPF must be enabled on two neighboring devices where RSVP authentication is required.
- Run mpls rsvp-te authentication { { cipher | plain } auth-key | keychain keychain-name }
The authentication key is configured.
HMAC-MD5 or keychain authentication is enabled by configuring one of the following optional parameters:cipher: configures HMAC-MD5 authentication with keys displayed in ciphertext.
plain: configures HMAC-MD5 authentication with keys displayed in plaintext.
keychain: configures keychain authentication by using a globally configured keychain. At present, only HMAC-MD5 authentication is supported.
Note that HMAC-MD5 encryption algorithm cannot ensure security. Keychain authentication is recommended.
- (Optional) Run mpls rsvp-te authentication lifetime lifetime
The RSVP authentication lifetime is set.
lifetime is in the format of HH:MM:SS. The value ranges from 00:00:01 to 23:59:59. By default, the time is 00:30:00, that is, 30 minutes.
RSVP neighbors to remain the neighbor relationship when no CR-LSP exists between them until the RSVP authentication lifetime expires. Configuring the RSVP authentication time does not affect the existing CR-LSPs.
- (Optional) Run mpls rsvp-te authentication handshake
The handshake function is configured.
The handshake function helps a device to establish an RSVP neighbor relationship with its neighbor. If a device receives RSVP messages from a neighbor, with which the device has not established an RSVP authentication relationship, the device will send Challenge messages carrying local identifier to this neighbor. After receiving the Challenge messages, the neighbor returns Response messages carrying the identifier that is the same as that in the Challenge messages. After receiving the Response messages, the local end checks the identifier carried in the Response messages. If the identifier in the Response messages is the same as the local identifier, the device determines to establish an RSVP authentication relationship with its neighbor.
If you run the mpls rsvp-te authentication lifetime lifetime command after configuring the handshake function, note that the RSVP authentication lifetime must be greater than the interval for sending RSVP refresh messages configured by mpls rsvp-te timer refresh command.
If the RSVP authentication lifetime is smaller than the interval for sending RSVP refresh messages, the RSVP authentication relationship may be deleted because no RSVP refresh message is received within the RSVP authentication lifetime. In such a case, after the next RSVP refresh message is received, the handshake operation is triggered. Repeated handshake operations may cause RSVP tunnels unable to be set up or cause RSVP tunnels to be deleted.
- (Optional) Run mpls rsvp-te authentication window-size window-size
The message window function is configured.
window-size is the number of valid sequence numbers carried in RSVP messages that a device can save.
The default window size is 1, which means that a device saves only the largest sequence number of the RSVP message from neighbors.
When window-size is larger than 1, it means that a device accepts several valid sequence numbers.
If RSVP is enabled on an Eth-Trunk interface, only one neighbor relationship is established on the trunk link between RSVP neighbors. Therefore, any member interface of the trunk interface receives RSVP messages in a random order, resulting in RSVP message mis-sequence. Configuring RSVP message window size prevents RSVP message mis-sequence.
The window size larger than 32 is recommended. If the window size is set too small, the RSVP packets are discarded because the sequence number is beyond the range of the window size, causing an RSVP neighbor relationship to be terminated.
- Run quit
Return to the system view.
- (Optional) Set an interval at which a Challenge message is retransmitted and the maximum number of times that a Challenge message can be retransmitted.
If Authentication messages exchanged between two RSVP nodes are out of order, a node sends a Challenge message to the other one to request for connection restoration. If no reply to the Challenge message is received, the node retransmits the Challenge message at a specified interval. If no reply is received after the maximum number of retransmission times is reached, the neighbor relationship is not restored. If a reply is received before the maximum number of retransmission times is reached, the neighbor relationship is restored, and the number of retransmission times is cleared for the Challenge message.
If the interval at which a Challenge message is retransmitted or the maximum number of times that a Challenge message can be retransmitted does not meet your RSVP authentication success ratio requirement, perform the following configurations:
Verifying the Configuration of Adjusting RSVP-TE Signaling Parameters
Procedure
- Run the display mpls rsvp-te command to check related information about RSVP-TE.
- Run the display default-parameter mpls rsvp-te command to check default parameters of RSVP-TE.
- Run the display mpls rsvp-te session ingress-lsr-id tunnel-id egress-lsr-id command to check information about the specified RSVP session.
- Run the display mpls rsvp-te psb-content [ ingress-lsr-id tunnel-id lsp-id ] command to check information about RSVP-TE PSB.
- Run the display mpls rsvp-te rsb-content [ ingress-lsr-id tunnel-id lsp-id ] command to check information about RSVP-TE RSB.
- Run the display mpls rsvp-te statistics { global | interface [ interface-type interface-number ] } command to check RSVP-TE statistics.
- Run the display mpls rsvp-te peer [ interface interface-type interface-number ] command to view information about the RSVP neighbor on an RSVP-TE-enabled interface.
- Configuring an RSVP Resource Reservation Style
- Enabling Reservation Confirmation Mechanism
- Configuring RSVP Timers
- Configuring RSVP-TE Refresh Mechanism
- Configuring RSVP Hello Extension
- Configuring the RSVP Message Format
- Configuring RSVP Authentication
- Verifying the Configuration of Adjusting RSVP-TE Signaling Parameters