Get Unlimited Access to our 786 Cisco Lessons Now Get $1 Trial
You are here: Home » Multicast

Multicast PIM Prune Override

The PIM prune mechanism works a bit different on multi-access links compared to point-to-point links.

On point to point links there is only one other router on the other end so when we receive a prune message, it’s safe to stop forwarding the traffic. On multi-access links however it’s possible that we have more than one downstream router that is interested in receiving the multicast traffic. When we receive a prune on a multi-access link, we need to make sure that nobody else still wants to receive it. This is done with the prune override mechanism and it applies to both PIM dense and sparse mode.

Here’s an example:

Multicast traffic S1 to routers and receivers

Above we have a source (S1) sending multicast traffic to R1. At the bottom are two receivers (H2 and H3) so R2/R3 are  both forwarding the traffic. After a few minutes, H2 doesn’t want to receive this traffic anymore:

PIM Multicast IGMP Leave Pim prune

H2 will send an IGMP leave towards R2 who will send a PIM prune to its upstream neighbor, R1. This PIM prune message is destined to 224.0.0.13 so R1 and R3 will both receive it. Here’s what happens next:

PIM Multicast PIM Prune Timer

R1 receives the prune message but it won’t stop forwarding right away. It will wait for a few seconds to see if other routers are still interested. R3 is still interested so it will send a PIM join. Since this PIM join overrides the prune, we call it a prune override but the packet is a regular PIM join.. R1 now knows what to do:

Multicast PIM R1 keeps forwarding

Since R3 is still interested, R1 will ignore the prune message from R2 and will keep forwarding the multicast traffic.

Let’s take a look at some real routers to see how this works in action!

Configuration

Here’s the topology I will use:

Multicast PIM Prune override topology

Above we have a small network with three routers. S1 will send multicast packets and H2/H3 will be the receivers. OSPF has been configured as the unicast routing protocol and PIM dense mode for multicast routing. If you want to test this example yourself, you can find the startup configurations below:

Startup Configurations

Want to take a look for yourself? Here you will find the final configuration of each device.

R1

hostname R1
!
ip multicast-routing 
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.123.1 255.255.255.0
 ip pim dense-mode
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/2
 ip address 192.168.1.254 255.255.255.0
 ip pim dense-mode
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
 network 192.168.1.0 0.0.0.255 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
end

R2

hostname R2
!
ip multicast-routing 
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.123.2 255.255.255.0
 ip pim dense-mode
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/2
 ip address 192.168.2.254 255.255.255.0
 ip pim dense-mode
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
 network 192.168.2.0 0.0.0.255 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
end

R3

hostname R3
!
ip multicast-routing 
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.123.3 255.255.255.0
 ip pim dense-mode
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/2
 ip address 192.168.3.254 255.255.255.0
 ip pim dense-mode
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
 network 192.168.3.0 0.0.0.255 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
end

H2

hostname H2
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.2.2 255.255.255.0
 no ip route-cache
 duplex auto
 speed auto
 media-type rj45
!
ip default-gateway 192.168.2.254
!
end

H3

hostname H3
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.3.3 255.255.255.0
 no ip route-cache
 duplex auto
 speed auto
 media-type rj45
!
ip default-gateway 192.168.3.254
!
end

S1

hostname S1
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 no ip route-cache
 duplex auto
 speed auto
 media-type rj45
!
ip default-gateway 192.168.1.254
!
end

Let’s configure the hosts to receive our multicast traffic:

H2 & H3
(config)#interface GigabitEthernet 0/1
(config-if)#ip igmp join-group 239.1.1.1

And generate some traffic from S1:

S1#ping 239.1.1.1 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
.
Reply to request 1 from 192.168.2.2, 20 ms
Reply to request 2 from 192.168.3.3, 5 ms

S1 is receiving replies from H2 and H3. Let’s check the multicast routing tables of R2 and R3:

R2#show ip mroute 239.1.1.1 192.168.1.1

(192.168.1.1, 239.1.1.1), 01:51:50/00:01:33, flags: T
  Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.123.1
  Outgoing interface list:
    GigabitEthernet0/2, Forward/Dense, 00:00:36/stopped
R3#show ip mroute 239.1.1.1 192.168.1.1

(192.168.1.1, 239.1.1.1), 01:52:29/00:01:55, flags: T
  Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.123.1
  Outgoing interface list:
    GigabitEthernet0/2, Forward/Dense, 01:52:29/stopped

Both router are forwarding traffic to the hosts. Before we configure H2 to stop listening, let’s enable a debug:

R1, R2 & R3
#debug ip pim 
PIM debugging is on

Let’s configure H2 to stop listening:

H2(config)#interface GigabitEthernet 0/1
H2(config-if)#no ip igmp join-group 239.1.1.1

Here’s what we we will see on R2:

R2#
PIM(0): Insert (192.168.1.1,239.1.1.1) prune in nbr 192.168.123.1's queue
PIM(0): Building Join/Prune packet for nbr 192.168.123.1
PIM(0):  Adding v2 (192.168.1.1/32, 239.1.1.1) Prune
PIM(0): Send v2 join/prune to 192.168.123.1 (GigabitEthernet0/1)
PIM(0): Received v2 Join/Prune on GigabitEthernet0/1 from 192.168.123.1, not to us
PIM(0): Prune-list: (192.168.1.1/32, 239.1.1.1) 
PIM(0): Received v2 Join/Prune on GigabitEthernet0/1 from 192.168.123.3, not to us
PIM(0): Join-list: (192.168.1.1/32, 239.1.1.1)

R2 sends the prune message to its upstream neighbor, R1. Here’s what R1 thinks of it:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 786 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

Give Membership a try - it's just $1 ►

1433 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,

Forum Replies

  1. Hi Rene,

    Very nice article. I was curious about the value of the timer on R1 once it receives prune message from the R2

    Thanks

    Nage

  2. So R2 will keep receiving the multicast stream even though it does not have a receiver. I wonder if the switch(es) sitting in the middle of the Multiaccess segment can do something to avoid sending the multicast stream to R2 once it sends the PIM Prune msg.

  3. Hello Muhmmad

    That’s a good question. It would seem that something like IGMP snooping could be used in such a case to ensure unwanted multicast traffic doesn’t reach a router like that. Although Layer 2 switches are IGMP-aware and can deal with delivering multicast traffic only to hosts that want it, they are unable to act upon PIM messages such as PIM prune in the same way, to help in making such communication more efficient.

    In such a case, a network designer should choose a better topology, such as ensuring that R2 and R3 are in different network segments.

    ... Continue reading in our forum

Ask a question or join the discussion by visiting our Community Forum