调整RSVP信令参数
RSVP-TE提供了丰富的信令参数，能够满足用户对于可靠性和网络资源充分利用的需求。
配置RSVP资源预留风格
背景信息
当多条CR-LSP有重合节点时，需要在MPLS TE隧道的入节点上配置资源预留风格，使得重合的节点在处理资源预留请求时采用相应资源预留方式，本地预留的资源通过单独或者共享方式给多条CR-LSP。
- FF（Fixed Filter）：固定过滤风格，为每个资源预留请求的发送者创建单独的预留，该预留不与其他发送者共享。即同一链路的不同CR-LSP有不同的资源预留。
- SE（Shared Explicit）：共享显式风格，建立单一的资源预留。该预留允许指定的一系列发送者共享。即同一链路的不同CR-LSP共享一个资源预留。
在目前的TE应用中，SE方式主要用于Make-Before-Break，固定过滤类型FF（Fixed-Filter）方式则很少使用。
请在MPLS TE隧道入节点进行如下配置。
配置RSVP的状态定时器
背景信息
对于路径状态或者预留状态，如果连续一段时间没有收到刷新消息，这个状态将被删除。通过配置RSVP的状态定时器，可以设置RSVP刷新消息的发送时间间隔和重发次数，从而改变这个超时时间，建议使用缺省配置。通过以下公式计算超时时间：
超时时间 ＝ （keep-multiplier-number＋0.5） × 1.5 × refresh-interval
其中，keep-multiplier-number代表RSVP刷新消息重发的次数，refresh-interval代表RSVP刷新消息的发送时间间隔。
请在MPLS TE隧道各节点进行如下配置。
操作步骤
- 执行命令system-view，进入系统视图。
- 执行命令mpls，进入MPLS视图。
- 执行命令mpls rsvp-te timer refresh refresh-interval，设置节点的RSVP刷新消息的发送时间间隔。
缺省情况下，节点的RSVP刷新消息的发送时间间隔为30秒。
如果修改刷新周期，该刷新周期的修改需要等到上次定时器超时以后才生效。建议不要设置超长刷新周期或反复修改刷新周期。
- 执行命令mpls rsvp-te keep-multiplier keep-multiplier-number，设置RSVP刷新消息重发的次数。
缺省情况下，RSVP刷新消息重发的次数为3。
配置RSVP-TE摘要刷新
背景信息
在两个邻居节点的接口视图下或MPLS视图下使能摘要刷新（Srefresh）可以减少开销，提高性能。在接口视图下只能使能该接口的摘要刷新功能；在MPLS视图下，将使整台设备所有接口使能摘要刷新。使能摘要刷新后，将同时在单一或全部接口上启动对Srefresh的可靠性重传。
在MPLS视图下配置摘要刷新的方式主要应用于TE FRR场景。在FRR的PLR和MP上配置全局的摘要刷新功能，不仅可以提高网络资源的使用率，还可以提高摘要刷新功能的可靠性。
如果在重传时间间隔内（假设为Rf秒），没有收到应答ACK，经过 (1 ＋ Delta) x Rf秒后，将重传此消息。Delta决定发送方增加重传间隔的速率。重传将一直持续到收到一个ACK消息或重传次数达到增量值RI。
请在MPLS TE隧道各节点进行如下配置。
配置RSVP的Hello扩展
操作步骤
- 执行命令system-view，进入系统视图。
- 执行命令mpls，进入MPLS视图。
- 执行命令mpls rsvp-te hello，使能本节点的RSVP Hello扩展功能。
缺省情况下，未使能RSVP的Hello扩展功能。
- 执行命令mpls rsvp-te hello-lost times，配置允许Hello消息丢失的最大次数。
缺省情况下，启用Hello扩展机制后，连续未收到3次Hello应答消息认为节点发生故障，相关的MPLS TE隧道将被拆除。
- 执行命令mpls rsvp-te timer hello interval，配置Hello消息刷新时间间隔。
启用Hello扩展机制后，缺省的Hello消息刷新时间间隔为3秒。
如果修改刷新周期，该刷新周期的修改结果需要等到上次定时器超时以后才生效。
- 执行命令quit，退回系统视图。
- 执行命令interface interface-type interface-number，进入MPLS TE链路的接口视图。
- 执行命令mpls rsvp-te hello，使能接口的RSVP Hello扩展功能。
配置RSVP消息格式
配置RSVP认证
背景信息
RSVP认证通过使用密钥验证的方法来防止非授权的节点与本节点进行RSVP邻居的建立和防止通过构造报文来达到欺骗的目的。缺省情况下，没有配置RSVP认证。建议配置RSVP认证，否则系统可能不安全。
防止对端在没有授权的情况下和本节点建立邻居关系；
防止通过伪造RSVP报文的方式和本节点建立RSVP邻居。
但只用RSVP密钥验证不能防止回放攻击，也不能解决因网络拥塞导致RSVP报文失序从而引发RSVP邻居之间认证关系终止的问题。这两个问题可以通过配置handshake功能和message window功能来解决。
为了防止RSVP认证无法终止，可配置RSVP认证生存时间。配置RSVP认证生存后，当RSVP邻居之间不存在CR-LSP时可保持RSVP邻居关系，直到RSVP认证生存时间超时。
- 配置接口视图下的RSVP密钥验证功能：应用于两个直连节点。
- 配置MPLS RSVP-TE邻居视图下的RSVP密钥验证功能：可以应用于任意两个互相配置为邻居的节点，推荐使用这种配置方式。
请在MPLS TE隧道各节点进行如下配置。
要求在三个刷新周期内，在直连的两个接口都完成配置。如果在三个刷新周期内没有在两个接口都完成配置，则会导致会话Down。
操作步骤
- 执行命令system-view，进入系统视图。
- 进入接口视图或者MPLS RSVP-TE邻居视图。
执行命令interface interface-type interface-number，进入MPLS TE链路的接口视图。
在接口视图下配置的RSVP密钥验证功能，仅在当前接口下生效且优先级最低。
执行命令mpls rsvp-te peer ip-address，进入MPLS RSVP-TE邻居视图。
- 当ip-address为邻居的接口地址，且与其LSR-ID不相同时，则该密钥认证是基于邻居接口地址的配置。这种配置方式只对该邻居的该接口生效，具有较高安全性，所以优先级最高。
- 当ip-address与邻居LSR-ID相同时，则该密钥认证是基于邻居LSR-ID的配置。这种配置方式将使密钥验证功能在该邻居上生效，而不限定邻居的接口，其优先级低于基于邻居接口地址配置的密钥验证的优先级，但高于接口视图下配置的验证功能的优先级。
当采用对端设备的LSR-ID作为邻居地址时，需要配置RSVP认证的设备上必须使能CSPF功能。
- 执行命令mpls rsvp-te authentication { { cipher | plain } auth-key | keychain keychain-name }，配置验证密钥。
可以根据选用的参数，配置HMAC-MD5认证或者Keychain认证。
cipher：配置HMAC-MD5认证，并使用密文方式显示认证密钥。
plain：配置HMAC-MD5认证，并使用明文方式显示认证密钥。
- keychain：配置Keychain认证，引用全局配置的Keychain，目前只支持HMAC-MD5方式。
在使用中需要注意，HMAC-MD5属于不安全的加密算法，建议使用Keychain认证。
- （可选）执行命令mpls rsvp-te
authentication lifetime lifetime，设置RSVP认证生存时间。
lifetime表示认证生存时间，HH：MM：SS格式，取值范围是00：00：01～23：59：59，缺省值为00：30：00，即30分钟。
RSVP认证时间的功能是：当RSVP邻居之间不存在CR-LSP时可以保持RSVP邻居关系，直到RSVP认证生存时间超时。RSVP认证时间不影响已存在的CR-LSP的状态。
- （可选）执行命令mpls rsvp-te
authentication handshake，配置handshake功能。
在本端配置handshake功能后，如果本端收到一个没有与自己建立RSVP认证关系的邻居所发送的RSVP消息，则本端会发送携带本端标识信息的Challenge消息给该邻居，邻居收到Challenge消息后回应一个Response消息。Response消息中携带了收到的Challenge消息的标识信息。本端收到邻居发来的Response消息，如果其中携带的标识信息与本端一致，就确定可以与该邻居建立RSVP认证关系。
如果在邻居之间配置了Handshake功能，并且需要执行mpls rsvp-te authentication lifetime lifetime命令配置认证生存时间，那么认证生存时间的时长需要大于命令mpls rsvp-te timer refresh配置的RSVP刷新消息的发送时间间隔。
如果认证生存时间小于RSVP刷新消息的发送时间间隔，就可能造成在认证生存时间内收不到RSVP刷新消息而删除认证关系。这样，当下一个刷新消息到来的时候就需要重新进行Handshake机制的检测，如此反复可能会造成TE隧道无法建立或者被删除。
- （可选）执行命令mpls rsvp-te
authentication window-size window-size，配置message window功能，即指定本地设备可保存的邻居RSVP消息有效序列号的个数。
缺省情况下，RSVP消息窗口大小是1，即本地设备只能保存邻居RSVP消息的一个最近的最大的序列号。
当配置的window-size大于1时，本地就可以保存邻居RSVP消息的最近多个有效序列号。
当RSVP接口类型为Eth-Trunk时，RSVP邻居之间只在Trunk链路上建立一个邻居关系。RSVP消息可以从Trunk的任意一个成员接口接收，且各个成员口不是按顺序接收报文的，这样可能造成RSVP消息失序，因此必须配置RSVP消息滑动窗口。建议将滑动窗口大小配置为大于32。如果滑动窗口设置过小，收到的失序的RSVP消息有些可能不在窗口范围内而被丢弃，这样会导致RSVP邻居关系终止。
- 执行命令quit，退回系统视图。
- （可选）配置challenge消息重传间隔和最大重传次数。
当两个节点间的认证消息失序以后，一个节点将向另一个节点发送challenge消息请求恢复连接；如果没有收到对端的响应消息，该节点将在一个重传间隔后重传challenge消息。如果达到最大重传次数后，仍未收到对方的响应消息，则认证失败；如果达到最大次数前，认证成功，则清零challenge消息重传计数。
为了在不同的网络条件下提升RSVP认证的成功率，可配置此步骤调整challenge消息的重传间隔和最大重传次数。
检查调整RSVP信令参数的配置结果
操作步骤
- 执行命令display mpls rsvp-te，查看RSVP-TE的相关信息。
- 执行命令display default-parameter mpls rsvp-te，查看MPLS RSVP-TE缺省参数信息。
- 执行命令display mpls rsvp-te session ingress-lsr-id tunnel-id egress-lsr-id，查看指定RSVP会话的所有信息。
- 执行命令display mpls rsvp-te psb-content [ ingress-lsr-id tunnel-id lsp-id ]，查看RSVP-TE PSB信息。
- 执行命令display mpls rsvp-te rsb-content [ ingress-lsr-id tunnel-id lsp-id ]，查看RSVP-TE RSB信息。
- 执行命令display mpls rsvp-te statistics { global | interface [ interface-type interface-number ] }，查看RSVP-TE运行统计信息。
- 执行命令display mpls rsvp-te peer [ interface interface-type interface-number ]，查看使能RSVP-TE的接口的RSVP-TE邻居信息。
