ADMAN方案路由器转控分离场景PPPoE业务不通问题的经验案例

ADMAN路由器转控分离方案，PPPoE客户端已拨号成功，但业务转发不通

无

ADMAN方案主要以H3C NFV Orchestrator业务编排器配合H3C CloudOS云管理平台，控制H3C CAS虚拟化平台创建vBRAS虚拟宽带远程接入服务器资源池，同时配合硬件交换机与vBRAS资源池建立VXLAN隧道用于转发用户接入业务控制报文，来完成运营商城域网接入层功能。

在ADMAN方案PPPoE业务路由器转控分离场景组网下，控制平面（CP）与转发平面（UP）分离，控制平面和数据平面可分别选择合适的网元分别承载，以标准接口交互。控制平面要求能处理复杂逻辑和维护状态机，需要强计算、大内存、高扩展能力，一般采用X86来承载，ADMAN方案中一般使用vBRAS来承载CP（如无特殊说明，下文中vBRAS即指代CP）；转发平面功能简单但性能压力大，需要高性能、低延时、低抖动能力，适合采用网络处理器（NP）或可编程ASIC来承载，ADMAN方案中目前使用交换机或路由器来承当UP（如无特殊说明，下文均以SR88路由器做为UP）。

ADAMN方案PPPoE业务路由器转控分离场景组网中，用户通常为PPPoE接入方式，PPPoE客户端通过PPPoE拨号触发PPPoE认证上线。UP将接入OLT上送的PPPoE用户控制报文封装为VXLAN报文上送给vBRAS设备，vBRAS设备解封装VXLAN报文后与AAA服务器交互，并将回应报文通过VXLAN隧道送回UP，UP解封装后返回给OLT，而PPPoE业务报文从OLT发送至UP后，在UP上上行查找路由表转发，下行查找流表转发。

本文仅就ADMAN方案路由器转控分离PPPoE用户宽带业务不通问题如何排查进行阐述。

问题排查前提：NFV Orchestrator已成功创建 vBRAS并且vBRAS状态正常为active（如果vBRAS无法创建或状态异常请参考《NFV Orchestrator创建vBRAS失败问题排查云图》、《NFV Orchestrator上vBRAS运行状态异常问题排查云图》进行排查），NFV Orchestrator已成功添加UP且路由器状态正常为AVAILABLE（如果路由器状态异常请参考《NFV Orchestrator添加交换机失败问题排查云图》进行排查）。且PPPoE用户已拿到地址并在vBRAS上成功上线，如果终端未拿到地址或未在vBRAS上上线，请参考《ADMAN方案PPPoE转控分离用户上线失败问题排查云图》进行排查。

PPPoE业务问题现象表现为用户上线成功，但宽带无法正常访问。排查此类问题时，需要首先排查vBRAS上是否存在PPPoE用户表项：如果不存在表项，则需要排查PPPoE用户无法上线的原因；如果存在表项，则需排查OpenFlow流表是否下发正确，路由是否学习正确等。具体排查思路如下：

1.  步骤1：检查vBRAS上是否存在对应用户的PPPoE会话。如果不存在，则排查PPPoE用户无法上线的原因；如果存在会话，第2步继续检查。

2.  步骤2：在UP上Ping PPPoE终端，测试是否能Ping通。如果UP无法Ping通PPPoE终端,则请排查UP下接的OLT网络；如果UP可以Ping通PPPoE终端，则转入步骤3继续排查。

3.  步骤3：在UP上Ping CR，测试是否能Ping通。如果UP无法Ping通CR,则转入步骤5继续排查；如果UP可以Ping通CR，则转入步骤4继续排查。

4.  步骤4：排查CDN到CR是否存在故障。

5.  步骤5：确认在CR上是否存在用户网段路由。如果不存在相应的用户网段路由，则进入步骤6继续排查。如果已经学习到相应路由，请排查CR到UP这一段的转发问题。

6.  步骤6：确认在UP上是否存在用户网段路由。如果不存在相应的用户网段路由，请排查相应配置。如果已经下发相应路由，请排查CR到UP这一段的路由学习问题。

7.  步骤7：排查UP上是否存在NAT会话。如果不存在请检查CGN相关配置。

8.  步骤8：检查用户表项是否在UP下发。转控分离PPPoE业务的下行流量是查找OpenFlow流表下发的用户表项进行转发的，如果在UP上无法直接Ping通PPPoE终端，则证明OpenFlow流表存在问题。如果流表存在问题，请进入步骤11继续排查，如果流表没有问题，请进入步骤9继续排查。

9.  步骤9：排查UP上VSI相关配置是否正确。如果相关配置正确，请进入步骤10继续排查，如果相关配置有问题，请登录vBRASSO进行相应修改。

10. 步骤10：排查UP上FIB等相关表项是否学习正确。如果表项学习正确，请进入步骤11继续排查。如果表项学习错误，可以尝试让IPTV终端重新上线。

11. 步骤11：检查OpenFlow配置是否下发正确。如果OpenFlow配置下发正确，请进入步骤11继续排查。如果OpenFlow配置下发错误，请在vBRASSO上检查对应的UP状态是否正确、交换机类型是否选择正确。

12. 步骤12：沿用户接入报文转发路径排查流量经过的其他设备（服务器网卡或者网络设备），确认流量丢弃的位置，并排查中间链路丢包原因。流量统计和抓包配置方法可参考相关交换机或vBRAS配置指导，如果确认报文未丢弃，可拨打H3C热线电话400-810-0504寻求帮助。

1.检查vBRAS上是否存在对应用户的PPPoE会话

检查vBRAS上是否存在对应用户的PPPoE会话。如果不存在，则请参考《ADMAN方案PPPoE转控分离用户上线失败问题排查云图》排查PPPoE用户无法上线的原因；如果存在会话，则转入步骤2继续排查业务转发状态。

登录NFV Orchestrator WEB界面后，在NFV编排/vBRASSO页面，选择对应的虚拟机资源池，通过名称或管理IP查找到对应的vBRAS后，即可点击操作一栏最右侧的控制台按钮，进入vBRAS的命令行界面。本例中，vBRAS名称为“PPPoE-1”，管理IP为“99.1.4.121”。如果操作员可以直接访问vBRAS的管理IP，也可以SSH直接登录vBRAS命令行。

登录vBRAS命令行界面之后，可使用“display ppp acces-user domain domain-name”命令查看是否存在对应用户的PPP会话。当已知用户的IP地址时，可使用“display ppp acces-user ip X.X.X.X”(X.X.X.X字段为用户IP地址)命令查找具体的用户会话；当已知用户的MAC地址时，可使用“display ppp acces-user mac-address X-X-X”(X-X-X字段为用户MAC地址)查找具体的用户会话。如下举例所示，pppoe domain下有一PPPoE上线用户，其IP地址为“12.1.1.1”及MAC地址为“9c06-1b76-5ddd”的用户已上线。

如果根本不存在对应用户会话，则PPPoE用户未上线，需要参考《ADMAN方案路由器转控分离方案PPPoE业务上线失败问题排查云图》进一步排查。

2.在UP上Ping PPPoE终端，测试是否能Ping通

         SSH登录UP，使用Ping命令 “ping –a 源VTEP IP 目的VTEP IP”命令检查UP上的网关IP是否能与PPPoE终端互通。如下所示，由标红加粗字段可以知源IP地址为“12.1.1.254”，目的IP地址为“12.1.1.1”，由“0.0% packet loss”可知源目 IP之间无丢包，通信正常，UP与IPTV终端之间源目IP可达；否则，如果“packet loss”字段前数字不为“0.0%”，则说明UP与IPTV终端之间通信异常，需要转入步骤7进一步排查。如果“packet loss”字段前数字为“0.0%”，则说明UP与PPPoE终端之间通信正常，需要转入步骤3进一步排查。

注意这里的源IP为PPPoE终端网关IP，只能在UP上发起该Ping操作，vBRAS上的该Ping操作正常情况下亦无法Ping通PPPoE终端。如果配置了VPN，还需要带上“-vpn-instance vpn-name”参数发起Ping操作。

    如果PPPoE终端为不允许Ping类型的终端，则需要在UP下行口抓包或流统确认ICMP报文已发出，如未发出则需要进入第七步继续排查。

3.在UP上Ping CR，测试是否能Ping通

登录UP，使用Ping命令 “ping –a 源VTEP IP 目的VTEP IP”命令检查UP上的用户业务网段网关地址是否能与公网互通。如下所示，由标红加粗字段可以知源IP地址为“12.1.1.254”，目的IP地址为“10.1.1.1”，由“0.0% packet loss”可知源目 IP之间无丢包，通信正常，UP与CR之间源目IP可达，需要进入步骤4进一步排查；否则，如果“packet loss”字段前数字不为“0.0%”，则说明设备之间通信异常，需要转入步骤5进一步排查。

4.排查CDN到CR是否存在故障

         经过上面三步的测试，我们可以判断CR到PPPoE终端这一段的网络是通畅，如果PPPoE业务仍旧存在问题，接下来需要判断运营商侧的CDN机房本身是否存在故障以及CND机房到CR这一段网络是否存在故障，同时需要了解现场PPPoE业务是否有特殊之处，比如是否需要大包放通、防火墙放通等，并做针对性测试。本文中不再赘述CDN到CR一段的排查方法。

5.确认在CR上是否存在用户网段路由

如果CR无法Ping通PPPoE终端或UP无法Ping通CR，而UP可以Ping通PPPoE终端，则需要登录CR上排查CR是否学习到了用户网段的路由，一般是由UP通过IBGP邻居将该用户网段路由发送给CR交换机，所以如果CR无法学习到用户网段路由，首先需要排查IBGP邻居是否正常，以及路由是否通过IBGP传递到CR了。如果邻居正常而UP上没有用户网段路由，则需要参考步骤6排查UP是否生成、引入了用户网段路由并发布给了CR。如果CR上已经学习到了用户网段路由，但仍旧无法Ping通IPTV终端，则需要排查CR到UP的转发是否存在问题，因该转发过程不涉及VXLAN，这里不再赘述。

6.确认在UP上是否存在NAT会话

PPPoE用户一般在UP上会使用CGN板卡配置CGN相关业务，请在UP上使用命令“display ppp access-user ip-address x.x.x.x verbose”来查看PPP用户的详细信息，并确认NAT转换后的公网IP地址及端口块：

如上，可以发现PPPoE用户认证通过后，下发了User group为user1，并且已经分配了公网地址22.22.4.64以及公网端口块1-401。

如果未分配公网IP或公网端口块，请使用命令“display nat statistics summary”查看公网地址和端口块的分配情况，确认是否有剩余：

相关参数解释如下：

如果DPB为可分配端口块，ADPB为已分配端口块，如果DPB-ADPB的数值小于端口块的size则会导致分配失败。可以在CP上通过命令“display current-configuration | begin addres-pool”查看nat address-pool的配置，确认地址块大小，如下图，端口块的大小为400：

    同时，可以在UP上通过命令“display current-configuration | begin addess-group”查看UP上的相关配置，如下图：

    注意此处port-range和port-block block-size的配置要与CP保持一致。同时，UP上配置了user-group user1，此处的user1需要在CP的domain中使用命令“authorization-attribute user-group user1”指定，或由AAA直接下发用户属性user1（可以使用命令“display ppp access-user”在AAA一栏查看user-group属性），如果user-group属性下发错误或未下发会导致用户流量无法匹配，从而无法进入CGN流程分配地址和端口块。

    同样，如果NAT地址和端口块分配失败，需要在UP上检查CGN的MQC相关配置是否正确，如下为正确配置：

    在UP上还需要检查CGN相关的其他配置，首先我们在UP上使用命令“display device”找到CGN板卡的slot号，如下图红框处，Brd Type为“IM-MSUX”的为CGN板卡，其slot号为3和4：

    这里我们选用slot 4来做CGN板卡，在UP上需要配置如下：

    最后，在CP上同样需要检查CGN相关配置，如下为正确的配置：

    CP上的addres-pool配置请参考本步骤上半部分的描述进行检查。需要注意的是，domain内需要配置用户地址类型为ipv4私有网络，该配置为vbrasso下发，需要登录到vbrasso前台web页面，在虚机模板中查看Domain的配置，确认是否勾选了“配置用户地址类型”，并选择地址类型为“private-ipv4”，如下图红框处：

7.确认在UP上是否存在用户网段路由

UP上的用户网段路由一般由vBRAS（CP）通过OpenFlow通道下发给UP，所以我们需要首先需要判断现场vBRAS（CP）上的DHCP地址池类型，如果是普通地址池、或地址池组内加入的是普通地址池，则需要在地址池内配置命令“subnet alloc-mode  dp-address ”，否则vBRAS（CP）不会主动向UP（DP）下发用户网段路由，此时需要手工在UP上配置用户网段的静态黑洞路由，并在BGP的IPV4地址簇中引入该静态路由。如果是动态地址池（配置了“dhcp server ip-pool pool-name subnet-alloc”命令），则vBRAS（CP）不用绑定DP也会自动下发用户网段路由。

如下举例中，vBRAS（CP）上配置了普通地址池，但其在地址池内使用标红命令“binding dp-address 111.1.1.2”绑定了DP 111.1.1.2，故而该CP会向该DP下发用户网段路由。

在UP上，我们可以使用命令“display openflow instance 1 flow-table”来查看UP上是否下发了对应的用户网段流表，如下：

该流表的目的地址为用户网段，出接口为NULL0。同时，该流表会在IP路由表中生成一条静态路由，我们可以使用命令“display ip routing-table protocol static”来确认查看，注意“display current-configuration”命令无法查看到该静态路由。

如果vBRAS（CP）上的地址池为普通地址池且未指定DP，则上述OpenFlow流表不会下发至UP，此时可以选择在CP上绑定DP，或直接在UP上手工配置用户网段静态路由，如下：

如果UP上未查看到该用户网段流表，则首先需要排查是否有用户终端上线，只有该网段的第一个终端上线成功后，该用户网段流表才会从CP下发至UP，然后需要排查CP与UP的OpenFlow实例是否正常，如下标红字段，在UP上使用命令“display openflow instance 1 controller”来判断OpenFlow连接是否正常，当“Connect state”为“Established”状态时是正常状态，其他状态均不正常。同时需要关注字段“Local IP address”和“Controller IP address”，其应该分别为VXLAN tunnel的源目的IP地址。

如果上述流表未下发，需要排查用户终端是否上线，OpenFlow连接是否正常等，请参考上述步骤排查。

如果该状态不正常或不存在openflow instance 1，请先确认防火墙是否放行相应端口，再进入步骤10继续排查。

8.检查用户Session是否在UP下发

转控分离PPPoE业务的下行流量是查找用户Session进行转发的，如果在UP上无法直接Ping通PPPoE终端，则证明OpenFlow流表存在问题。首先，我们需要确认用户终端已在vBRAS（CP）上拿到地址并成功上线。然后，我们可以在UP上使用命令“display openflow instance 1 controller”来判断OpenFlow连接是否正常，当“Connect state”为“Established”状态时是正常状态，其他状态均不正常。同时需要关注字段“Local IP address”和“Controller IP address”，其应该分别为VXLAN tunnel的源目的IP地址。

如果OpenFlow连接不正常或不存在openflow instance 1，请进入步骤10继续排查。

UP上的用户Session由CP通过OpenFlow流表下发给UP，确认OpenFlow连接正常后，我们需要在UP设备上，使用命令“display ppp acces-user vxlan vxlan-id verbose”来查看UP上是否下发了对应的用户终端Session，如下：

在UP的PPP session中我们找到了IP 为12.1.1.1的终端，其VLAN为1500、VXLAN为1500，如果上述Session表项未下发，需要排查用户终端是否上线，OpenFlow连接是否正常，防火墙是否放行相应端口等，请参考上述步骤排查。

如果上述PPP Session已经下发，仍旧无法在UP上Ping通PPPoE终端，请进入步骤8继续排查。

9.排查UP上VSI相关配置是否正确

根据第7步的排查，我们已经找到了PPPoE用户终端对应的OpenFlow流表下发的用户表项，并从该用户表项信息中得知，示例中的终端IP为12.1.1.1，MAC地址为9c06-1b76-5ddd，其应该携带VLAN1500的标签进入VXLAN 1500。故而首先我们需要根据现场情况确认PPPoE终端在OLT上携带什么VLAN标签上到UP，以及UP上对应的配置是否下发正确。

此处我们可以通过抓包和流统等手段确认PPPoE终端携带了什么VLAN标签从OLT发送至UP，这里不再赘述。

关于UP上的配置，首先我们可以通过命令“display l2vpn mac-address”来查看该PPPoE终端从UP的哪个物理接口上来：

从上述步骤中可以得知终端“9c06-1b76-5ddd”从VSI实例“VBRASSO_UP2_1500”的Link ID为0的接口上来，我们可以再使用命令“display l2vpn vsi name VSI实例名 verbose”来查看Link ID具体为哪个物理接口：

从上述步骤中得知了IPTV终端12.1.1.1应该从UP的GE2/2/9.1500口上来，故而可以通过命令“display current-configuration interface GE2/2/9.1500”来确认配置，如下：

我们可以得知该UP的GE2/2/9.1500口上通过命令“vlan-type dot1q vid 1500”匹配外层vlan标签1500，并将此类报文送入vsi实例“VBRASSO_UP2_1500”。我们可以通过命令“display current-configuration configuration vsi”来确认该vsi绑定了哪个VXLAN，如下图标红处，可以得知该实例绑定了VXLAN 1500，完全符合第8步的用户终端Session信息：

     如果确认配置均正确，PPPoE业务仍旧不通，则需要进入第10步排查表项是否学习正确。

     如果VSI相关配置错误，请登录vBRASSO Web页面的【NFV编排/vBRASSO】路径，按照下图标注的步骤，依次进入【服务实例/服务实例名/资源绑定/修改】，找到对应的AC链路，并确认该链路的配置是否正确，如果不正确需要在vBRASSO上修改为正确配置。

       如果UP下行口不存在上述配置，请确认UP的AC资源是否已经超规格。

10.排查l2vpn mac-address和FIB相关表项是否学习正确

在上述步骤中，进入UP的GE2/2/9.1500口并且匹配的外层VLAN（s-vid）为1500的报文会进入到VSI实例“VBRASSO_UP2_1500”里。此时如果PPPoE终端发送DHCP报文上到OLT，OLT理应打上VLAN 2000的标签，送到UP的GE2/2/9.1500口，匹配了s-vid 1500，进入到VSI实例“VBRASSO_UP2_1500”。如果以上配置均正确，且报文已携带正确的VLAN标签进入到UP对应接口，则在UP上输入命令“display l2vpn mac-address vsi VBRASSO_UP2_1500”，能够看到终端的MAC地址，如下图红框处。

如果不能看到该终端的l2vpn mac-address，请首先排查UP业务口下的配置是否正确。配置正确的情况下，仍旧看不到l2vpn mac-address，则需要在该业务口配置流量统计或流镜像功能，确认OLT是否将PPP报文上到UP对应接口，以及PPP报文携带的VLAN标签是否正确。

通过抓包或流量统计方法检查终端PPP报文是否可以正常到达UP。如果终端PPP报文无法到达UP,请排查UP下层网络；如果终端PPP报文携带的VLAN标签不正确，请确认OLT配置；如果终端PPP报文可以到达UP，且能看到l2vpn mac-address，终端PPP用户仍旧无法在UP上Ping通，请使用命令查看UP“display ppp access-user”查看用户Session表项是否生成，同时可以通过命令“display fib ip_address”来查看FIB表是否下发正确。如果Session表项或FIB表生成有问题，可以尝试将该PPPoE终端下线并触发重新认证上线，从而触发OpenFlow流表重新下发用户Session表项。

流镜像或利用MQC进行流量统计的配置方法可参考UP对应型号版本的相关配置指导。

11.检查OpenFlow配置是否下发正确

在UP上使用命令“display current-configuration | begin "openflow instance"来确认openflow实例的配置是否已经下发，如下：

其中最重要的配置为标红的两行，第一行指明了控制器IP和本地IP，这两个IP为OpenFlow连接的IP，必须能够互通，同时这两个IP为VXLAN Tunnel的源目IP。

第二行“active instance”为激活该OpenFlow实例，正常情况下由vBRASSO自动下发。

如果上述配置未下发或有缺失，请在确认网络连通性后，登录vBRASSO Web页面的【NFV编排/vBRASSO】路径，按照下图标注顺序依次点击【资源目录/物理设备/路由器/详情】查看对应UP的运行状态和路由器类型。

如果运行状态不未AVAILABLE，请检查管理IP的连通性及Netconf账号密码的正确性。如果交换机类型不是“VXLAN DP转发节点”，请修改为该类型。

12.沿转发路径排查流量经过的其他设备，确认流量丢弃的位置

沿转发路径排查流量经过的其他设备（服务器网卡或者网络设备），确认流量丢弃的位置，并排查中间链路丢包原因。流量统计和抓包配置方法可参考交换机或vBRAS相关配置指导，如果确认报文未丢弃，可拨打H3C热线电话400-810-0504寻求帮助。如果通过流量统计、抓包、流镜像等方式确认报文丢在某一设备上，则需要在该设备上具体分析，可拨打H3C热线电话400-810-0504寻求帮助。

本案例中经过流统分析发现CR已将报文发送至CDN，故判断为CDN问题。