Multicast Routing

Excellent explanation, thanks Rene. Finally I am getting dense and sparse mode

thanks a ton.

so there are multiple ways multiple protocols to achieve multicast in a network .
but talking about today’s real time network , is it correct to say that PIM SPARSE MODE is popular and mostly seen.

Dense-Mode is never used except maybe as a troubleshooting step. For IGMP v1 and v2 that only leaves Sparse-Mode. However, there are a lot of advantages to using Source Specific Multicast (SSM) (no need for a rendezvous point!), but this is only available via IGMP v3. I would say certainly any new implementation of multicast would use SSM if possible, but whether there are actually more sparse-mode vs SSM, I would save given that IGMP v2 has been around longer, Sparse-Mode might be the more common.

Hi Rene/Andrew,

Can you please help in understating when multicast-routing distributed needs to be used ? I read reference of stackable switches.
So is it mandatory that if we have stacked swithces which are participating in L-3 routing , we must use multicast-routing distributed instead multicast-routing ?

Thanks
Abhishek

Hello Abhishek!

The main purpose of the multicast-routing distributed command is to take advantage of the Multicast Distributed Switching (MDS) functionality that is available on high end Cisco L3 switching devices. MDS is accomplished using a forwarding data structure called a Multicast Forwarding Information Base (MFIB), which is a subset of the routing table. The multicast-routing distributed command essentially enables multicast routing on an L3 device. There is no alternative multicast-routing command. Counterintuativly, the distributedkey word indicates that distributed SWITCHING be taken advantage of in the multicast routing process.

As for stackable switches, there is no specific configuration considerations when configuring multicast routing. The only thing that should be taken into account is the fact that it is the master switch that performs the following in multicast routing:

•It is responsible for completing the IP multicast routing functions of the stack. It fully initializes and runs the IP multicast routing protocols.
•It builds and maintains the multicast routing table for the entire stack.
•It is responsible for distributing the multicast routing table to all stack members.

The stack members perform these functions:

•They act as multicast routing standby devices and are ready to take over if there is a stack master failure. If the stack master fails, all stack members delete their multicast routing tables. The newly elected stack master starts building the routing tables and distributes them to the stack members.
•They do not build multicast routing tables. Instead, they use the multicast routing table that is distributed by the stack master.

For more information about distributed switching and multicast routing using stacked L3 switches, take a look at the following Cisco support document:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_52_se/configuration/guide/3750scg/swmcast.html#wp1392467

I hope this has been helpful!

Laz

Thankyou Laz. great explanation.

While working in LAB i noticed, 3750 has this distributed keyword available but not 3850. Looks like Cisco has enabled MDS enabled by default.

Regards
abhishek

Hello Abhishek

Yes, it seems that way. It also depends on the IOS version that is being used on each platform.

Laz

Hi,
What is the meaning of (*, X.x.x.x) in multicast routing table.

Thanks,

Hi Mohammad,

The x.x.x.x is the multicast group address and the * depends if you are using PIM dense or PIM sparse mode.

I covered both in these lessons with an explanation of how the multicast routing table works:

https://networklessons.com/cisco/ccie-routing-switching-written/multicast-pim-dense-mode/

https://networklessons.com/cisco/ccie-routing-switching-written/multicast-pim-sparse-mode/

Hi Rene,
Can you explain in detail about the VRF aware Multicast…

Hi Sushanth,

The multicast commands can be enabled per VRF. Here is a quick example of two routers and two VRFs, RED and BLUE.

R1 has two loopback interfaces, one for each VRF. The IP addresses on the loopback interfaces are used as the RP address.

R1:

hostname R1
!
ip vrf BLUE
 rd 20:20
!
ip vrf RED
 rd 10:10
!
ip multicast-routing vrf RED 
ip multicast-routing vrf BLUE 
ip cef
!
interface Loopback1
 ip vrf forwarding RED
 ip address 1.1.1.1 255.255.255.255
 ip pim sparse-mode
!
interface Loopback2
 ip vrf forwarding BLUE
 ip address 11.11.11.11 255.255.255.255
 ip pim sparse-mode
!
interface GigabitEthernet0/1.10
 encapsulation dot1Q 10
 ip vrf forwarding RED
 ip address 192.168.12.1 255.255.255.0
 ip pim sparse-mode
!
interface GigabitEthernet0/1.20
 encapsulation dot1Q 20
 ip vrf forwarding BLUE
 ip address 192.168.21.1 255.255.255.0
 ip pim sparse-mode
!
router eigrp 1
 !
 address-family ipv4 vrf BLUE autonomous-system 21
  network 11.0.0.0
  network 192.168.21.0
 exit-address-family
 !
 address-family ipv4 vrf RED autonomous-system 12
  network 1.0.0.0
  network 192.168.12.0
 exit-address-family
!
ip pim vrf RED rp-address 1.1.1.1
ip pim vrf BLUE rp-address 11.11.11.11
!
end

R2:

hostname R2
!
ip vrf BLUE
 rd 20:20
!
ip vrf RED
 rd 10:10
!
ip multicast-routing vrf RED 
ip multicast-routing vrf BLUE 
ip cef
!
interface GigabitEthernet0/1.10
 encapsulation dot1Q 10
 ip vrf forwarding RED
 ip address 192.168.12.2 255.255.255.0
 ip pim sparse-mode
!
interface GigabitEthernet0/1.20
 encapsulation dot1Q 20
 ip vrf forwarding BLUE
 ip address 192.168.21.2 255.255.255.0
 ip pim sparse-mode
!
interface GigabitEthernet0/2
 no ip address
!
router eigrp 1
 !
 address-family ipv4 vrf BLUE autonomous-system 21
  network 192.168.21.0
 exit-address-family
 !
 address-family ipv4 vrf RED autonomous-system 12
  network 192.168.12.0
 exit-address-family
!
ip pim vrf RED rp-address 1.1.1.1
ip pim vrf BLUE rp-address 11.11.11.11
!
end

Now you can use the same multicast commands but include the VRF.

VRF RED:

R2#show ip pim vrf RED rp
Group: 224.0.1.40, RP: 1.1.1.1, uptime 00:03:04, expires never

VRF BLUE:

R2#show ip pim vrf BLUE rp
Group: 224.0.1.40, RP: 11.11.11.11, uptime 00:03:07, expires never

Above we see the RP, one for each VRF. Here are the multicast routing tables.

VRF RED:

R2#show ip mroute vrf RED
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
   L - Local, P - Pruned, R - RP-bit set, F - Register flag,
   T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
   X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
   U - URD, I - Received Source Specific Host Report, 
   Z - Multicast Tunnel, z - MDT-data group sender, 
   Y - Joined MDT-data group, y - Sending to MDT-data group, 
   G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
   N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
   Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
   V - RD & Vector, v - Vector, p - PIM Joins on route, 
   x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:03:26/00:02:14, RP 1.1.1.1, flags: SJPCL
  Incoming interface: GigabitEthernet0/1.10, RPF nbr 192.168.12.1
  Outgoing interface list: Null

VRF BLUE:

R2#show ip mroute vrf BLUE
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
   L - Local, P - Pruned, R - RP-bit set, F - Register flag,
   T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
   X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
   U - URD, I - Received Source Specific Host Report, 
   Z - Multicast Tunnel, z - MDT-data group sender, 
   Y - Joined MDT-data group, y - Sending to MDT-data group, 
   G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
   N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
   Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
   V - RD & Vector, v - Vector, p - PIM Joins on route, 
   x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:03:29/00:02:16, RP 11.11.11.11, flags: SJPCL
  Incoming interface: GigabitEthernet0/1.20, RPF nbr 192.168.21.1
  Outgoing interface list: Null

Hello Rene, your explanations and examples are always helpful ! One confusion i am having is that every packet has a destination of multicast address ! There is a multicast group which i meed to understand in detail ! I mean where is this destination located ? And why we use multicast group instead of destination ?

Means in unicast table, there is one source and one destination ! Why in multicast we use group ! Please explain in easy english as always :slightly_smiling_face:

Hello Bilal,

The term “group address” might be a bit confusing. In reality, a multicast address is just a destination IP address. The main difference is that we call them “group” addresses since a single multicast IP address can represent a “group” of receivers.

We still have one destination address (a multicast address) but instead of forwarding an IP packet from A > B, we can forward it from A > everyone who listens to the multicast address.

Rene

Hi Rene,

could you please write a topic about multicast sparse mode between Vlans SVI at on core switch ( layer 3.

how the multicast routing table will be one we enabled that in one Vlan then once add one more vlan in the multicast group .

regards

Hello ABC

You can make suggestions about topics at this page:

As for your specific question, you shouldn’t see a difference between how a multicast routing table will be for a L3 switch with multiple SVIs or just a router with multiple ports as members of a single multicast group. You can actually modify Rene’s topology in this lesson to accommodate that and see it first hand.

I hope this has been helpful!

Laz

Rene,

Can I use a layer 3 switch instead of a router in the labs for multicast?

Hello David

If the switch platform supports multicast functionality such as PIM and RP and the rest, then sure, you can use an L3 switch. The Catalyst 3850 with the appropriate IOS for example, supports all of the required parameters.

For features such as IGMP, an L3 switch would also do the trick since it does support L2 multicast features as well.

I hope this has been helpful!

Laz

Hi Laz and Rene,

I might have known the answer for my next question before, but right now after memorizing this topic again, I can’t find a solution for the behaviour as described below:

We can overcome duplicate multicast traffic by using the RPF check to the (S,G) group, and the router that receive the duplicate streams will only accept the packets from the lower metric path - which means only the best path link will accept the multicast traffic if it will be duplicated/received from different paths. (I’ts not the same topology as with PIM Assert, I’m talking about different physical links which means different segments to receive the traffic from)

What happen when the traffic will come from different paths with the same metric?
How would the duplicate data can be avoided in such scenario?

(I tried to lab such a scenario and forced igmp join from 2 different links for the same group , I can see the join messages but for some reason, one of the routers in the middle between the RP wouldn’t insert the interface which received the igmp report message to the OIL - and I can’t figure out why this is happening, after all both of the two middle routers do advertises the IGMP REPORT as a PIM JOIN but one of them doesn’t insert the port from which the igmp report came from to the OIL for that multicast group)

Thanks you vey much again!

Hello Nitay

By default, when you have multiple equal-cost paths in multicast, the PIM neighbor with the highest IP address will be used.

You can find out more about this behaviour at the following Cisco documentation.

I hope this has been helpful!

Laz