某局点S7506E下组播接收者无法接收组播视频流的经验案例

device B和device C下的用户无法接收到组播视频流量。

现场有组播的视频业务，经过一系列中间设备后device B和device C下的用户无法接收到组播视频流量，组播采用的是PIM SM的方式。

1、 首先检查配置无误，以Device C的配置为例。

上下行vlan三层接口配置pim sm，全局配置multicast routing，连接终端侧vlan三层接口配置igmp enable。

interface Vlan-interface1910

ip address 10.xxx.xx.222 255.255.255.252

pim sm

#

interface Vlan-interface1911

description link-Device B

ip address 10.xxx.xx.217 255.255.255.252

pim sm

#

multicast routing

#

pim

#

interface Vlan-interface513

ip address 10.xxx.xx.254 255.255.255.0

igmp enable

 2、 检查Pim邻居关系正常且igmp组、rp、bsr信息也正常，可以和前面业务正常设备作对比。

<Device C>dis pim neighbor

 Total Number of Neighbors = 2

Neighbor        Interface           Uptime    Expires    DR-Priority Mode

10.xxx.xx.221    Vlan1910           16:55:46  00:01:38 1           P

10.xxx.xx.218    Vlan1911           00:56:38  00:01:26 1           P

< Device C >dis igmp group

IGMP groups in total: 1

 Vlan-interface513(10.xxx.xx.254):

  IGMP groups reported in total: 1

   Group address   Last reporter   Uptime      Expires

   239.8.8.8       10.xxx.xx.14    16:38:16    00:02:23

检查发现Device C没有sg表项和multicast routing-table表项，而上一跳的Device B上述表项均正常，怀疑组播流到Device B后未正常转发至Device C：

<Device C>dis pim routing-table

 Total 1 (*, G) entries; 0 (S, G) entries

(*, 239.8.8.8)

     RP: 10.xxx.xx.254

     Protocol: pim-sm, Flag: WC

     UpTime: 16:40:47

     Upstream interface: Vlan-interface1911

         Upstream neighbor: 10.xxx.xx.218

         RPF prime neighbor: 10.xxx.xx.218

     Downstream interface information:

     Total number of downstream interfaces: 2

         1: Vlan-interface1910

             Protocol: pim-sm, UpTime: 01:07:48, Expires: 00:02:43

         2: Vlan-interface513

             Protocol: igmp, UpTime: 16:38:17, Expires: - 

3、在Device B部署流量统计，发现组播流量到达Device B后未转发至Device C。

<Device B>dis acl 3333

Advanced IPv4 ACL 3333, 1 rule,

ACL"s step is 5, start ID is 0

rule 10 permit ip destination 239.8.8.8 0

<Device B>display qos policy interface ten 4/0/48

Interface: Ten-GigabitEthernet4/0/48             //与Device C互联

  Direction: Outbound

  Policy: 1

   Classifier: 1

     Operator: AND

     Rule(s) :

      If-match acl 3333

     Behavior: 1

      Accounting enable:

        0 (Packets)

        0 (pps)

< Device B >display qos policy interface ten 6/0/48

Interface: Ten-GigabitEthernet6/0/48             //与业务正常设备互联

  Direction: Inbound

  Policy: 1

   Classifier: 1

     Operator: AND

     Rule(s) :

      If-match acl 3333

     Behavior: 1

      Accounting enable:

        22527 (Packets)

129 ps)

4、进一步收集Device B的诊断信息排查发现有较多IPV4_TTL的softcar丢弃计数和IPV4_TTL丢包，通过wireshark翻译出来发现是组播报文，默认ttl=1的报文会上送CPU处理。

====debug rxtx softcar show chassis 0 slot 6==== 

ID  Type                RcvPps Rcv_All    DisPkt_All Pps  Dyn Swi Hash ACLmax

45  IPV4_TTL            6      370127     165        100  S   On  SMAC 8

The last discarded packet of  IPV4_TTL :

 -----------------------------------------------------

 0000  01 00 5e 08 08 08 14 51 7e 46 34 01 81 00 07 78

 0010  08 00 45 00 05 40 6c a4 00 00 01 11 46 71 0a 83

….

组播源修改ttl后解决。