现场拓扑如下图，组播源直连在设备的G1/0/1接口，组播接收者直连在设备的G1/0/2接口，组播源的网关为设备上的interface vlan 203接口，组播接收者的网关为设备上的interface vlan 201接口。
问题描述
如上连接拓扑，经过组播业务测试发现，组播源和组播接收者在同一个vlan，组播源和组播接收者IP同网段时，进行二层组播测试正常，但是跨了三层以后，组播接收者无法接收组播视频。
过程分析
（1）查看组播组注册情况，有相应终端的IGMP注册信息：
[H3C]dis igmp group
IGMP groups in total: 3
Vlan-interface201(172.18.0.1):
IGMP groups reported in total: 3
Group address Last reporter Uptime Expires
224.2.2.9 172.18.0.34 00:03:29 00:04:17 //172.18.0.34为测试终端
224.2.2.17 172.18.2.0 00:00:31 00:04:19 //172.18.2.0为测试的电视，该终端地址掩码为22位
239.255.255.250 172.18.1.241 00:03:35 00:04:19
（2）查看组播路由表项，发现组播源无法加表，组播路由表项无法看到上行接口，组播流下行接口学习正常。
[H3C]dis pim routing-table
Total 3 (*, G) entries; 0 (S, G) entries
(*, 224.2.2.9)
Protocol: pim-dm, Flag: WC
UpTime: 00:03:30
Upstream interface: NULL
Upstream neighbor: NULL
RPF prime neighbor: NULL
Downstream interface information:
Total number of downstream interfaces: 1
1: Vlan-interface201
Protocol: igmp, UpTime: 00:03:30, Expires: -
(*, 224.2.2.17)
Protocol: pim-dm, Flag: WC
UpTime: 00:00:32
Upstream interface: NULL
Upstream neighbor: NULL
RPF prime neighbor: NULL
Downstream interface information:
Total number of downstream interfaces: 1
1: Vlan-interface201
Protocol: igmp, UpTime: 00:00:32, Expires: -
(*, 239.255.255.250)
Protocol: pim-dm, Flag: WC
UpTime: 00:03:36
Upstream interface: NULL
Upstream neighbor: NULL
RPF prime neighbor: NULL
Downstream interface information:
Total number of downstream interfaces: 1
1: Vlan-interface201
Protocol: igmp, UpTime: 00:03:36, Expires: -
（3）1/0/1口和1/0/2口均是处于STP的Forwarding转发状态的，而且连接组播源的G1/0/1口下有组播包计数：
GigabitEthernet1/0/7
Current state: UP
Line protocol state: UP
Input (total): 124097622173 packets, 169020955287638 bytes
5005 unicasts, 48 broadcasts, 124097617106 multicasts, 0 pauses
（4）查看现场设备配置也并未发现问题：
interface Vlan-interface201 //接收者所在的vlan为201，对应vlan接口下开启IGMP协议
ip address 172.18.0.1 255.255.252.0
igmp enable
#
multicast routing
#
interface Vlan-interface203 //组播源的网关接口下开启PIM路由协议
ip address 10.10.10.1 255.255.255.0
pim dm
（5）经过以上步骤排查后，并未发现什么异常，现场目前主要的问题是，组播源无法加入组播路由表。正常情况下，组播源发包给组播源网关接口上以后，组播路由设备应该就能正常加表了。于是我们进行抓包分析，发现组播源侧，确实发送了许多组播数据报文，但是设备收到后为什么不将组播源地址加表呢？
于是我们继续分析抓包报文中的内容，发现组播源发送的所有组播报文中，携带的TTL数值均为0。由于TTL数值，每经过一个三层设备转发，都会进行减1操作，当三层设备收到TTL值为0的报文时，会将报文直接进行丢弃，进而不再进行处理。
根据分析的情况，协调现场的组播源服务器进行确认发包的TTL数值，发现其设置值确实为0，后续让现场调整组播源的TTL为256后，组播业务正常，组播源加表正常，问题解决。
解决方法
根据分析的情况，协调现场的组播源服务器进行确认发包的TTL数值，发现其设置值确实为0，后续让现场调整组播源的TTL为256后，组播业务正常，组播源加表正常，问题解决。
对于我们日常使用的组播软件，以VLC组播软件为例，在session选项下，新建组播会话时，有个TTL值选项，建议直接配置为较大值256使用。
