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

简介:
Technorati 标签:  Hank

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 –Kaka’s 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 ?    <CR> 
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的原理,命令输出可能略有不同,原理相同,可以参考. 
1_thumb[1]_thumb

上面就是PIM JOIN报文的报文格式.

Neighbor Discovery 邻居发现 
路由器通过周期性的查询(缺省 30 秒)来发现 PIM 邻居路由器的存在,对于多路访问网络, 这种查询消息发现 224.0.0.2(All-Routers)。对于多路访问网络,还要选举 DR,IP 地址最高的路由器成为 DR。在疏模式中,DR负责为多路访问网段上的主机向 RP 发送 Join 消息,在密模式中,DR 的选举没有意义。 
 

2_thumb[1]_thumb

上图中显示的是 show ip pim neighbor 命令的输出,我们可以清楚的看到上面五条记录中的路由器和这台路由器同属于一个多路访问网络,171.68.0.91 因为有最高的 IP 地址而成为DR。

4, 实验拓扑: 
3_thumb[2]_thumb

关于实验拓扑图解释: 
在这个拓扑中,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-routing

interface loopback0 
ip address 10.10.10.10 255.255.255.255 
ip pim sparse-mode 
exit

interface fastethernet1.10 
ip address 1.1.1.2 255.255.255.0 
encapsulation dot1q 10 
ip pim sparse-mode 
exit

interface 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 
exit

ip pim rp-address 10.10.10.10 
 

MP1800-D:

ip multicast-routing

interface fastethernet0 
ip address 3.1.1.1 255.255.255.0 
ip pim sparse-mode 
exit

interface 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 
exit

ip 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 
exit

interface 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 
exit

ip pim rp-address 10.10.10.10 
 

6, 实验过程: 
这里再看着拓扑图来说明情况. 
4_thumb[3]_thumb_thumb_thumb

下游PC的单播IP网关是MP1800-D, 3.1.1.1. 
这个时候在3.1.1.2 PC客户端上运行VLC等组播软件,期望组播组为224.1.1.10. 
按照刚才我们了解的原理部分应该得到下面的结论: 
●首先确定MP1800-D和MP1800-U哪个设备是组播局域网的DR. 
 

5_thumb[2]_thumb_thumb_thumb

这里可以看到我登录在MP1800-D上面的,本机的LAN是3.1.1.1, 局域网中3.1.1.2是DR.所以注定了我们设备是不会发送PIM JOIN到RP,也不会引组播流量下来的。 
●当客户端发送了IGMP reprot报文以后,MP1800—D上面.show ip igmp groups. 应该可以看到224.1.1.10的表项. 
 

6_thumb[1]_thumb_thumb_thumb

●但是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的表项。

7_thumb[1]_thumb_thumb_thumb

●在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) =&gt; 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 (Family 1, Type 0) 

03:14:50:  PIM-SM:   Number of Join: 1 
03:14:50:  PIM-SM:   Number of Prune: 0 
03:14:50:  PIM-SM: Join: (*,G) 10.10.10.10/32 (Family 1, Type 0) 
03:14:50:  PIM-SM: US (*, 224.1.1.10): Starting JT timer with 60 secs timeout 
03:14:50:  PIM-SM: US (*, 224.1.1.10): NOT JOINED to JOINED, JoinDesired(*,G) =&gt; TRUE 
MP1800-U# 
 

●在MP1800-D上面,show ip pim mroute groups 224.1.1.10, (*,G)的状态应该是NOT JOINED. 
8_thumb[1]_thumb_thumb_thumb

●在MP1800-U上面,show ip pim mroute groups 224.1.1.10, (*,G)的状态应该是JOINED. 
 

9_thumb[1]_thumb_thumb_thumb

7, 关于DR的调整。 
这里关于哪个路由器是DR,是可以进行调整的。 
找我们的设备上面每个接口的DR优先级都是1, 范围是0-4294967294,越大越优先. 
如果大家的DR优先级都一样的话,那么就比较IP地址在同网段内哪个IP地址大,大的那个会被选为DR. 在我这个实验中,3.1.1.1  和3.1.1.3,明显MP1800-U该选举为DR. 
如果想刻意的修改优先级可以用下面的命令在接口下面改变DR的优先级,这对于网络设计还是有用的: 
 

10_thumb[1]_thumb_thumb_thumb




本文转自 hny2000 51CTO博客,原文链接:http://blog.51cto.com/361531/626812

相关文章
|
1月前
|
存储 运维 分布式计算
面经:HDFS分布式文件系统原理与故障排查
【4月更文挑战第10天】本文深入剖析了HDFS的底层原理和面试重点,包括HDFS的架构(NameNode、DataNode、Secondary NameNode)、文件读写流程、高级特性(快照、Erasure Coding、Federation、High Availability)以及故障排查方法。通过HDFS Shell命令示例,加强理解,并对比了HDFS与其他分布式文件系统的优缺点。掌握这些知识将有助于求职者在面试中脱颖而出,应对HDFS相关技术考察。
35 3
|
Web App开发 域名解析 网络协议
|
2月前
|
SQL 运维 监控
TiDB集群故障排查与恢复
【2月更文挑战第28天】本章将详细探讨TiDB集群故障排查与恢复的方法。我们将介绍常见的故障类型、排查工具与步骤,以及故障恢复的策略与最佳实践。通过本章的学习,读者将能够掌握TiDB集群故障排查与恢复的技术,确保数据库的稳定性和可用性。
|
5月前
|
运维 Kubernetes 网络安全
k8s学习-CKA真题-集群故障排查kubelet
k8s学习-CKA真题-集群故障排查kubelet
131 0
|
7月前
|
运维 Kubernetes Shell
Kubernetes —集群故障排查(Kubectl 、telepresence)
Kubernetes —集群故障排查(Kubectl 、telepresence)
67 2
|
7月前
|
JSON 运维 Kubernetes
Kubernetes集群故障排查—使用 crictl 对 Kubernetes 节点进行调试
Kubernetes集群故障排查—使用 crictl 对 Kubernetes 节点进行调试
109 0
|
10月前
|
存储 缓存 JSON
Kubernetes集群故障排查—审计
Kubernetes集群故障排查—审计
106 1
Kubernetes集群故障排查—审计
|
运维 监控 Java
Elasticsearch 集群故障排查及修复指南
Elasticsearch 集群在运行的过程中,由于各种原因,经常会出现健康问题。比较直观的是:kibana监控、head插件监控显示集群非绿色(红色或者黄色)。
1290 0
Elasticsearch 集群故障排查及修复指南
|
运维 监控 安全
《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》——导读
目前市场上关于Linux运维管理的书籍有很多,但是普遍存在的问题是模式单一,要么只讲基础理论和系统命令,要么侧重粘贴代码,要么介绍软件的安装与配置,这种模式带有很大的实验性质,并没有介绍生产环境中的实战应用和经验技巧。
2651 0