VPLS两端能学到对端MAC但实际不通

一、 组网图

二、故障现象：S6520X-EI交换机发生VPLS场景两终端不通

二、 问题定位与原因分析

从反馈的交换机的诊断信息分析：

首先从反馈信息看到

查看vpls隧道正常

  ===============display l2vpn forwarding pw===============  

Total number of VSIs: 10

Total number of PWs: 31, 31 up, 0 blocked, 0 down

VSI Name                        In/Out Label    NID        Link ID    State   

boss                            131232/131242   8          2048       Up      

boss                            131236/131242   12         2052       Up      

boss                            131237/131242   7          2053       Up      

boss                            131239/131242   9          2055       Up      

boss                            131241/131242   3          2057       Up      

boss                            131243/131242   6          2058       Up      

boss                            131244/131242   24         2059       Up      

boss                            131247/131242   26         2062       Up      

jf1                             131199/131164   2          2048       Up      

jf2                             131198/131163   2          2048       Up      

jf3                             131197/131162   2          2048       Up      

jf4                             131196/131161   2          2048       Up      

jf5                             131195/131160   2          2048       Up      

能看到两端都能通过隧道学到对方终端的Mac地址

<Longtangdafeng-SW-S6520X>display l2vpn mac-address

0009-f50a-bbe5 Dynamic   jf5                             XGE1/0/23      Aging   

0009-f607-0f77 Dynamic   jf5                             2048           Aging   

0009-f607-2e84 Dynamic   jf5                             2048           Aging   

0009-f607-5a8f Dynamic   jf5                             2048           Aging   

0009-f611-3a20 Dynamic   jf5                             2048           Aging   

0009-f611-3a23 Dynamic   jf5                             2048           Aging   

0009-f611-3a26 Dynamic   jf5                             2048           Aging

 <ZhuanXian-S7606>display l2vpn mac-address

000b-0566-72c9 Dynamic  jf5                             257             Aging   

000b-0566-72ca Dynamic  jf5                             257             Aging   

000b-0566-72cc Dynamic  jf5                             259             Aging   

000b-0566-72cf Dynamic  jf5                             268             Aging   

000b-0566-72d0 Dynamic  jf5                             270             Aging   

后续进一步流统发现和 debug arp 发现

76下联终端192.168.1.237有发ARP Request报文给6520X下联终端的192.168.1.238，并且该报文正确发送到给192.168.1.238终端，通过在6520X-EI上打印上送CPU的报文确认下联终端也有发起相应的ARP Reply报文回复237终端，但是自身没有发起ARP Request报文去请求237的地址。怀疑报文存在封装的异常导致两端没有相互学到对端的ARP，后续安排现场进行抓包查看报文的具体封装情况，并且这边实验室也进行了相应的复现。但是现场存在6520X-EI设备地处较远抓包不方便情况，并且设备现网业务流量大，指导了现场进行了Wireshark命令行抓包避免流量打满。

初始在76设备的上下行接口抓包并未定位到具体原因，实验室复现结果两端能互通，原因是实验室环境并没有中间接一台16K的路由器。后续第二次抓包，具体方式：镜像方式是将上图的中间16K入接口2/1/0/4和1/1/0/4镜像到16K的1/0/0/11（16K上抓不了包），然后在76的3/0/48上端口镜像到3/0/4，同时也将AC口的3/0/37镜像到3/0/4上进行抓包。对报文进行观察分析发现：

正常的ARP reply 报文外层TTL为255

6520下联终端238回复的arp reply 外层标签TTL值为0

6520下联终端的icmp请求报文

76下联终端237发的arp request报文，一个是AC口抓的，一个是76与16K接口封装抓的报文。

76下联终端的arp request带封装的

至此判断出报文存在封装错误

排查发现6520X上之前配置了一条 mpls ttl propagate vpn命令。

指导一线工程师undo mpls ttl propagate vpn命令，并在相应的VSI中进行shutdown和undo shutdown命令振荡之后业务回复正常。

后续从官网查看该命令

【使用指导】

IP报文进入MPLS网络和IP报文离开MPLS网络时，TTL的处理方式分为以下两种情况：

·     使能TTL复制功能：IP报文进入MPLS域时将IP TTL复制到标签的TTL域；报文离开MPLS域时将标签的TTL复制到IP的TTL域。Ingress和Egress上都使能TTL复制功能的情况下，Tracert的结果将反映报文实际经过的路径，MPLS骨干网的节点对用户网络的报文可见。

·     禁止TTL复制功能：IP报文进入MPLS域，为IP报文添加标签时，标签的TTL域取值为255；报文离开MPLS域时，直接弹出标签，不修改IP TTL的值。禁止TTL复制功能的情况下，Tracert的结果不包括MPLS骨干网络中的每一跳，MPLS骨干网的节点对用户网络的报文不可见，从而隐藏MPLS骨干网络的结构。

对于Marvell芯片，该命令是复制ip报文的ttl字段的，因为arp报文没有ip字段，所以复制完是0，导致报文到达16K之后被丢弃，经分析讨论该命令本该只对L3VPN生效，此处对VPLS产生影响，后续会对此命令进行优化操作。