內容前言前提條件需求使用的組件慣例背景信息由于RPF故障，路由器未向主機轉發多播數據包診斷問題可能的修正由于源端TTL設置，路由器未向主機轉發多播數據包診斷問題可能的修正由于路由器的TTL閾值，路由器未轉發多播數據包診斷問題可能的修正多個成本相等的路徑造成多余的返回路徑轉發行為診斷問題可能的修正為什么沒有在所有可用的等價路徑之間進行IP多播負載均衡？可能的修正為什么在路由器上收到IP多播“INVALID_RP_JOIN”錯誤消息?診斷問題-第1部分診斷問題-第2部分CGMP不能防止多播數據包泛洪診斷問題觀察可能的修正由于源端/接收端的放置問題，CGMP不能防止多播數據包泛洪診斷問題可能的修正CGMP不能防止某些組地址的多播數據包泛洪可能的修正收到重復的多播數據包流原因1可能的修復方法1原因2可能的修復方法2原因3可能的修復方法3多播數據包為什么被丟棄?原因1可能的修復方法1原因2可能的修復方法2前言本文介紹IP多播的常見問題和解決方案前提條件需求本文檔沒有任何特定的要求使用的組件本文檔不限于特定的軟件和硬件版本慣例有關文檔規則的詳細信息，請參閱Cisco技術提示規則。背景信息在排除多播路由故障時，最主要的問題是源地址。多播有一個反向路徑轉發檢查(RPF檢查)的概念。當多播數據包到達某個接口時，RPF進程將檢查以確保此傳入接口是單播路由用于抵達多播數據包源的傳出接口。此RPF檢查進程將防止出現環路。組播路由不轉發數據包，除非數據包的source通過反向路徑轉發(RPF)檢查。數據包通過此RPF檢查后，多播路由將僅根據目標地址轉發數據包。類似單播路由，組播路由有幾份可用的協議，例如獨立于協議的組播密集模式(PIM-DM)，PIM稀疏模式(PIM-SM)，距離矢量組播路由協議(DVMRP)、組播邊界網關協議(MBGP)和組播源發現協議(MSDP)。本文將通過案例研究詳細介紹各種問題的解決過程。您將了解用于迅速查明問題的命令并學習如何解決問題。這里列出的案例研究適用于各種協議，除非特別說明。由于RPF故障，路由器未向主機轉發多播數據包此部分提供一解決方案給IP多播反向路徑轉發(RPF)失敗的常見問題。我們以下面的網絡圖為例。2.1.1.1HostASourceRouter72a2.1.1.1HostASourceRouter72aSendingto224.1.1.1在上圖中，多播數據包從IP地址為1.1.1.1的服務器進入路由器75a的E0/0并發送到組224.1.1.1。這稱為(S,G)或(1.1.1.1,224.1.1.1)。診斷問題直接連接到路由器75a的主機將接收該多播饋送，但直接連接到路由器72a的主機不會進行接收。首先，發出showipmroute224.1.1.1命令查看路由器75a的狀況。該命令將檢查組地址224.1.1.1的多播路由(mroute)：75a#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),00:01:23/00:02:59,RP0.0.0.0,flags:DIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist: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:TAIncominginterface:Ethernet0/0,RPFnbr0.0.0.0Outgoinginterfacelist: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接口轉發出去。這是一個完美的方案。發出showippimneighbor命令以查看路由器72a是否將上游路由器(75a)顯示為PIM鄰居：ip22-72a#showippimneighborPIMNeighborTableNeighborAddress Interface Uptime Expires Ver Mode2.1.1.1 Ethernet3/1 2d00h 00:01:15 v2從showippimneighbor命令的輸出看，PIM鄰居看起來一切正常。使用showipmroute命令查看路由器72a是否具有良好的多播路由：ip22-72a#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,B-BidirGroup,s-SSMGroup,C-Connected,L-Local,P-Pruned,R-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPT,M-MSDPcreatedentry,X-ProxyJoinTimerRunning,A-CandidateforMSDPAdvertisement,U-URD,I-ReceivedSourceSpecificHostReport,Z-MulticastTunnelY-JoinedMDT-datagroup,y-SendingtoMDT-datagroupOutgoinginterfaceflags:H-Hardwareswitched,A-AssertwinnerTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),00:10:42/stopped,RP0.0.0.0,flags:DCIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet3/1,Forward/Dense,00:10:42/00:00:00Ethernet3/2,Forward/Dense,00:10:42/00:00:00(1.1.1.1,224.1.1.1),00:01:10/00:02:48,flags:Incominginterface:Ethernet2/0,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet3/1,Forward/Dense,00:01:10/00:00:00Ethernet3/2,Forward/Dense,00:00:16/00:00:00ip22-72a#通過showipmroute224.1.1.1命令可以發現，傳入接口為Ethernet2/0而不是預期的Etheret3/1。發出showipmroute224.1.1.1count命令以查看該組是否有任何多播流量抵達路由器72a以及接下來發生的情況：ip22-72a#showipmroute224.1.1.1countIPMulticastStatistics3routesusing2032bytesofmemory2groups,0.50averagesourcespergroupForwardingCounts:PktCount/Pktspersecond/AvgPktSize/KilobitspersecondOthercounts:Total/RPFfailed/Otherdrops(OIF-null,rate-limitetc)Group:224.1.1.1,Sourcecount:1,Packetsforwarded:0,Packetsreceived:471Source:1.1.1.1/32,Forwarding:0/0/0/0,Other:471/471/0ip22-72a#從Other計數中可以看到流量由于RPF故障而被丟棄：total471drops,duetoRPFfailure-471…發出showiprpf<source>命令以查看是否有RPF錯誤：ip22-72a#showiprpf1.1.1.1RPFinformationfor?(1.1.1.1)RPFinterface:Ethernet2/0RPFneighbor:?(0.0.0.0)RPFroute/mask:1.1.1.1/32RPFtype:unicast(static)RPFrecursioncount:0Doingdistance-preferredlookupsacrosstablesip22-72a#CiscoIOS?以這種方式計算RPF接口。RPF信息的可能源包括單播路由表、MBGP路由表、DVMRP路由表和靜態多播路由表。計算RPF接口時，主要使用管理距離確定RPF計算所基于的信息源。具體規則如下：?在所有以前的RPF數據源中搜索源IP地址的匹配項。如果使用共享樹，則使用RP地址而不是源地址。?如果找到多個匹配路由，則使用管理距離最短的路由。?如果管理距離相等，則使用以下優先順序：靜態多播路由DVMRP路由MBGP路由單播路由如果某個路由在同一個路由表中有多個條目，則使用最長的匹配路由。showiprpf1.1.1.1命令輸出表明RPF接口為E2/0,但傳入接口應該是E3/1。發出showiproute1.1.1.1命令以查看RPF接口為什么與預期接口不同。ip22-72a#showiproute1.1.1.1Routingentryfor1.1.1.1/32Knownvia"static",distance1,metric0(connected)RoutingDescriptorBlocks:*directlyconnected,viaEthernet2/0Routemetricis0,trafficsharecountis1從此showiproute1.1.1.1命令的輸出中可以看到有一個靜態/32路由,它導致選擇了錯誤的接口作為RPF接口。發出某些debug命令進行進一步調試：ip22-72a#debugipmpacket224.1.1.1*Jan1409:45:32.972:IP:s=1.1.1.1(Ethernet3/1)d=224.1.1.1len60,notRPFinterface*Jan1409:45:33.020:IP:s=1.1.1.1(Ethernet3/1)d=224.1.1.1len60,notRPFinterface*Jan1409:45:33.072:IP:s=1.1.1.1(Ethernet3/1)d=224.1.1.1len60,notRPFinterface*Jan1409:45:33.120:IP:s=1.1.1.1(Ethernet3/1)d=224.1.1.1len60,notRPFinterface數據包自E3/1傳入,這是正確的。然而,由于這不是單播路由表用于進行RPF檢查的接口,因此出現掉包。注意：調試數據包具有一定危險。數據包調試會觸發非常占用CPU資源的多播數據包交換進程。此外,數據包調試還會產生大量輸出,由于向控制臺端口輸出過慢,從而可能導致將路由器完全掛起。在調試數據包之前,切記要禁用向控制臺的日志輸出,并啟用將日志輸出到內存緩沖區。為此,需配置nologgingconsole和loggingbuffereddebugging。可以使用showlogging命令查看調試結果。可能的修正您可以更改單播路由表以滿足此要求,也可以添加靜態多播路由以強制多播的RPF使用特定接口,而不管單播路由表的設置如何。添加靜態多播路由：ip22-72a(config)#ipmroute1.1.1.1255.255.255.2552.1.1.1此靜態多播路由表明，要到達地址1.1.1.1，RPF將使用2.1.1.1作為下一跳，其傳出接口為E3/1。ip22-72a#showiprpf1.1.1.1RPFinformationfor?(1.1.1.1)RPFinterface:Ethernet3/1RPFneighbor:?(2.1.1.1)RPFroute/mask:1.1.1.1/32RPFtype:staticmrouteRPFrecursioncount:0Doingdistance-preferredlookupsacrosstablesshowipmroute和debugipmpacket的輸出一切正常，showipmroutecount中的發送數據包數增加了，并且HostA收到數據包。ip22-72a#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),00:01:15/00:02:59,RP0.0.0.0,flags:DJCIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet3/1,Forward/Sparse-Dense,00:01:15/00:00:00Ethernet3/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:CTAIncominginterface:Ethernet3/1,RPFnbr2.1.1.1,MrouteOutgoinginterfacelist:Ethernet3/2,Forward/Sparse-Dense,00:00:48/00:00:00ip22-72a#showipmroute224.1.1.1countIPMulticastStatistics3routesusing2378bytesofmemory2groups,0.50averagesourcespergroupForwardingCounts:PktCount/Pktspersecond/AvgPktSize/KilobitspersecondOthercounts:Total/RPFfailed/Otherdrops(OIF-null,rate-limitetc)Group:224.1.1.1,Sourcecount:1,Packetsforwarded:1019,Packetsreceived:1019Source:1.1.1.1/32,Forwarding:1019/1/100/0,Other:1019/0/0ip22-72a#showipmroute224.1.1.1countIPMulticastStatistics3routesusing2378bytesofmemory2groups,0.50averagesourcespergroupForwardingCounts:PktCount/Pktspersecond/AvgPktSize/KilobitspersecondOthercounts:Total/RPFfailed/Otherdrops(OIF-null,rate-limitetc)Group:224.1.1.1,Sourcecount:1,Packetsforwarded:1026,Packetsreceived:1026Source:1.1.1.1/32,Forwarding:1026/1/100/0,Other:1026/0/0ip22-72a#ip22-72a#debugipmpacket224.1.1.1*Jan1410:18:29.951:IP:s=1.1.1.1(Ethernet3/1)d=224.1.1.1(Ethernet3/2)len60,mforward*Jan1410:18:29.999:IP:s=1.1.1.1(Ethernet3/1)d=224.1.1.1(Ethernet3/2)len60,mforward*Jan1410:18:30.051:IP:s=1.1.1.1(Ethernet3/1)d=224.1.1.1(Ethernet3/2)len60,mforward由于源端TTL設置，路由器未向主機轉發多播數據包因為存活時間(TTL)值消耗到零，此部分提供一解決方案給IP多播數據包常見問題不轉發的。由于多播應用的情況較多，因此這個問題很常見。多播應用主要設計用于LAN,因此會將TTL設置為一個較低的值，甚至為1。我們以下面的網絡圖為例。SourceSendingto224.1.1.1診斷問題在上圖中，路由器A并不將來自源的數據包轉發至路由器B所直接連接的接收方。查看路由器A的showipmroute命令的輸出以檢查多播路由狀態：ROUTERA#showipmrouteIPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.0.1.40),00:00:01/00:00:00,RP0.0.0.0,flags:DJCLIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0/1,Forward/Sparse-Dense,00:00:01/00:00:00(*,224.1.1.1),00:00:02/00:02:57,RP0.0.0.0,flags:DIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0/1,Forward/Sparse-Dense,00:00:02/00:00:00您可以忽略上述輸出中的224.0.1.40，因為所有路由器都會加入此自動RP發現組。但是這里沒有為224.1.1.1列出源。除了“*,224.1.1.1”外，您還應當看到“1.1.1.1,224.1.1.1”。發出showiprpf命令發現它是否是反向路徑轉發(RPF)發貨：ROUTERA#showiprpf1.1.1.1RPFinformationfor?(1.1.1.1)RPFinterface:Ethernet0/0RPFneighbor:?(0.0.0.0)-directlyconnectedRPFroute/mask:1.1.1.0/24RPFtype:unicast(connected)RPFrecursioncount:0Doingdistance-preferredlookupsacrosstables從上面的輸出可以看出這不是RPF問題。RPF檢查正確表明E0/0對應于源IP地址。使用showippiminterface命令檢查接口是否配置了PIM：ROUTERA#showippiminterface

AddressDRAddressDRInterface1.1.1.2Ethernet0/01.1.1.22.1.1.1Ethernet0/12.1.1.2Version/ModeNbrQueryCountIntvlv2/Sparse-Dense030v2/Sparse-Dense230輸出一切正常，因此這不是問題所在。使用showipmrouteactive命令檢查路由器是否識別出任何活動流量：ROUTERA#showipmrouteactiveActiveIPMulticastSources-sending>=4kbps根據上面的輸出，路由器并未識別出任何活動流量。ROUTERA#debugipmpacketIPmulticastpacketsdebuggingison或許接收方沒有發送任何互聯網組管理協議(IGMP)報告(加入)組的224.1.1.1。您可以使用showipigmpgroup命令檢查它：ROUTERB#showipigmpgroupIGMPConnectedGroupMembershipGroupAddressReporter224.0.1.40224.1.1.1InterfaceGroupAddressReporter224.0.1.40224.1.1.1InterfaceEthernet1/1Ethernet1/2Uptime00:34:3400:30:02Expiresnever00:02:45Last2.1.1.23.1.1.2224.1.1.1已在E1/2加入，這是正確的。PIM密集模式是一個泛洪和修剪協議，因此沒有加入，但是有嫁接。由于路由器B未從路由器A接收到泛洪，因此它并不知道向何處發送嫁接。您可以使用嗅探器捕捉和showiptraffic命令進行檢查以查看是否是TTL問題：ROUTERA#showiptrafficIPstatistics:Rcvd:248756total,1185localdestination0formaterrors,0checksumerrors,63744badhopcount0unknownprotocol,0notagateway0securityfailures,0badoptions,0withoptions上面的輸出顯示有63744個壞跳計數。每次鍵入此命令時，壞跳計數都將增加。這是一個強烈信號，表明發送方使用TTL=1發送數據包，而路由器A將其衰減為零。這導致壞跳計數字段不斷增加。可能的修正要解決此問題，需要增加TTL。這要在發送方的應用級別進行設置。有關詳細信息，請參閱您的多播應用說明手冊。完成設置后，路由器A將如下所示：ROUTERA#showipmrouteIPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.0.1.40),01:16:32/00:00:00,RP0.0.0.0,flags:DJCLIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0/1,Forward/Sparse-Dense,01:16:32/00:00:00(*,224.1.1.1),00:28:42/00:02:59,RP0.0.0.0,flags:DIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist: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:TAIncominginterface:Ethernet0/0,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0/1,Forward/Sparse-Dense,00:19:24/00:00:00這是您希望的輸出。在路由器B上，您會看到：ROUTERB#showipmrouteIPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.0.1.40),01:23:57/00:00:00,RP0.0.0.0,flags:DJCLIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet1/1,Forward/Sparse-Dense,01:23:57/00:00:00(*,224.1.1.1),01:19:26/00:02:59,RP0.0.0.0,flags:DJCIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet1/1,Forward/Sparse-Dense,01:19:26/00:00:00Ethernet1/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:CTAIncominginterface:Ethernet1/1,RPFnbr2.1.1.1Outgoinginterfacelist:Ethernet1/2,Forward/Sparse-Dense,00:17:46/00:00:00由于路由器的TTL閾值，路由器未轉發多播數據包此部分為常見的由于TTL閾值設置過低而導致IP多播流量未能到達接收方的問題提供了一個解決方案。我們以下面的網絡圖為例。診斷問題在上圖中，接收方未收到來自源的多播數據包。在源和路由器75a之間可能有多個路由器首先查看路由器75a，因為它直接連接到接收方。ip22-75a#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),00:32:05/00:02:59,RP0.0.0.0,flags:DJCIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist: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:CTAIncominginterface:Ethernet0/0,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0/1,Forward/Sparse-Dense,00:01:02/00:00:00上面的輸出表明，路由器75a將數據包從Ethernet0/1轉出。要絕對確定路由器75a是否轉發了數據包，請只為此源和多播組執行debug：ip22-75a#configureterminalEnterconfigurationcommands,oneperline.EndwithCNTL/Z.ip22-75a(config)#access-list101permitudphost1.1.1.1host224.1.1.1ip22-75a(config)#endip22-75a#debugipmpacket101IPmulticastpacketsdebuggingisonforaccesslist101ip22-75a#*Jan1709:04:08.714:IP:s=1.1.1.1(Ethernet0/0)d=224.1.1.1len60,thresholddenied*Jan1709:04:08.762:IP:s=1.1.1.1(Ethernet0/0)d=224.1.1.1len60,thresholddenied*Jan1709:04:08.814:IP:s=1.1.1.1(Ethernet0/0)d=224.1.1.1len60,thresholddenied上面的debug消息表明路由器75a并未轉發多播數據包，因為已達TTL閾值。檢查路由器配置以查看是否能找到原因。下面的輸出表明了問題所在：interfaceEthernet0/1ipaddress2.1.1.1255.255.255.0ippimsparse-dense-modeipmulticastttl-threshold15路由器的TTL閾值為15，但這并不意味著任何大于15的TTL都不會予以發送。事實恰恰相反。該應用使用TTL15進行發送。當它到達路由器75a時，多播數據包的TTL將小于15。ipmulticastttl-threshold<value>命令意味著TTL低于指定閾值（本例中為15）的任何數據包都不會進行轉發。該命令通常用于提供一個界限，以防止內部多播流量流到Intranet以外。可能的修正可以使用ipmulticastttl-threshold<value>命令的no格式刪除該命令，這將恢復默認TTL閾值0；也可以降低TTL閾值以便能夠傳遞流量。多個成本相等的路徑造成多余的返回路徑轉發行為這區分顯示組播源的等價路徑如何能引起不需要的回程路徑轉發（RPF）行為。此外還會說明如何配置IP多播以避免這種行為。我們以下面的網絡圖為例。診斷問題在上圖中，路由器75b有三個等價路徑返回到源（1.1.1.1），并且它選擇的RPF首選鏈路并不是您所希望的。當面對指向源的多個等價路徑時，IP多播會選擇其獨立多播協議（PIM）鄰居具有最高IP地址的接口作為傳入接口，然后將修剪發送給其他鏈路上的PIM鄰居。可能的修正要更改IP多播選擇作為其傳入接口的接口，可執行下列操作之一：?只在希望多播流經的接口上配置PIM,這意味著要犧牲多播冗余。?更改子網，以使最高IP地址位于您希望作為多播主鏈路的鏈路上。?創建一個從所需多播接口傳出的靜態多播路由（mroute），這意味著要犧牲多播冗余。為舉例說明，我們將創建一個靜態多播路由。在安裝靜態多播路由之前，您會在下面的輸出中看到路由表為源地址1.1.1.1提供了三個等價路由。RPF信息表明RPF接口為E1/3：ip22-75b#showiproute1.1.1.1Routingentryfor1.1.1.0/24Knownvia"ospf1",distance110,metric20,typeintraareaRedistributingviaospf1Lastupdatefrom3.1.1.1onEthernet1/2,00:26:21agoRoutingDescriptorBlocks:*4.1.1.1,from10.0.119.66,00:26:21ago,viaEthernet1/3Routemetricis20,trafficsharecountis1from10.0.119.66,00:26:21ago,viaEthernet1/1Routemetricis20,trafficsharecountis1from10.0.119.66,00:26:21ago,viaEthernet1/2Routemetricis20,trafficsharecountis1ip22-75b#showiprpf1.1.1.1RPFinformationfor?(1.1.1.1)RPFinterface:Ethernet1/3RPFneighbor:?(4.1.1.1)RPFroute/mask:1.1.1.0/24RPFtype:unicast(ospf1)RPFrecursioncount:0Doingdistance-preferredlookupsacrosstablesip22-75b#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),01:30:34/00:02:59,RP0.0.0.0,flags:DJCIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet1/4,Forward/Sparse-Dense,01:30:34/00:00:00Ethernet1/1,Forward/Sparse-Dense,01:30:35/00:00:00Ethernet1/2,Forward/Sparse-Dense,01:30:35/00:00:00Ethernet1/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:CTIncominginterface:Ethernet1/3,RPFnbr4.1.1.1Outgoinginterfacelist:Ethernet1/1,Prune/Sparse-Dense,01:30:35/00:02:32Ethernet1/4,Forward/Sparse-Dense,01:30:35/00:00:00Ethernet1/2,Prune/Sparse-Dense,00:24:22/00:02:42配置了靜態多播路由后，您會在此輸出中看到RPF接口已更改為E1/1：ip22-75b#configureterminalEnterconfigurationcommands,oneperline.EndwithCNTL/Z.ip22-75b(config)#ipmroute0.0.0.00.0.0.02.1.1.1ip22-75b(config)#endip22-75b#showiprpf1.1.1.1RPFinformationfor?(1.1.1.1)RPFinterface:Ethernet1/1RPFneighbor:?(2.1.1.1)RPFroute/mask:1.1.1.1/0RPFtype:staticmrouteRPFrecursioncount:0Doingdistance-preferredlookupsacrosstablesip22-75b#showiproute1.1.1.1Routingentryfor1.1.1.0/24Knownvia"ospf1",distance110,metric20,typeintraareaRedistributingviaospf1Lastupdatefrom3.1.1.1onEthernet1/2,00:26:21agoRoutingDescriptorBlocks:*4.1.1.1,from10.0.119.66,00:26:21ago,viaEthernet1/3Routemetricis20,trafficsharecountis1from10.0.119.66,00:26:21ago,viaEthernet1/1Routemetricis20,trafficsharecountis1from10.0.119.66,00:26:21ago,viaEthernet1/2Routemetricis20,trafficsharecountis1ip22-75b#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),01:31:29/00:02:59,RP0.0.0.0,flags:DJCIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet1/4,Forward/Sparse-Dense,01:31:29/00:00:00Ethernet1/1,Forward/Sparse-Dense,01:31:30/00:00:00Ethernet1/2,Forward/Sparse-Dense,01:31:30/00:00:00Ethernet1/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:CTIncominginterface:Ethernet1/1,RPFnbr2.1.1.1,MrouteOutgoinginterfacelist:Ethernet1/4,Forward/Sparse-Dense,01:31:30/00:00:00Ethernet1/2,Prune/Sparse-Dense,00:25:17/00:01:47Ethernet1/3,Prune/Sparse-Dense,00:00:31/00:02:28為什么沒有在所有可用的等價路徑之間進行IP多播負載均衡？此部分為配置IP多播以便在所有可用等價路徑上均衡負載的常見問題提供了一個解決方案。我們以下面的網絡圖為例。在上圖中，路由器75b有三個等價路徑返回到源(1.1.1.1)。您希望在全部三條鏈路上均衡多播流量。可能的修正如同您在多條相等成本路徑看到了請導致以上不需要的返回路徑轉發行為的部分，獨立于協議的組播(PIM)只選擇回程路徑轉發(RPF)檢查的一個接口并且修剪其他。這意味著不會進行負載均衡。要進行負載均衡，需要從冗余鏈路中刪除PIM并在路由器75a與路由器75b之間創建一條隧道。然后您可以在鏈路級別進行負載均衡，并且IP將通過隧道運行。面是隧道的配置。路由器75ainterfaceTunnelOipaddress6.1.1.1255.255.255.0ippimsparse-dense-modetunnelsourceEthernet0/0tunneldestination5.1.1.1interfaceEthernet0/0ipaddress1.1.1.2255.255.255.0ippimsparse-dense-mode!interfaceEthernet0/lipaddress2.1.1.1255.255.255.0!interfaceEthernet0/2ipaddress3.1.1.1255.255.255.0!interfaceEthernet0/3ipaddress4.1.1.1255.255.255.0路由器75binterfaceTunnel0ipaddress6.1.1.2255.255.255.0ippimsparse-dense-modetunnelsourceEthernetl/4tunneldestination1.1.1.2!interfaceEthernetl/1ipaddress2.1.1.2255.255.255.0!interfaceEthernetl/2ipaddress3.1.1.2255.255.255.0!interfaceEthernetl/3ipaddress4.1.1.2255.255.255.0!interfaceEthernetl/4ipaddress5.1.1.1255.255.255.0ippimsparse-dense-modeipmroute0.0.0.00.0.0.0TunnelO配置隧道后，使用showipmroute命令查看組的多播路由(mroute)：ip22-75a#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),O2:4O:31/OO:O2:59,RPO.O.O.O,flags:DIncominginterface:Null,RPFnbrO.O.O.OOutgoinginterfacelist:TunnelO,Forward/Sparse-Dense,OO:2O:55/OO:OO:OO(1.1.1.1,224.1.1.1),O2:4O:32/OO:O3:29,flags:TAIncominginterface:EthernetO/O,RPFnbrO.O.O.OOutgoinginterfacelist:TunnelO,Forward/Sparse-Dense,OO:2O:55/OO:OO:OOip22-75b#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),O2:42:2O/OO:O2:59,RPO.O.O.O,flags:DJCIncominginterface:Null,RPFnbrO.O.O.OOutgoinginterfacelist:TunnelO,Forward/Sparse-Dense,OO:22:53/OO:OO:OOEthernet1/4,Forward/Sparse-Dense,O2:42:2O/OO:OO:OO(1.1.1.1,224.1.1.1),OO:22:53/OO:O2:59,flags:CTIncominginterface:Tunnel0,RPFnbr6.1.1.1,MrouteOutgoinginterfacelist:Ethernet1/4,Forward/Sparse-Dense,00:22:53/00:00:00要檢查多播數據是否均衡分布在三條鏈路上，可查看路由器75a的接口數據傳入接口為9000位/秒：ip22-75a#showinterfacee0/05minuteinputrate9000bits/sec,20packets/sec三個傳出接口每個均顯示3000位/秒：ip22-75a#showinterfacee0/15minuteoutputrate3000bits/sec,7packets/secip22-75a#showinterfacee0/25minuteoutputrate3000bits/sec,7packets/secip22-75a#showinterfacee0/35minuteoutputrate3000bits/sec,7packets/sec為什么在路由器上收到IP多播“INVALID_RP_JOIN”錯誤消息？此部分為常見的IP多播“INVALID_RP_JOIN”錯誤消息提供了一個解決方案。診斷問題-第1部分此錯誤消息在聚合點(RP)接收：00:55:15:%PIM-6-INVALID_RP_JOIN:Received(*,224.1.1.1)Joinfrom1.1.6.2forinvalidRP1.1.5.400:56:15:%PIM-6-INVALID_RP_JOIN:Received(*,224.1.1.1)Joinfrom1.1.6.2forinvalidRP1.1.5.4CiscoIOSSoftwareSystemErrorMessages(CiscoIOS軟件系統錯誤消息)解釋了此錯誤的原因：一個下游PIM路由器發出加入共享樹的消息，但此路由器并不希望接受。這一行為表明此路由器只允許下游路由器加入特定RP。這里可能存在某種過濾。您需要查看一下路由器的配置：interfaceEthernet0/0ipaddress1.1.5.4255.255.255.0ippimsparse-dense-mode!ippimaccept-rp10.2.2.28ippimsend-rp-announceEthernet0/0scope15ippimsend-rp-discoveryscope15!access-list8permit224.0.0.00.255.255.255那么配置中的accept-rp語句的用途是什么呢？在IPMulticastRoutingCommand(IP多播路由命令)中，該文檔說明“要配置路由器以接受指定RP和特定組列表的‘加入'或‘修剪'設置，可以使用ippimaccept-rp全局配置命令。要刪除這項檢查，可使用此命令的no格式。”如果刪除ippimaccept-rp命令，就會出現錯誤消息。我們找到了導致問題的命令，但是如果希望在配置中保留該命令，該如何做呢？您可能啟用了錯誤的RP地址。使用showippimrpmapping命令可以看到正確的RP地址：ip22-75a#showippimrpmappingPIMGroup-to-RPMappingsThissystemisanRP(Auto-RP)ThissystemisanRP-mappingagentGroup(s)224.0.0.0/4RP1.1.5.4(?),v2v1Infosource:1.1.5.4(?),viaAuto-RPUptime:01:00:48,expires:00:02:07根據上面的輸出，1.1.5.4是通過自動RP或其他方式獲得的唯一RP。然而，此路由器是組224.0.0.0/4的唯一RP。因此，上述配置中的pimaccept-rp語句是錯誤的。可能的修正解決方案是糾正ippimaccept-rp語句中的IP地址，如下所示：將此語句：ippimaccept-rp10.2.2.28更改為：ippimaccept-rp1.1.5.48您還可以將該語句更改為接受auto-rp緩存中的內容，并確保訪問列表(在本例中為8)允許必要的多播組范圍。如下面的示例所示：ippimaccept-rpauto-rpaccess-list8permit224.0.0.00.255.255.255診斷問題-第2部分此錯誤消息出現在router2上。router2#*Aug1215:18:17.891:%PIM-6-INVALID_RP_JOIN:Received(*,224.0.1.40)Joinfrom0.0.0.0forinvalidRP2.1.1.1檢查以確認router2是否是組224.1.1.1的RP：router2#showippimrpmapPIMGroup-to-RPMappingsGroup(s)224.0.0.0/4RP1.1.1.1(?),v2v1Infosource:1.1.1.1(?),electedviaAuto-RPUptime:00:21:26,expires:00:02:24router2#224.1.1.1的RP是1.1.1.1。檢查它是否是router2的其中一個接口：router2#showipinterfacebriefInterfaceIP-AddressOK?MethodStatusProtocolEthernet0/01.1.1.2YESNVRAMupupEthernet1/02.1.1.1YESNVRAMupupEthernet2/0unassignedYESNVRAMadministrativelydowndownrouter2#由于router2不是RP,因此不應收到此RP-Join數據包。檢查下游路由器為什么將“加入"發送給router2，本來不應如此：router3#showippimrpmapPIMGroup-to-RPMappingsGroup(s)224.0.0.0/4RP1.1.1.1(?),v2v1Infosource:1.1.1.1(?),electedviaAuto-RPUptime:00:24:30,expires:00:02:16Group(s):224.0.0.0/4,Static-OverrideRP:2.1.1.1(?)router3#可以看到，router3靜態配置了RP信息，指向router2，這是不對的。這解釋了為什么router3將RP-Join發送給router2。可能的修正將router2作為組224.1.1.1的RP，或者更改router3的設置使其引用正確的RP地址。router3#showrun|irpippimrp-address2.1.1.1overriderouter3#configureterminalEnterconfigurationcommands,oneperline.EndwithCNTL/Z.router3(config)#noippimrp-address2.1.1.1overriderouter3(config)#exitrouter3#更正router3的配置后,router3將引用正確的RP地址,這時便會停止顯示錯誤消息。router3#showippimrpmapPIMGroup-to-RPMappingsGroup(s)224.0.0.0/4RP1.1.1.1(?),v2v1Infosource:1.1.1.1(?),electedviaAuto-RPUptime:00:30:45,expires:00:02:02router3#CGMP不能防止多播數據包泛洪此部分說明組播信息包不需要的泛濫如何能發生，當Cisco組管理協議(CGMP)在特定子網時的所有路由器沒有啟用,并且此問題如何可以避免。我們以下面的網絡圖為例。

E0/02/3Catalyst5000

SwitchA2/4E1/3E1/4OkRouter75a2/6Router75bSourceHostE0/02/3Catalyst5000

SwitchA2/4E1/3E1/4OkRouter75a2/6Router75bSourceHost診斷問題在上圖中，Catalyst5000交換機A中的靜態CAM表未顯示任何所填充的正確端口。配置了CGMP的路由器未發送CGMP數據包。SwitchA上的setcgmpenable命令和路由器75a的E0/2接口上的ipcgmp命令已經正確配置了CGMP。然而，當發出showmulticastgroup命令時，在SwitchA上看不到多播組。Console>(enable)showmulticastgroupCGMPenabledIGMPdisabledIGMPfastleavedisabledGMRPdisabledVLANDestMAC/RouteDes[CoS]DestinationPortsorVCs/[ProtocolType]TotalNumberofEntries=0此命令的輸出應當顯示其中具有配置了CGMP的路由器的每個端口（端口2/3）以及其中具有意向接收方的每個端口（端口2/6）。由于列出了0，因此不管希望與否，多播流量都可能會不必要地泛洪到所有端口。觀察檢查路由器75a上是否有任何獨立多播協議（PIM）鄰居：ip22-75a#showippimneighborPIMNeighborTable

NeighborAddressInterface2.1.1.1NeighborAddressInterface2.1.1.1Ethernet0/2UptimeExpiresVerMode00:07:4100:01:34v2上面的輸出顯示，路由器75a能夠通過交換機A將路由器75b視為一個有效PIM鄰居。現在檢查是否能在路由器上收到正確的多播路由(mroute)信息：ip22-75a#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),00:14:55/00:02:59,RP0.0.0.0,flags:DJCIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist: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:CTAIncominginterface:Ethernet0/1,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0/2,Forward/Sparse-Dense,00:14:56/00:00:00上面的輸出顯示路由器75a將多播數據包從E0/2轉發到交換機A。下面的輸出顯示路由器75b獲取多播數據包并將其正確轉發出去：ip22-75b#showipmroute224.1.1.1IPMulticastRoutingTableFlags:D-Dense,S-Sparse,C-Connected,L-Local,P-PrunedR-RP-bitset,F-Registerflag,T-SPT-bitset,J-JoinSPTM-MSDPcreatedentry,X-ProxyJoinTimerRunningA-AdvertisedviaMSDPTimers:Uptime/ExpiresInterfacestate:Interface,Next-HoporVCD,State/Mode(*,224.1.1.1),00:17:57/00:02:59,RP0.0.0.0,flags:DJCIncominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet1/3,Forward/Sparse-Dense,00:17:57/00:00:00Ethernet1/4,Forward/Sparse-Dense,00:17:57/00:00:00(1.1.1.1,224.1.1.1),00:00: