][override]group-list :
指定组X围,缺省为224.0.0.0/4,这是很危险,因为它把 Auto-RP 多播组<224.0.1.39和 224.0.1.40>也包括进来了,注意这两个多播组是使用密模式进展维护的.所以我们至少应该使用访问列表将这两个组排除.
override :
参数指示静态配置优先于Auto-RP 学得的内容.
[例如]
host1#access-listboston
host1#ippimrp-address122.0.0.11boston
静态 RP 的配置比拟容易理解,但是管理工作量很大,由于没有冗余能力,可靠性也不强,不适于在大的网络中使用.为了保证RP的有效性,防止网络因为失效导致网络切换至密集模式,我们可以指定静态RP,但是为了防止静态RP阻碍Auto-RP协议的运行,必须与访问列表相结合使用.如下例:
ippimrp-address10
access-list10deny224.0.1.39
access-list10deny224.0.1.40
access-list10permitany
[例如]
host1#access-list11permit224.0.1.39.0
host1#access-list11permit224.0.1.40.0
host1#ippimrp-address192.48.1.2211override
2.2.4PIM-SM自动RP
除了Candidate RPs
Candidate RPs和MappingAgents路由器通过专用的两个多播地址224.0.1.39和224.0.1.40以PIMDM<否如此在Chicken and Egg 问题>方式传递RP 相关信息.网络中可以存在多个RP 以作备份,可以通过管理X围对消息的传递加以限制,BSR 不个备这一功能,这一功能对减少多播信息对广域网带宽的占用非常有效.
●CandidateRPs
RP 候选者以固定周期向 224.0.1.39 组播地址送 RP-Announcement 消息,这个消息用来说明该路由器是一个RP 候选者,rp-announce-interval 的缺省值为60s.RP 声明中包括:
组X围<缺省为224.0.0.0/4>、候选RP 的地址,保持时间缺省为三分钟,即三倍的rp-announce-interval.
在全局模式下以下述命令设置:
ippimsend-rp-announcescope[group-listacl].
Interface:
用于指定RP 声明中的源地址取自哪个接口.
Group-list:
其中的Deny 在不同的IOS 版本中意义不同,12.0<1.1>以前的版本中表示当前路由器不是相应组X围的候选RP,12.0<1.1>以后版本中表示该组X围永远采用密模式.
[例如]
host1#access-list1deny224.0.1.39
host1#access-list1de
ippimsend-rp-announceloopback2scope16group-list1
●MappingAgents
用于接收发自 Candidate RPs 的声明,自动参加224.0.1.39 这个多播组.所有声明存储在缓存中,为每个特定组X围选举具有最高IP 地址的候选者作为RP.我们可以通过showippimrpmapping 命令来查看MA 的缓存.[注意:
所有MA 的缓存内容必须一致.]向地址发送Cisco-Discovery 消息,每60 秒或检测到变化时发送.消息中包含从多个候选者中选出的RP.可以通过如下命令设置:
ippimsend-rp-discovery[]scope.
Interface:
用于指定消息包源地址取自哪个接口,如果不设置,源地址为送出接口,这样将会导致一个MA以多个地址出现.所有其它路由器自动参加224.0.1.40 以接收Cisco-Discovery消息.通过接收Cisco-Discovery消息以确定负责特定组的RP.
[例如]
ippimsend-rp-discoveryscope23loopback1
通常一个网络中应该至少设置两个C-RP 和MA,一台路由器可以同时担当这两种角色.Intfc最好使用回环接口来定义.需要支持多播的每台路由器的每个接口下都应该配置成疏密模式,因为Auto-RP 采用密模式 PIM 工作,其它多播数据采用稀疏模式工作.
Auto-RP可以采用冗余模式,在冗余模式中,是通过比拟相应端口的IP地址大小来实现的,通常是做法是对于主RP配置较高IP地址的Loopback接口,而对于冗余RP如此采用较小的IP地址作为Loopback接口.
●自动RP控制
Auto-RP 声明和发现消息中的 TTL 的值设成多大适宜?
这个跟网络结构有关,只要保证所有的MA/C-RPs 都可以收到来自 C-RPs/MA 的消息就可以了.不妨把 TTL 值设得大一些,我们可以在网络边界使用 ipmulticastboundary 的命令来限定 Auto-RP 多播信息的传递,如如下图.
为了防止不正确的配置导致 RP 信息的不一致,可以通过 ippimaccept-rp 命令对可承受 RP 进展限制,命令用法如下:
Ippimaccept-rp[acl]
Ippimaccept-rpauto-rp[acl]
Ippimaccept-r.0[acl]
Auto-rp 和 .0 只能设置一条,acl 如果省略掉如此表示 224.0.0.0/4.
[例如]
ippimaccept-rp172.17.1.13
对 RP 的限定可以用来控制组模式,只有通过 RP 验证的组才可以使用稀疏模式.也可以用来限定哪些<*,G>的参加消息是可承受的,还可以用来限定哪些注册消息是可承受的.此外,我们可以在 MA 中使用 RP 过滤来验证 RP 候选者的有效性,进而控制 RP.命令如下:
ippimrp-announce-filterrp-list[group-list]
rp-list 和 group-list 分别用来指定哪些 C-RP 和多播信息是可以承受的.
[注意]group-list 如果不指定表示不承受一切组.
[例如]
ippimrp-announce-filterrp-list1group-list2
access-list1permit.1
access-list1permit.2
2.2.5PIMv2BSR模式
多个C-BSR<引导路由器候选者>通过选举优先级和IP 地址最高者为活动BSR,这个选举过程是抢先式的.活动BSR 根据C-BSR 的优先级随时变化,作为接收者的AllOtherRouters在 AcceptAny 和AcceptPreferred 两种状态中改变.BSR通过以下命令设置:
ippimbsr-candidate [priority ]
:
指定hash mask 的长度,这一长度决定了RP 服务于多播组的X围有多大.
Priority:
定义了当前BSR的优先级,优先级缺省等于0.
[例如]
ippimbsr-candidateethernet0/0192
2.3监控调试PIM
2.3.1showippimneighbor
Uptime 显示毗邻关系存在的时间
Expires 显示条目过期前的剩余时间,周期性的PIMHello 消息用来刷新这条记录.
Mode 显示接口下PIM的模式:
Dense,SparseorSparse/Dense.
2.3.2showippiminterface
NbrCount 显示该接口连接网络中邻居的数量.
DR=.0 说明该接口所连接的是P2P网络,不存在DR.
2.3.3showiprpf
上图中显示了两条RPF 信息,这些信息都是基于单播路由表形成的.关于每一个多播源和RP路由器都有相关条目,记录RPF接口,上游路由器,相关路由等信息.
2.3.4showiproute
不要忘了,多播的转发决断依赖于单播路由表<如RPF检验>,所以在我们调试多播路由时经常检验单播路由的正确性同样重要.
2.3.5showipmroute
这是一个多播路由表的一局部,同其它的多播路由表一样,其中包含<*,G>和 条目,每个条目下会有流入接口,OIL流出接口列表,RP<如果存在的话>,标志位和Uptime/Expires计时器.此外还有showipmroutesummary 和showipmroutecount 两条命令没有列出示例.分别用于查看多播路由表每个条目的汇总信息和统计信息.
2.3.6showipmrouteactive
显示当前活动的源<流量大于某个门限值,缺省为4K> 其中包含组地址,会话名称,组播源地址,域名称以与带宽占用情况.
2.3.7showippimrpmapping
这条命令是关于PIMSparseMode 的.
RP 可以被自动发现,也可以被手工设置.
RP 在一个多播网络中可以存在多个,并且可以基于组播地址X围进展转发分工.
2.3.8debugipmpacket
用来解码多播包,这是一条轻易不要用的命令,特别是当有较大多播流量通过路由器时,会加大路由器负载,并且大量信息输出无法过滤
2.3.9debugipmroute
2.3.10debugippim
用来查看PIM 邻居之间的消息交换,图中显示该路由器通过E0和E1口向外发出 PIM 路由器查询,但只在E0口上收到了来自 172.16.6.1 的回应.
现在看到的还是 debugippim 的输出,记录的是此路由器向RP<172.16.8.1>发送注册消息并收到RP 发回的RP-Reachable 消息.
2.3.11mtrace/mstat命令
mtrace 命令的工作方式很特殊,让我们通过下面的图来进展解释:
上图中,绿色箭头表示从源到接收者的多播流传递路径,红色箭头表示mtrace包传递的路径.mtrace 采用专用的IGMP 包类型,0x1F表示查询/请求,0x1E 表示响应.查询/请求包发往与接收者相邻的末跳路由器,末跳路由器将它转为单播的traceroute 请求,按单播路由上溯到与源相邻的首跳路由器,在此过程中,每个经由的路由器都将查询到达时间、流入接口、流出接口、上一跳路由器地址、输入输出包计数、源/组包计数、路由协议、TTL 门限值以与转发/错误码等信息记入包中.首跳路由器参加自己的响应数据后将单播 traceroute 信息包转换为mtrace 类型送回查询主机.类似于单播的traceroute 命令,mtrace 也显示多播信息的转发路径与各段延时.可以用它来查找多播信息传递过程中的中断点,也可以用它来发现次佳路由.
上图显示的是mtrace 命令的输出示例,其中显示了多播数据包传递时经由的路径与每一跳的时延.
mstat 命令以图形的方式输出多播转发路径,可用于分析网络中任意两点间的多播信息转发情况,报告显示每个节点丢弃/重复包的数量以与TTL 值和延时.主要用于在网络中查找存在大量包丢弃或包复制的节点.