MPLS TE隧道带宽的决定因素有哪些？

上次实验中（使用RSVP-TE配置跨域的MPLS TE隧道），我们使用RSVP配置了跨域的MPLS TE隧道，实现了IS-IS、OSPF和BGP等路由协议的综合应用。这样一来，通过使用动态路由协议，可以很灵活地实现路由调整，在保证路由可达的前提下，使用RSVP建立的CRLSP也可以根据网络拓扑变化动态调整MPLS TE隧道。

需要提示的是，如果使用IS-IS协议，在配置路由器级别时，需要配置为level-2路由器才能引入其他协议的路由；如果使用区域内的level-1路由器，则无法实现路由互通。

我现在比较关注的就是带宽问题，前面我们配置了3个带宽，第一个是MPLS TE隧道最大带宽，为30000kbps；第二个是隧道沿途链路的最大带宽，为80000kbps；第三个是最大预留保证带宽，为40000kbps。那这几个带宽在实际使用中是什么效果呢？

我们现在也就是测试出来了MPLS TE隧道的最大带宽，那隧道沿途链路的最大带宽和最大预留保证带宽是否有效呢？我们今天就来简单测试一下。

本次实验以上个实验为基础（使用RSVP-TE配置跨域的MPLS TE隧道），为了模拟链路拥塞，我们在VSR1和VSR4上分别增加了一台主机通过打流来模拟链路拥塞。实验环境和配置保持不变，组网图修改如下。

然后就是设备配置，前面我在配置IS-IS时，是在所有边缘接口上都配置的启用IS-IS。但是后来我才发现，原来IS-IS引入路由的方式和OSPF不一样，而是和BGP比较类似，需要在address-family ipv4 unicast视图下进行配置。

#

isis 1

is-level level-2

cost-style wide

mpls te enable

distribute bgp-ls

network-entity 10.0000.0000.0001.00

#

address-family ipv4 unicast

import-route direct

而OSPF直接在OSPF视图下就可以配置引入直连路由了。

#

ospf 1

import-route direct

area 0.0.0.0

network 34.1.1.0 0.0.0.255

mpls te enable

这样一来，从VSR1上就学到了VSR4上新增的网段了。

同样，从VSR4上也学到了VSR1上新增的网段。

测试一下PCC到PCD的可达性。

测一下PCC和PCD之间的链路带宽。

PCC到PCD是4.7 Gbps，PCD到PCC是4.85 Gbps。

回想一下之前测试VPN性能的时候，我们测试得到的单VSR的转发性能大概是6.52 Gbps。在开启MPLS并且4台串联之后，我们稍微多算一点，视作VSR1到VSR4的链路带宽为6 Gbps。

然后我们开始配置MPLS TE带宽，允许配置的最大值为4,294,967,295，大概是4 Tbps，完全够用。

但是因为显示的接口速率为千兆，所以我们无法配置大于1000000 kbps的带宽。

那就配置隧道沿途链路的最大带宽为800,000 kbps，大概是800 Mbps；配置最大预留保证带宽为500,000 kbps，大概是500 Mbps；先把MPLS TE隧道的最大带宽配置为300,000 kbps，大概是300 Mbps。

此时VSR1的相关配置调整如下：

#

interface GigabitEthernet3/0

mpls te max-link-bandwidth 800000

mpls te max-reservable-bandwidth 500000

#

interface Tunnel14 mode mpls-te

mpls te bandwidth ct0 300000

对应的，在VSR2、VSR3和VSR4设备上调整接口的最大带宽和最大预留保证带宽即可。

调整之后测试PCA到PCB之间的带宽。

测得带宽为295 Mbps，和配置的300000 kbps基本相符。

然后我们在PCC上向PCD打流50 Gbps，模拟拥塞。

再次测试PCA到PCB之间的带宽。

测得带宽为295 Mbps，基本没有受到拥塞的影响。

接下来我们把MPLS TE隧道的最大带宽配置为600,000 kbps，大于最大预留保证带宽的500,000 kbps。

#

interface Tunnel14 mode mpls-te

mpls te bandwidth ct0 600000

比较有意思的事，这个配置没有立即同步到沿途的LSR上，我们从VSR2上查看，分配的带宽依旧是300000 kbps。

这是因为RSVP是软状态协议，需要定时发送消息来维护节点上的资源预留状态。缺省情况下，路径消息和预留消息的刷新时间间隔为30秒。

但是路径消息和预留消息不能很好地兼顾大量刷新时引起的网络负担加重和少量刷新时引起的时延敏感应用体验下降的问题，此时可以使用摘要刷新功能来进行优化。缺省情况下，RSVP摘要刷新功能处于关闭状态，可以在接口下通过以下命令开启：

#

interface GigabitEthernet3/0

rsvp reduction srefresh

修改之后，发现问题没有解决。我就尝试了shutdown接口然后重新开启，发现接口无法UP了。

查看MPLS TE的接口带宽分配信息。

发现可用带宽的最大值竟然是500000 kbps，难道是不能超过最大预留保证带宽？我们把MPLS TE隧道的最大带宽配置为500,000 kbps试一下。

可以了，带宽分配出去了，再次测试PCA到PCB之间的带宽。

在链路拥塞的情况下，第一次测得带宽为461 Mbps，第二次测得带宽为493 Mbps，一时间我竟然无法判断是TE隧道的限速在生效，还是最大预留保证带宽在生效。

那么，不配置隧道沿途链路的最大带宽和最大预留保证带宽是否可行呢？

需要注意，链路的最大带宽不能小于最大预留保证带宽，所以在取消配置时需要先取消最大预留保证带宽的配置。

注意看，此时隧道接口又DOWN了，原因是资源不足，可用带宽为0。这也是正常情况，缺省情况下，用于转发MPLS TE流量的链路最大带宽和最大可预留带宽均为0。

那单独配置链路最大带宽可行吗？

#

interface GigabitEthernet3/0

mpls te max-link-bandwidth 800000

还是不行，还是因为可预留带宽资源不足。那我们试着把链路最大带宽和最大可预留带宽配置成一样的。

#

interface GigabitEthernet3/0

mpls te max-link-bandwidth 800000

mpls te max-reservable-bandwidth 800000

可以了，带宽分配出去了，再次测试PCA到PCB之间的带宽。

在链路拥塞的情况下，第一次测得带宽为489 Mbps，第二次测得带宽为498 Mbps，感觉像是TE隧道的限速和最大预留保证带宽都生效了。

我们再尝试把TE隧道的限速也配置成800,000 kbps。

#

interface Tunnel14 mode mpls-te

mpls te bandwidth ct0 800000

OK，带宽也分配出去了，再次测试PCA到PCB之间的带宽。

在链路拥塞的情况下，第一次测得带宽为766 Mbps，第二次测得带宽为784 Mbps，基本测出了“TE隧道的限速=最大预留保证带宽=链路最大带宽”的效果。

从模拟链路拥塞的流量一侧看一下。

可以看到，流量在两个时间段有了比较明显的下降。当然，如果转换成折线图可能更直观一些。

至于为什么会出现波动，我猜应该是流量整形的原因。我们从中间设备VSR2上可以看到，隧道的带宽是有方向的，并且是应用在了和TE流量相同方向的出接口上。

由此一来，就可以初步判断是通过流量整形进行限速的了。

简单总结一下：MPLS TE隧道的最大带宽、隧道沿途链路的最大带宽、隧道沿途链路的最大预留保证带宽，这三者之间是有依赖关系的：TE链路的最大预留保证带宽不能超过TE链路的最大带宽，TE隧道的最大带宽不能超过TE链路的最大预留保证带宽。除此之外，TE链路的最大带宽不能超过接口速率。

最直观的就是TE链路的最大预留保证带宽和TE链路的最大带宽的配置，如果配置不合逻辑会直接报错；而如果TE隧道的最大带宽配置不合逻辑，如果之前有生效的配置，则不合规的配置不会下发成功；而如果是其他情况，则TE隧道接口会因为资源不足而DOWN掉。需要注意的是，TE隧道沿途链路指的是在途所有设备，比如说本案例中的VSR2、VSR3和VSR4，如果链路资源配置不满足需求，TE隧道接口也会因为资源不足而DOWN掉。

那TE隧道接口DOWN掉之后又会怎样呢？

查路由表转发呗，就和MPLS TE的限速和保障都没有关系了。