某广电IPTV高清用户点播失败问题定位分析

发布时间:  2015-06-24 浏览次数:  310 下载次数:  3
问题描述
某广电数据网割接后,经过两天观察,NE40E-X8的博达交换机下挂IPTV用户机顶盒访问点播页面失败,问题出现概率在20%左右。
告警信息
网络中用户侧存在环路导致cisco交换机cpu使用率一直高达99%,同时有大量的DHCP请求报文被透传到NE40E。
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host 00:24:C1:35:37:7A in vlan 908 is flapping between port Fa2/22 and port Gi6/1
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host 00:24:C1:35:37:7A in vlan 908 is flapping between port Gi6/1 and port Fa2/22
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host 00:24:C1:35:37:7A in vlan 908 is flapping between port Gi6/1 and port Fa2/22
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host C8:60:00:DE:6C:F9 in vlan 900 is flapping between port Gi6/1 and port Fa2/9
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host 00:24:C1:35:3A:38 in vlan 53 is flapping between port Gi6/1 and port Fa2/27
处理过程
3.1 分析NE40E下方的cisco交换机
在问题出现期间,发现cisco交换机cpu使用率长时间处于99%状态,且交换机上有MAC地址漂移现象,从这些现象可以看出cisco交换机下的网络中可能存在环路或者有仿冒MAC攻击,由于是IPTV用户,基本排除是仿冒MAC攻击问题。在出现二层环路的情况下广播报文会被大量重复转发,这会对业务产生影响。
Cisco交换机上看到的MAC地址漂移:
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host 00:24:C1:35:37:7A in vlan 908 is flapping between port Fa2/22 and port Gi6/1
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host 00:24:C1:35:37:7A in vlan 908 is flapping between port Gi6/1 and port Fa2/22
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host 00:24:C1:35:37:7A in vlan 908 is flapping between port Gi6/1 and port Fa2/22
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host C8:60:00:DE:6C:F9 in vlan 900 is flapping between port Gi6/1 and port Fa2/9
1d06h: %C4K_EBM-4-HOSTFLAPPING: Host 00:24:C1:35:3A:38 in vlan 53 is flapping between port Gi6/1 and port Fa2/27

Cisco交换机上cpu和接口接收报文异常:
LZ_GDJ_C4506_1#show processes cpu
CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   1          84      2306         36  0.00%  0.00%  0.00%   0 Chunk Manager   
   2      557612  20098031         27  0.00%  0.00%  0.00%   0 Load Meter      
   3       67516    250464        269  0.00%  0.00%  0.00%   0 SpanTree Helper 
   4           0         1          0  0.00%  0.00%  0.00%   0 Deferred Events 
   5   151250016  16495028       9169  0.00%  0.13%  0.15%   0 Check heaps     
   6        1076      3020        356  0.00%  0.00%  0.00%   0 Pool Manager    
   7           0         2          0  0.00%  0.00%  0.00%   0 Timers          
   8           0         2          0  0.00%  0.00%  0.00%   0 Serial Backgroun
   9       10968   1675970          6  0.00%  0.00%  0.00%   0 IPC Dynamic Cach
  10           0         1          0  0.00%  0.00%  0.00%   0 IPC Zone Manager
  11     1061572  99851081         10  0.00%  0.00%  0.00%   0 IPC Periodic Tim
  12      660124  99850876          6  0.00%  0.00%  0.00%   0 IPC Deferred Por
  13           0         1          0  0.00%  0.00%  0.00%   0 IPC Seat Manager
  14           0         1          0  0.00%  0.00%  0.00%   0 IFS Agent Manage
  15    24718704  65432004        377  0.00%  0.00%  0.00%   0 ARP Input       
  16        1872       940       1991  0.00%  0.00%  0.00%   0 Entity MIB API  
  17           0         1          0  0.00%  0.00%  0.00%   0 SERIAL A'detect 
  18     1223256  99851051         12  0.00%  0.00%  0.00%   0 Dynamic ARP Insp
  19     1407644  25047464         56  0.00%  0.00%  0.00%   0 HC Counter Timer
  20           0         1          0  0.00%  0.00%  0.00%   0 Critical Bkgnd  
  21     4611560 257244962         17  0.00%  0.02%  0.00%   0 Net Background  
  22      374952   3660978        102  0.00%  0.00%  0.00%   0 Logger          
         

GigabitEthernet6/1 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet Port, address is 000e.83a2.6ac0 (bia 000e.83a2.6ac0)
  Description: link_bdcom
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 5/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 21910000 bits/sec, 3678 packets/sec
  5 minute output rate 2584000 bits/sec, 1128 packets/sec
     537892658 packets input, 458594794860 bytes, 0 no buffer
3.2 分析NE40E设备
在问题最初爆发的时候在NE40E设备上查看到大量的DHCP报文被丢弃,说明DHCP报文的接收量已经超过了设备默认的处理速度,后来通过将DHCP报文cp-car值调大才基本不再丢包,但6号中午的时候又出现了DHCP报文丢包,每秒钟丢将近200个,影响到了部分IPTV用户。在设备上通过防攻击溯源命令查看,可以发现不停的在收到这两个DHCP请求报文,这就更能肯定了下面的二层网络中存在环路。
<LZ-D-NE40E-X8-R2>display attack-source-trace slot 4 ver
Info: Please waiting......
  No 1 Packet Info:

  Interface Name    : GigabitEthernet4/1/2
  PeVlanid          : 3924
  CeVlanid          : 327
  Attack Type       : Application apperceive
  Attack Packet Time: 2013-02-05 07:29:20

  L2 Type: Ethernet
    Source Mac   : 00-0a-e6-73-e9-6f
    Dest Mac     : ff-ff-ff-ff-ff-ff
    Ethernet type: 8021Q

  L3 Type: IP
    Version        : 4
    Header Length  : 5 byte
    Type Of Service: 0
    Total Length   : 353
    Identification : 8
    Fragment Offset: 0
    TTL            : 64
    Protocol Num   : 17
    Checksum       : 31109
    Source Ip      : 0.0.0.0
    Dest Ip        : 255.255.255.255     

  L4 Type: UDP
    Source Port  : 68
    Dest Port    : 67
    Header Length: 333 byte
Checksum     : 4550

  No 2 Packet Info: 
Interface Name    : GigabitEthernet4/1/3
  PeVlanid          : 3922
  CeVlanid          : 316
  Attack Type       : Application apperceive
  Attack Packet Time: 2013-02-05 07:29:20

  L2 Type: Ethernet                      
    Source Mac   : 5c-d4-1b-80-00-83
    Dest Mac     : ff-ff-ff-ff-ff-ff
    Ethernet type: 8021Q

  L3 Type: IP
    Version        : 4
    Header Length  : 5 byte
    Type Of Service: 0
    Total Length   : 576
    Identification : 0
    Fragment Offset: 0
    TTL            : 64
    Protocol Num   : 17
    Checksum       : 30894
    Source Ip      : 0.0.0.0
    Dest Ip        : 255.255.255.255

  L4 Type: UDP
    Source Port  : 68
    Dest Port    : 67
    Header Length: 556 byte
    Checksum     : 23536

结合上面的分析,可以说明是由于网络中的环路导致DHCP报文被疯狂广播,影响设备上的业务运行。在cisco设备上PPPoE用户和IPTV用户在同一个VLAN中,由于DHCP报文是广播报文,在交换机上会被广播,占用更多资源,相应的受到的影响也更大;而PPPoE用户只有在上线时的第一个请求报文是广播,其他的都是单播报文。另外对于PPPoE用户猫在拨号的时候如果上线失败会不停的重复拨号,直到上线成功,而IPTV用户拨号几次失败后需要重新开关机顶盒,这样IPTV用户对接入失败也更明显。
根因
NE40E-X8下挂一台cisco 交换机出现环路,导致正常的IPTV机顶盒注册数据包丢失,导致20% IPTV用户无法进行视频点播
解决方案
根据出现异常的用户的信息找出网络中的环路位置。并在出现环路的网络设备上,关闭环路接口

END