某运营商网络WEB认证页面弹出过程中偶发性出现大延时问题处理

 某运营商网络WEB认证页面弹出过程中

偶发性出现大延时问题处理

一、   组网：

         某运营商网络中，地市城域网中部署WLAN网络，在大规模使用过程中，用户使用WLAN网络访问公网数据，其中用户网关终结在IAG上，IAG与FW之间起VRRP做网关冗余，FW与NE80之间起OSPF进行三层路由转发，Portal服务器在集团网集中控制。

现网组网图

WX6000E配置说明：

1） 用户数据流从AC板卡二层透传给网关IAG板卡，最终数据流透过FW板卡过NAT出WX6000E设备。

2） 其中AC、交换板起二层转发作用，IAG板卡作为BAS设备起portal重镜像功能。

二、   问题描述：

客户在正常使用WLAN网络的过程中发现，WEB登陆认证时会偶发性的出现弹出portal页面慢的现象，前期认为是无线侧丢包引起的，经过排查后发现无线空口环境干净，不会出现该现象，初步估问题出现在有线侧，需要进一步排查。

三、   问题分析过程：

1.   Portal认证知识点介绍：

1) 整个Portal认证中Portal页面弹出过程的流程图如下：

2) 其中我司设备在这个过程中参与的流程如下（具体参与的见红色方框内）：

a)   其中第一步与第二步，我司设备起到重镜像的作用，回应客户端Portal页面的地址。

b)   其中第三步与第十步，我司设备起到透出数据的作用，将终端访问Portal服务器的报文转发给下一层设备，将Portal服务器回应的报文转发给终端。

2.   问题分析过程：

1)   为了定位问题与客户商量后决定在AC侧新建 SSID，IAG上单独使用公网地址下发给公网地址给测试用户，不过NAT，直接到NE80，服务器指向等和现网一致，然后搭建测试环境。

2)   测试环境搭建后，现场笔记本终端不断弹Portal页面来复现问题，在设备侧做流统计，同时在终端进行抓包分析，具体流统如下实现：

a)   在NE80的下行口（接75E）做双向流统计；

b)   在NE80上行口（接省网）做入方向流统计；

c)   在75E上行口（接NE80）做双向流统计；

d)   在FW与75E内部互联口做双向流统计；

以上流统计和终端抓包同时执行，下图第980行是终端和服务器交互的一个包，45秒后才开始有新的报文交互。

3)   在日常网络使用中也存在丢包

a)   75E交换板流统计情况：

<HZ_ST_H3C7510E_2>dis qos policy interface

  Interface: GigabitEthernet12/0/1

  Direction: Outbound

  Policy: 4

   Classifier: 33

     Operator: AND

     Rule(s) : If-match acl 3333

     Behavior: 3

      Accounting Enable:

        7366 (Packets)   //此处设备发送给NE80上行7366个包

Interface: GigabitEthernet13/0/1            

  Direction: Inbound

  Policy: 4    

   Classifier: 33

     Operator: AND

     Rule(s) : If-match acl 3333

     Behavior: 3

      Accounting Enable:

        6291 (Packets)    //此处设备收到对端NE80发过来6291个包

b)     7FW板流统计情况：

  Interface: Ten-GigabitEthernet11/0/1

  Direction: Inbound

  Policy: 4    

   Classifier: 33

     Operator: AND

     Rule(s) : If-match acl 3333

     Behavior: 3

      Accounting Enable:

        13657 (Packets)  //防火墙入方向数据流上下行两次13657=7366+6291此处说明我们75E正常转发，未丢包。               

  Direction: Outbound

  Policy: 4    

   Classifier: 33

     Operator: AND

     Rule(s) : If-match acl 3333

     Behavior: 3

      Accounting Enable:

        13657 (Packets)

c)   此时现场已经对比NE80上行收到和下行发出的包数量也为7366和6291个包，此处证明NE80也正常，无丢包。

d)   分析终端此时的抓包数据：

上图为终端发出给Portal server包数量为7366，和75E流统、NE80流通数据一致，此处说明上行直到NE80为完全正常无任何丢包：

上图为在终端抓取服务器发送给终端的报文统计为6280个，从NE80下行出方向和75上行入方向流统可以看出报文数为6291个，此处说明可能无线侧丢包11个，无线丢包11个属于正常现象。

上图为统计终端和服务器交互收发包情况，可以看出上行发生了102次重传，下行发送了11次重传，整个过程至少丢包113个，其中下行丢包11个和上面分析可能为11个为无线侧丢掉吻合。从分析中可以看出上行到NE80为无丢包，因此可以确认这102个包丢弃位置为NE80和服务器之间。

3.   最终在省网与集团网之间做统计，发现集团传过来的报文就已经存在丢包，明确问题是由于客户网络本身故障导致的。

四、   解决方法：

客户决定在本地网做portal服务器本地镜像，即在省网内部搭建portal服务器，问题解决。