Multicast Forwarding Problem

Unanswered Question
Oct 1st, 2007


I have a problem with multicast traffic. I have a test sender and group, the traffic worked for weeks and has now stopped.

I have tried all the troubleshooting I can think of, the 1st hop router from the sender shows a S,G pair and the counters for this groups are increasing, but I have put a sniffer on the destination VLAN (directly connected to this router) and there is nothing there!

I have tried clearing the mroutes and restarted the sender and group. The forwarding tree looks good and there are no RPF errors that I can see.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
ankbhasi Mon, 10/01/2007 - 02:08

Hi David,

Can you give little more details about your setup. As you said receiver is directly connected to this router is sender and receiver on same subnet?

Also when you see receiver does not see any multicast traffic can you confirm on your router you see igmp entry. Can you check with "sh ip igmp group" and confirm if you see any of your client as last reporter? Also can you check on your switch if you see snooping entry for the port on which your client exist and mrouter port entry?



davidjbradley Mon, 10/01/2007 - 02:58

Hi, thanks for you reply...

This is the setup.

Sender on VLAN A -> Router 1 -> VLAN B -> Router 2 -> Receiver on VLAN C

Router 2 sees the IGMP report from the receiver.

Router 2 builds an in-VLAN B, out-VLAN C mroute

Router 1 build an in VLAN-A, out VLAN-B mroute, if you add 'counters' you see traffic stats for the mroute and they are increasing.

I put a sniffer on VLAN B does not see any multicast packets.

You can receive the multicast on the local VLAN and the TTL is set at 15...

I have done a show ip igmp groups and my machine is the last reporter. thr mrouter shows the router. If you do a show ip igmp snooping stats you don't see anything, but there again you cannot see an entry anywhere and other mutlicast is running OK


Kevin Dorrell Mon, 10/01/2007 - 03:37


You say that show ip igmp snooping mrouter shows the correct router port. I presume that is so on both VLANs C and B, is it?

How is VLAN B implemented? Is it a layer-2 switch and two routers, or is it two layer-3 switches (or more)?

Strange that router 1 is counting traffic stats for the mroute, but you cannot see them on VLAN B.

How are you sniffing VLAN B? I guess an access port on VLAN B is not sufficient unless your sniffer can generate IGMP, or you switch IGMP snooping off on VLAN B. Therefore I suppose you are doing a SPAN monitor session with VLAN B as source, right?

Kevin Dorrell


davidjbradley Mon, 10/01/2007 - 05:21

hi Kevin,

I've attached a rather crude drawing because there is another part of the design that could be important.

The VLAN shown in the pictur (VLAN B) is a layer 2 core VLAN. A third router has a connection to the RP.

The mrouter entry on both routers 1 and 2 list thier connections to the third router.

Router 1 has an S,G and router 2 has a *,G it's mrouter is listed as it's router 3 link (which is in VLAN B), this is towards the RP.

As for sniffing, I has used a NAM on router 3, sniffing VLAN B and also another type of sniffer on a SPAN port on router 1.

I have also captured RP joins between router 2 and the third router (towards the RP) and it did assume this should be enough because router 3 is aware of the S,G. Perhaps the RP needs to be in the loop...?! I have not tried testing if router 3 is sending joins to the RP.


Kevin Dorrell Mon, 10/01/2007 - 05:54

I am looking around for ideas about this, so this post may look a bit disjoined.

I think the RP can be off the screen as you have it, but it does look like a split-horizon issue on R3. But you say this problem is new ... so has the architecture changed?

You should, of course, check the mroute all the way back to the RP. Does each router on VLAN B see both of the others as PIM neighbors? And do the switches on VLAN see all three router ports as mrouter?

While I was researching, I found this document with some useful diagnostic techniques in it. I wondered whether the problem they are talking about was relevant to VLAN B, but I don't think so.

Those are my thoughts for the moment. I shall keep researching.




This Discussion