2024年8月29日发(作者：满山槐)
MPLS MTU问题
MPLS MTU每次想写的时候都觉得很麻烦，因为问题的原因只有一个，但是现象
千差万别，各个产品实现还不一样，即使同一个产品不同板卡也有区别。
【问题描述】
问题一：
问题二：
现象：如下网络结构，四个设备PE设备间，互为IBGP邻居。相互间
使用loopback口建立BGP peer。S9505与SR6608A之间的BGP邻居不
断UP/Down
经排查，发现更改IGP路由优先级，使S9505与SR6608A间数据流优
选NE40就不会出现问题，如果数据流优选SR8805就会出问题。查看
线路发现S8805的线路上还经过了两个交换机。如下图：S9505和
SR8805之间有一台3com S4500G全千兆交换机。S8805和SR6608A之
间有一台S3126T交换机。并且中间的报文为二层互通，带VLAN tag。
现象：宁波江北政务网为MPLS L3 VPN环境，AR46作为纯P设备，下
挂两台S85作为PE。
拓扑如下，一台S85下用户业务正常，另一台则邮件附件不能上传，
部分业务不能使用。两台S85配置基本相同
AR46
| |
| |
| |
S85B--------S85A（业务不正常）
经排查，发现业务正常S85接AR46主控板以太口，业务不正常S85
接AR46 2GE单板中的一个千兆口。
AR46
ERPU口 2GE口
| |
| |
| |
S85B--------S85A
问题三：
现象：SR6602A和C7509两个PE设备间IBGP邻居不断UP/Down。
经排查，发现SR6602A和C7509发现设备之间使用的使PPP MP进行的
互连。
问题四：
现象：三个PE设备AR46，AR46B下私网用户访问和AR46A，AR28互访
正常。AR46A和AR28之间的用户可以ping通，但无法互访。
经排查，发现AR46A到AR46B的数据，因为倒数第二跳的原因就一层
标签。而AR46A到AR28的数据有两层标签。
总结MPLS网络中这些不通的现象有一个共同点：能ping通，部分业务不通。其
实这些业务的共同点就是业务中几乎都是大报文。
如果ping小包都不通，那么去查线路吧，问题就和本文无关了。
【问题分析】
第一步：定位办法ping报文。这种情况一般都是ping小包通，ping –s 1500
的大包不通。逐步改小ping包的大小，找到临界值。
第二步：如果找到临界值，那么百分百肯定是线路上某一个节点的MTU的问题，
那么下一步就是确认是哪一个点MTU有问题。
问题一的分析过程：
ping1468的报文可以ping通，1469的报文无法ping通。
那么在线路上实际传输报文的长度。
目的mac＋源mac＋TAG＋类型＋＋MPLS＋IP头＋ICMP头＋报文
6 6 4 2 4 20 8 1468＝
1518
目的mac＋源mac＋TAG＋类型＋＋MPLS＋IP头＋ICMP头＋报文
6 6 4 2 4 20 8 1469＝
1519
而S4500的最大接收报文长度就是1518，所以导致1519的报文无法
接收而丢弃。
但是设备间不是有MTU协商吗，为什么S4500还会收到超过接收能力
的报文呢？
那么就要看什么是MTU。MTU最大传输单元，这个最大传输单元实际上
和链路层协议有着密切的关系，让我们先仔细回忆一下EthernetII
帧的结构DMAC+SMAC+Type+Data+CRC
由于以太网传输电气方面的限制，每个以太网帧都有最小的大小
64bytes最大不能超过1518bytes，对于小于或者大于这个限制的以太
网帧我们都可以视之为错误的数据帧，一般的以太网转发设备会丢弃
这些数据帧。（注：小于64Bytes的数据帧一般是由于以太网冲突产
生的“碎片”或者线路干扰或者坏的以太网接口产生的，对于大于
1518Bytes的数据帧我们一般把它叫做Giant帧，这种一般是由于线
路干扰或者坏的以太网口产生）
由于以太网EthernetII最大的数据帧是1518Bytes这样，刨去以太网
帧的帧头（DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址
48bit=6Bytes+Type域2bytes）14Bytes和帧尾CRC校验部分4Bytes
（这个部门有时候大家也把它叫做FCS），那么剩下承载上层协议的
地方也就是Data域最大就只能有1500Bytes这个值我们就把它称之为
MTU。这个就是网络层协议非常关心的地方，因为网络层协议比如IP
协议会根据这个值来决定是否把上层传下来的数据进行分片。
那么说我S4500的1518的最大接收报文长度－（目的mac＋源mac＋
TAG＋类型）＝1500
那么对端发送大于1500的报文就要分片，为什么我还收到了1519大
小的报文？
那就是因为对端发送的时候有MPLS标签。MPLS是一个二层三层之间
的概念。路由器在发送报文的时候，原始报文1469＋（IP头＋ICMP
头）＝1497，不到1500没有分片。这样在封装MPLS头和以太头后，
就超过了对端的接收范围。
[解决办法]
1．V3上可以在MPLS视图添加mtu label-including把标签长度统计
进来，目前V5尚没有这个命令，目前正在开发。
2．NE上有更改MPLS MTU的命令规避该问题，这个实现和Cisco是一
样的。
[NE40-3-GigabitEthernet3/0/0]mpls mtu ?
<328-8000> MTU value
3．当然也可以从S4500上下手，在S4500上开启jumboframe enable，
让S4500可以接收大报文，也能解决这个问题。
问题二的分析过程：
也是一样ping1468字节可以通，1469字节不能通。
因S85发送报文MTU计算的时候是不计算MPLS头的。
S85A发出的1468字节的ping报文封装（ip+icmp）后8+20+1468=1496
因小于MTU=1500，发送。发送报文的大小为1496+4+4+14（两个标签+
以太头）=1518；1469ping报文，最后发出包大小为1519。
AR46上2GE使用Intel GE8254x芯片，最大接收报文长度为1518。所
以1468的ping报文能够通过。并且在AR46和S85A链接的端口上有
大量超大帧错包。
GigabitEthernet1/0/0 current state :UP
Last 300 seconds input rate 0.00 bytes/sec, 0 bits/sec, 0.00
packets/sec
Last 300 seconds output rate 0.00 bytes/sec, 0 bits/sec, 0.00
packets/sec
Input: 167736958 packets, 724939975 bytes, 167737023 buffers
3 broadcasts, 1222013 multicasts, 0 pauses
298998 errors, 0 runts, 298978 giants
0 crc, 0 align errors, 0 overruns
0 dribbles, 0 drops, 0 no buffers
但是和S85B连接的ERPU使用BCM1250芯片，最大接收报文长度为1700，
这样S85发出的报文因MTU为1500，1500+4+4+14<1700 所以能通过。
[解决办法]
1．参照上面的解决办法，因为S85使用的V5平台的版本，不支持mtu
label-including，那么在发送上只能将S85出口的MTU改为1496，
让S85不发出大于1518的大包。
2．在接收上，考虑到不同接口的接收能力不同，可以将S85都连在主
控板的接口上，幸好AR46 ERPU上自带3个combo口。
问题三的分析过程：
如果SR6602A发大包目的是SR6608A的环回口，会走MPLS转发，下一
跳是VT接口。当大包时，IP按照MTU分片为1500并加4个字节MPLS
标签送MP转发。MP将1504的报文分两片处理。CISCO收到这个报文
后会丢弃。分析原因是我们与CISCO做LCP协商时会把本地的
MRU=1500发给CISCO，而CISCO收到报文时会与该MRU做比较，如果
大于该MRU，认为报文非法，而丢弃。
用PING报文也可以验证这个问题，如果PING包为1469，+20字节IP
头+8字节ICMP头=1497。这时候走MPLS转发时为1501。VT口为两个
通道，分为2片。可以看到CISCO收到了2个分片：
01:32:32: Se4/1/5:0 MLP: I frag 80000A1E size 759 encsize 4
01:32:32: Se4/1/5:0 MLP: I data FF03 003D 8000 0A1E 0281 0019 11FF
4500
01:32:32: Se4/1/6:0 MLP: I frag 40000A1F size 760 encsize 4
01:32:32: Se4/1/6:0 MLP: I data FF03 003D 4000 0A1F C5C6 C7C8 C9CA
CBCC
对分片进行重组后发现大于接口MRU=1500，CISCO将包丢弃：
00:50:11: Mu1 MLP: I pkt len 1503 > MRRU 1500 in 'r*-HG-', discarding
//CISCO错误的多统计了0281这两个标志字节
00:50:11: Mu1 MLP: Unable to add to reassembled pkt in 'r*-HG-'
00:50:11: Mu1 MLP: Discard reassembled packet
C7507-8(config-if)#
这个问题几个因素导致，一个是CISCO判断过严，我们的MP其实在
1600字节以下都是可以接收的。二是SR66目前没有MPLS MTU的概念，
IP分片后又格外增加了标签，导致超过接口的MTU。
另：与CISCO的MP只有一个通道时，可以正常转发。看来CISCO只是
在重组分片后才做该检查。
01:27:44: Se4/1/6:0 MLP: I frag C0000976 size 1511 encsize 4
01:27:44: Se4/1/6:0 MLP: I data FF03 003D C000 0976 0281 0019 11FF
4500
[解决办法]
1．
参照上面的解决办法，因为S66使用的V5平台的版本，不支持
mtu label-including。而且这个问题更改MTU也没有用，那么在
发送端没有任何办法。
2．
接收端Cisco是因为双方协商为1500，但是收到1504的IP报文
而任务是错误报文导致。可以配置Cisco允许接收大于协商的MTU
来解决。
C7507(config-if)#ppp multilink mrru local ?
<128-16384> Our MRRU value
C7507(config-if)#ppp multilink mrru local 1504
问题四的分析过程：
问题四的分析过程和前面的类似，只不过要考虑一下相邻PE间有PHP
问题，只有一层标签。读者可以自己分析一下。
归结上面的问题的原因就是链路上有的端口的最大接收报文长度为1518或1522。
这样一个1500的报文＋14个以太头＋一两层MPLS头或者QinQ头就很容易超过
接收能力。
目前常见的MIM 2GE和下面四款FIC接口卡，因为最大接收长度为1518（不含
CRC），都存在这个问题。
【解决办法总结】
1．
在接收端，增强接收能力，开启jumboframe的能力，cisco上增大
MRRU。或者更换接收能力强的端口。
2．
在发送端，如果在接收端上面的操作都无法实施的时候，那么考虑发
送端更改MTU的计算方法mtu label-including；或者把发送端端口
的MTU值改小；对于能设置MPLS MTU的设备，更小这个设置。
3．
最终用户端，当然有的时候发送端不是H3C设备，或不允许更改的时
候，只有最后一个最土的办法，更改CE下面用户PC机的MTU。
8062支持MIM 2GE，导致某些特别应用受限，如GRE多层封装，MPLS多标签等
等，需要配置对端为小MTU才可以。
V5平台正在开发支持MPLS MTU功能。2007年9月10日提交的需求，单号：
2
2024年8月29日发(作者：满山槐)
MPLS MTU问题
MPLS MTU每次想写的时候都觉得很麻烦，因为问题的原因只有一个，但是现象
千差万别，各个产品实现还不一样，即使同一个产品不同板卡也有区别。
【问题描述】
问题一：
问题二：
现象：如下网络结构，四个设备PE设备间，互为IBGP邻居。相互间
使用loopback口建立BGP peer。S9505与SR6608A之间的BGP邻居不
断UP/Down
经排查，发现更改IGP路由优先级，使S9505与SR6608A间数据流优
选NE40就不会出现问题，如果数据流优选SR8805就会出问题。查看
线路发现S8805的线路上还经过了两个交换机。如下图：S9505和
SR8805之间有一台3com S4500G全千兆交换机。S8805和SR6608A之
间有一台S3126T交换机。并且中间的报文为二层互通，带VLAN tag。
现象：宁波江北政务网为MPLS L3 VPN环境，AR46作为纯P设备，下
挂两台S85作为PE。
拓扑如下，一台S85下用户业务正常，另一台则邮件附件不能上传，
部分业务不能使用。两台S85配置基本相同
AR46
| |
| |
| |
S85B--------S85A（业务不正常）
经排查，发现业务正常S85接AR46主控板以太口，业务不正常S85
接AR46 2GE单板中的一个千兆口。
AR46
ERPU口 2GE口
| |
| |
| |
S85B--------S85A
问题三：
现象：SR6602A和C7509两个PE设备间IBGP邻居不断UP/Down。
经排查，发现SR6602A和C7509发现设备之间使用的使PPP MP进行的
互连。
问题四：
现象：三个PE设备AR46，AR46B下私网用户访问和AR46A，AR28互访
正常。AR46A和AR28之间的用户可以ping通，但无法互访。
经排查，发现AR46A到AR46B的数据，因为倒数第二跳的原因就一层
标签。而AR46A到AR28的数据有两层标签。
总结MPLS网络中这些不通的现象有一个共同点：能ping通，部分业务不通。其
实这些业务的共同点就是业务中几乎都是大报文。
如果ping小包都不通，那么去查线路吧，问题就和本文无关了。
【问题分析】
第一步：定位办法ping报文。这种情况一般都是ping小包通，ping –s 1500
的大包不通。逐步改小ping包的大小，找到临界值。
第二步：如果找到临界值，那么百分百肯定是线路上某一个节点的MTU的问题，
那么下一步就是确认是哪一个点MTU有问题。
问题一的分析过程：
ping1468的报文可以ping通，1469的报文无法ping通。
那么在线路上实际传输报文的长度。
目的mac＋源mac＋TAG＋类型＋＋MPLS＋IP头＋ICMP头＋报文
6 6 4 2 4 20 8 1468＝
1518
目的mac＋源mac＋TAG＋类型＋＋MPLS＋IP头＋ICMP头＋报文
6 6 4 2 4 20 8 1469＝
1519
而S4500的最大接收报文长度就是1518，所以导致1519的报文无法
接收而丢弃。
但是设备间不是有MTU协商吗，为什么S4500还会收到超过接收能力
的报文呢？
那么就要看什么是MTU。MTU最大传输单元，这个最大传输单元实际上
和链路层协议有着密切的关系，让我们先仔细回忆一下EthernetII
帧的结构DMAC+SMAC+Type+Data+CRC
由于以太网传输电气方面的限制，每个以太网帧都有最小的大小
64bytes最大不能超过1518bytes，对于小于或者大于这个限制的以太
网帧我们都可以视之为错误的数据帧，一般的以太网转发设备会丢弃
这些数据帧。（注：小于64Bytes的数据帧一般是由于以太网冲突产
生的“碎片”或者线路干扰或者坏的以太网接口产生的，对于大于
1518Bytes的数据帧我们一般把它叫做Giant帧，这种一般是由于线
路干扰或者坏的以太网口产生）
由于以太网EthernetII最大的数据帧是1518Bytes这样，刨去以太网
帧的帧头（DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址
48bit=6Bytes+Type域2bytes）14Bytes和帧尾CRC校验部分4Bytes
（这个部门有时候大家也把它叫做FCS），那么剩下承载上层协议的
地方也就是Data域最大就只能有1500Bytes这个值我们就把它称之为
MTU。这个就是网络层协议非常关心的地方，因为网络层协议比如IP
协议会根据这个值来决定是否把上层传下来的数据进行分片。
那么说我S4500的1518的最大接收报文长度－（目的mac＋源mac＋
TAG＋类型）＝1500
那么对端发送大于1500的报文就要分片，为什么我还收到了1519大
小的报文？
那就是因为对端发送的时候有MPLS标签。MPLS是一个二层三层之间
的概念。路由器在发送报文的时候，原始报文1469＋（IP头＋ICMP
头）＝1497，不到1500没有分片。这样在封装MPLS头和以太头后，
就超过了对端的接收范围。
[解决办法]
1．V3上可以在MPLS视图添加mtu label-including把标签长度统计
进来，目前V5尚没有这个命令，目前正在开发。
2．NE上有更改MPLS MTU的命令规避该问题，这个实现和Cisco是一
样的。
[NE40-3-GigabitEthernet3/0/0]mpls mtu ?
<328-8000> MTU value
3．当然也可以从S4500上下手，在S4500上开启jumboframe enable，
让S4500可以接收大报文，也能解决这个问题。
问题二的分析过程：
也是一样ping1468字节可以通，1469字节不能通。
因S85发送报文MTU计算的时候是不计算MPLS头的。
S85A发出的1468字节的ping报文封装（ip+icmp）后8+20+1468=1496
因小于MTU=1500，发送。发送报文的大小为1496+4+4+14（两个标签+
以太头）=1518；1469ping报文，最后发出包大小为1519。
AR46上2GE使用Intel GE8254x芯片，最大接收报文长度为1518。所
以1468的ping报文能够通过。并且在AR46和S85A链接的端口上有
大量超大帧错包。
GigabitEthernet1/0/0 current state :UP
Last 300 seconds input rate 0.00 bytes/sec, 0 bits/sec, 0.00
packets/sec
Last 300 seconds output rate 0.00 bytes/sec, 0 bits/sec, 0.00
packets/sec
Input: 167736958 packets, 724939975 bytes, 167737023 buffers
3 broadcasts, 1222013 multicasts, 0 pauses
298998 errors, 0 runts, 298978 giants
0 crc, 0 align errors, 0 overruns
0 dribbles, 0 drops, 0 no buffers
但是和S85B连接的ERPU使用BCM1250芯片，最大接收报文长度为1700，
这样S85发出的报文因MTU为1500，1500+4+4+14<1700 所以能通过。
[解决办法]
1．参照上面的解决办法，因为S85使用的V5平台的版本，不支持mtu
label-including，那么在发送上只能将S85出口的MTU改为1496，
让S85不发出大于1518的大包。
2．在接收上，考虑到不同接口的接收能力不同，可以将S85都连在主
控板的接口上，幸好AR46 ERPU上自带3个combo口。
问题三的分析过程：
如果SR6602A发大包目的是SR6608A的环回口，会走MPLS转发，下一
跳是VT接口。当大包时，IP按照MTU分片为1500并加4个字节MPLS
标签送MP转发。MP将1504的报文分两片处理。CISCO收到这个报文
后会丢弃。分析原因是我们与CISCO做LCP协商时会把本地的
MRU=1500发给CISCO，而CISCO收到报文时会与该MRU做比较，如果
大于该MRU，认为报文非法，而丢弃。
用PING报文也可以验证这个问题，如果PING包为1469，+20字节IP
头+8字节ICMP头=1497。这时候走MPLS转发时为1501。VT口为两个
通道，分为2片。可以看到CISCO收到了2个分片：
01:32:32: Se4/1/5:0 MLP: I frag 80000A1E size 759 encsize 4
01:32:32: Se4/1/5:0 MLP: I data FF03 003D 8000 0A1E 0281 0019 11FF
4500
01:32:32: Se4/1/6:0 MLP: I frag 40000A1F size 760 encsize 4
01:32:32: Se4/1/6:0 MLP: I data FF03 003D 4000 0A1F C5C6 C7C8 C9CA
CBCC
对分片进行重组后发现大于接口MRU=1500，CISCO将包丢弃：
00:50:11: Mu1 MLP: I pkt len 1503 > MRRU 1500 in 'r*-HG-', discarding
//CISCO错误的多统计了0281这两个标志字节
00:50:11: Mu1 MLP: Unable to add to reassembled pkt in 'r*-HG-'
00:50:11: Mu1 MLP: Discard reassembled packet
C7507-8(config-if)#
这个问题几个因素导致，一个是CISCO判断过严，我们的MP其实在
1600字节以下都是可以接收的。二是SR66目前没有MPLS MTU的概念，
IP分片后又格外增加了标签，导致超过接口的MTU。
另：与CISCO的MP只有一个通道时，可以正常转发。看来CISCO只是
在重组分片后才做该检查。
01:27:44: Se4/1/6:0 MLP: I frag C0000976 size 1511 encsize 4
01:27:44: Se4/1/6:0 MLP: I data FF03 003D C000 0976 0281 0019 11FF
4500
[解决办法]
1．
参照上面的解决办法，因为S66使用的V5平台的版本，不支持
mtu label-including。而且这个问题更改MTU也没有用，那么在
发送端没有任何办法。
2．
接收端Cisco是因为双方协商为1500，但是收到1504的IP报文
而任务是错误报文导致。可以配置Cisco允许接收大于协商的MTU
来解决。
C7507(config-if)#ppp multilink mrru local ?
<128-16384> Our MRRU value
C7507(config-if)#ppp multilink mrru local 1504
问题四的分析过程：
问题四的分析过程和前面的类似，只不过要考虑一下相邻PE间有PHP
问题，只有一层标签。读者可以自己分析一下。
归结上面的问题的原因就是链路上有的端口的最大接收报文长度为1518或1522。
这样一个1500的报文＋14个以太头＋一两层MPLS头或者QinQ头就很容易超过
接收能力。
目前常见的MIM 2GE和下面四款FIC接口卡，因为最大接收长度为1518（不含
CRC），都存在这个问题。
【解决办法总结】
1．
在接收端，增强接收能力，开启jumboframe的能力，cisco上增大
MRRU。或者更换接收能力强的端口。
2．
在发送端，如果在接收端上面的操作都无法实施的时候，那么考虑发
送端更改MTU的计算方法mtu label-including；或者把发送端端口
的MTU值改小；对于能设置MPLS MTU的设备，更小这个设置。
3．
最终用户端，当然有的时候发送端不是H3C设备，或不允许更改的时
候，只有最后一个最土的办法，更改CE下面用户PC机的MTU。
8062支持MIM 2GE，导致某些特别应用受限，如GRE多层封装，MPLS多标签等
等，需要配置对端为小MTU才可以。
V5平台正在开发支持MPLS MTU功能。2007年9月10日提交的需求，单号：
2