EPON网络VPLS与QinQ业务inQ实现和故障解决

南京信息职业技术学院 丁秀锋

一、组网及业务实现

1.组网背景

不同ONU下挂的PC之间需要实现二层以太网业务的互通。由于OLT启用了QinQ业务，所以不同PON口之间不能实现互通，在OLT上传采用VPLS业务实现。VPLS（Virtual Private LAN Service）是虚拟专用局域网服务，在公用网络中提供的一种点到多点的L2VPN业务。VPLS使地域上隔离的用户站点能通过MAN/WAN相连，并且使各个站点间的连接效果像在一个LAN中一样。

2.网络结构

OLT启用基于PON-OLT口的灵活QinQ，需要实现不同PON口双层VLAN业务的互通。当前OLT可以通过ARP-AGENT来实现单层业务在OLT内部的互通，而双层业务的互通只能在上层设备上实现，在SR上通过VPLS配置来实现，网络结构如图1所示。

图1 组网结构图

二、数据配置

PC1和PC2是一个网段的2个用户，现在的目的就是要实现他们两者的互相通信。PC1和PC2分别接在9806H-1和9806H-2上，都使用的内层VLAN为334。到OLT之后，OLT将对334打不同的外层标签。具体配置如下：

打不同的外层标签以后再发给SR，在SR上做了一个VPLS（二层VPN），配置如下：

三、业务流程

VPLS的功能就是做二层的转发，也就是PC1要访问PC2，正常情况下流程描述如下。

1.上行

（1）PC和ONU。PC发出的数据报文是普通数据报文，不带VLAN标签。数据报文在进入9806端口时根据端口PVID打上VLAN标签“334”，并通过上联口透传到OLT的内联口上。

（2）OLT。从9806上传的数据业务流需要经过OLT的内联口、交换芯片处理和上联口等几个环节。业务流在内联口上直接打上保留“VLAN 4042”，变成双层VLAN标签业务（334，4042）。之后根据VLAN转换规则将双层VLAN标签的数据业务报文的外层保留标签转换成实际的外层标签，业务流变成（334，1003）。由于外层标签以tag方式加入上联口，所以该报文就会从上联口转发出去。

（3）SR。数据包到了SR以后，SR会将这个数据包从sap 1/1/4:1004.334 转发出去，也就是又转发回了OLT。正常情况下，这个数据包转回OLT时，带的外层标签为“1004”，内层标签为“334”，业务流报文变成（334，1004）。可以看出此时到了OLT以后，OLT应该把1004的外层标签替换成保留VLAN 4043，然后转发给PON口0/3/4口，从0/3/4转发给ONU时就把保留VLAN 4042去掉，只保留了334的内层VLAN。这时在9806H-2上就会根据VLAN 334转发并最终发给PC2。

2.下行

（1）OLT。数据报文在SR转发出来后，源/目的MAC地址和内层CVLAN均保持不变，只改变外层VLAN为PC2所带的外层VLAN为1004。因此该业务可以从上联口进入设备并在VLAN 1004中转发。当该报文抵达PON口时，将外层标签剥离掉。所以从内联口出去时就变成单层VLAN（334）的数据报文。

（2）ONU。OLT内联口发出的数据报文广播到该PON口下带的所有网元。根据报文头中的LLID进入相对应的ONU，并剥离PON封装报文还原成标准以太网帧。由于ONU的上联口透传所有VLAN（默认配置），所以“vid＝334”的报文进入上联口，并根据MAC地址学习表转发到相对应的用户端口，在用户口上将VLAN标签剥离还原成普通数据报文。

四、故障现象及分析

由上面正常业务转发流程可以看出，业务的关键在上层的SR设备将上联口出去报文的VLAN标签从“1003”改为“1004”后，再从原上联口转发回去。由于PC1的MAC地址虽然作为源地址出现在上联口，但由于这时上下VLAN不一致，所以不会造成MAC地址漂移的问题。

现场出现这样的问题：开通VPLS业务VLAN均出现业务中断的问题。对MAC地址查询是处理业务中断问题的有效手段，检查OLT和ONU上MAC地址学习情况如下。

1.MAC地址学习情况

（1）先查询ONU用户端口的MAC地址学习情况

（2）再查询OLT上的MAC地址学习情况

从MAC地址表分析，ONU的用户口MAC地址学习正常，且在正确的VLAN中，所以排除ONU的MAC地址学习问题。检查OLT的MAC地址学习情况，可以发现用户的MAC地址作为源地址在上联口动态学习到1004 VLAN中去，同时静态学习到所有保留VLAN中去。

动态学习到1004 VLAN中，是由于SR设备转发VPLS业务，因此这个学习是正常的。静态学习到所有保留VLAN中是由于当前QinQ的内部学习机制产生也属于正常现象。

2.OLT灵活QinQ MAC地址学习机制

为正确了解上述MAC地址学习情况，需要对OLT的灵活QinQ配置下MAC地址学习有所了解。OLT在启用QinQ功能后，上行业务流中用户MAC地址在单层VLAN的情况下转发到OLT的内联口时首先学习到该内联口的保留VLAN中，然后根据业务类型进行软件学习：如果业务是透传的（单层VLAN），那么将用户MAC地址再软件学习到透传VLAN中去；如果业务是双层的（内层CVLAN＋外层SVLAN），那么将用户MAC地址再软件学习到外层SVLAN中去。

下行业务流中，MAC地址首先学习到上联口的外层SVLAN中去（上联口上需要配置外层SVLAN），然后将该MAC地址软件学习到上联口上配置的保留VLAN中去。

如上所述，内联口和上联口学习到MAC地址都会同时存在用户业务VLAN（透传VLAN或外层SVLAN）以及保留VLAN中，前者是动态学习的，后者是软件学习（静态）的。

3.问题分析

由于OLT的MAC地址学习机制，当业务流从SR转发回给OLT时，OLT的MAC学习并不只学习在外层1004里面，而且也会学习到所有保留VLAN里。由于上联口在4042 VLAN中静态学习到用户PC1的MAC地址，这就和EPON-OLT_0/3/4内联口在VLAN 4042中学习到的该用户的MAC地址之间存在冲突，即PC1的用户地址被错误的迁移到上联口上。由于用户PC1的MAC地址在保留VLAN 4042中，PON口也学习到了，上联口也学习到了，所以就出现了业务不通的情况。

由此可见，业务中断是由于QinQ情况下MAC地址学习机制和上层VPLS的业务转发机制冲突造成的。

五、解决方法

1.工程规避

造成该问题的关键是用户MAC地址在上联口学习到错误的保留VLAN中去。由于这个学习是OLT的软件学习，是静态的，而OLT上只能用命令清除动态地址，所以“clear mac dynamic all”命令是无效的，只能手工删除静态MAC地址。

当执行：

以后，再执行：

业务就正常了。

2.解决方法

上述方法只能暂时规避这个问题，如果SR重新进行VPLS业务转发时，用户的MAC地址还是会学习到上联口所有的保留VLAN中去，一旦保留VLAN学习在上联口学习到用户的MAC地址，业务仍然会中断。问题的关键是OLT的MAC地址学习方式上。

当前OLT启用QinQ有多种模式，默认为normal模式。普通模式即开启QinQ功能时在上联口学习到上联设备源MAC地址时会自动将这些MAC地址静态学习到该上联口所有的保留VLAN中。也就是QinQ的这种工作模式造成了本故障。

OLT的QinQ还有用户模式（customer模式）。用户模式下关闭了上联口的MAC地址静态学习功能，也就是说上联口的MAC地址不会学习到保留VLAN中。因此采用用户模式可以解决此故障。配置方法：

需要注意的是修改QinQ的工作模式，并不能自动删除上联口已经学习到的静态MAC地址，可以使用MAC地址删除的命令：

在关闭上联口MAC地址软件学习后，下行业务流存在洪泛问题，所以还要取消OLT上的洪泛抑制，具体命令如下：

见www.dcw.org.cn