Understanding Multicast PIM Sparse Mode (Packet Flow)

Topology


I- No Multicast traffic from source

1- Receiver is interested in group 239.2.2.2, send IGMP Report for this group to NX-02 (LHMR)


Verification on NX-02:

NX-02# show ip igmp groups
IGMP Connected Group Membership for VRF "default" - 1 total entries
Type: S - Static, D - Dynamic, L - Local, T - SSM Translated, H - Host Proxy
      * - Cache Only
Group Address      Type Interface              Uptime    Expires   Last Reporter
239.2.2.2          D   Ethernet1/1            00:26:20  00:03:11  10.10.0.1


2- NX-02 after receiving the IGMP report from receiver will join the Shared tree, it will send an (*,G) Join to the Rendezvous Point (RP):


Verification of building of shared tree (*,G):

NX-02 as LHMR installed (*,G):

  • Incoming interface: Eth1/2 toward NX-03 where RP resides.
  • RPF pointing to the RP (root of the shared tree).
  • Outgoing interface: Eth1/1 where the receiver resides and sent interest for the group via IGMP (branch for the shared tree).
NX-02# show ip mroute
IP Multicast Routing Table for VRF "default"

(*, 239.2.2.2/32), uptime: 00:25:59, igmp ip pim
  Incoming interface: Ethernet1/2, RPF nbr: 172.16.14.2
  Outgoing interface list: (count: 1)
    Ethernet1/1, uptime: 00:25:59, igmp


NX-02 sent (*,G) Join to the RP, verification on the RP:

NX-03 (RP) installed (*,G):

  • Incoming interface: Loopback (since NX-03 is the RP)
  • Outgoing interface: Eth1/1, the (*,G) PIM Join from LHMR (NX-02) was received on this interface
NX-03# show ip mroute
IP Multicast Routing Table for VRF "default"

(*, 239.2.2.2/32), uptime: 00:26:51, pim ip
  Incoming interface: loopback0, RPF nbr: 3.3.3.3
  Outgoing interface list: (count: 1)
    Ethernet1/1, uptime: 00:26:51, pim


II- The source Starts sending Multicast traffic

1- Source 192.168.50.50 starts sending Multicast traffic for the group 239.2.2.2:

Verification on NX-01:

NX-01 (FHMR) install the (S,G) to the source:

  • Incoming interface and RPF pointing to the source (root for S,G tree)
  • No outgoing interface: the source tree isn’t built yet
NX-01# show ip mroute
IP Multicast Routing Table for VRF "default"

(192.168.50.50/32, 239.2.2.2/32), uptime: 00:14:41, ip pim
  Incoming interface: Ethernet1/3, RPF nbr: 192.168.50.50
  Outgoing interface list: (count: 0)


2- Source Registration to RP: FHMR (NX-01) encapsulated the first packet sent from the source and send a PIM Register Unicast to the RP:


The RP install the (S,G) entry and starts joining the source tree:

(Below output taken when the RP didn’t have route to the source, so basically (S,G) still not built yet, in the next steps, the source subnet is advertised):

NX-03# show ip mroute
(*, 239.2.2.2/32), uptime: 02:13:21, pim ip
  Incoming interface: loopback0, RPF nbr: 3.3.3.3
  Outgoing interface list: (count: 1)
    Ethernet1/1, uptime: 02:13:21, pim


(192.168.50.50/32, 239.2.2.2/32), uptime: 00:00:46, pim mrib ip
  Incoming interface: Null, RPF nbr: 0.0.0.0, internal
  Outgoing interface list: (count: 1)
    Ethernet1/1, uptime: 00:00:29, pim


3- RP sends (S,G) toward the source:

Once the RP receives the PIM register from the source, 2 scenarios can occur:

  • If no receiver is interested in receiving this Multicast traffic from this group: the RP will send a PIM Register-Stop message to the source router (which timeout in 60 seconds).

    After the timer expiration, the source router will send a PIM Register Null message to refresh status if RP got receiver joined for the group.
  • If there is at least 1 receiver for the Multicast group, the RP will send an (S,G) PIM join to the source:

(192.168.50.50, 239.2.2.2) Join from RP to the Source:

Below packet capture illustrating RP sending (S,G) Join in order to join the source tree:


At this point, 2 tree where built:

  • The shared tree (*,G)
  • The source tree (S,G)


4- Register-Stop

Once the RP receives native multicast traffic (not via Unicast Register), it will sends a Register-Stop to the source indicating that (S,G) tree was built.

At this point, multicast traffic will follow (S,G) from source to RP and no Register sent anymore from FHMR (NX-01) to the RP.

After receiving mcast traffic, the RP sent out Register-stop:


5- LHMR Router (NX-02) Switchover to the (S,G) tree:

Initially, the traffic from the source will reach RP and then downstream from RP toward the receiver through the (*,G) shared tree.

At this point, the receiver router (NX-02) receives the traffic from the source. Since now, LHMR (NX-02) knows the source of this multicast group, the rendezvous point could be not needed anymore. By default, a switch over to the (S,G) tree is triggered.

As a result, the LHMR (NX-02) send an (S,G) Join to the source:

NX-02 will look into its uRIB unicast routing table and see that Shortest path to the source is via NX-01 directly:

NX-02# show ip route 192.168.50.50

192.168.50.48/30, ubest/mbest: 1/0
    *via 172.16.12.2, Eth1/3, [110/80], 01:04:16, ospf-10, intra
Code language: PHP (php)

Using SPT threshold, we can specify that the traffic must first reach a threshold before (LHMR) switchover to the (S,G).

You can configure when a PIM leaf router should join the shortest-path tree for a specified group. If a source sends at a rate greater than or equal to the specified kbps rate, the router triggers a PIM Join message toward the source to construct a source tree (shortest-path tree).

For example, once receive 1000 Kpbs multicast traffic for group, LHMR can switchover to SPT (source tree):

ip pim spt-threshold 1000

If the infinity keyword is specified, all sources for the specified group use the shared tree, never switching to the source tree.

ip pim spt-threshold infinity


6- LHMR sends Prune to the RP:

Once the Receiver router NX-02 (LHMR) receives multicast traffic on the (S,G) tree, the switchover is complete and we can say LHMR joined the SPT to the source.

At this point, the RP isn’t needed for the multicast flow from source to the receiver, a Prune message is sent from the LHMR toward the RP indicating that it has switched to the SPT for the group 239.2.2.2 and source 192.168.50.50.

As a result, the RP will remove eth1/1 from outgoing interfaces for the (S,G) mroute:

NX-03# show ip mroute
IP Multicast Routing Table for VRF "default"


(*, 239.2.2.2/32), uptime: 02:27:03, pim ip
  Incoming interface: loopback0, RPF nbr: 3.3.3.3
  Outgoing interface list: (count: 1)
    Ethernet1/1, uptime: 02:27:03, pim


(192.168.50.50/32, 239.2.2.2/32), uptime: 00:14:28, pim mrib ip
  Incoming interface: Ethernet1/2, RPF nbr: 172.16.13.2, internal
  Outgoing interface list: (count: 0)


By the End, after SPT switchover and prune to RP, we will have the following mroute status:

NX-01( FHMR):

NX-01# show ip mroute
IP Multicast Routing Table for VRF "default"

(192.168.50.50/32, 239.2.2.2/32), uptime: 00:25:18, ip pim
  Incoming interface: Ethernet1/3, RPF nbr: 192.168.50.50
  Outgoing interface list: (count: 1)
    Ethernet1/4, uptime: 00:17:45, pim


NX-03( RP):

NX-03# show ip mroute
IP Multicast Routing Table for VRF "default"


(*, 239.2.2.2/32), uptime: 02:37:54, pim ip
  Incoming interface: loopback0, RPF nbr: 3.3.3.3
  Outgoing interface list: (count: 1)
    Ethernet1/1, uptime: 02:37:54, pim


(192.168.50.50/32, 239.2.2.2/32), uptime: 00:25:19, pim mrib ip
  Incoming interface: Ethernet1/2, RPF nbr: 172.16.13.2, internal
  Outgoing interface list: (count: 0)


NX-02( LHMR):

NX-02# show ip mroute
IP Multicast Routing Table for VRF "default"

(*, 239.2.2.2/32), uptime: 02:45:10, igmp ip pim
  Incoming interface: Ethernet1/2, RPF nbr: 172.16.14.2
  Outgoing interface list: (count: 1)
    Ethernet1/1, uptime: 02:45:10, igmp


(192.168.50.50/32, 239.2.2.2/32), uptime: 00:18:00, ip mrib pim
  Incoming interface: Ethernet1/3, RPF nbr: 172.16.12.2
  Outgoing interface list: (count: 1)
    Ethernet1/1, uptime: 00:18:00, mrib
Bilel

Bilel

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x