IP組播故障排除指南

內(nèi)容前言前提條件需求使用的組件慣例背景信息由于RPF故障，路由器未向主機(jī)轉(zhuǎn)發(fā)多播數(shù)據(jù)包診斷問題可能的修正由于源端TTL設(shè)置，路由器未向主機(jī)轉(zhuǎn)發(fā)多播數(shù)據(jù)包診斷問題可能的修正由于路由器的TTL閾值，路由器未轉(zhuǎn)發(fā)多播數(shù)據(jù)包診斷問題可能的修正多個成本相等的路徑造成多余的返回路徑轉(zhuǎn)發(fā)行為診斷問題可能的修正為什么沒有在所有可用的等價路徑之間進(jìn)行IP多播負(fù)載均衡？可能的修正為什么在路由器上收到IP多播“INVALID_RP_JOIN”錯誤消息?診斷問題-第1部分診斷問題-第2部分CGMP不能防止多播數(shù)據(jù)包泛洪診斷問題觀察可能的修正由于源端/接收端的放置問題，CGMP不能防止多播數(shù)據(jù)包泛洪診斷問題可能的修正CGMP不能防止某些組地址的多播數(shù)據(jù)包泛洪可能的修正收到重復(fù)的多播數(shù)據(jù)包流原因1可能的修復(fù)方法1原因2可能的修復(fù)方法2原因3可能的修復(fù)方法3多播數(shù)據(jù)包為什么被丟棄?原因1可能的修復(fù)方法1原因2可能的修復(fù)方法2前言本文介紹IP多播的常見問題和解決方案前提條件需求本文檔沒有任何特定的要求使用的組件本文檔不限于特定的軟件和硬件版本慣例有關(guān)文檔規(guī)則的詳細(xì)信息，請參閱Cisco技術(shù)提示規(guī)則。背景信息在排除多播路由故障時，最主要的問題是源地址。多播有一個反向路徑轉(zhuǎn)發(fā)檢查(RPF檢查)的概念。當(dāng)多播數(shù)據(jù)包到達(dá)某個接口時，RPF進(jìn)程將檢查以確保此傳入接口是單播路由用于抵達(dá)多播數(shù)據(jù)包源的傳出接口。此RPF檢查進(jìn)程將防止出現(xiàn)環(huán)路。組播路由不轉(zhuǎn)發(fā)數(shù)據(jù)包，除非數(shù)據(jù)包的source通過反向路徑轉(zhuǎn)發(fā)(RPF)檢查。數(shù)據(jù)包通過此RPF檢查后，多播路由將僅根據(jù)目標(biāo)地址轉(zhuǎn)發(fā)數(shù)據(jù)包。類似單播路由，組播路由有幾份可用的協(xié)議，例如獨立于協(xié)議的組播密集模式(PIM-DM)，PIM稀疏模式(PIM-SM)，距離矢量組播路由協(xié)議(DVMRP)、組播邊界網(wǎng)關(guān)協(xié)議(MBGP)和組播源發(fā)現(xiàn)協(xié)議(MSDP)。本文將通過案例研究詳細(xì)介紹各種問題的解決過程。您將了解用于迅速查明問題的命令并學(xué)習(xí)如何解決問題。這里列出的案例研究適用于各種協(xié)議，除非特別說明。由于RPF故障，路由器未向主機(jī)轉(zhuǎn)發(fā)多播數(shù)據(jù)包此部分提供一解決方案給IP多播反向路徑轉(zhuǎn)發(fā)(RPF)失敗的常見問題。我們以下面的網(wǎng)絡(luò)圖為例。2.1.1.1HostASourceRouter72a2.1.1.1HostASourceRouter72aSendingto224.1.1.1在上圖中，多播數(shù)據(jù)包從IP地址為1.1.1.1的服務(wù)器進(jìn)入路由器75a的E0/0并發(fā)送到組224.1.1.1。這稱為(S,G)或(1.1.1.1,224.1.1.1)。診斷問題直接連接到路由器75a的主機(jī)將接收該多播饋送，但直接連接到路由器72a的主機(jī)不會進(jìn)行接收。首先，發(fā)出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密集模式協(xié)議(D標(biāo)志表明這是密集模式)，因此請忽略*,G條目而只關(guān)注S,G條目。該條目表明多播數(shù)據(jù)包來自地址為1.1.1.1的服務(wù)器并發(fā)送到多播組224.1.1.1。數(shù)據(jù)包在Ethernet0/0接口傳入并在Ethernet0/1接口轉(zhuǎn)發(fā)出去。這是一個完美的方案。發(fā)出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命令可以發(fā)現(xiàn)，傳入接口為Ethernet2/0而不是預(yù)期的Etheret3/1。發(fā)出showipmroute224.1.1.1count命令以查看該組是否有任何多播流量抵達(dá)路由器72a以及接下來發(fā)生的情況：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計數(shù)中可以看到流量由于RPF故障而被丟棄：total471drops,duetoRPFfailure-471…發(fā)出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路由表和靜態(tài)多播路由表。計算RPF接口時，主要使用管理距離確定RPF計算所基于的信息源。具體規(guī)則如下：?在所有以前的RPF數(shù)據(jù)源中搜索源IP地址的匹配項。如果使用共享樹，則使用RP地址而不是源地址。?如果找到多個匹配路由，則使用管理距離最短的路由。?如果管理距離相等，則使用以下優(yōu)先順序：靜態(tài)多播路由DVMRP路由MBGP路由單播路由如果某個路由在同一個路由表中有多個條目，則使用最長的匹配路由。showiprpf1.1.1.1命令輸出表明RPF接口為E2/0,但傳入接口應(yīng)該是E3/1。發(fā)出showiproute1.1.1.1命令以查看RPF接口為什么與預(yù)期接口不同。ip22-72a#showiproute1.1.1.1Routingentryfor1.1.1.1/32Knownvia"static",distance1,metric0(connected)RoutingDescriptorBlocks:*directlyconnected,viaEthernet2/0Routemetricis0,trafficsharecountis1從此showiproute1.1.1.1命令的輸出中可以看到有一個靜態(tài)/32路由,它導(dǎo)致選擇了錯誤的接口作為RPF接口。發(fā)出某些debug命令進(jìn)行進(jìn)一步調(diào)試：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數(shù)據(jù)包自E3/1傳入,這是正確的。然而,由于這不是單播路由表用于進(jìn)行RPF檢查的接口,因此出現(xiàn)掉包。注意：調(diào)試數(shù)據(jù)包具有一定危險。數(shù)據(jù)包調(diào)試會觸發(fā)非常占用CPU資源的多播數(shù)據(jù)包交換進(jìn)程。此外,數(shù)據(jù)包調(diào)試還會產(chǎn)生大量輸出,由于向控制臺端口輸出過慢,從而可能導(dǎo)致將路由器完全掛起。在調(diào)試數(shù)據(jù)包之前,切記要禁用向控制臺的日志輸出,并啟用將日志輸出到內(nèi)存緩沖區(qū)。為此,需配置nologgingconsole和loggingbuffereddebugging。可以使用showlogging命令查看調(diào)試結(jié)果?？赡艿男拚梢愿膯尾ヂ酚杀硪詽M足此要求,也可以添加靜態(tài)多播路由以強(qiáng)制多播的RPF使用特定接口,而不管單播路由表的設(shè)置如何。添加靜態(tài)多播路由：ip22-72a(config)#ipmroute1.1.1.1255.255.255.2552.1.1.1此靜態(tài)多播路由表明，要到達(dá)地址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中的發(fā)送數(shù)據(jù)包數(shù)增加了，并且HostA收到數(shù)據(jù)包。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設(shè)置，路由器未向主機(jī)轉(zhuǎn)發(fā)多播數(shù)據(jù)包因為存活時間(TTL)值消耗到零，此部分提供一解決方案給IP多播數(shù)據(jù)包常見問題不轉(zhuǎn)發(fā)的。由于多播應(yīng)用的情況較多，因此這個問題很常見。多播應(yīng)用主要設(shè)計用于LAN,因此會將TTL設(shè)置為一個較低的值，甚至為1。我們以下面的網(wǎng)絡(luò)圖為例。SourceSendingto224.1.1.1診斷問題在上圖中，路由器A并不將來自源的數(shù)據(jù)包轉(zhuǎn)發(fā)至路由器B所直接連接的接收方。查看路由器A的showipmroute命令的輸出以檢查多播路由狀態(tài)：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發(fā)現(xiàn)組。但是這里沒有為224.1.1.1列出源。除了“*,224.1.1.1”外，您還應(yīng)當(dāng)看到“1.1.1.1,224.1.1.1”。發(fā)出showiprpf命令發(fā)現(xiàn)它是否是反向路徑轉(zhuǎn)發(fā)(RPF)發(fā)貨：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對應(yīng)于源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根據(jù)上面的輸出，路由器并未識別出任何活動流量。ROUTERA#debugipmpacketIPmulticastpacketsdebuggingison或許接收方?jīng)]有發(fā)送任何互聯(lián)網(wǎng)組管理協(xié)議(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密集模式是一個泛洪和修剪協(xié)議，因此沒有加入，但是有嫁接。由于路由器B未從路由器A接收到泛洪，因此它并不知道向何處發(fā)送嫁接。您可以使用嗅探器捕捉和showiptraffic命令進(jìn)行檢查以查看是否是TTL問題：ROUTERA#showiptrafficIPstatistics:Rcvd:248756total,1185localdestination0formaterrors,0checksumerrors,63744badhopcount0unknownprotocol,0notagateway0securityfailures,0badoptions,0withoptions上面的輸出顯示有63744個壞跳計數(shù)。每次鍵入此命令時，壞跳計數(shù)都將增加。這是一個強(qiáng)烈信號，表明發(fā)送方使用TTL=1發(fā)送數(shù)據(jù)包，而路由器A將其衰減為零。這導(dǎo)致壞跳計數(shù)字段不斷增加?？赡艿男拚鉀Q此問題，需要增加TTL。這要在發(fā)送方的應(yīng)用級別進(jìn)行設(shè)置。有關(guān)詳細(xì)信息，請參閱您的多播應(yīng)用說明手冊。完成設(shè)置后，路由器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閾值，路由器未轉(zhuǎn)發(fā)多播數(shù)據(jù)包此部分為常見的由于TTL閾值設(shè)置過低而導(dǎo)致IP多播流量未能到達(dá)接收方的問題提供了一個解決方案。我們以下面的網(wǎng)絡(luò)圖為例。診斷問題在上圖中，接收方未收到來自源的多播數(shù)據(jù)包。在源和路由器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將數(shù)據(jù)包從Ethernet0/1轉(zhuǎn)出。要絕對確定路由器75a是否轉(zhuǎn)發(fā)了數(shù)據(jù)包，請只為此源和多播組執(zhí)行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并未轉(zhuǎn)發(fā)多播數(shù)據(jù)包，因為已達(dá)TTL閾值。檢查路由器配置以查看是否能找到原因。下面的輸出表明了問題所在：interfaceEthernet0/1ipaddress2.1.1.1255.255.255.0ippimsparse-dense-modeipmulticastttl-threshold15路由器的TTL閾值為15，但這并不意味著任何大于15的TTL都不會予以發(fā)送。事實恰恰相反。該應(yīng)用使用TTL15進(jìn)行發(fā)送。當(dāng)它到達(dá)路由器75a時，多播數(shù)據(jù)包的TTL將小于15。ipmulticastttl-threshold<value>命令意味著TTL低于指定閾值（本例中為15）的任何數(shù)據(jù)包都不會進(jìn)行轉(zhuǎn)發(fā)。該命令通常用于提供一個界限，以防止內(nèi)部多播流量流到Intranet以外?？赡艿男拚梢允褂胕pmulticastttl-threshold<value>命令的no格式刪除該命令，這將恢復(fù)默認(rèn)TTL閾值0；也可以降低TTL閾值以便能夠傳遞流量。多個成本相等的路徑造成多余的返回路徑轉(zhuǎn)發(fā)行為這區(qū)分顯示組播源的等價路徑如何能引起不需要的回程路徑轉(zhuǎn)發(fā)（RPF）行為。此外還會說明如何配置IP多播以避免這種行為。我們以下面的網(wǎng)絡(luò)圖為例。診斷問題在上圖中，路由器75b有三個等價路徑返回到源（1.1.1.1），并且它選擇的RPF首選鏈路并不是您所希望的。當(dāng)面對指向源的多個等價路徑時，IP多播會選擇其獨立多播協(xié)議（PIM）鄰居具有最高IP地址的接口作為傳入接口，然后將修剪發(fā)送給其他鏈路上的PIM鄰居?？赡艿男拚腎P多播選擇作為其傳入接口的接口，可執(zhí)行下列操作之一：?只在希望多播流經(jīng)的接口上配置PIM,這意味著要犧牲多播冗余。?更改子網(wǎng)，以使最高IP地址位于您希望作為多播主鏈路的鏈路上。?創(chuàng)建一個從所需多播接口傳出的靜態(tài)多播路由（mroute），這意味著要犧牲多播冗余。為舉例說明，我們將創(chuàng)建一個靜態(tài)多播路由。在安裝靜態(tài)多播路由之前，您會在下面的輸出中看到路由表為源地址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配置了靜態(tài)多播路由后，您會在此輸出中看到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為什么沒有在所有可用的等價路徑之間進(jìn)行IP多播負(fù)載均衡？此部分為配置IP多播以便在所有可用等價路徑上均衡負(fù)載的常見問題提供了一個解決方案。我們以下面的網(wǎng)絡(luò)圖為例。在上圖中，路由器75b有三個等價路徑返回到源(1.1.1.1)。您希望在全部三條鏈路上均衡多播流量?？赡艿男拚缤诙鄺l相等成本路徑看到了請導(dǎo)致以上不需要的返回路徑轉(zhuǎn)發(fā)行為的部分，獨立于協(xié)議的組播(PIM)只選擇回程路徑轉(zhuǎn)發(fā)(RPF)檢查的一個接口并且修剪其他。這意味著不會進(jìn)行負(fù)載均衡。要進(jìn)行負(fù)載均衡，需要從冗余鏈路中刪除PIM并在路由器75a與路由器75b之間創(chuàng)建一條隧道。然后您可以在鏈路級別進(jìn)行負(fù)載均衡，并且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要檢查多播數(shù)據(jù)是否均衡分布在三條鏈路上，可查看路由器75a的接口數(shù)據(jù)傳入接口為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軟件系統(tǒng)錯誤消息)解釋了此錯誤的原因：一個下游PIM路由器發(fā)出加入共享樹的消息，但此路由器并不希望接受。這一行為表明此路由器只允許下游路由器加入特定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和特定組列表的‘加入'或‘修剪'設(shè)置，可以使用ippimaccept-rp全局配置命令。要刪除這項檢查，可使用此命令的no格式?！比绻麆h除ippimaccept-rp命令，就會出現(xiàn)錯誤消息。我們找到了導(dǎo)致問題的命令，但是如果希望在配置中保留該命令，該如何做呢？您可能啟用了錯誤的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根據(jù)上面的輸出，1.1.5.4是通過自動RP或其他方式獲得的唯一RP。然而，此路由器是組224.0.0.0/4的唯一RP。因此，上述配置中的pimaccept-rp語句是錯誤的?？赡艿男拚鉀Q方案是糾正ippimaccept-rp語句中的IP地址，如下所示：將此語句：ippimaccept-rp10.2.2.28更改為：ippimaccept-rp1.1.5.48您還可以將該語句更改為接受auto-rp緩存中的內(nèi)容，并確保訪問列表(在本例中為8)允許必要的多播組范圍。如下面的示例所示：ippimaccept-rpauto-rpaccess-list8permit224.0.0.00.255.255.255診斷問題-第2部分此錯誤消息出現(xiàn)在router2上。router2#*Aug1215:18:17.891:%PIM-6-INVALID_RP_JOIN:Received(*,224.0.1.40)Joinfrom0.0.0.0forinvalidRP2.1.1.1檢查以確認(rèn)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,因此不應(yīng)收到此RP-Join數(shù)據(jù)包。檢查下游路由器為什么將“加入"發(fā)送給router2，本來不應(yīng)如此：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靜態(tài)配置了RP信息，指向router2，這是不對的。這解釋了為什么router3將RP-Join發(fā)送給router2?？赡艿男拚龑outer2作為組224.1.1.1的RP，或者更改router3的設(shè)置使其引用正確的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不能防止多播數(shù)據(jù)包泛洪此部分說明組播信息包不需要的泛濫如何能發(fā)生，當(dāng)Cisco組管理協(xié)議(CGMP)在特定子網(wǎng)時的所有路由器沒有啟用,并且此問題如何可以避免。我們以下面的網(wǎng)絡(luò)圖為例。

E0/02/3Catalyst5000

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

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

NeighborAddressInterface2.1.1.1NeighborAddressInterface2.1.1.1Ethernet0/2UptimeExpiresVerMode00:07:4100:01:34v2上面的輸出顯示，路由器75a能夠通過交換機(jī)A將路由器75b視為一個有效PIM鄰居?，F(xiàn)在檢查是否能在路由器上收到正確的多播路由(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將多播數(shù)據(jù)包從E0/2轉(zhuǎn)發(fā)到交換機(jī)A。下面的輸出顯示路由器75b獲取多播數(shù)據(jù)包并將其正確轉(zhuǎn)發(fā)出去：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: