PON网络MAC地址欺骗引起PPPOE拨号认证失败案例.docVIP

PON网络MAC地址欺骗引起PPPOE拨号认证失败的案例 故障现象： 2012年7月11日， GPON网络出现大量用户PPPOE拨号认证失败投诉，拨号错误代码676，但同台OLT下部分用户能够正常拨号。 原因分析： PPPOE拨号认证失败原因很多，主要有设备软硬件问题、物理链路问题、PPPOE协议报文丢失等几大类。此次故障中上报拨号676错误，首先排除物理链路问题(物理链路中断会上报678错误代码)，从设备软硬件和协议报文丢失方面分析。 1、从设备软硬件方面分析 检查OLT各单板(主控板、上下行板)的告警性能误码状态，发现无任何异常告警和异常性能。上行G28单板和下行PON板的流量状态也未超负荷，其中上行G28板流量很少，排除设备单板软硬件及网络拥塞问题。 2、查看MAC地址表与现场供电交换机抓包对比分析 在网管上用show svc all 命令查看，发现有一个DHCP获得的地址和BARS 相同(00:30:88:01:d6:5b为BRAS的MAC地址)，详见下图红色字体标识。 图1 查看故障OLT下的业务流数据 上图中红色字体显示，有一个设备DHCP获得的地址和BRAS的相同，该条流标识为“3F8BAB”,该设备还发出了一个ARP广播报文请求IP地址为10.240.136.1的设备,并且该设备DHCP获得1402,58的vlan数值。 通过show crs gem命令找到流标识为“3F8BAB”对应的GEM号,然后在OLT的交叉连接中找到同GEM号的ONU为ONT-14-3-4,该台ONU下挂了的供电交换机管理vlan正是58,而1402的vlan是在OLT的PON口所标记的svlan，找到该台供电交换机后,在其管理口做镜像抓包结果如下: 图2 现场供电交换机管理口镜像抓包截图 从上图第一行可以看出,该供电交换机mac地址为00:22:93:55:c0:bf,且发出了请求IP为10.240.136.1设备MAC地址的广播包,与图1数据吻合。 从以上分析结果可以看出,是供电交换机自身向上层网络发送了BRAS的MAC地址。 3、现场OLT上行口捕获PPPOE拨号报文分析 （1）宽带用户PPPOE拨号流程 PPPoE拨号的工作流程包含发现和会话发现阶段是无状态的，目的是获得PPPoE终结端（）的以太网MAC地址，并建立一个唯一的PPPoE SESSION-ID。 从上述抓包结果分析可得，用户电脑拨号发出的PADI广播报文能够正常抵达BRAS设备，同时BRAS设备回应的PADO报文也能够顺利发送至拨号电脑，但是用户电脑发出的PADR请求报文没有在OLT的上行口正常发出,从而导致BRAS无法响应PADS报文,用户拨号出现异常。 4、原因综合分析 （1）供电交换机伪装BRAS,间歇性地向OLT发送BRAS的MAC地址,该MAC地址被OLT的上行G28单板记录在MAC地址表内,且该MAC地址条目会将原先正常BRAS的MAC地址条目冲掉。 （2）用户电脑发出PADI广播报文后,真正的BRAS和伪BRAS都收到该报文,然后真正的BRAS响应PADO报文,用户电脑正常接收.此时用户电脑会发出PADR报文,因PADR报文的发出是以BRAS的MAC地址为目的地(不区分端口信息),当该PADR报文送到OLT的G28上联板时,OLT按照G28单板内伪BRAS的MAC地址条目,将该报文转发至伪BRAS,而伪BRAS无法响应PADR报文,导致用户拨号报676错误代码。 经验总结： 通过在OLT的下行PON口设置欺骗MAC地址过滤策略,杜绝用户侧伪BRAS设备将真正BRAS的MAC信息发送至上层网络,排除故障。 设定的过滤规则如下: copy profile classifier New CHECKBRAS5B????? 建立一个名为CHECKBRAS5B的classifier conf?????????????????????????????????????? 配置模式 profile classifier CHECKBRAS5B???????????? 进入编辑classifier smac 00:30:88:01:d6:5b? ???????????????????源地址 00:30:88:01:d6:5b(BRAS地址) action deny??????????????????????????????? 设定deny动作（拒绝） exit 将上述classifier配置到指定端口 conf int olt-14-4 edit port olt-14-4 oos? classifier CHECKBRAS5B????????????????????? edit port olt-14-4 is 查看建立的c