路由表的读法（route print）－－特殊IP地址，单播，组播，广播
Active Routes:&&& Network Destination&&&&&&& Netmask&&&&&&&&&& Gateway&&&&&&&& Interface& Metric1,&&&&&&&&&&& 0.0.0.0&&&&&&&&& 0.0.0.0&& 192.168.123.254&&& 192.168.123.88&&&&&& 12,&&&&&&&&&&& 0.0.0.0&&&&&&&&& 0.0.0.0&& 192.168.123.254&&& 192.168.123.68&&&&&& 13,&&&&&&&&& 127.0.0.0&&&&&&& 255.0.0.0&&&&&&&& 127.0.0.1&&&&&&&& 127.0.0.1&&&&&& 1&&&&&&4,&&&&& 192.168.123.0&&& 255.255.255.0&&& 192.168.123.68&&& 192.168.123.68&&&&&& 15,&&&&& 192.168.123.0&&& 255.255.255.0&&& 192.168.123.88&&& 192.168.123.88&&&&&& 16,&&&& 192.168.123.68& 255.255.255.255&&&&&&&& 127.0.0.1&&&&&&&& 127.0.0.1&&&&&& 17,&&&& 192.168.123.88& 255.255.255.255&&&&&&&& 127.0.0.1&&&&&&&& 127.0.0.1&&&&&& 18,&&& 192.168.123.255& 255.255.255.255&&& 192.168.123.68&&& 192.168.123.68&&&&&& 19,&&& 192.168.123.255& 255.255.255.255&&& 192.168.123.88&&& 192.168.123.88&&&&&& 110,&&&&&&&& 224.0.0.0&&&&&&& 224.0.0.0&&& 192.168.123.68&&& 192.168.123.68&&&&&& 111,&&&&&&&& 224.0.0.0&&&&&&& 224.0.0.0&&& 192.168.123.88&&& 192.168.123.88&&&&&& 112,&& 255.255.255.255& 255.255.255.255&&& 192.168.123.68&&& 192.168.123.68&&&&&& 1& , Default Gateway:&& 192.168.123.254 -------------------------------------------------------
-------------------------======================================================================当前的路由：destination 目的网段&&&&&& mask 子网掩码& interface 到达该目的地的本路由器的出口ip&&& gateway 下一跳路由器入口的ip，路由器通过interface和gateway定义一调到下一个路由器的链路，通
常情况下，interface和gateway是同一网段的&&&& metric 跳数，该条路由记录的质量，一般情况下，如果有多条到达相同目的地的路由记录，路由器会
采用metric值小的那条路由第一条缺省路由：意思就是说，当一个数据包的目的网段不在你的路由记录中，那么，你的路由器该把那个数据包
发送到哪里！缺省路由的网关是由你的连接上的default gateway决定的该路由记录的意思是：当我接收到一个数据包的目的网段不在我的路由记录中，我会将该数据包通过
192.168.123.88这个接口发送到192.168.123.254这个地址，这个地址是下一个路由器的一个接口，这样这个
数据包就可以交付给下一个路由器处理，与我无关。该路由记录的线路质量 1第二条缺省路由：该路由记录的意思是：当我接收到一个数据包的目的网段不在我的路由记录中，我会将该数据包通过
192.168.123.68这个接口发送到192.168.123.254这个地址，这个地址是下一个路由器的一个接口，这样这个
数据包就可以交付给下一个路由器处理，与我无关。该路由记录的线路质量 1第三条本地环路：127.0.0.0这个网段内所有地址都指向自己机器，如果收到这样一个数据，应该发向哪里该路由
记录的线路质量 1
第四条直联网段的路由记录：当路由器收到发往直联网段的数据包时该如何处理，这种情况，路由记录的interface
和gateway是同一个。当我接收到一个数据包的目的网段是192.168.123.0时，我会将该数据包通过192.168.123.68这个接口直接发
送出去，因为这个端口直接连接着192.168.123.0这个网段，该路由记录的线路质量 1
第五条直联网段的路由记录当我接收到一个数据包的目的网段是192.168.123.0时，我会将该数据包通过192.168.123.88这个接口直接发
送出去，因为这个端口直接连接着192.168.123.0这个网段，该路由记录的线路质量 1
第六条本地主机路由：当路由器收到发送给自己的数据包时将如何处理当我接收到一个数据包的目的网段是192.168.123.68时，我会将该数据包收下，因为这个数据包时发送给我
自己的，该路由记录的线路质量 1
第七条本地主机路由：当路由器收到发送给自己的数据包时将如何处理当我接收到一个数据包的目的网段是192.168.123.88时，我会将该数据包收下，因为这个数据包时发送给我
自己的，该路由记录的线路质量 1第八条本地广播路由：当路由器收到发送给直联网段的本地广播时如何处理当我接收到广播数据包的目的网段是192.168.123.255时，我会将该数据从192.168.123.68接口以广播的形势
发送出去，该路由记录的线路质量 1第九条本地广播路由：当路由器收到发送给直联网段的本地广播时如何处理当我接收到广播数据包的目的网段是192.168.123.255时，我会将该数据从192.168.123.88接口以广播的形势
发送出去，该路由记录的线路质量 1第十条组播路由：当路由器收到一个组播数据包时该如何处理当我接收到组播数据包时，我会将该数据从192.168.123.68接口以组播的形势发送出去，该路由记录的线路
质量 1第十一条组播路由：当路由器收到一个组播数据包时该如何处理当我接收到组播数据包时，我会将该数据从192.168.123.88接口以组播的形势发送出去，该路由记录的线路
质量 1第十二条广播路由：当路由器收到一个绝对广播时该如何处理当我接收到绝对广播数据包时，将该数据包丢弃掉
-----------------------------------------------------------------------------必须知道的特殊IP地址
就像我们每个人都有一个身份证号码一样，网络里的每台电脑(更确切地说，是每一个设备的网络接口)都有
一个IP 地址用于标示自己。我们可能都知道这些地址由四个字节组成，用点分十进制表示以及它们的A，B，
C分类等，然而，在总数大约为四十多亿个可用IP地址里，你知道下面一些常见的有特殊意义地址吗？让我来
告诉你吧！
　　一、0.0.0.0
　　严格说来，0.0.0.0已经不是一个真正意义上的IP地址了。它表示的是这样一个集合：所有不清楚的主机
和目的网络。这里的"不清楚"是指在本机的路由表里没有特定条目指明如何到达。对本机来说，它就是一个"
收容所"，所有不认识的"三无"人员，一律送进去。如果你在网络设置中设置了缺省网关，那么Windows系统
会自动产生一个目的地址为0.0.0.0的缺省路由。
　　二、255.255.255.255
　　限制广播地址。对本机来说，这个地址指本网段内(同一广播域)的所有主机。如果翻译成人类的语言，
应该是这样："这个房间里的所有人都注意了！"这个地址不能被路由器转发。
　　三、127.0.0.1
　　本机地址，主要用于测试。用汉语表示，就是"我自己"。在Windows系统中，这个地址...
分享这篇日志的人也喜欢
热门日志推荐
人人最热标签
分享这篇日志的人常去
北京千橡网景科技发展有限公司：
文网文[号··京公网安备号·甲测资字
文化部监督电子邮箱：wlwh@··
文明办网文明上网举报电话： 举报邮箱：&&&&&&&&&&&&
请输入手机号，完成注册
请输入验证码
密码必须由6-20个字符组成
下载人人客户端
品评校花校草，体验校园广场博客访问： 977073
博文数量： 326
博客积分： 3133
博客等级： 中校
技术积分： 3606
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 系统运维
IP组播地址&&&&&&&&&&&
组播协议的地址在IP协议中属于D类地址。D类地址是从224.0.0.0到239.255.255.255之间的IP地址其中224.0.0.0到224.0.0.255是被保留的地址。&
组播协议的地址范围类似于一般的单播地址，被划分为两个大的地址范围，
239.0.0.0—239.255.255.255是私有地址，供各个内部网在内部使用，这个地址的组播不能上公网，类似于单播协议使用的192.168.X.X和10.X.X.X。
224.0.1.0—238.255.255.255是公用的组播地址，可以用于Internet上。&
下面是一些常见的有特殊用途的IP组播地址
224.0.0.0 － Base address
224.0.0.1 － 网段中所有支持多播的主机
224.0.0.2 － 网段中所有支持多播的路由器
224.0.0.4 － 网段中所有的DVMRP路由器
224.0.0.5 － 所有的OSPF路由器
224.0.0.6 － 所有的OSPF指派路由器
224.0.0.7 － 所有的ST路由器
224.0.0.8 － 所有的ST主机
224.0.0.9 － 所有RIPv2路由器
224.0.0.10 － 网段中所有支的路由器
224.0.0.11 － Mobile-Agents
224.0.0.12 － DHCP server / relay agent服务专用地址
224.0.0.13 － 所有的PIM路由器
224.0.0.22 － 所有的IGMP路由器
224.0.0.251 － 所有的支持组播的DNS服务器
224.0.0.9 RIPv2支持组播更新。
224.0.0.22&&IGMPv2使用此地址，这个协议的本意是减少广播，让组员以组播形式通信。
224.0.0.5&&224.0.0.6这两个是ospf协议使用的组播地址。
在broadcast network不论是DR,BDR,DRother,大家发送hello packet的时候目标地址都是AllSPFRouter(224.0.0.5)；DRother向DR,BDR发送DD,LSA request或者LSA UPdate时目标地址是AllDRouter(224.0.0.6)；DR,BDR向DRother发送DD,LSA Request或者LSA Update时目标地址是AllSPFRouter(224.0.0.5)；retransmit的LSA都是unicast,LSA ACK要看是explicit ack(unicast)还是implicit ack(multicast 224.0.0.6)；
组播IP地址与以太网二层MAC地址的映射：
IP组播地址用于标识一个IP组播组。IANA把D类地址空间分配给IP组播，范围从224.0.0.0到239.255.255.255，IP组播地址前四位均为1110。
　　从224.0.0.0至224.0.0.255被IANA保留为网络协议使用。例如：244.0.0.1 全主机组244.0.0.2 全多播路由器组244.0.0.3 全DVMRP路由器组244.0.0.5 全OSPF路由器组。在这一范围的多播包不会被转发出本地网络，也不会考虑多播包的TTL值。
　　地址从239.0.0.0至239.255.255.255作为管理范围地址，保留为私有内部域使用。
　　如下图所示，以太网和FDDI的MAC地址01:00:5E:00:00:00到01:00:5E:7F:FF:FF用于将三层IP组播地址映射为二层地址，即IP组播地址中的低23位放入IEEE MAC地址的低23位。IP组播地址有28位地址空间，但只有23位被映射到IEEE MAC地址，这样会有32个IP组播地址映射到同一MAC地址上。
阅读(10198) | 评论(4) | 转发(2) |
相关热门文章
给主人留下些什么吧！~~
鸪灵: 广域网广播？.....广域网组播，一份数据。
灯泡代表我的心: 在局域网挺有用的！.....以后ＩＰｔｖ也要这么做。
在局域网挺有用的！
广域网广播？
请登录后评论。IP 组播故障排除指南
[an error occurred while processing this directive]
新闻与刊物
商业解决方案
网络解决方案
服务与支持
思科网络技术学院
培训、活动与会议
合作伙伴与代理商
中国：简体中文
TAC中文文档
原文件的链接(英语)
此文档是由人工智能自动翻译系统翻译的,请随时参考。
IP 组播故障排除指南
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
本文描述常见问题和解决方案为IP组播。
本文档没有任何特定的前提条件。
本文不限于特定的软硬件版本。
有关文件规则的更多信息请参见“ Cisco技术提示规则”。
当排除组播路由故障时，最关心是源地址。 组播有反向路径转发检查(RPF检查)的概念。 当组播信息包在接口时到达， RPF过程检查保证此流入的接口是流出的接口由单播路由使用到达组播信息包的来源。 此RPF检查进程防止循环。 除非信息包的来源通过Reverse-Path-Forwarding (RPF)支票，组播路由不转发信息包。 一旦信息包通过此RPF检查，组播路由仅转发基于信息包在目的地地址。
类似单播路由，组播路由有几个可用的协议，例如独立于协议的组播密集模式(PIM-DM)， PIM稀疏模式(PIM-SM)，距离矢量组播路由协议(DVMRP)、组播边界网关协议(MBGP)和组播源发现协议(MSDP)。 案例分析在本文通过排除多种问题故障的进程走您。 您将看到哪些命令如何被用于迅速精确定位问题和了解解决它。 这里列出的案例分析横跨协议是通用的，除了在哪里注释。
此部分提供一个解决方案给IP组播Reverse-Path-Forwarding (RPF)故障的常见的问题。 例如使用此网络图。
在以上图，组播信息包进入路由器75a E0/0从IP地址是1.1.1.1并且发送组队224.1.1.1的服务器。 这通认作为(S， G)或(1.1.1.1， 224.1.1.1)。
主机直接连接到路由器75a接受组播输入，但是主机直接连接到路由器72a不。 首先，请发出show ip mroute 224.1.1.1命令用路由器75a发现怎么回事。 此命令检查组播路由(mroute)为组地址224.1.1.1 ：
75a#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
(1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
因为路由器运行PIM密集模式(我们知道它是密集模式由于D标志位)，请忽略*， G条目和重点在S， G条目。 此条目告诉您组播信息包从地址是1.1.1.1，发送到一个组播组224.1.1.1的服务器被发出。 信息包在Ethernet0/0接口来和转发Ethernet0/1接口。 这是一个完善的方案。
发出show ip pim neighbor命令发现路由器72a是否显示上行路由器(75a)作为PIM相邻：
ip22-72a#show ip pim neighbor
PIM Neighbor Table
Neighbor Address
Ethernet3/1
从show ip pim neighbor命令输出， PIM结邻看起来好。
请使用此show ip mroute命令发现路由器72a是否有好mroute ：
ip22-72a#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
(1.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags:
Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
您能从show ip mroute 224.1.1.1命令看到流入的接口是Ethernet2/0，而Etheret3/1预计。
发出show ip mroute 224.1.1.1计数命令发现任何组播数据流为此组是否到达到路由器72a，并且什么其次发生：
ip22-72a#show ip mroute 224.1.1.1 count
IP Multicast Statistics
3 routes using 2032 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg
Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null,
rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded:
0, Packets received: 471
1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
您能从其他计数看到数据流被撤销由于RPF故障： 共计471下落，由于RPF故障- 471…
发出show ip rpf &source>命令发现是否有RPF错误：
ip22-72a#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet2/0
RPF neighbor: ? (0.0.0.0)
RPF route/mask: 1.1.1.1/32
RPF type: unicast (static)
RPF recursion count: 0
Doing distance-preferred lookups across tables
Cisco IOS ？ 计算RPF接口这样。 RPF信息的可能的来源是单播路由表、MBGP路由表、DVMRP路由表和静态Mroute表。 当您计算RPF接口时，信息源RPF计算根据主要的管理距离被用于正确地确定。 特定规则是：
RPF数据的所有之前的来源在IP原地址被搜索匹配。 当使用共享结构树时， RP寻址使用而不是源地址。
如果超过一个配比的路由被找到，带有最低管理距离使用路由。
如果管理距离是相等的，则使用此优先级顺序：
静态mroutes
如果多个条目为路由在同一个路由表之内发生，使用最长匹配路由。
show ip rpf 1.1.1.1命令输出显示RPF接口是E2/0，但是流入的接口应该是E3/1。
发出show ip route 1.1.1.1命令发现RPF接口为什么是与什么不同预计了。
ip22-72a#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Ethernet2/0
Route metric is 0, traffic share count is 1
您能从此show ip route 1.1.1.1命令输出看到有一个静态/32路由，做错误接口将被选择作为RPF接口。
发出一些进一步debug命令：
ip22-72a#debug ip mpacket 224.1.1.1
*Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 len 60, not RPF interface
*Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 len 60, not RPF interface
*Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 len 60, not RPF interface
*Jan 14 09:45:33.120: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 len 60, not RPF interface
信息包在E3/1进来，是正确的。 然而，他们被丢弃，因为那不是单播路由表使用RPF检查的接口。
注意： ？调试信息包是危险的。 Pakcet调试触发组播pakcets的流程转换， CPU加强。 并且，信息包调试能生成能完全地悬挂路由器由于缓慢的输出到控制台端口的巨大的输出。 Befor必须使用调试信息包，特别注意禁用操作日志输出到控制台，并且启用记录到存储器缓冲区。 为了达到此，请配置no logging console和操作日志缓冲调试。 调试的结果能用show logging命令被看到。
您能或者更改单播路由表满足此要求或您能添加一静态mroute驱逐组播对RPF特殊接口，不管什么单播路由表陈述。 添加一静态mroute ：
ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1
此静态mroute声明那有地址1.1.1.1，为RPF，使用2.1.1.1作为下一跳，接口E3/1。
ip22-72a#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet3/1
RPF neighbor: ? (2.1.1.1)
RPF route/mask: 1.1.1.1/32
RPF type: static mroute
RPF recursion count: 0
Doing distance-preferred lookups across tables
show ip mroute和debug ip mpacket的输出看似好，被发送的信息包的数量在show ip mroute count增加，并且玉簪属植物收到信息包。
ip22-72a#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00
Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00
(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA
Incoming interface: Ethernet3/1, RPF nbr 2.1.1.1, Mroute
Outgoing interface list:
Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00
ip22-72a#show ip mroute 224.1.1.1 count
IP Multicast Statistics
3 routes using 2378 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019
Source: 1.1.1.1/32, Forwarding: /0, Other:
ip22-72a#show ip mroute 224.1.1.1 count
IP Multicast Statistics
3 routes using 2378 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026
Source: 1.1.1.1/32, Forwarding: /0, Other:
ip22-72a#debug ip mpacket 224.1.1.1
*Jan 14 10:18:29.951: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 (Ethernet3/2) len 60, mforward
因为存活时间(TTL)值消耗到零，此部分提供一个解决方案给IP组播信息包常见的问题不转发的。 尽管有许多组播appplications，这是常见的问题。 这些组播应用设计主要为LAN使用方法和因而设置TTL到低值甚至1。 例如请使用此网络图。
在以上图，路由器A不转发信息包从来源到路由器B的直接连接的接收器。 查看show ip mroute命令的输出在路由器A发现组播路由状态：
ROUTERA#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00
(*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00
因为所有路由器参加此自动RP发现组，您在以上输出中能忽略224.0.1.40。 但是没有为224.1.1.1列出的来源。 除之外“*， 224.1.1.1"您应该看到"1.1.1.1， 224.1.1.1"。
发出show ip rpf命令发现它是否是Reverse-Path-Forwarding (RPF)问题：
ROUTERA#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet0/0
RPF neighbor: ? (0.0.0.0) - directly connected
RPF route/mask: 1.1.1.0/24
RPF type: unicast (connected)
RPF recursion count: 0
Doing distance-preferred lookups across tables
从以上输出，您看到它不是RPF问题。 RPF检查正确地指出E0/0达到IP原地址。
证实PIM是否在接口被配置使用show ip pim interface命令：
ROUTERA#show ip pim interface
Version/Mode
Count Intvl
Ethernet0/0
v2/Sparse-Dense
Ethernet0/1
v2/Sparse-Dense
输出看似好，因此这不是问题。 证实路由器是否使用show ip mroute active命令认可任何有效数据流：
ROUTERA#show ip mroute active
Active IP Multicast Sources - sending &= 4 kbps
根据上述输出，路由器不认可任何有效数据流。
ROUTERA#debug ip mpacket
IP multicast packets debugging is on
或许接受器不发送任何互联网组管理协议(IGMP)报告(加入)为第224.1.1.1组。 您能使用show ip igmp group命令检查它：
ROUTERB#show ip igmp group
IGMP Connected Group Membership
Group Address
Last Reporter
224.0.1.40
Ethernet1/1
Ethernet1/2
224.1.1.1在E1/2被加入了，优良是。
PIM密集模式是充斥和修剪协议，那么没有加入，但是有贪占。 因为路由器B从路由器A未接受一次溢出，在哪里不知道发送贪占。
您能检查发现它是否是一个TTL问题的嗅探器捕获并且看到用show ip traffic命令：
ROUTERA#show ip traffic
IP statistics:
248756 total, 1185 local destination
0 format errors, 0 checksum errors, 63744 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 0 with options
以上输出显示63744个坏跳次计数。 每次您键入此命令，坏跳次计数增加。 这是发送器发送信息包与TTL=1，路由器A减少量到零的明确的提示。 这导致坏跳次计数字段的增量。
要解决问题，您需要增加TTL。 这执行在应用程序级在发送器。 欲知更多信息，请参见您的组播应用说明书。
一旦这执行，路由器A如下所示:
ROUTERA#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00
(*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00
(1.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00
这是您想要发现的类输出。
在路由器B上您看到：
ROUTERB#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00
(*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00
(1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA
Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1
Outgoing interface list:
Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00
此部分提供一个解决方案给TTL门限值的常见的问题设置太低，因此IP组播数据流不到达接受器。 例如使用此网络图。
在以上图，接受器从来源不收到组播信息包。 可能有几个路由器在来源和路由器75a之间。 第一查找在路由器75a，因为是直接连接到接受器。
ip22-75a#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00
(1.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00
以上输出显示路由器75a是转发信息包Ethernet0/1。 要是绝对肯定的路由器75a转发信息包，打开调试为此来源和组播组：
ip22-75a#configure terminal
Enter configuration commands, one per line.
End with CNTL/Z.
ip22-75a(config)#access-list 101 permit udp host 1.1.1.1 host 224.1.1.1
ip22-75a(config)#end
ip22-75a#debug ip mpacket 101
IP multicast packets debugging is on for access list 101
*Jan 17 09:04:08.714: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied
*Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied
*Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied
上述调试消息表明路由器75a不转发组播信息包，因为TTL门限值达到了。 查看路由器配置发现您是否能找到原因。 此输出显示罪犯：
interface Ethernet0/1
ip address 2.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip multicast ttl-threshold 15
路由器有一个TTL门限值15，但是这不意味着TTL 15没有发送大于的任何。 实际上，对面是真的。 应用程序被发送与TTL 15。 当它达到路由器75a的时候，组播信息包有TTL少于15。
ip multicast ttl-threshold &value>命令意味着所有信息包与TTL低于指定的极限，在这种情况下， 15，没有转发。 此命令通常被用于提供边界保持内部组播数据流从漂移在内部网外面。
二者之一通过使用此命令no形式删除ip multicast ttl-threshold &value>命令，恢复到默认TTL门限值为0，或者降低TTL门限值，以便数据流能通过。
这区分显示相等费用路径到组播源如何能引起不需要的回程路径转发(RPF)工作情况。 它如何也描述配置IP组播避免此工作情况。 例如使用此网络图。
在以上图，路由器75b有三个相等费用路径回到来源(1.1.1.1)，并且选择您不希望是其第一个选择作为RPF链路的链路。
当面对多条相等费用路径到来源， IP组播选择在其他链路有Protocol-Independent Multicast (PIM)相邻用最高的IP地址的接口，因为流入的接口然后发送修剪到PIM相邻。
要更改接口IP组播选择作为其流入的接口，您能执行这些中的一个：
只请配置PIM在您希望组播横断，意味着的接口您失去组播冗余。
更改子网，因此最高的IP地址在您想要是主要组播链路的链路。
创建指出首选的组播接口的静态组播路由(mroute)，意味着您失去组播冗余。
例如，一静态mroute被创建。
在安装一静态mroute之前，您在下面的输出中看到路由表有三等价路由为源地址1.1.1.1。 RPF信息表明RPF接口是E1/3 ：
ip22-75b#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
3.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2
Route metric is 20, traffic share count is 1
ip22-75b#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet1/3
RPF neighbor: ? (4.1.1.1)
RPF route/mask: 1.1.1.0/24
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables
ip22-75b#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00
Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00
(1.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT
Incoming interface: Ethernet1/3, RPF nbr 4.1.1.1
Outgoing interface list:
Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32
Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42
在配置静态mroute以后，您在输出RPF接口的这中看到变成了E1/1 ：
ip22-75b#configure terminal
Enter configuration commands, one per line.
End with CNTL/Z.
ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 2.1.1.1
ip22-75b(config)#end
ip22-75b#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet1/1
RPF neighbor: ? (2.1.1.1)
RPF route/mask: 1.1.1.1/0
RPF type: static mroute
RPF recursion count: 0
Doing distance-preferred lookups across tables
ip22-75b#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
3.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2
Route metric is 20, traffic share count is 1
ip22-75b#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00
Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00
(1.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT
Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1, Mroute
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47
Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28
此部分提供一个解决方案给配置IP组播常见的问题横跨所有可用的等价路径负载平衡。 例如使用此网络图。
在以上图，路由器75b有三个等价路径回到来源(1.1.1.1)。 您想要负载平衡组播数据流横跨所有三条链路。
如同您在看到了请以上部分， Protocol-Independent Multicast (PIM)只选择一个接口为回程路径转发(RPF)检查并且修剪其他。 这意味着负载平衡不出现。 为了负载平衡，您需要从冗余链路去除PIM和创建一条隧道在路由器75a和路由器75b之间。 您能然后负载平衡在链路级，并且IP运行隧道。
这些是隧道的配置。
interface Tunnel0
ip address 6.1.1.1 255.255.255.0
ip pim sparse-dense-mode
tunnel source Ethernet0/0
tunnel destination 5.1.1.1
interface Ethernet0/0
ip address 1.1.1.2 255.255.255.0
ip pim sparse-dense-mode
interface Ethernet0/1
ip address 2.1.1.1 255.255.255.0
interface Ethernet0/2
ip address 3.1.1.1 255.255.255.0
interface Ethernet0/3
ip address 4.1.1.1 255.255.255.0
interface Tunnel0
ip address 6.1.1.2 255.255.255.0
ip pim sparse-dense-mode
tunnel source Ethernet1/4
tunnel destination 1.1.1.2
interface Ethernet1/1
ip address 2.1.1.2 255.255.255.0
interface Ethernet1/2
ip address 3.1.1.2 255.255.255.0
interface Ethernet1/3
ip address 4.1.1.2 255.255.255.0
interface Ethernet1/4
ip address 5.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip mroute 0.0.0.0 0.0.0.0 Tunnel0
在您配置隧道之后，请使用show ip mroute命令为组发现组播路由(mroute) ：
ip22-75a#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00
(1.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00
ip22-75b#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00
(1.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT
Incoming interface: Tunnel0, RPF nbr 6.1.1.1, Mroute
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00
要检查组播数据横跨三条链路均等地负载平衡，请查看路由器75a接口数据。
流入的接口是9000位/秒：
ip22-75a#show interface e0/0
5 minute input rate 9000 bits/sec, 20 packets/sec
三个流出的接口中的每一个显示3000位/秒：
ip22-75a#show interface e0/1
5 minute output rate 3000 bits/sec, 7 packets/sec
ip22-75a#show interface e0/2
5 minute output rate 3000 bits/sec, 7 packets/sec
ip22-75a#show interface e0/3
5 minute output rate 3000 bits/sec, 7 packets/sec
此部分提供解决方案给IP组播“INVALID_RP_JOIN”错误信息的常见的问题。
此错误信息在聚合点(RP)收到：
00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1)
Join from 1.1.6.2 for invalid RP 1.1.5.4
00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1)
Join from 1.1.6.2 for invalid RP 1.1.5.4
解释什么导致此错误： 一个下行PIM路由器发送了一个加入消息为共享结构树，此路由器不想要接受。 此工作情况表明此路由器允许仅下行路由器加入对特定RP。
我们怀疑过滤继续。 您需要看一看在路由器的配置：
interface Ethernet0/0
ip address 1.1.5.4 255.255.255.0
ip pim sparse-dense-mode
ip pim accept-rp 10.2.2.2 8
ip pim send-rp-announce Ethernet0/0 scope 15
ip pim send-rp-discovery scope 15
access-list 8 permit 224.0.0.0 0.255.255.255
什么是accept-rp语句在配置应该完成？ 阐明， “配置路由器接受加入或为组一张特定列表注定的为指定的RP和修剪，使用ip pim accept-rp global configuration命令。 要去除该检查，请使用此命令no形式”。
当您删除ip pim accept-rp命令时，消息消失。 引起问题的命令若在配置被找到，但是您想要保留该命令？ 您可能允许错误的RP寻址。 使用show ip pim rp mapping命令，您能看到正确的RP寻址：
ip22-75a#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent
Group(s) 224.0.0.0/4
RP 1.1.5.4 (?), v2v1
Info source: 1.1.5.4 (?), via Auto-RP
Uptime: 01:00:48, expires: 00:02:07
根据以上输出， 1.1.5.4是通过自动RP了解的唯一的RP或。 然而，此路由器是仅RP为第224.0.0.0/4组。 因此， pim accept-rp语句在以上配置是错误的。
解决方案将更正IP地址在ip pim accept-rp语句如下：
更改此语句：
ip pim accept-rp 10.2.2.2 8
ip pim accept-rp 1.1.5.4 8
您能也更改语句接受什么在自动RP高速缓冲存储器和确定访问控制列表(8在本例中)允许必要的组播组范围。 这是示例：
ip pim accept-rp auto-rp
access-list 8 permit 224.0.0.0 0.255.255.255
此错误信息在router2被看到。
*Aug 12 15:18:17.891:
%PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40)
0.0.0.0 for invalid RP 2.1.1.1
确认router2是否是RP为第224.1.1.1组：
router2#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:21:26, expires: 00:02:24
RP为224.1.1.1是1.1.1.1。
检查这是否是其中一个router2接口：
router2#show ip interface brief
IP-Address
OK? Method Status
Ethernet0/0
Ethernet1/0
Ethernet2/0
unassigned
administratively down down
因为router2不是RP，应该不收到此RP加入信息包。 检查下行路由器为什么发送了加入对router2，而不应该：
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:24:30, expires: 00:02:16
Group(s): 224.0.0.0/4, Static-Override
RP: 2.1.1.1 (?)
您看到， router3静态地配置了RP信息，指向router2，是不正确的。 这解释router3为什么发送RP加入对router2。
任一制造router2 RP为组224.1.1.1或在router3更改配置，因此引用正确的RP寻址。
router3#show run | i rp
ip pim rp-address 2.1.1.1 override
router3#configure terminal
Enter configuration commands, one per line.
End with CNTL/Z.
router3(config)#no ip pim rp-address 2.1.1.1 override
router3(config)#exit
在router3更正之后配置， router3引用正确的RP寻址，并且错误信息停止出现。
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:30:45, expires: 00:02:02
此部分说明组播信息包不需要的泛滥如何能发生，当Cisco组管理协议(CGMP)在所有路由器在特定子网时没有被启用，并且此问题如何可以避免。 例如使用此网络图。
在以上图，静态CAM表在Catalyst 5000交换机A不显示被填充的其中任一个正确的端口。 配置CGMP的路由器不发送CGMP信息包。
CGMP用set cgmp enable命令和ip cgmp命令在交换机A在路由器75a E0/2接口正确地被配置。 然而，当发出时，组播组在交换机A没看到show multicast group命令：
Console& (enable) show multicast group
CGMP enabled
IGMP disabled
IGMP fastleave disabled
GMRP disabled
Dest MAC/Route Des
Destination Ports or VCs / [Protocol Type]
------------------
-------------------------------------------
Total Number of Entries = 0
此命令的输出应该显示其中每一有一个配置CGMP的路由器对此的端口(端口2/3)和有一台感兴趣接受器对此的每个端口(端口2/6)。 因为0是列出的，您能假设所有端口不必要地被充斥与组播数据流是否他们想要它。
确认是否有任何Protocol-Independent Multicast (PIM)相邻在路由器75a ：
ip22-75a#show ip pim neighbor
PIM Neighbor Table
Neighbor Address
Ethernet0/2
以上输出表示，路由器75a能发现路由器75b作为有效PIM相邻通过交换机A。
现在请证实您是否获得正确的组播路由(mroute)信息关于路由器：
ip22-75a#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00
(1.1.1.1, 224.1.1.1), 00:14:56/00:02:59, flags: CTA
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00
以上输出显示路由器75a转发组播信息包E0/2往交换机A。 以下表示路由器75b得到组播信息包并且正确地转发他们：
ip22-75b#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00
(1.1.1.1, 224.1.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 2.1.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
查找从交换机A的观点，您看到看到路由器75a端口2/3。
Console& (enable) show multicast router
CGMP enabled
IGMP disabled
IGMP fastleave disabled
----------------
Total Number of Entries = 1
被看到的很好似乎到目前为止一切。 发出一些debug命令在路由器75a发现什么您能发现：
ip22-75a#debug ip cgmp
CGMP debugging is on
8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2
8 12:45:22.206:
GDA 00, USA 00d0.ff2f.a002
8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2
8 12:46:22.234:
GDA 00, USA 00d0.ff2f.a002
8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2
8 12:47:22.262:
GDA 00, USA 00d0.ff2f.a002
在以上输出中， 00是所有组地址和使用，当路由器发送CGMP加入时或离开信息，因此交换机能填充路由器端口。 GDA代表组目的地地址以媒体访问控制(MAC)级别格式，并且USA代表单播源地址。 这是产生IGMP报告此CGMP消息生成主机的地址。 在这种情况下，它是MAC地址为路由器75a接口E0/2。 MAC地址为路由器75a E0/2能用show interface命令被看到如这里被看到：
ip22-75a#show interface e0/2
Ethernet0/2 is up, line protocol is up
Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)
另外，当debug ip igmp命令打开时，您可以周期地发现此：
8 12:51:41.854: IGMP: Received v2 Report from 2.1.1.3 (Ethernet0/2) for 224.1.1.1
然而，您随后看不到一个对应的CGMP信息包从路由器75a。 这意味着路由器75a收到IGMP报告，但是不生成必要的CGMP信息包帮助交换机A知道阻拦的哪些端口。 这是预计路由器75a的事，如果它是IGMP查询者。 路由器75a的此输出告诉我们期望的工作情况为什么不发生：
ip22-75a#show ip igmp interface e0/2
Ethernet0/2 is up, line protocol is up
Internet address is 2.1.1.2/24
IGMP is enabled on interface
Current IGMP version is 2
CGMP is enabled
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 3 joins, 1 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 2.1.1.2 (this system)
IGMP querying router is 2.1.1.1
No multicast groups joined
如果在相同子网有二个路由器，并且为CGMP配置两个，只有你将发送CGMP信息包。 发送CGMP信息包的路由器是IGMP查询路由器。 这意味着路由器与支持IGMP的路由器的最低的单播IP地址。
在这种情况下，路由器75a和路由器75b有支持IGMP (路由器75b成为IGMP查询路由器)，但是仅路由器75a有支持CGMP。 因为路由器75a不是IGMP查询路由器，没有发送CGMP信息包。
要解决问题，您在IGMP查询路由器需要配置CGMP。 在这种情况下，路由器75b。 首先，请打开debug命令在路由器75b ：
ip22-75b#conf t
Enter configuration commands, one per line.
End with CNTL/Z.
ip22-75b(config)#int e 1/3
ip22-75b(config-if)#ip cgmp
ip22-75b(config-if)#end
ip22-75b#debug ip cgmp
ip22-75b#debug ip igmp
8 12:58:42.422: IGMP: Received v2 Report from 2.1.1.3 (Ethernet1/3) for 224.1.1.1
8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3
8 12:58:42.422:
from 2.1.1.3 for 224.1.1.1
8 12:58:42.422: CGMP: Sending Join on Ethernet1/3
8 12:58:42.422:
GDA .0101, USA .a859
路由器75b从2.1.1.3收到一个IGMP报告为第224.1.1.1组。 它随后发送CGMP加入到交换机A为224.1.1.1 MAC等同带有MAC地址(USA) 2.1.1.3感兴趣的主机。 交换机A知道主机打开的哪个端口，因此标记它如开放并且阻拦其他。
事应该在交换机A现在运作：
Console& (enable) show multicast group
CGMP enabled
IGMP disabled
IGMP fastleave disabled
GMRP disabled
Dest MAC/Route Des
Destination Ports or VCs / [Protocol Type]
------------------
-------------------------------------------
01-00-5e-00-01-28
01-00-5e-01-01-01
Total Number of Entries = 2
这好是。 224.1.1.1 (01-00-5e-01-01-01)信息包只是被派出的端口2/3， 2/4和2/6在交换机A，他们应该。 充斥对其他端口终止了。 条目总数正确地现在列出作为2。 MAC地址01-00-5e-00-01-28从组播地址224.0.1.40被映射，使用CGMP自加入。
此部分提供一个解决方案给Catalyst交换机溢出数据流的常见的问题给每个端口，而不是给正确的主机。 例如使用此网络图。
在以上图，路由器75a和75b和Catalyst 5000 (交换机A)为组播和Cisco组管理协议(CGMP)是适当配置。 主机获得组播数据流。 然而，如此是其他主机的交换机A.交换机A充斥数据流每个端口，因此它意味着CGMP不工作。
show multicast group命令的输出在交换机A看似类似：
Console& (enable) show multicast group
CGMP enabled
IGMP disabled
IGMP fastleave disabled
GMRP disabled
Dest MAC/Route Des
Destination Ports or VCs / [Protocol Type]
------------------
-------------------------------------------
01-00-5e-00-01-28
Total Number of Entries = 1
您能从以上输出看到唯一的组是224.0.1.40，路由器使用，当发送CGMP自加入为自动RP组时。 有没有为什么没有其他组？
要了解解决方案，您需要了解CGMP在一定条件下如何正常运行。 支持CGMP的路由器发送CGMP加入到通知对特定组播组感兴趣的交换机的交换机主机。 交换机为这些主机在其CAM表里查寻MAC地址，然后转送组播信息包端口用感兴趣的主机并且阻拦其他端口从转发组播信息包。
路由器传送CGMP自加入一个支持CGMP的接口，如果从在同一个接口的来源收到组播信息包(路由器)有支持CGMP。
例如，如果来源在相同子网(VLAN)， 2.1.1.0/24，作为路由器75a和75b， CGMP将理想工作。 路由器，在看到自来源的信息包，将发送CGMP自加入到交换机，将动态地然后了解哪些端口路由器打开并且阻拦其他端口从转发组播信息包。
路由器发送CGMP加入支持CGMP的接口，如果从一台主机在同一个接口收到IGMP报告(路由器)有支持CGMP。
如果我们在此同样VLAN，有一台感兴趣的主机另一个示例是。 在那种情况下，当支持CGMP的路由器从是对特定组播组感兴趣的主机收到了一个互联网组管理协议(IGMP)报告，路由器将发送CGMP加入。 想参加的加入将指示想加入主机和组的MAC控制(MAC)地址。 Catalyst 5000在组播组列表将检查其CAM表主机的MAC地址，然后放置相关的端口，并且阻拦其他不感兴趣的端口。
同样不是真的，当来源和感兴趣的主机在子网除支持CGMP的子网时(VLAN)之外。 组播信息包，来自来源，不触发路由器发送CGMP自加入到交换机。 所以信息包押交换机并且在VLAN之内充斥到处。 此方案在VLAN继续直到一台主机，来端口在交换机，发送IGMP加入。 仅与IGMP的收据报告执行路由器发送CGMP信息包，然后引起交换机添加适当的主机端口，当转发的和所有其他端口被阻拦(除路由器端口之外)。
因此对于CGMP工作在此转换类型结构方面，您在此网络图可能二者之一添加主机到VLAN和路由器75a和75b一样，正如。
或者请移动来源在相同子网作为路由器75a和75b，正如在此示例。
移动来源向相同子网然后检查交换机A的输出：
Console& (enable) show multicast router
CGMP enabled
IGMP disabled
IGMP fastleave disabled
----------------
Total Number of Entries = 2
'*' - Configured
Console& (enable)
Console& (enable) show multicast group
CGMP enabled
IGMP disabled
IGMP fastleave disabled
GMRP disabled
Dest MAC/Route Des
Destination Ports or VCs / [Protocol Type]
------------------
-------------------------------------------
01-00-5e-00-01-28
01-00-5e-01-01-01
Total Number of Entries = 2
现在224.1.1.1 (01-00-5e-01-01-01)只被充斥到路由器端口2/3和2/4和不对每个端口交换机A。
此部分说明一些组播IP地址为什么在局域网(LAN)造成Cisco组管理协议(CGMP)充斥组播数据流所有端口。 当您使用组播组地址225.0.0.1时， Cisco组管理协议(CGMP)不工作。 它充斥组播流所有交换端口并且浪费带宽。 然而，如果优良更改地址到225.1.1.1 CGMP工作。 因为它不是一个注册的地址为路由协议，使用225.0.0.1怎么回事？
首先，了解是重要的第三层组播地址如何被映射对第二层组播地址。 所有IP组播帧使用IEEE MAC控制(MAC)层地址从0x0100.5e开始24位前缀。 当映射第三层到第二层地址时，第三层组播地址的低价位23位被映射到IEEE MAC地址的低价位23位。
要了解的另一个重要事实是那里是28位唯一地址空间为IP组播地址(32位减包含1110 D类前缀)的前4位。 因为只有23位插入IEEE MAC地址， 5位交叠依然存在。 这意味着多个第三层组播地址能映射对同一个第二层组播地址。
224.0.0.1 = 00 00. in binary
low order 23 bits =
hex equivalent
result of mapping = 0x.0001
224.128.0.1 = 00 00. in binary
low order 23 bits =
hex equivalent
result of mapping = 0x.0001
注意在上述示例224.0.0.1和224.128.0.1映射对同一个第二层组播地址。
即然您知道第三层到第二层组播地址如何被映射，请进行对特定解决方案到上述问题。
交换机A充斥组播信息包对224.0.0.x，因为那些地址是本地链路，并且我们在局域网(LAN)想要保证本地链路地址达到所有设备。 Catalyst交换机也充斥组播信息包对例如是MAC级模棱两可的与224.0.0.x的其他组播地址(224.0.0.1和225.0.0.1两映射对.0001)。 交换机充斥为这些链路本地地址注定的组播信息包是否CGMP启用。
所以，组播应用必须避免使用映射对.00xx第二层组播地址，其中xx可以是十六进制的00□FF的D类地址。 这包括这些D类地址：
224.0.0.x (x = 0 to 255)
224.128.0.x (x = 0 to 255)
225.128.0.x
239.128.0.x
声明：此文档是由为思科 TAC 网页内容翻译所开发的英汉机器自动翻译系统翻译的。在有疑问或作出重要的技术支持决策时,请随时参考英文原文。Updated:
Aug 20, 2004Document ID: 16450
[an error occurred while processing this directive]
[an error occurred while processing this directive]