Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Introduction to IOS XR Multicast

 

 

Introduction

 

This document will assume that the reader knows very litle about multicast in general and we will try to explain how Protocol Independent Multicast (PIM) will setup the distribution of multicast traffic from sources to receivers.

 

The objective is to be able to quickly get up to speed and understand the basic multicast show commands in IOS XR.

 

This document will have show commands captured from devices running IOS XR but it shoudl help the reader get familiar with PIM in general as there should be similar commands on different platforms since PIM remains the same protocol.

 

We will not go into the hardware forwarding part as this would vary from platform to platform. We will not cover features like IPv6 mcast, MVPN, mcast MPLS TE, LSM... just the basic PIM multicast. Hopefully they will be covered in different documents.

 

IOS XR multicast is based on the MFIB architecture which has been introduced recently in IOS too.

 

IOX XR PIM follows the new PIM RFC 4601.

 

Multicast

 

A mcast stream is defined by 2 things:

 

  • A source: this is the host transmitting mcast traffic. It will be  the source of the IPv4 mcast packet. A source can start transmitting at  any time without asking the permission to anybody. It will be the  responsibility of the PIM routers in the network to forward the  traffic towards from the source towards all the receivers interested in that stream.
  • A group: this is the destination address of the IPv4 packet in the range 224.0.0.0/4.

 

The stream is represented as (source, group) or (S,G), for instance (10.10.10.10, 225.1.1.1).

 

Then we have receivers which want to receive the stream. These hosts  would usually send IGMP (version 2 or 3) reports to the PIM routers on  their network to let them know of their interest in the stream.

 

  • With IGMP version 2, a receiver can say that it wants to receive packets from any source (this is represented by a '*') for one specific group so these streams are represented as (*,G). For instance (*,230.1.1.1). So if we have 10  sources transmitting to 230.1.1.1, the receiver will receive the 10  streams. IGMPv2  can only register for (*,G) and can't specify indidual sources.  When the (downstream) bandwidth is limited, receiving mcast traffic (high bandwidth television channel for instance) from all these sources may not be optimal/possible.
  • IGMPv3 can achieve the same but  IGMPv3 adds the ability to register for some specific sources only in a group or all but some sources in a group... this is what we is called source-specific-multicast (SSM) when the receivers know in advance which host will be the transmitter.

 

It will then be the responsibility of the PIM routers connected to the  receivers (in particular the designated PIM router) to send some PIM Join messages towards the source or a rendez-vous point to make sure that the  stream is forwarded towards those receivers.

 

So first thing to do when starting to work on a a multicast problem is to:

 

  • Get a topology map.
  • What is the group (ipv4 address of G) ? 225.1.1.1 for instance.
  • Where is the source (ipv4 address of S) or where are the  sources when there are mutliple ones ? So now you should have some (S,G) like  (10.10.10.10, 225.1.1.1).
  • Where are the receivers located ? They should be on one or more LANs somewhere.

 

Now we need to understand how mcast moves between the source and the receivers. This is where PIM comes into the picture.

 

There are multiple flavors of PIM:

 

  • PIM Source Specific Multicast (SSM)
  • PIM Sparse Mode (SM)
  • PIM Sparse Mode with Anycast RP
  • Bidirectional PIM (Bidir)

 

In general, customers would decide to use one mode in their network...  but multiple modes can be used at the same time in the network. The  decision to use one mode or another is based on the group address. The 224.0.0.0/4 range is  divided into multiple subranges and each subrange can be assigned to one PIM mode. In IOS XR you need to do a "show pim group-map" to see the different ranges:

 

RP/0/0/CPU0:bottomright#show pim group-map 
Wed Jul 20 08:42:23.674 PDT

IP PIM Group Mapping Table 
(* indicates group mappings being used) 
(+ indicates BSR group mappings active in MRIB) 

Group Range         Proto Client   Groups RP address      Info

224.0.1.39/32*      DM    perm     1      0.0.0.0         
224.0.1.40/32*      DM    perm     1      0.0.0.0         
224.0.0.0/24*       NO    perm     0      0.0.0.0         
232.0.0.0/8*        SSM   config   0      0.0.0.0         
230.0.0.0/24*       SM    autorp   0      192.168.0.2     RPF: Gi0/0/0/1,192.168.1.13
224.0.0.0/4*        SM    config   1      192.168.0.3     RPF: Gi0/0/0/0,192.168.1.9
224.0.0.0/4         SM    static   0      0.0.0.0         RPF: Null,0.0.0.0
RP/0/0/CPU0:bottomright#

 

224.0.1.39 and 224.0.1.40 are the only 2 Dense Mode (DM) groups allowed in IOS XR. They are used to propagate the auto-rp messages which is a way to let PIM SM routers in the network know who's the rendez-vous point (RP) for some group ranges.

 

232.0.0.0/8 is for SSM by default in XR so you don't have to configure anything to have it there. You can change the SSM range with the "multicast-routing ssm range" command. So if the source 10.1.1.1 starts  transmitting to 232.1.1.1 which is part of 232.0.0.0/8, then the receivers will have to know (through a mcast stream listing on a web page for instance or manual config) that (S,G)  and join (10.1.1.1,232.1.1.1) directly towards the source.

 

230.0.0.0/24 is a sparse mode (SM) group learned through auto-rp. The  auto-rp announcements indicate that 192.168.0.2 is the rendez-vous point  (RP) for that range. You could also use BSR for Group range to RP mapping.

 

224.0.0.0/4 is a Sparse Mode range and the RP 192.168.0.3 is known through config so that means that "pim rp-address 192.168.0.3" is configured on  this router. But you could also specify an RP address for smaller ranges by using an ACL.

 

So now that you know whether your group is SM or SSM or Bidir thanks to "show pim group-map", you can jump to the appropriate section below.

 

PIM Source Specific Multicast (SSM)

 

 

lab-enxr-mcast-ssm.jpg

 

 

To start with, routers have the SSM range (the default one or another configured one) marked with the Drop flag:

 

RP/0/0/CPU0:topleft#sh mrib route
Wed Jul 20 12:53:04.947 PDT

IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept

(*,232.0.0.0/8) Flags: D
  Up: 05:34:24

 

This tells us that if we receive traffic from a source with a destination within  232.0.0.0/8, we should drop it as for SSM to work, we need to have a  receiver join one (S,G) in particular first and that will create an (S,G) route which will be more specific than the whole SSM range.

 

So first we need a receiver to join one (S,G). We can simulate this on an XR router under IGMP:

 

router igmp
 interface GigabitEthernet0/0/0/0
  join-group 232.1.1.1 192.168.1.18

 

This is configured on the bottomrightce router in the topology diagram above and it will act as a receiver host which sends an IGMPv3 report to receive traffic sent by 192.168.1.18 only and to 232.1.1.1 only.

 

So on the router connected to that receiver, we can see that we have an IGMP receiver directly connected:

 

RP/0/0/CPU0:bottomright#sh igmp groups gigabitEthernet 0/0/0/2
Wed Jul 20 13:03:03.699 PDT
IGMP Connected Group Membership
Group Address   Interface                     Uptime    Expires   Last Reporter
224.0.0.2       GigabitEthernet0/0/0/2        05:33:18  never     192.168.1.41
224.0.0.5       GigabitEthernet0/0/0/2        05:32:44  never     192.168.1.41
224.0.0.6       GigabitEthernet0/0/0/2        05:32:44  never     192.168.1.41
224.0.0.13      GigabitEthernet0/0/0/2        05:33:18  never     192.168.1.41
224.0.0.22      GigabitEthernet0/0/0/2        05:33:18  never     192.168.1.41
232.1.1.1       GigabitEthernet0/0/0/2        00:05:17  not used  192.168.1.42
RP/0/0/CPU0:bottomright#
RP/0/0/CPU0:bottomright#sh igmp groups 232.1.1.1 gigabitEthernet 0/0/0/2 detail 
Wed Jul 20 13:02:42.100 PDT

Interface:      GigabitEthernet0/0/0/2
Group:          232.1.1.1
Uptime:         00:04:55
Router mode:    INCLUDE
Host mode:      INCLUDE
Last reporter:  192.168.1.42
Group source list:
  Source Address   Uptime    Expires   Fwd  Flags
  192.168.1.18     00:04:55  00:01:28  Yes  Remote 4
RP/0/0/CPU0:bottomright#

 

There is one PIM router on that network connected to the receiver which is elected Designated Router:

 

RP/0/0/CPU0:bottomright#sh pim neighbor gigabitEthernet 0/0/0/2
Wed Jul 20 13:07:53.844 PDT

PIM neighbors in VRF default

Neighbor Address             Interface              Uptime    Expires  DR pri   Flags

192.168.1.41*                GigabitEthernet0/0/0/2 05:38:09  00:01:41 1 (DR) B P
192.168.1.42                 GigabitEthernet0/0/0/2 00:01:46  00:01:37 0      B
RP/0/0/CPU0:bottomright#

 

Note that in IOS XR , the router lists itself in "show pim neighbors" with a  '*'. The system with "(DR)" is now responsible to send some PIM joins  "upstream" towards the source. Mcast traffic flows from the source  "downstream" towards receivers but the PIM joins have to be sent first in the  reverse direction "upstream" towards the source to create a distribution tree and let the routers along the upstream path know that they have to  forward the mcast stream downstream on the interface where they received the PIM join. So on a given router for an SSM group, there is one  upstream interface and  it's the interface towards the source and there  is one or more downstream interface towards all the receivers for that  group.

The routers will do a Reverse Path Forwarding (RPF) lookup for the source (the transmitter of the stream) of the group. It's called "reverse"  because in unicast we do a lookup on the destination but in mcast we  have to do a lookup on the source. So in SSM, we do the RPF lookup on  the source of the group (this may be different in Sparse Mode).

 

RP/0/0/CPU0:bottomright#sh pim rpf 192.168.1.18
Wed Jul 20 13:15:32.663 PDT

Table: IPv4-Multicast-default
* 192.168.1.18/32 [110/3] 
    via GigabitEthernet0/0/0/1 with rpf neighbor 192.168.1.13
RP/0/0/CPU0:bottomright#

 

One important thing to note about the command above is  that it only gives some output if the address that you're doing the RPF  lookup on is already in use as the source of an active group in the mrib. You can't use it to figure out what would happen if a new source  would start to transmit... for that you may want to use the "sh pim rpf hash" command.

The RPF interface to reach the source is found based on the unicast routing table when the mcast address-family is not configured (bgp,  isis...) and there's gonna be a separate Multicast Unicast RIB (MURIB)  when you enable the multicast address-family. You can check it with  "show route ipv4 multicast". When you enable the mcast address-family under bgp, then there is no fallback to the bgp prefixes learned in the  unicast address-family, we only use the prefixes learned in the mcast  address-family. So all sources should be learned in the mcast  address-family in that case when the mcast AF is configured under BGP.

 

So... the PIM DR connected to the receiver (bottomright) does an RPF lookup for the source and finds that it points at gig 0/0/0/1 so it will send a PIM join for the (S,G) upstream on gig 0/0/0/1 to the upstream router.

 

RP/0/0/CPU0:bottomright#show pim topology  232.1.1.1
Wed Jul 20 15:47:12.463 PDT

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(192.168.1.18,232.1.1.1)SPT SSM Up: 02:49:27                         =====> line 1 
JP: Join(00:00:26) RPF: GigabitEthernet0/0/0/1,192.168.1.13 Flags:   =====> line 2
  GigabitEthernet0/0/0/2      02:49:27  fwd LI LH                    =====> line 3
RP/0/0/CPU0:bottomright# 

 

Line 1 tells that it's an SSM group up for 2 hours and 45 mins.

Line 2 is the upstream state. This is the state which defines what we  have to do upstream to make sure that this router receives the mcast  stream. In the example, we send some Joins upstream over the RPF  interface Gig 0/0/0/1 to the upstream router 192.168.1.13 which is our  next hop towards the source of the group 192.168.1.

Line 3 is the downstream state. This tells us which downstream interfaces have an interest in that group so basically where we have to forward the mcast traffic for that group. In the example, we can see  that we should forward the traffic over Gig 0/0/0/2 as there is some  "local interest" (LI) for that group and we're the "last hop" (LH) as  this is the interface where we have a receiver sending IGMP reports. There can be multiple  downstream interfaces as we can have receivers directly connected on multiple interfaces or we can have multiple PIM routers sending us some  joins for that group (we would see "Join" instead of "LI LH" when a  downstream PIM router sends us some periodic joins for that group). When we have multiple downstream interfaces, this is where mcast becomes  useful as we have one packet arriving on the upstream interfaces and it's replicated on multiple downstream interfaces.

 

Next step is to check the corresponding MRIB entry. The MRIB is the multicast routing table.

 

RP/0/0/CPU0:bottomright#sh mrib route 232.1.1.1
Wed Jul 20 15:56:52.800 PDT

IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept

(192.168.1.18,232.1.1.1) RPF nbr: 192.168.1.13 Flags:
  Up: 02:59:07

  Incoming Interface List
    GigabitEthernet0/0/0/1 Flags: A, Up: 02:59:07
  Outgoing Interface List
    GigabitEthernet0/0/0/2 Flags: F NS LI, Up: 02:59:07
RP/0/0/CPU0:bottomright#

 

We can see that the router will "Accept" (the 'A' flag) on Gig 0/0/0/1 which is the upstream RPF interface towards the source so this is where the traffic should be coming from and forward ('F' flag) traffic on Gig  0/0/0/2 which is where there's the receiver ('LI' flag). The 'NS' flag  means that traffic for that group received on that interface should  trigger some control plane activity. In this case this is because we're  supposed to be the designated forwarder on that interface so if we start  receiving traffic on that interface that means that another router is  forwarding the stream too and we should go through the PIM assert procedure to avoid some duplicate packets being forwarded on that network.

 

Based on the mrib entry, we build the software mfib entry which is used for the lookup for packets being switched in software and we also build the hardware mfib based on this software mfib:

 

RP/0/0/CPU0:bottomright#sh mfib route 232.1.1.1
Wed Jul 20 16:04:38.043 PDT

IP Multicast Forwarding Information Base
Entry flags: C - Directly-Connected Check, S - Signal, D - Drop,
  IA - Inherit Accept, IF - Inherit From, MA - MDT Address,
  ME - MDT Encap, MD - MDT Decap, MT - MDT Threshold Crossed,
  MH - MDT interface handle, CD - Conditional Decap,
  DT - MDT Decap True, EX - Extranet
  MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
  NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
  EG - Egress, EI - Encapsulation Interface, MI - MDT Interface,
  EX - Extranet, A2 - Secondary Accept
Forwarding/Replication Counts: Packets in/Packets out/Bytes out
Failure Counts: RPF / TTL / Empty Olist / Encap RL / Other

(192.168.1.18,232.1.1.1),   Flags:  
  Up: 03:06:52
  Last Used: 03:04:15
  SW Forwarding Counts: 79/79/7900
  SW Replication Counts: 79/79/7900
  SW Failure Counts: 0/0/0/0/0
  GigabitEthernet0/0/0/1 Flags:  A, Up:03:06:52
  GigabitEthernet0/0/0/2 Flags:  NS EG, Up:02:56:51
RP/0/0/CPU0:bottomright#

 

Accept ('A') on the upstream interface and forward on the interfaces with the Egress ('EG') flag.

Same meaning for NS => signal the routing protocol that a packet for that group was received on that interface.

 

Next step would be to check the hardware mfib entry (similar "show mfib" command but with the "hardware" keyword) but the output  will depend on the platform. On the ingress linecard the entry should  accept  on the upstream interface towards the source and point to a  Fabric Group  ID (FGID) which is a mcast group in the fabric which  contains all the  slots which have receivers for that group. And on the  egress linecard  the entry should contain all the downstream interfaces  towards  receivers.

 

So the designated router connected to the receiver sends the join upstream on Gig 0/0/0/1 to 192.168.1.13 where the pim topology looks  like:

 

RP/0/0/CPU0:topright#

(192.168.1.18,232.1.1.1)SPT SSM Up: 02:45:51 
JP: Join(now) RPF: GigabitEthernet0/0/0/0,192.168.1.1 Flags: 
  GigabitEthernet0/0/0/1      02:45:51  fwd Join(00:02:42) 

 

The Gig 0/0/0/1 is the downstream interface towards bottomright (the DR  connected to the receiver) and we can see that we've received the join  from bottomright on that interface. And this router topright will send a  join upstream towards the source after an RPF lookup on the source of  the group (192.168.1.18) and the upstream router is 192.168.1.1 on Gi  0/0/0/0 (topleft).

 

So the joins will go upstream like this from router to router until we  reach the first hop router which is directly connected to the source:

 

RP/0/0/CPU0:topleft#sh pim topology 232.1.1.1 
Wed Jul 20 16:21:36.160 PDT

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(192.168.1.18,232.1.1.1)SPT SSM Up: 03:13:49 
JP: Join(00:00:01) RPF: GigabitEthernet0/0/0/2,192.168.1.18* Flags: 
  GigabitEthernet0/0/0/0      03:13:49  fwd Join(00:02:41) 
RP/0/0/CPU0:topleft#

 

And so we're good now as we have built a distribution tree end to end from the source through all the PIM routers in the middle and then to the PIM DR  connected to the receiver.  In SSM, this is called a Shortest Path Tree (SPT) as routers send join on the shortest path to the source so that multicast traffic will be sent in the reverse direction on the shortest path from the source to the receivers.

 

Summary of SSM (very simple):

 

  • Receivers report interest for one source in particular in IGMv3.
  • PIM routers do RPF lookups for the source to join upstream towards the source. This establishes a shortest path tree (SPT) between  the source and the receivers.
  • Mcast traffic starts to flow downstream from source towards receivers on the SPT.

 

PIM Sparse Mode (SM)

 

lab-enxr-mcast-sm.jpg

 

In Sparse Mode, the receivers are interested in all sources sending to one group.

So they send some (*,G) IGMPv2 report to their directly connected router or some IGMPv3 report including all sources.

And the group G has to be in the SM range in "show pim group-map" as seen above.

But then the routers connected to the receivers know that there is an interest in a group but they don't know where all the sources for this group are located as they can be anywhere in the network. So they can't send joins directly towards the source like in SSM. So in SM there is rendez-vous point (RP) where the  receivers can meet the senders. Once they become aware of some sources  through the rendez-vous point, the routers connected to the receivers  know the addresses of the sources and they can join towards them directly like in SSM as this is more efficient than going through the RP which may not be on the shortest path tree.

 

So first step is to have all PIM SM routers learn the RP for each group range. The whole mcast range can be split into multiple ranges so that an RP only handles a subrange aka a "grange". But all PIM SM routers should agree on the RP-to-range mapping. This mapping can be configured  directly on the router ("router pim rp-address" command) or through  auto-rp or BSR. And we can see the SM group mappings in "show pim  group-map":

 

230.0.0.0/24*       SM    autorp   0      192.168.0.2     RPF: Gi0/0/0/1,192.168.1.13
224.0.0.0/4*        SM    config   0      192.168.0.3     RPF: Gi0/0/0/0,192.168.1.9

 

2 things must happen to have the receivers meet the senders at the RP (they can happen in any order):

 

  1. The PIM DR receiving the IGMP report will send some (*,G) join towards the RP and this will build the RP Tree (RPT) aka shared tree. This is to make sure  that once packets for group G arrive at the RP (in step 2 below), the RP will forward these packets downstream over that RPT towards the  receivers.
  2. Source will start to transmit at any time. The PIM DR connected to the source will send packets to the RP and RP will forward packets over RPT so that packets will reach the receivers. 

 

So traffic will be flowing end to end at this point and there will be further optimizations at this point like the RP joining the SPT towards the source and the receiver DR when discovering new sources received on the RPT will join the SPT towards the sources to have an SPT from source to receiver in the end. There's no treshold in XR so we join immediately the SPT. 

 

So let's go over all these steps in greater details...

 

First, when the receivers sends an IGMP report to bottomright:

 

RP/0/0/CPU0:bottomright#sh pim topology 225.1.1.1
Thu Jul 21 10:07:46.835 PDT

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 00:00:30 RP: 192.168.0.3                           =====> line 1
JP: Join(00:00:18) RPF: GigabitEthernet0/0/0/0,192.168.1.9 Flags: LH    =====> line 2
  GigabitEthernet0/0/0/2      00:00:30  fwd LI LH                       =====> line 3
RP/0/0/CPU0:bottomright#

 

Line 1: We can see that the RP for 225.1.1.1 is 192.168.0.3. Router finds this information in the grange list that we can see in "show pim group-map".

Line 2: Upstream state. Router does an RPF lookup for the RP (not for the source since we don't know it yet) and sends joins towards  the RP so that an RP tree is built from the RP to the receivers. This  RP tree is ready to forward packets from the RP to the receivers once  the RP starts receiving packets from a source for that group.

Line 3: Downstream state. This is where we have the receivers so where packets should be forwarded (based on IGMP reports of PIM joins from downstream routers).

 

Corresponding mrib route entry:

 

(*,225.1.1.1) RPF nbr: 192.168.1.9 Flags: C
  Up: 5w1d
  Incoming Interface List
    GigabitEthernet0/0/0/0 Flags: A NS, Up: 5w1d
  Outgoing Interface List
    GigabitEthernet0/0/0/2 Flags: F NS LI, Up: 5w1d

 

Notice the NS flag on the accepting interface Gi0/0/0/0. That means that  if a packet is received from the RP, PIM will be signaled and this  router will join towards the source of the packet since this is the last hop router.

 

So now let's have a look at the 2nd step when the source starts transmitting. Here are the different steps which will happen:

 

  • The PIM DR connected to the source (topleft) detects the first packet sent to 225.1.1. This packet will match the 224.0.0.0/4 entry in the mrib and mfib which has the C (connected) flag so that topleft  will know that it has to sent them to the RP through PIM registers. PIM  registers are created by forwarding packets over the (virtual)  Encapstunnel0 interface and that will encapsulate the original packet  into a PIM register unicast packet to the RP (this is for a PIM data  register, there are also PIM null registers without data to refresh state).

 

 

RP/0/0/CPU0:topleft#
RP/0/0/CPU0:Sep 16 12:23:14.304 : pim[1126]: [-426959984] VRF : default (192.168.1.18,225.1.1.1) Start registering to 192.168.0.3 RP/0/0/CPU0:topleft#sh pim topology Fri Sep 16 12:23:23.940 CEST IP PIM Multicast Topology Table Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive     RA - Really Alive, IA - Inherit Alive, LH - Last Hop     DSS - Don't Signal Sources,  RR - Register Received     SR - Sending Registers, E - MSDP External, EX - Extranet     DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap     MT - Crossed Data MDT threshold, MA - Data MDT group assigned Interface state: Name, Uptime, Fwd, Info Interface flags: LI - Local Interest, LD - Local Dissinterest,     II - Internal Interest, ID - Internal Dissinterest,     LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet (*,224.0.1.40) DM Up: 5w2d RP: 0.0.0.0 JP: Null(never) RPF: Null,0.0.0.0 Flags:   GigabitEthernet0/0/0/0      5w2d      off LI II (192.168.1.18,225.1.1.1)SPT SM Up: 00:00:09 JP: Join(never) RPF: GigabitEthernet0/0/0/2,192.168.1.18* Flags: KAT(00:03:23) RA SR   Encapstunnel0               00:00:09  fwd RP/0/0/CPU0:topleft#

 

  • RP will receive the PIM register on it's decapstunnel interface  and forward packets from registers down the (*,G) RPT route towards the  receivers based on the (*,G) entry which had been created when the receivers had joined:

 

RP/0/0/CPU0:bottomleft#sh pim topology 225.1.1.1
Fri Sep 16 12:25:34.027 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 5w2d RP: 192.168.0.3* 
JP: Join(never) RPF: Decapstunnel1,192.168.0.3 Flags: 
  GigabitEthernet0/0/0/0      5w2d      fwd Join(00:03:04) 
RP/0/0/CPU0:bottomleft#

 

We can see that on the RP, the RPF interface is the Decapstunnel1 interface as packets are supposed to be received in PIM registers.

 

  • RP will create an (S,G) SPT towards the source DR so that packets  can flow over this (S,G) entry from the source to the RP without the  need for PIM registers as there is some overhead to encapsulate the mcast packets into unicast PIM registers and decapsulate them.

 

RP (bottomright):

 

RP/0/0/CPU0:bottomleft#sh pim topology 225.1.1.1
Fri Sep 16 12:26:56.444 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 5w2d RP: 192.168.0.3* 
JP: Join(never) RPF: Decapstunnel1,192.168.0.3 Flags: 
  GigabitEthernet0/0/0/0      5w2d      fwd Join(00:02:42) 

(192.168.1.18,225.1.1.1) SM Up: 00:00:12 
JP: Join(00:00:37) RPF: GigabitEthernet0/0/0/1,192.168.1.5 Flags: KAT(00:03:19) RA RR (00:04:22) 
  No interfaces in immediate olist
RP/0/0/CPU0:bottomleft#

 

We know have an (S,G) entry with the upstream state having its RPF interface towards the source.

No interface in output list at this point (until a DR connected to a receiver decides to join the SPT and if this SPT goes through the RP).

 

Source DR (topright):

 

RP/0/0/CPU0:topleft#sh pim topology 225.1.1.1
Fri Sep 16 12:28:02.123 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(192.168.1.18,225.1.1.1)SPT SM Up: 00:04:48 
JP: Join(never) RPF: GigabitEthernet0/0/0/2,192.168.1.18* Flags: AA PA 
  GigabitEthernet0/0/0/1      00:01:18  fwd Join(00:03:13) 
RP/0/0/CPU0:topleft#

 

The downstream interface is the interface towards the RP.

 

  • Once SPT is setup from source to RP, RP will send PIM Register- Stop message to source DR (topleft):

 

RP/0/0/CPU0:topleft#

Sep 16 12:27:56.212 : pim[1126]: [-426959984] VRF : default (192.168.1.18,225.1.1.1) Stop registering

 

  • Receiver DR (bottomright) when receiving a packet over the RTP will detect new sources thanks to the NS flag and PIM will be signaled to build an (S,G) shortest path tree (SPT) towards the source. So that packets will flow on the SPT from the  source to the receivers without help from the RP at that point. Note  that this SPT may or may not go through the RP, this depends on the RPF  path from the receiver to the source. But there is now an SPT (S,G) entry  being created along the path while before packets were being forwarded  through the (*,G) RPT entry.

 

Note that the RPF interface for the source on bottomright is through topright.... so the SPT won't go through the RP in our lab.

 

RP/0/0/CPU0:bottomright#sh pim topology 225.1.1.1
Fri Sep 16 12:47:17.447 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 5w2d RP: 192.168.0.3 
JP: Join(00:00:41) RPF: GigabitEthernet0/0/0/0,192.168.1.9 Flags: LH 
  GigabitEthernet0/0/0/2      5w2d      fwd LI LH 

(192.168.1.18,225.1.1.1) SM Up: 00:01:36 
JP: Join(00:00:11) RPF: GigabitEthernet0/0/0/1,192.168.1.13 Flags: KAT(00:01:54) RA DCC 
  No interfaces in immediate olist
RP/0/0/CPU0:bottomright#

 

  • Once receiver DR starts receiving packets on the SPT, it sends an (S,G,RPT) Prune towards the RP so that the RP will stop forwarding  packet towards the receiver on the RPT since the receiver is already getting the packets directly through the SPT.

 

RP/0/0/CPU0:bottomleft#sh pim topology 225.1.1.1
Fri Sep 16 12:49:18.533 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 5w2d RP: 192.168.0.3* 
JP: Join(never) RPF: Decapstunnel1,192.168.0.3 Flags: 
  GigabitEthernet0/0/0/0      5w2d      fwd Join(00:03:20) 

(192.168.1.18,225.1.1.1)RPT SM Up: 00:00:09 RP: 192.168.0.3*    <=======  (S,G,RPT) entry
JP: Prune(never) RPF: Decapstunnel1,192.168.0.3 Flags: KAT(00:03:21) RA DCC RR (00:04:22) 
  GigabitEthernet0/0/0/0      00:00:09  off Prune(00:03:20)     <======= pruned by bottomright

(192.168.1.18,225.1.1.1) SM Up: 00:07:51 
JP: Null(never) RPF: GigabitEthernet0/0/0/1,192.168.1.5 Flags: KAT(00:03:21) RA DCC RR (00:04:22) <====== SPT towards source not joined anymore
  No interfaces in immediate olist
RP/0/0/CPU0:bottomleft#

 

All these steps should happen pretty quickly once the source starts to  transmit so in theory you would not see them unless something breaks and  we end up being stuck in an intermediate step. Here is how it should  look like in the end:

 

  • Source DR:

 

RP/0/0/CPU0:topleft#sh pim topology 225.1.1.1
Thu Sep 15 16:26:08.232 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(192.168.1.18,225.1.1.1)SPT SM Up: 00:05:14 
JP: Join(never) RPF: GigabitEthernet0/0/0/2,192.168.1.18* Flags: KAT(00:02:59) RA 
  GigabitEthernet0/0/0/0      00:05:09  fwd Join(00:03:23) 
RP/0/0/CPU0:topleft#
RP/0/0/CPU0:topleft#sh mrib route 225.1.1.1
Thu Sep 15 16:26:50.678 CEST

IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept

(192.168.1.18,225.1.1.1) RPF nbr: 192.168.1.18 Flags:
  Up: 00:05:56
  Incoming Interface List
    GigabitEthernet0/0/0/2 Flags: A, Up: 00:05:56
  Outgoing Interface List
    GigabitEthernet0/0/0/0 Flags: F NS, Up: 00:05:52
RP/0/0/CPU0:topleft#

 

There's just an (S,G) with Incoming interface is the interface connected  to source and outgoing interface list contains all egress interface towards receivers which have joined the SPT.

 

  • Receiver DR:

 

 

RP/0/0/CPU0:bottomright#sh pim topology 225.1.1.1
Thu Sep 15 16:27:15.628 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 5w2d RP: 192.168.0.3 
JP: Join(00:00:42) RPF: GigabitEthernet0/0/0/0,192.168.1.9 Flags: LH 
  GigabitEthernet0/0/0/2      5w2d      fwd LI LH 

(192.168.1.18,225.1.1.1)SPT SM Up: 00:06:17 
JP: Join(00:00:32) RPF: GigabitEthernet0/0/0/1,192.168.1.13 Flags: KAT(00:01:56) RA 
  No interfaces in immediate olist
RP/0/0/CPU0:bottomright#
RP/0/0/CPU0:bottomright#sh mrib route 225.1.1.1
Thu Sep 15 16:27:22.178 CEST

IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept

(*,225.1.1.1) RPF nbr: 192.168.1.9 Flags: C
  Up: 5w2d
  Incoming Interface List
    GigabitEthernet0/0/0/0 Flags: A NS, Up: 5w1d
  Outgoing Interface List
    GigabitEthernet0/0/0/2 Flags: F NS LI, Up: 5w2d

(192.168.1.18,225.1.1.1) RPF nbr: 192.168.1.13 Flags:
  Up: 00:06:23
  Incoming Interface List
    GigabitEthernet0/0/0/1 Flags: A, Up: 00:06:23
  Outgoing Interface List
    GigabitEthernet0/0/0/2 Flags: F NS, Up: 00:06:23
RP/0/0/CPU0:bottomright#

 

The (*,G) entry has an RPF entry pointing towards the RP (this is where new groups should be coming from).

The (S,G) entry has an RPF entry pointing towards the source.

 

  • RP:

 

RP/0/0/CPU0:bottomleft#sh pim topology 225.1.1.1
Thu Sep 15 16:28:31.047 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 5w1d RP: 192.168.0.3* 
JP: Join(never) RPF: Decapstunnel1,192.168.0.3 Flags: 
  GigabitEthernet0/0/0/0      5w1d      fwd Join(00:03:07) 

(192.168.1.18,225.1.1.1)RPT SM Up: 00:07:22 RP: 192.168.0.3* 
JP: Prune(never) RPF: Decapstunnel1,192.168.0.3 Flags: KAT(00:03:32) RA DCC RR (00:04:34) 
  GigabitEthernet0/0/0/0      00:07:22  off Prune(00:03:07) 

(192.168.1.18,225.1.1.1) SM Up: 00:07:35 
JP: Null(never) RPF: GigabitEthernet0/0/0/1,192.168.1.5 Flags: KAT(00:03:32) RA DCC RR (00:04:34) 
  No interfaces in immediate olist
RP/0/0/CPU0:bottomleft#
RP/0/0/CPU0:bottomleft#sh mrib route 225.1.1.1
Thu Sep 15 16:28:35.359 CEST

IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept

(*,225.1.1.1) RPF nbr: 192.168.0.3 Flags: C
  Up: 5w1d
  Incoming Interface List
    Decapstunnel1 Flags: A, Up: 5w1d
  Outgoing Interface List
    GigabitEthernet0/0/0/0 Flags: F NS, Up: 5w1d

(192.168.1.18,225.1.1.1) RPF nbr: 192.168.0.3 Flags: L
  Up: 00:07:39
  Incoming Interface List
    Decapstunnel1 Flags: A, Up: 00:07:26
RP/0/0/CPU0:bottomleft#

 

The state on the RP will depend on whether the SPT goes through it or  not. That will be reflected on the (S,G) entry as it may or may not join  upstream depending on whether it has received (S,G) joins on downstream interfaces or not.

 

Note: all the tests above were done with this very simple mcast config on all routers:

 

router pim
 address-family ipv4
  rp-address 192.168.0.3
 !
!
multicast-routing
 address-family ipv4
  interface all enable
 !
!

 

Enabling multicast-routing on an interface will enable PIM and IGMP automatically. No need to configure the PIM mode on interfaces in XR as it's determined by the group range.

 

Summary of PIM SM:

 

  • A receiver builds an RP Tree (RPT) which is made of (*,G) routes from the RP to the receiver. The RPF interface for the (,G) entries is the interface towards the RP.
  • When the source transmits, first packets are sent by the source DR through PIM Registers (unicast messages to the RP address).
  • There's a temporary SPT (S,G) from the RP to the source.
  • There's a final SPT (S,G) built from the receiver DR towards the source. RPF interface is the source.
  • Receiver DR sends (S,G,RPT) to the RP to let the RP know that there's no need to send this (S,G) down the RPT.
  • Periodic Null Registers from the source DR to the RP to let  the RP know that the source is still alive in case there are new receivers. If no new receivers, RP replies with Register Stop.

 

PIM Sparse Mode with Anycast RP

 

Anycast RP is an extension of PIM SM to provide RP redundancy and loadbalancing.

 

lab-enxr-mcast-anycast.jpg

 

The idea is:

 

  • 2 RPs configured with an extra loopback with the same address on both RPs.
  • That address is advertized into the IGP by both RPs.
  • Other PIM routers in the network configured as usual for PIM SM with that address as RP (manually configured, auto-rp, BSR).
  • PIM routers will use the closest RP since they will prefer the best metric to reach the anycast loopback address.
  • The problem is when the source is on one RP and the receiver  is on the other RP. For this scenario, the 2 RPs run the Multicast  Source Discovery Protocol (MSDP) between them to let the other RP know when a new source is active.
  • When an RP receives an MSDP Source Active (SA) message, it  can join toward that source and then forward packets to its receivers  through the RPT.
  • When receiver DR starts receiving packets through the RPT, it  can then join the SPT toward the source directly and prune the (S,G,RPT). This is usual PIM SM behavior.

 

Config on the RP:

 

interface Loopback1  <=== new loopback just used for anycast-RP, same address on both RPs
 ipv4 address 192.168.0.255 255.255.255.255
!
router ospf lab
 area 0
  interface Loopback1
   passive enable
  !
router msdp
 originator-id Loopback0
 peer 192.168.0.4
  connect-source Loopback0
  description bottomright
 !
!
router pim
 address-family ipv4
  rp-address 192.168.0.255

 

Note: you must configure originator-id in XR while in IOS it was not required.

 

And the other PIM routers in the network point their RP at 192.168.0.255.

 

Here are the different steps:

 

  • MSDP peering must be up between the 2 RPs but without SA initially:

 

 

RP/0/0/CPU0:bottomright#sh msdp peer 
Mon Sep 19 12:38:45.862 CEST
MSDP Peer 192.168.0.3 (?), AS 0
Description: bottomleft
  Connection status:
    State: Up, Resets: 0, Connection Source: 192.168.0.4
    Uptime(Downtime): 01:31:42, SA messages received: 19
    TLV messages sent/received: 184/187
  Output messages discarded: 0
    Connection and counters cleared 01:31:42 ago
  SA Filtering:
    Input (S,G) filter: none
    Input RP filter: none
    Output (S,G) filter: none
    Output RP filter: none
  SA-Requests:
    Input filter: none
    Sending SA-Requests to peer: disabled
  Password: None 
  Peer ttl threshold: 0
  Input queue size: 0, Output queue size: 0
  KeepAlive timer period: 30
  Peer Timeout timer period: 75
RP/0/0/CPU0:bottomright#sh msdp sa-cache 
Mon Sep 19 12:38:53.670 CEST
No SA entries found
RP/0/0/CPU0:bottomright#

 

 

  • When the receiver toprightce sends IGMP report, the receiver DR topright builds RPT with bottomright as it's its closest RP:

 

 

RP/0/0/CPU0:bottomright#sh mrib route 225.1.1.1
Mon Sep 19 12:36:44.319 CEST

IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept

(*,225.1.1.1) RPF nbr: 192.168.0.255 Flags: C
  Up: 00:56:22
  Incoming Interface List
    Decapstunnel0 Flags: A, Up: 00:56:22
  Outgoing Interface List
    GigabitEthernet0/0/0/1 Flags: F NS, Up: 00:56:22
RP/0/0/CPU0:bottomright#

 

  • When source topleftce starts transmitting, the source DR will start registering to its closest RP which is bottomleft.

 

  • The RP bottomleft informs the other RP that a source is active through an MSDP SA:

 

 

RP/0/0/CPU0:bottomright#sh msdp sa-cache 
Mon Sep 19 12:42:11.342 CEST

MSDP Flags:
E - set MRIB E flag , L - domain local source is active,
EA - externally active source, PI - PIM is interested in the group,
DE - SAs have been denied.  Timers age/expiration,
Cache Entry:
(192.168.1.18, 225.1.1.1), RP 192.168.0.3, MBGP/AS 0, 00:00:29/00:02:00
  Learned from peer 192.168.0.3, RPF peer 192.168.0.3
  SAs recvd 1, Encapsulated data received: 100
    grp flags: PI,  src flags: E, EA, PI
RP/0/0/CPU0:bottomright#

 

That first SA should contain the first encapsulated packet so that it can be forwarded down the RPT towards the receiver.

 

  • The RP bottomleft joins towards the source:

 

RP/0/0/CPU0:bottomright#sh pim topology 225.1.1.1
Mon Sep 19 12:43:36.423 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 01:03:14 RP: 192.168.0.255* 
JP: Join(never) RPF: Decapstunnel0,192.168.0.255 Flags: 
  GigabitEthernet0/0/0/1      01:03:14  fwd Join(00:03:15) 

(192.168.1.18,225.1.1.1) SM Up: 00:01:54 
JP: Join(now) RPF: GigabitEthernet0/0/0/1,192.168.1.13 Flags: E 
  No interfaces in immediate olist
RP/0/0/CPU0:bottomright#

 

 

  • The receiver DR starts getting packets and joins towards the source:

 

 

RP/0/0/CPU0:topright#sh pim topology 225.1.1.1
Mon Sep 19 12:44:42.443 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 01:12:19 RP: 192.168.0.255 
JP: Join(00:00:29) RPF: GigabitEthernet0/0/0/1,192.168.1.14 Flags: LH 
  GigabitEthernet0/0/0/2      01:12:19  fwd LI LH 

(192.168.1.18,225.1.1.1)SPT SM Up: 00:03:00 
JP: Join(00:00:49) RPF: GigabitEthernet0/0/0/0,192.168.1.1 Flags: KAT(00:03:20) RA 
  No interfaces in immediate olist
RP/0/0/CPU0:topright#

 

 

  • Once topright receives packets on the SPT, it can prune the  (S,G,RPT) entry since packets do not need to come from the RP anymore:

 

RP/0/0/CPU0:bottomright#sh pim topology 225.1.1.1
Mon Sep 19 12:46:30.384 CEST

IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive
    RA - Really Alive, IA - Inherit Alive, LH - Last Hop
    DSS - Don't Signal Sources,  RR - Register Received
    SR - Sending Registers, E - MSDP External, EX - Extranet
    DCC - Don't Check Connected, ME - MDT Encap, MD - MDT Decap
    MT - Crossed Data MDT threshold, MA - Data MDT group assigned
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary, EX - Extranet

(*,225.1.1.1) SM Up: 01:06:08 RP: 192.168.0.255* 
JP: Join(never) RPF: Decapstunnel0,192.168.0.255 Flags: 
  GigabitEthernet0/0/0/1      01:06:08  fwd Join(00:03:21) 

(192.168.1.18,225.1.1.1)RPT SM Up: 00:01:59 RP: 192.168.0.255* 
JP: Prune(never) RPF: Decapstunnel0,192.168.0.255 Flags: 
  GigabitEthernet0/0/0/1      00:01:59  off Prune(00:03:21)       <====== (S,G,RPT) has been pruned

(192.168.1.18,225.1.1.1) SM Up: 00:01:05 
JP: Null(never) RPF: GigabitEthernet0/0/0/1,192.168.1.13 Flags: E 
  No interfaces in immediate olist                               <======= The SPT is not through the RP so (S,G) is useless now
RP/0/0/CPU0:bottomright#

 

 

Summary of Anycast RP:

  • 2 RPs with one new loopback with the same address on both RPs. That loopback address is advertized in the IGP and is configured as RP addresses in the PIM network.
  • It's Sparse-Mode as usual for all routers as they connect to their closest RP based on the best IGP metric.
  • The 2 RPs run MSDP between them to let the other one know when a source becomes active.

 

Bidirectional PIM (Bidir)

 

Bidir PIM is significantly simpler in operation than Sparse-Mode. Bidir eliminates the maintenance of source states (no (S,G) entries, only  (*,G)) and there's no data driven events hence packets never need to be  signaled and preserved. So that makes it much more scalable for many-to-many applications.

 

Bidir PIM uses the Designated Forwarder (DF) election mechanism (based on routing protocol cost to the RP) to elect a single router on each  link which becomes responsible for two special tasks:

 

  • DF is responsible for picking up packets from the link and forwarding them upstream towards the RP.
  • DF is responsible for forwarding downstream traveling packets  from the RP onto the link (provided a Join has been received for the  group).

 

There's no bidir range by default so we first need to create one on each router and have it point to one RP:

 

RP/0/0/CPU0:topleft#sh run ipv4 access-list bidir-range 
Fri Sep 16 16:54:39.114 CEST
ipv4 access-list bidir-range
 10 permit ipv4 226.0.0.0 0.255.255.255 any
!

RP/0/0/CPU0:topleft#sh run router pim
Fri Sep 16 16:54:42.618 CEST
router pim
 address-family ipv4
  rp-address 192.168.0.3
  rp-address 192.168.0.3 bidir-range bidir
 !
!

RP/0/0/CPU0:topleft#sh pim group-map 
Fri Sep 16 16:54:48.316 CEST

IP PIM Group Mapping Table 
(* indicates group mappings being used) 
(+ indicates BSR group mappings active in MRIB) 

Group Range         Proto Client   Groups RP address      Info

224.0.1.39/32*      DM    perm     0      0.0.0.0         
224.0.1.40/32*      DM    perm     1      0.0.0.0         
224.0.0.0/24*       NO    perm     0      0.0.0.0         
232.0.0.0/8*        SSM   config   0      0.0.0.0         
226.0.0.0/8*        BD    config   0      192.168.0.3     RPF: Gi0/0/0/1,192.168.1.6    <====== bidir
224.0.0.0/4*        SM    config   0      192.168.0.3     RPF: Gi0/0/0/1,192.168.1.6
224.0.0.0/4         SM    static   0      0.0.0.0         RPF: Null,0.0.0.0
RP/0/0/CPU0:topleft#

 

So the first thing to check is where the router has been elected as DF:

 

RP/0/0/CPU0:topleft#sh pim df election-state 
Sun Sep 18 23:45:07.620 CEST

RP               Interface                    DF State      Timer       Metrics
192.168.0.3      GigabitEthernet0/0/0/3       Winner        4s 713ms    [110/2]
192.168.0.3      GigabitEthernet0/0/0/2       Winner        0s 713ms    [110/2]
192.168.0.3      GigabitEthernet0/0/0/1       Lose          0s 0ms      [inf/inf]
192.168.0.3      GigabitEthernet0/0/0/0       Winner        3s 113ms    [110/2]
192.168.0.3      Loopback0                    Winner        6s 113ms    [110/2]
RP/0/0/CPU0:topleft#
RP/0/0/CPU0:topleft#sh mrib route 226.0.0.0/8           
Sun Sep 18 23:47:42.605 CEST

IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept

(*,226.0.0.0/8) RPF nbr: 192.168.1.6 Flags: IF
  Up: 2d06h
  Incoming Interface List
    Loopback0 Flags: A, Up: 2d06h
    GigabitEthernet0/0/0/0 Flags: A, Up: 2d06h
    GigabitEthernet0/0/0/1 Flags: F A, Up: 2d06h
    GigabitEthernet0/0/0/2 Flags: A, Up: 2d06h
    GigabitEthernet0/0/0/3 Flags: A, Up: 2d06h
  Outgoing Interface List
    GigabitEthernet0/0/0/1 Flags: F A, Up: 2d06h
RP/0/0/CPU0:topleft#

 

So under steady state (no receiver yet), the router has a (*,G/Mask) where:

  • Packets are accepted on the interfaces where the router has won the DF election.
  • Packets are forwarded on the upstream interface towards the RP (Gi0/0/0/1 on topleft) to make sure that traffic will reach the RP.  Note that the DF election makes sure that the router closest to the RP  (lowest routing protocol cost to the RP) will be elected DF and forward  packets upstream toward the RP).
  • Packets coming from the RP are accepted.

 

The accepting interfaces will not change over time. When a receiver  joins, we will create a (*,G) for the group being joined but that (*,G)  will inherit the accepting interfaces from that (*,G/M) above thanks to the Inherit Accept (IA) flag. The new (*,G) will only have the  forwarding info to indicate where there are receivers for that group and  forward packets accordingly.

 

So let's add a receiver on toprightce:

 

RP/0/0/CPU0:topright#sh igmp groups 226.1.1.1
Mon Sep 19 00:58:28.909 CEST
IGMP Connected Group Membership
Group Address   Interface                     Uptime    Expires   Last Reporter
226.1.1.1       GigabitEthernet0/0/0/2        00:00:23  00:01:55  192.168.1.34
RP/0/0/CPU0:topright#
RP/0/0/CPU0:topright#sh mrib route            
Mon Sep 19 01:02:55.986 CEST

IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept

<snip>
(*,226.0.0.0/8) RPF nbr: 192.168.1.14 Flags: IF
  Up: 01:19:27
  Incoming Interface List
    Loopback0 Flags: A, Up: 01:19:27
    GigabitEthernet0/0/0/1 Flags: F A, Up: 01:19:27
    GigabitEthernet0/0/0/2 Flags: A, Up: 01:19:27
    GigabitEthernet0/0/0/3 Flags: A, Up: 01:19:27
  Outgoing Interface List
    GigabitEthernet0/0/0/1 Flags: F A, Up: 01:19:27

(*,226.1.1.1) RPF nbr: 192.168.1.14 Flags: IA Inherit: 226.0.0.0/8  <===== Inherit Accept
  Up: 00:04:50
  Outgoing Interface List
    GigabitEthernet0/0/0/1 Flags: F, Up: 00:04:50
    GigabitEthernet0/0/0/2 Flags: F LI, Up: 00:04:50

(*,232.0.0.0/8) Flags: D
  Up: 5w5d
RP/0/0/CPU0:topright#
RP/0/0/CPU0:topright#sh pim df election-state 
Mon Sep 19 01:04:49.010 CEST

RP               Interface                    DF State      Timer       Metrics
192.168.0.3      GigabitEthernet0/0/0/3       Winner        7s 733ms    [110/3]
192.168.0.3      GigabitEthernet0/0/0/2       Winner        2s 133ms    [110/3]
192.168.0.3      GigabitEthernet0/0/0/1       Lose          0s 0ms      [inf/inf]
192.168.0.3      GigabitEthernet0/0/0/0       Lose          0s 0ms      [110/3]
192.168.0.3      Loopback0                    Winner        10s 333ms   [110/3]
RP/0/0/CPU0:topright#

 

So we can see from the (*,G/M) that topright has won the DF election on 0/0/0/2 and 0/0/0/3 so it will accept on these 2 interfaces. It will  also accept from the RP (0/0/0/1). And it will forward to the RP.

We can see that the (*,G) inherits the accepting interface from the  (*,G/M) through the IA flag and has its forwarding interface set to the  upstream interface to the RP (0/0/0/1) and to the interface with the receiver (0/0/0/2).

So what happens when the source (topleftce) starts transmitting ?  topleft forwards packet to the RP bottomleft based on the (*,G/M) and  there's no (S,G) or (*,G) created for that source and no signaling at  all. The forwarding is just based on the (*,G/M) entry which was already  there in steady state.

 

So packets make it to the RP bottomleft where we had these entries:

 

(*,226.0.0.0/8) RPF nbr: 192.168.0.3 Flags: IF
  Up: 01:41:17
  Incoming Interface List
    Loopback0 Flags: F A, Up: 01:41:17
    GigabitEthernet0/0/0/0 Flags: A, Up: 01:41:17
    GigabitEthernet0/0/0/1 Flags: A, Up: 01:41:15
    GigabitEthernet0/0/0/2 Flags: A, Up: 01:41:17
    GigabitEthernet0/0/0/3 Flags: A, Up: 01:41:16
  Outgoing Interface List
    Loopback0 Flags: F A, Up: 01:41:17

(*,226.1.1.1) RPF nbr: 192.168.0.3 Flags: IA Inherit: 226.0.0.0/8
  Up: 00:26:31
  Outgoing Interface List
    Loopback0 Flags: F, Up: 00:26:31
    GigabitEthernet0/0/0/0 Flags: F, Up: 00:26:31

 

So we were accepting packets from topleft on 0/0/0/1 since we've won the  DF election (we're the RP!) and we're forwarding on 0/0/0/0 since we've  received a join on this interface due to the receiver joining off  topright. So bottomleft will accept the packet thanks to the (*,G/M) and  forward it thanks to the (*,G). Downstream routers bottomright and  topright will do the same and packets will reach the receiver...

 

Summary of bidir:

 

  • Designated Forwarder election based on routing protocol metric to the RP.
  • Routers have a (*,G/M) entry accepting from the RP and on interfaces where they've won the DF election. The (*,G/M) forwards towards the RP.
  • Routers create a (*,G) when there are receivers. That entry has  the IA flag so it inherits the accepting interfaces from the (*,G/M).  And it forwards towards the RP and towards receivers.
  • No (S,G) entry.
Comments
Cisco Employee

brilliant !

Cisco Employee

Well written!

Cisco Employee

Better than any book I have read. Thank you for your time.

ar
Community Member

How do we enable bidir in XR if not using static RP?

Looking for the command equivalent to  ip pim bidir enable in IOS.

thanks

17981
Views
25
Helpful
4
Comments