Multicast is enabled in the network butusers cannot demand the multicast service. |
Possible Causes 1) The multicast receiver is not connectedto the server and therefore no unicast route is established. 2) Multicast configuration is abnormal onthe intermediate switches. 3) Packet TX/RX is abnormal between themulticast receiver and server. Step 1: Check whether the connectionbetween the multicast receiver and server is normal. Step 2: Check whether configurations amongswitches are correct. Step 3: Check whether the multicast sourceand receiver can properly send and receive multicast packets. Step 4: Check whether multicast entries onthe multicast source and receiver are normal. Step 5: Check whether IGMP snooping entriesare created on the access switches. Step 6:Collectfault information and submitcases to Ruijie Service Portal. Step1: Check whether the connection between the multicastreceiver and server is normal.1.Verify the following items carefully: - Interfaces between the server and theswitches - IP address and MAC address of the server - Interfaces between the switches and theirIP addresses - Interfaces between the PC and theswitches - IP address and MAC address of the PC - IP address of the gateway 2.Check whether the multicast serverproperly communicates with the multicast receiver on demand. (Before demanding,check routing problems to ensure that multicast routing protocol iscommunicable.) 1.Check basic configurations in PIM-DM mode: 1) Whether themulticast routing protocol is globally enabled 2) Whether all the interfaces to send or receivemulticast packets are enabled with PIM-DM and IGMP (IGMP is enabled by defaultwhen multicast routing is enabled.) 2.Check advanced configurations in PIM-DMmode: 1) Whether neighborfiltering is incorrectly configured 2) Whether ACLs foroptimized filtering are incorrectly configured which causes legitimatemulticast and IGMP packets to be discarded 3.Check basic configurations in PIM-SM mode: 1) Whether themulticast routing protocol is globally enabled 2) Whether all theinterfaces to send or receive multicast packets are enabled with PIM-SM andIGMP (IGMP is enabled by default when multicast routing is enabled.) 3) Whether staticor dynamic RPs (C-RP and C-BSR) are configured 4.Check advanced configurations in PIM-SMmode: 1) Whether neighborfiltering is incorrectly configured 2) Whether the RPregistry packet filtering is correctly configured 3) Whether the BSRrange limit is correctly configured 4) Whether the legitimateC-RP range and multicast group are correctly configured 5) Whether ACLs foroptimized filtering are incorrectly configured which causes legitimatemulticast and IGMP packets to be discarded 5.Check advanced configurations of IGMP: 1) Whether IGMPaccess group is configured for multicast control and whether ACLs are correctlyadded 2) Whether theimmediate-leave feature is incorrectly configured on a multi-user interface 3) Whether the IP IGMPlimit is too small on an interface. The default value is 1,024. 6.Check the IGMP snooping configuration onthe access switches: For example, runthe show ip igmp snooping command: Ruijie(config)# show ip igmp snooping IGMP Snoopingrunning mode: SVGL SVGL vlan: 1 SVGL profilenumber: 11 Source port checkisable Source ip checkisable IGMP Fast-Leaveisable IGMP Reportsuppress: Disable 1) Check whetherIVGL or SVGL is configured. (SVGL must be used with the IGMP profile.) 2) In the IGMPprofile, only data packets in the multicast address range can be forwardedacross VLANs. By default, all multicast groups are not in the SVGL range andall the multicast packets are discarded. 3) Check whether therouting interfaces are statically configured or automatically learning andwhether source interface/IP address check is enabled. (When troubleshooting thefault, you can disable source interface check to prevent related advancedsecurity functions from influencing troubleshooting.) 4) Check whetherIGMP snooping filter is enabled on user interfaces. If yes, disable it beforetroubleshooting. Step3: Check whether the multicast source and receiver canproperly send and receive multicast packets.Capture packets on the application layer tocheck whether the multicast source and receiver properly work. In some cases,the multicast source server may be incorrectly deployed and parameter settingsare incorrect on the multicast receiver. You can exclude or replace the faultydevices. Packet capture on the multicast sourcehelps understand parameters of multicast packets, for example, fragmentation,multicast packet size, source and destination IP addresses, port, and TTL.Generally, these parameters are useful for troubleshooting. Step4: Check whether correct multicast routing entries arecreated on intermediate switches (from the multicast source to the multicast receiver).(Prerequisite: ensure the unicast routing is normal.)PIM-DM 1. Check the multicast routing table inPIM-DM mode: ruijie#show ip mroute IPMulticast Routing Table Flags:I - Immediate Stat, T - Timed Stat, F - Forwarder installed Timers:Uptime/Stat Expiry InterfaceState: Interface (TTL) Multicastsource Multicast destination (210.34.130.27,224.3.1.2), uptime 00:18:04 (creation time), stat expires 00:01:21 (expirationtime) OwnerPIMDM, Flags: TF Incominginterface: TenGigabitEthernet 3/1 //Enter the RPF interface. Outgoinginterface list: Outgoing interface TenGigabitEthernet3/2 (1) 2. Check detailed entries: show ip pim dense-mode mroute (protocol table) Ruijie#show ip pim dense-mode mroute PIM-DMMulticast Routing Table (1.1.1.111,229.1.1.1) MRTlifetime expires in 205 seconds RPFNeighbor: 50.50.50.1, Nexthop: 50.50.50.1, VLAN 4 RPF check UpstreamIF: VLAN 4 UpstreamState: Pruned, PLT:200 AssertState: NoInfo DownstreamIF List: FastEthernet0/45: DownstreamState: NoInfo AssertState: Loser, AT:170 Notes n The preceding example listsinformation of the entry (1.1.1.111, 229.1.1.1), among which the MRT lifetimeis 205 seconds. The RPF neighbor is 50.50.50.1, which is the next hop. The outgoinginterface of the next hop is VLAN 4. The upstream interface VLAN 4 is in Prunedstate, indicating that the entry has no downstream forwarding egress. Thedownstream interface FastEthernet0/45 is in NoInfo state and its Assert stateis Loser. FastEthernet 0/45 is not a forwarding egress. Pay attention to three points: 1. whether entries arecreated; 2. whether ingresses meet the expectation; 3. whether forwardinginterfaces are available. 3. If entries are not created, check thefollowing items: 1) Whether PIM neighbors are normal show ip pim dense-mode neighbor show ip pim dense-mode interface show ip mvif 2) Whether PIM packets are properly sent and received(packet capture or debugging) file:///C:/Users/Admin/AppData/Local/Temp/msohtmlclip1/01/clip_image002.jpg Since debugging is risky (you may even need to restart thedevice to recover services), collect such information after the customer isnotified of the risks and agrees on debugging. Debugging is recommended in lowpeak hours. (Perform careful assessment before debugging a core switch.) Ifpacket capture is required for troubleshooting, perform debugging and packetcapture at the same time. show ip pim dense-mode track debug ip pim sparse-mode fsm debug ip pim sparse-mode nsm debug ip pim sparse-mode all PIM-SM 1. Check the multicast routing table inPIM-SM mode: PIM hastwo trees: shortest path tree (SPT) from the multicast source to the rendezvouspoint (RP) and rendezvous point tree (RPT) from the multicast destination tothe RP. Themulticast routing table of the RPT differs from that of the SPT. Since RPT canbe shared by many sources, its protocol routing entries are in (*,G) mode(including RP information). The routing entries of the SPT are in (S,G) mode.The RP has both (*,G) [RPF next hop is 0.0.0.0] and (S,G) entries. show ip mroute OnRuijie switches, the show ip mroutecommand displays information about the forwarding table instead of the protocoltable. Whether in PIM-DM or PIM-SM mode or not, the entries are in (S,G)format. On Cisco switches of the same type, the entries in the show ip mroute command are in (*,G)format. RuijiePIM-SMv4/v6 does not support forwarding based on (*,G) entries. Inimplementation, * indicating allsources changes to s indicating aspecific source. The switch uses the NSM module to forward protocol tablesbased on (S,G) entries, which is reflected in the debug nsm command. Multicast forwarding is based on the forwardingtable, which is reflected in the debugmsf command. The show ip mroute and show ip igmp-sngda commands respectively provide Layer-3 and Layer-2tables to user interfaces. The show msf msc command providesmulticast forwarding tables to debugging interfaces. The show ip pimsparse-mode mroute command displays routingentries in PIM-SM mode. 2. Check detailed entries: show ip pim sparse-mode mroute show ip mroute //Layer-3 table show ip igmp-sn gda //Layer-2 table show msf msc 3. If protocol entries are not created,check the following items: 1) Whether PIM neighbors are normal show ip pim sparse-mode neighbor [detail] show ip pim sparse-mode interface show ip mvif 2) Whether RP mapping exists show ip pim sparse-mode rp mapping 3) BSR information show ip pim sparse-mode bsr-router 4) Whether the PIM packet RX/RX and processing mechanismare normal (by packet capture or debugging) show ip pim sparse-mode track debug ip pim sparse-mode packets debug ip pim sparse-mode event debug ip pim sparse-mode state debug ip pim sparse-mode nsm debug ip pim sparse-mode mfc debug ip pim sparse-mode all Step5: Check whether IGMP snooping entries are created onthe access switches.IGMP snooping can effectively restrictmulticast data from spreading on Layer-2 network. If IGMP snooping is disabled,multicast packets are regarded as broadcast packets and forwarded in the VLAN.If IGMP snooping is enabled, user interfaces with demanding requirements canreceive related data. If multicast becomes abnormal after SNP is enabled, checkSNP entry creation. Check entries. Ruijie#show ip igmp snooping gda-table MulticastSwitching Cache Table D: DYNAMIC S: STATIC M: MROUTE (*,224.1.1.1, 100): VLAN(100) 2 OPORTS: GigabitEthernet 0/13(M) GigabitEthernet 0/22(D) Ifentries are not created, check the following items: 1) Runthe show ip igmp group and debug ip igmpevents commands or capture packets on the gateway tocheck the TX/RX status of IGMP packets. 2)Capture packets on the PC to check the TX/RX status of IGMP packets. 3) Runthe debug igmp-snp event, debug igmp-snp packets, and debug igmp-snp msf (optional) commands on the access switches. Step6: Collect fault information on all Layer-3 switches betweenthe multicast source and the multicast receiver.1 Collect basic information: showrun showver showver slo showint co su //Run this command every 15seconds for three times if the fault occurs. showint co rate showint co //Run this command every 15seconds for three times if the fault occurs. showcpu showcpu mb show ipmroute show iproute show iproute cou show ipigmp groups show ipigmp groups detail showlog In PIM-DM mode, run the following commands to collectinformation: show ippim dense-mode mroute show ippim dense-mode neighbor show ippim dense-mode interface show ipmvif show ippim dense-mode track In PIM-SM mode, run thefollowing commands to collect information: show ip pim sparse-mode mroute show ip pim sparse-mode neighbor [detail] show ip pim sparse-mode interface show ip mvif show ip pim sparse-mode rp mapping show ip pim sparse-mode bsr-router show ip pim sparse-mode track 2. Collect information on the accessswitches. show run show ver show ver slo show int co su //Run this commandevery 15 seconds for three times if the fault occurs. show int co rate show int co //Run this commandevery 15 seconds for three times if the fault occurs. show cpu show ip igmp snooping show ip igmp snooping gda-table show ip igmp snooping interfaces show ip igmp snooping mrouter show ip igmp snooping querier show ip igmp snooping statistics show ip igmp profile show msf nsf show msf msc 3. Perform SPAN packet capture on switchesbetween the multicast source and the multicast receiver. Capture packets first on the accessswitches and then on upstream switches to identify the switches that thepackets can reach and that do not forward multicast data flow. |
This site contains user submitted content, comments and opinions and is for informational purposes only. Ruijie may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Ruijie can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Ruijie disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Ruijie Community Terms of Use.
More ways to get help: Visit Support Videos, call us via Service Hotline, Facebook or Live Chat.
©2000-2023 Ruijie Networks Co,Ltd