关于组播的DR的工作原理与故障排查思路

关于组播的DR的工作原理与故障排查思路 1, 问题描述： 我们一台CPE MP1803路由器作为客户的CE路由器，PC发了IGMP report以后，我们路由器会在IGMP表项里写上该组播组，但是客户那里说上游的Huawei PE设备没有收到我们设备的PIM JOIN报文而最终不能将组播流量引下来。 经过排查，发现客户在同一个局域网中有多个CPE, 而且我们的MP1803不是DR. 所以这就是为什么客户开了debug以后不能在我们路由器的上游接口抓到PIM JOIN报文误认为是我们路由器的问题。 当时建议客户把局域网断开，然后直接用PC接到MP1803的LAN口上面，这个时候PC组播正常工作。 问题找到。下面就是关于局域网DR的工作原理展开论述和实验。 2, 组播DR的工作原理. PS : 在看该文档前，需要回忆IGMP的工作原理，还有组播客户端如果加入到RP的公共原理部分。详细细节可以参考文档: 一份极强的CCIE笔记 . CISCO CCIE routing and switching Kakas Note Author: 房智勇个人理解: 现在我对DR的理解是，如果一个局域网有多个路由器同时做上联，那么在show ip pim neighbor的时候，对于局域网也会选举一个DR出来。 当客户端在发送IGMP report报文的时候，和PC的默认网关没有关系，IGMP report会发送到所有的上游路由器，这个时候只有DR接收到了下游的PC的IGMP report以后才会重新封装PIM的join 报文送到RP去加入. 而对于另外一台非DR的设备,当他收到了IGMP report以后，他只会在自己的IGMP表里面记录该主播组，但是他不会向RP去发送PIM join报文，所以如果有人说，这个路由show ip pim mroute group x.x.x.x 状态怎么是NOT JOINED, 那么需要看该路由器对于局域网到底是否是DR.如果不是DR那么这个现象是正常的,也应该这样.还有就是如果本台路由器发送了PIM JOIN以后，那么在本台设备上面show ip pim mroute应该可以发现期望组播组的(*,G)表项，然后再看上游路由器，也应该有(*,G)才对，因为我们是往上面送了的.如果我们发了上面也有(*,G),那么就应该核查上面的路由器组播是否正常工作这里又引出一个问题，在同一个局域网，只有DR才转发主播流量，才发送PIM JOIN报文，那么如果主播组多的情况下，对局域网的DR是否也是一个性能考验呢？ 那肯定是是的。 所以在设计网络的时候，如果局域网的主播组需求量很大的话，那么CPE路由器一定要用性能高一点的设备来做，否则的话很有可能因为性能引起瓶颈问题。 我对协议的建议: MP1800-D(config-if-fastethernet0)#ip pim dr-priority 200 ? MP1800-D(config-if-fastethernet0)#ip pim dr-priority 200 Q:你看这里都是基于接口来做的，但是我想对224.1.1.1 R1作为DR,224.1.1.2 R2作为DR,来达到一个负载均衡的功能，这样可以做吗？ A:我觉得真的还算是一个需求，如果一次我有20个主播组需要运行，每个都是高清视频流，那不是对CPE的要求很高才能行吗？每个高清按照4M来算，都是100M的高清。本来4个1800就可以，现在非要3个MP1800加上一个2824才能做这个事情，而且还不能做到备份。换言之是需要4个2824才能完全做热备，否则主2824瘫了，那么任何一个1800都会瘫痪，因为一个1800不能达到100M高清视频流量的线速转发. 3, CCIE学习笔记上面关于这个软件模块的描述.(关于重点我用红色进行标注)-下面都是CISCO的原理，命令输出可能略有不同，原理相同，可以参考. 上面就是PIM JOIN报文的报文格式.Neighbor Discovery 邻居发现 路由器通过周期性的查询（缺省 30 秒）来发现 PIM 邻居路由器的存在，对于多路访问网络， 这种查询消息发现 224.0.0.2（All-Routers）。对于多路访问网络，还要选举 DR，IP 地址最高的路由器成为 DR。在疏模式中，DR负责为多路访问网段上的主机向 RP 发送 Join 消息，在密模式中，DR 的选举没有意义。 上图中显示的是 show ip pim neighbor 命令的输出，我们可以清楚的看到上面五条记录中的路由器和这台路由器同属于一个多路访问网络，171.68.0.91 因为有最高的 IP 地址而成为DR。4, 实验拓扑： 关于实验拓扑图解释： 在这个拓扑中，Multicast client 3.1.1.2,他的默认网关是MP1800-D, 这里向说明的问题是，主播发的请求和单播的默认IP网关是没有关系的，所以最后我们可以发现，假设3.1.1.2发出的IGMP REPORT请求224.1.1.10出去，实际上是MP1800-U路由器帮忙发送的PIM JOIN报文上去，也是MP1800-U路由器show ip pim mroute可以看到(*,G)表项的状态是JOINED 的状态。最后也是MP1800-U路由器转发的主播流量. 5，各个设备的配置： MP2800: ip multicast-routinginterface loopback0 ip address 10.10.10.10 255.255.255.255 ip pim sparse-mode exitinterface fastethernet1.10 ip address 1.1.1.2 255.255.255.0 encapsulation dot1q 10 ip pim sparse-mode exitinterface fastethernet1.20 ip address 2.1.1.2 255.255.255.0 encapsulation dot1q 20 ip pim sparse-mode exit router ospf 1 network 0.0.0.0 255.255.255.255 area 0 exitip pim rp-address 10.10.10.10 MP1800-D:ip multicast-routinginterface fastethernet0 ip address 3.1.1.1 255.255.255.0 ip pim sparse-mode exitinterface fastethernet1.10 ip address 1.1.1.1 255.255.255.0 encapsulation dot1q 10 ip pim sparse-mode exit router ospf 1 network 0.0.0.0 255.255.255.255 area 0 exitip pim rp-address 10.10.10.10 MP1800-U: ip multicast-routing interface fastethernet0 ip address 3.1.1.3 255.255.255.0 ip pim sparse-mode exitinterface fastethernet1.20 ip address 2.1.1.1 255.255.255.0 encapsulation dot1q 20 ip pim sparse-mode exit router ospf 1 network 0.0.0.0 255.255.255.255 area 0 exitip pim rp-address 10.10.10.10 6, 实验过程： 这里再看着拓扑图来说明情况. 下游PC的单播IP网关是MP1800-D, 3.1.1.1. 这个时候在3.1.1.2 PC客户端上运行VLC等组播软件，期望组播组为224.1.1.10. 按照刚才我们了解的原理部分应该得到下面的结论： 首先确定MP1800-D和MP1800-U哪个设备是组播局域网的DR. 这里可以看到我登录在MP1800-D上面的，本机的LAN是3.1.1.1， 局域网中3.1.1.2是DR.所以注定了我们设备是不会发送PIM JOIN到RP,也不会引组播流量下来的。 当客户端发送了IGMP reprot报文以后，MP1800D上面.show ip igmp groups. 应该可以看到224.1.1.10的表项. 但是MP1800-D不会向上游的RP发送PIM JOIN. 下面是相关的debug报文，我们找不到任何关于FE1.10发送PIM报文的表项. (224.1.1.10,送到RP 10.10.10.10)MP1800-D# 03:06:26: PIM-SM: PIM Hello from 3.1.1.3 on fastethernet0 03:06:26: PIM-SM: Recv Hello message 03:06:26: PIM-SM: Holdtime: 105 03:06:26: PIM-SM: T-bit: off 03:06:26: PIM-SM: Lan delay: 1 03:06:26: PIM-SM: Override interval: 3 03:06:26: PIM-SM: DR priority: 1 03:06:26: PIM-SM: Gen ID: 30973 03:06:26: PIM-SM: Restarting NLT for neighbor 3.1.1.3 on fastethernet0 with 105 secs timeout from Hello message 03:06:26: PIM-SM: DR is 3.1.1.3 03:06:28: PIM-SM: Recv (*, 224.1.1.10) Include on fastethernet0 03:06:28: PIM-SM: Apply (*, 224.1.1.10) Include on fastethernet0 03:06:28: PIM-SM: Nexthop 10.10.10.10: Increment refcnt 2 03:06:36: PIM-SM: Scanning PIM-SM IPv4 Next Hop Cache. 03:06:39: PIM-SM: Hello Timer expired on fastethernet0 03:06:39: PIM-SM: Restarting Hello Timer on fastethernet0 with 30 secs timeout 03:06:39: PIM-SM: Stopping Triggered Hello Timer on fastethernet0 03:06:39: PIM-SM: Hello send to fastethernet0 03:06:39: PIM-SM: Send Hello message 03:06:39: PIM-SM: Holdtime: 105 03:06:39: PIM-SM: T-bit: off 03:06:39: PIM-SM: Lan delay: 1 03:06:39: PIM-SM: Override interval: 3 03:06:39: PIM-SM: DR priority: 1 03:06:39: PIM-SM: Gen ID: 414 03:06:42: PIM-SM: Hello Timer expired on fastethernet1.10 03:06:42: PIM-SM: Restarting Hello Timer on fastethernet1.10 with 30 secs timeout 03:06:42: PIM-SM: Stopping Triggered Hello Timer on fastethernet1.10 03:06:42: PIM-SM: Hello send to fastethernet1.10 03:06:42: PIM-SM: Send Hello message 03:06:42: PIM-SM: Holdtime: 105 03:06:42: PIM-SM: T-bit: off 03:06:42: PIM-SM: Lan delay: 1 03:06:42: PIM-SM: Override interval: 3 03:06:42: PIM-SM: DR priority: 1 03:06:42: PIM-SM: Gen ID: 15118 MP1800-D#no debu all 在MP1800-U上面，show ip igmp groups应该可以看到224.1.1.10的表项。在MP1800-U上面，如果debug ip pim all的话，应该可以看到1800-U的FE1.20接口向上面送PIM JOIN报文到RP. 下面是MP1800-U上面，debug ip pim all的内容，可以发现FE1.20是发送了PIM JOIN报文到RP 10.10.10.10的。MP1800-U# 03:14:50: PIM-SM: Recv (*, 224.1.1.10) Include on fastethernet0 03:14:50: PIM-SM: Apply (*, 224.1.1.10) Include on fastethernet0 03:14:50: PIM-SM: Nexthop 10.10.10.10: Increment refcnt 2 03:14:50: PIM-SM: JoinDesired(*,G) => TRUE event for (*, 224.1.1.10) 03:14:50: PIM-SM: MRIB.next_hop_rp(10.10.10.10): nexthop 2.1.1.2 03:14:50: PIM-SM: Send Join/Prune message 03:14:50: PIM-SM: Upstream: 2.1.1.2 (Family 1, Type 0) 03:14:50: PIM-SM: Rserved: 0 03:14:50: PIM-SM: Num groups: 1 03:14:50: PIM-SM: Holdtime: 210 03:14:50: PIM-SM: Multicast group: 224.1.1.10/32 (Fa