Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Well I am up to IPexpert Volume 1 lab 17. Knowing full well that it would throw a beat down on me hardcore, I decided to re-read the chapters in the CCIE R/S exam cert guide involving mcast, and also watch through both the VOD lecture and configuration on the blended learning solution. As I was watching the configuration video, I was configuring things along with Scott on my own home lab. One small difference between my home lab and the one in the video is that I have a mix of ethernet/FastEthernet interfaces…this turned out to actually cause me to learn a LOT more over the last few days. So while going through the configurations I ran into an issue…and it was really bugging me. I wanted to understand exactly what was going on, and I could not explain it, so I started digging around (curiosity and the desire to know EXACTLY what is going on must be a common trait among us CCIE candidates haha).

I went hard until 2:30 AM and went to bed defeated and exhausted. I worked on the issue all day today….finally 15 minutes ago I put my finger on it. I wanted to write a blog to explain all the pain and suffering : )

Here is the topology for this fun excursion into multicast:

So R2 is our RP, which is statically assigned on all our other routers here. Behind R2 there is a multicast source pumping info to R2 is our Frame-Relay hub, and the routers are all happily running OSPF without any issues. I’ve also added ip pim nmba-mode to R2s frame interface to avoid other issues.

So the first thing I do is make R5 join the multicast group from it’s fa1/0 interface

conf t
int fa1/0
ip igmp join-group

R5#show ip mroute | beg \(\*
(*,, 00:02:54/00:02:32, RP, flags: SL
Incoming interface: Serial2/0, RPF nbr
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:01:57/00:02:32

OK … so I see the multicast coming in from the frame cloud…good. And I see it exiting out E0/0 …hmmmmmm. This was really puzzling because I had put the igmp join command on Fa1/0 , so why was it adding e0/0 to the outgoing interfaces list?

R5#debug ip pim
PIM debugging is on

*Dec 10 21:49:27.737: PIM(0): Received v2 Join/Prune on Ethernet0/0 from, to us
*Dec 10 21:49:27.737: PIM(0): Join-list: (*,, RPT-bit set, WC-bit set, S-bit set
*Dec 10 21:49:27.737: PIM(0): Update Ethernet0/0/ to (*,, Forward state, by PIM *G Join

So R5 is getting PIM joins from R7 on its E0/0 interface. That sure seemed strange, considering I have no real users or anything off or R7 ANYWHERE. When R5 receives that PIM join on its E0/0 interface from R7, it causes R5 to add e0/0 to the outgoing interface list for group The question was why in the hell is R7 sending me PIM joins for this group?

Well according to the route/switch exam cert guide 3rd edition, when there is more than 1 router on an ethernet that receives an IGMP join, they need to battle it out to decide which router has the right to forward multicast onto the segment for that specific multicast group. How they decide that seems to be a bit confusing. The book says it is based on lowest AD of the route to the source address, followed by lowest route metric, followed by highest ip address. In this case, R5 has the better metric to the source of the multicast traffic (, and R7 has the highest IP address. However I found that R7 seemed to win the ability to forward traffic. I even changed the ip address on R5 to a higher number and at that point R5 started forwarding.

R5#sh ip route
Routing entry for
Known via “ospf 1”, distance 110, metric 36, type intra area
Last update from on Serial2/0, 00:30:08 ago
Routing Descriptor Blocks:
*, from, 00:30:08 ago, via Serial2/0
Route metric is 36, traffic share count is 1

R7(config-if)#do sh ip route
Routing entry for
Known via “ospf 1”, distance 110, metric 37, type intra area
Last update from on FastEthernet0/0, 00:30:18 ago
Routing Descriptor Blocks:
*, from, 00:30:18 ago, via FastEthernet0/0
Route metric is 37, traffic share count is 1

So lets think about this…. There is essentially a user off of R5’s Fa1/0 interface joining the group. What happens? R5,R6, and R7 all get an IGMP join request for (*, R7, having won the ability to forward traffic for that group sends a PIM join to the RP. HERE IS THE TRICK! When R7 sends that PIM join to the RP it send it out it’s RPF interface….on R7 that would be Fa0/0 because it’s route to the RP through the FastEthernet interface has a better metric than its route to the RP through its Ethernet interface ….the FastEthernet interface happens to be on the same segment as R5’s E0/0. THAT is why R5 keeps seeing PIM joins from R7 on its E0/0 interface…which causes R5 to add E0/0 to the outbound interface list for !

To demonstrate this we can mess with the OSPF interface costs…lets see what things look like now, running as described first.

R5#show ip mroute | beg \(\*
(*,, 00:40:38/00:03:10, RP, flags: SL
Incoming interface: Serial2/0, RPF nbr
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:39:42/00:03:10

R7#show ip mroute | beg \(\*
(*,, 00:40:14/00:02:45, RP, flags: SC
Incoming interface: FastEthernet0/0, RPF nbr
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:40:14/00:02:45

R7#sh ip ospf int fa0/0 | i Cost
Process ID 1, Router ID, Network Type BROADCAST, Cost: 1
R7#sh ip ospf int e1/0 | i Cost
Process ID 1, Router ID, Network Type BROADCAST, Cost: 10

So we see the Ethernet interface has a cost of 10 and the FastEthernet has a cost of 1 as expected in OSPF. Let’s flip them and see what happens.

R7(config)#int fa0/0
R7(config-if)#ip ospf cost 10
R7(config-if)#int e1/0
R7(config-if)#ip ospf cost 1
R7(config-if)#do clear ip mroute *

This causes the Ethernet interface on R7 to actually have a better metric to the RP than the FastEthernet interface….therefore the Ethernet interface becomes the interface checked for RPF.

R5#show ip mroute | beg \(\*
(*,, 00:45:49/00:02:03, RP, flags: SCL
Incoming interface: Serial2/0, RPF nbr
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:01:34/00:01:56

R7(config-if)#do show ip mroute | beg \(\*
(*,, 00:01:50/00:02:08, RP, flags: SPC
Incoming interface: Ethernet1/0, RPF nbr
Outgoing interface list: Null

As we can see, now what happens is that the multicast receiver on R5’s Fa1/0 LAN sends an IGMP join for group just like before. Just as before R5, R6, and R7 all receive it. R7 wins the right to forward multicast traffic for that LAN (so far as I understand it) because it has the highest IP address. Therefore, R7 sends a PIM join out it’s RPF interface, which is now e1/0. R5 sees that PIM join request on it’s Fa1/0 interface, and therefore adds it to the outbound interface list as it forwards it up to R2.

I am fairly confident I am giving an accurate description of what is going on here, but if anybody out there sees any mistakes let me know! I sure am curious about that whole thing regarding what router gets the right to forward traffic on a LAN when there is more than 1 router. Is it the lowest metric , or the highest IP address? My testing seems to indicate highest IP address. Oh yeah, this all of course is PIMv2.


5 Responses to “My Multicast Ass-Kicking”

  1. Sharath on December 11th, 2008 8:35 am

    The Group-address of client registrations are always forwarded by the PIM-DR. Highest IP address is chosen as a DR by default. The DR can also be changed by inteface based ip pim dr-priority command. Higher the better.

  2. nassim on December 12th, 2008 6:48 am

    pls i want to know the name of the software used to draw this diagrams, pls i need that

  3. Joe A on December 12th, 2008 12:48 pm

    Hi Nassim,

    Microsoft Visio

  4. nassim on December 14th, 2008 7:15 am

    thanks a lot for the reply

  5. Martin Thomas on March 13th, 2009 11:52 am


    What IGMP version are you using?

    The selection process is different according with the IGMP version used in the LAN.
    IGMP v1 does not have a method of its own to dispute the right to forward in a LAN and uses PIM assert message, in this case the Admin distance, Routing protocol metric and highest IP should be used as tiebreakers.

    IGMPv2 and v3 uses the lowest IP as per the guide.

    Not sure if this explains the behavior but i though it was inportant to bear in mind the difference for the two IGMP versions.


    Martin (Also preparing my CCIE at the moment!!)

Leave a Reply