IPTV组播故障处理案例

jaym

故障现象：在调试高新E320的IPTV组播过程中，正确配置完组播信息后，组播无法引导到BAS上。故障处理步骤：1）、检查组播有无启动BAS（config）#show ip multicast routingMulticast forwarding is enabled on this router结果显示正常2）、检查pim的neighbour情况用show ip pim neighbour可以看到BAS #show ip pim neighbor PIM Neighbor TableNeighbor Addr   Interface Name   Uptime     Expires  Ver Mode61.130.123.193  GigabitEthernet12/0/0.52 3w3d22:13:37 00:01:19 2   Sparse结果正常3）、检查RP的配置BAS #show ip pim rp mappingPIM Group-to-RP mappingsGroup(s) 233.18.205.0/24  RP 220.191.138.18, priority 0, via Static, from access-list 88Group(s) 233.18.206.0/24  RP 220.191.138.18, priority 0, via Static, from access-list 88Group(s) 233.18.207.0/24  RP 220.191.138.19, priority 0, via Static, from access-list 99Group(s) 233.18.208.0/24  RP 220.191.138.18, priority 0, via Static, from access-list 88结果显示正常。经过以上三步的检查，确定组播的配置应该不存在错误的情况，在BAS的上联设备（NE80E）上无法看到组播下发到BAS上，由于NE80E已经有BAS与其连接，且组播已经正常使用，故判断故障点应该在BAS上，为了便于测试，在BAS上起一个组播的接口，手工加入组播组进行测试，配置如下：nterface gigabitEthernet 16/0/0.50!  vlan id 50 ip address 2.2.2.2 255.255.255.255 ip igmp ip igmp query-interval 100 ip igmp promiscuous on ip igmp immediate-leave ip igmp static-group 233.18.205.101 ip pim sparse-mode检查IGMP情况Show ip igmp interface bri该手工加入的端口也无法加入组播组，考虑到组播是依赖单播路由进行的，当组播数据包到达BAS时，BAS还要做RPF（Reverse Path Forwarding）检查，有可能是路由的不一致引起组播无法下发，故核对组播和单播路由的一致性。A）、先检查单播路由Show ip route 路由的结果如下：  Prefix/Length    Type     Next Hop     Dst/Met         Interface  ---------------------------------------------------- -------------------------------------------0.0.0.0/0    Static  61.130.123.81   1/0        GigabitEthernet16/0/0.52                  61.130.123.85   1/0        GigabitEthernet12/0/0.52这里有2条默认路由，考虑到起pim的时候只起了一个接口，有可能去文广平台的路由选择了没有起pim的接口上，导致RPF检查不成功引起B）、检查组播路由使用的单播路由情况Show ip pim sparese-mode unicast-route无路由条目显示为了确认组播与单播路由是否一致，手工加入一条到组播源的路由，确认单播是从起pim的上联口出去的Ip route 220.191.136.0 255.255.252.0 61.130.123.85此时在检查pim的单播路由情况Show ip pim sparese-mode unicast-route可以看到PIM SM unicast route table informationRoute               RpfNbr         Iif           Pref  Metric---------------------------------------------------------------------------220.191.136.0  /255.255.252.0   61.130.123.85   61.130.123.86   254   0Count of entries: 1此时在检查组播路由情况Show ip mroute                  IP Multicast Routing Table(S, G) uptime d h:m:s[, expires d h:m:s]  [Admission bandwidth: bps]  [QoS bandwidth: bps]  RPF route: addr/mask, incoming interface             neighbor address, owner route-owner  Incoming interface list:      Interface (addr/mask), State/Owner [(RPF IIF)]  Outgoing interface list:      Interface (addr/mask), State/Owner, Uptime/Expires (220.191.137.6, 233.18.205.101) uptime 29 17:11:45  RPF route: 220.191.136.0/22, incoming interface GigabitEthernet12/0/0.52      neighbor 61.130.123.85, owner Netmgmt  Incoming interface list:      GigabitEthernet12/0/0.52 (61.130.123.86/30), Accept/Pim (RPF IIF)  Outgoing interface list:      GigabitEthernet16/0/0.50 (2.2.2.2/32), Forward/Pim, 29 17:11:45/neverCounts: 1 (S, G) entries        0 (*, G) entries加了组播源的地址后，E320上可以看到组播路由已经正常了，组播故障排除，故障原因确定为RPF的检查失败引起组播路由下发失败结论：在排除组播故障时，往往会遗忘RPF的路由，对于组播，如果RPF检查不通过，组播就会失败，从该故障中我们需要注意1）、在起pim时，对0.0.0.0路由经过的接口上最好都起pim的模式2）、在多个上联口时，如果只有一个接口作为pim的接口，则需要加入组播源的IP路由，确保RPF能正常通过。小知识：１）逆向路径转发(Reverse Path Forward: RPF) 当组播数据包到达路由器时，路由器作RPF检查，以决定是否转发或抛弃该数据包，若成功则转发，否则抛弃。RPF检查过程如下： 检查数据包的源地址，以确定该数据包经过的接口，是否在从源到此的路径上； 若数据包是从可返回源主机的接口上到达，则RPF检查成功，转发该数据包到输出接口表上的所有接口，否则RPF检查失败，抛弃该数据包。2）组播转发缓存对于每一个输入组播数据包进行RPF检查会导致较大的路由器性能损失。因此，建立组播转发缓存时，通常由组播路由确定RPF接口。然后将RPF接口变成组播转发缓存项的输入接口。一旦RPF检查程序使用的路由表发生变化，必须重新计算RPF接口；并更新组播转发缓存项。