The Cisco CLI Analyzer is a standalone SSH client infused with Cisco TAC Intellectual Capital, and is available for Windows and Mac OS X platforms.   The TAC Data Collection tool is part of the CLI Analyzer and allows automatic collection of diagnostic commands requested by your TAC engineer. This is supported on ASA, IOS, IOS-XE, IOS-XR, NX-OS, WLC, and UCS platforms.   If you already have the CLI Analyzer installed, you may go directly to this video for a demo of the TAC Data Collection tool.   Objective   Collecting show commands from a device and sending the output to a TAC engineer appears to be a simple task, but often it is not. Errors created by copy-pasting commands to the device, terminal length cutting off outputs, email attachments too large, emails sent to one engineer while the TAC case is re-queued to another engineer in addition to the time it takes to complete this task and for TAC to follow up to correct any issues with collection errors. It should be faster and simpler. Now it is...   The TAC Data Collection Tool was created to make this process more reliable and easier.   This document will guide you through your first data collection.   Email From TAC Engineer   The TAC Data Collection process is initiated by a TAC engineer when diagnostic commands are needed from one or more of your devices.   The TAC engineer creates a data collection request identified by a TaskID which points a list of commands to collect and upload to your TAC case.  A TaskID looks like "#TAC-D0A6-2561" (with the # sign and without the quotes).  The TaskID needs to be entered in the CLI Analyzer to tell the tool which commands to collect and which case they should be uploaded to.   Note: Ensure you only run the TAC Data Collection tool on the device(s) your TAC engineer has requested.   This TaskID is shared by the TAC engineer in an email to the case contact similar to the one below:   -------- Forwarded Message -------- Subject: Data collection task #TAC-D0A6-2561 for TAC case 681631261 Date: Wed, 18 Jan 2017 14:58:25 GMT From: xxxx@cisco.com To: yyyy@cisco.com CC: xxxx@cisco.com , attach@cisco.com   Dear Customer, In order to move things forward in SR 681631261, I need your assistance to collect a few CLI outputs from the device you opened the SR on. This will help assess the technical direction to take. You have a couple of options to provide the CLI outputs. Option 1: Use Cisco CLI Analyzer to collect required CLI commands automatically. Step 1. Download CLI Analyzer for your platform (Win/Mac): https://cway.cisco.com/go/sa/ Note: If you already have CLI Analyzer 3.2 or greater installed proceed to Step 2. Step 2. Use the CLI Analyzer to connect to the device. Step 3. Click on the Tools button (top right corner) and run the "TAC Data Collection" tool. Step 4. Select TaskID #TAC-D0A6-2561 from the dropdown or paste it. Option 2: If you prefer to collect data manually, please collect the following outputs: admin show platform show install active summary show run show log For option 2, you can use https://cway.cisco.com/csc/index.html?requestID=681631261 for diagnostic data upload. Thank you.   As explained in the email, using the CLI Analyzer to collect the commands is optional and customers may still collect commands with their favorite telnet/SSH client and send them to the TAC engineer by email or through the Case File Uploader.   This document will guide you through the steps to collect the commands with the TAC Data Collection tool.   Step 1.  Install CLI Analyzer   If you're already running CLI Analyzer 3.2 or above, you can skip this step.   The CLI Analyzer can be downloaded from:   https://cway.cisco.com/go/sa/    You should be able to follow the install procedure on Mac or Windows relatively easily by selecting the defaults.   First Run - Master Password   The CLI Analyzer can remember the device credentials. A master password is used to protect these credentials on your computer:     This master password will be requested each time you open the CLI Analyzer again in the future to be able to unlock the device credentials.   Main Window   After entering the master password, the main window appears:     The "Devices" tab is selected and this is where you will find all your saved devices.  Once you have a few devices created, you can search by name, location, version, labels  etc to limit the number of devices being displayed.   Step 2.  Connect to the Device   Creating Devices   There are 3 ways to create new devices and connect to them:   Click  "New Session" in the left toolbar and enter the destination IP address or hostname, the type (SSH, telnet, serial port or shared/screen sharing) and the port number.  This will connect you directly to the device but this will also created a bookmark for this device under the "Devices" tab. When the "Devices" tab is selected, click the "+" sign (with a red circle in the screenshot above) to first create a bookmark for the device.   When creating or editing a device, you can set some fields like a location or label(s) which can help limit the number of devices when searching for them.  Here is how the "Devices" tab looks like after creating 3 new devices but filtering on "Euro-TAC" to only display devices whose location has been set to Euro-TAC:        Now you can connect to the device by clicking on "New Session" in the left bar or click on the connect button below the device (red circle in screenshot above).   Detecting Device Type   When the CLI Analyzer logs into a device for the first time, it runs a few commands automatically to detect the device type:     You can see in the screen shot above that the commands "show version" and "admin show diag chassis" were executed. Some commands on some platforms may take a few seconds to complete so let it run until the "Device Information" is displayed.   In the example above, the CLI Analyzer detected that this is an IOS-XR device as indicated at the bottom right of the screen (red circle).    Notes:   If you reach the final device through some intermediate hops (jump server or other routers or switches), it's possible that the CLI Analyzer won't detect the correct device type. Always check the device type at the bottom right of the window. If it does not appear to be set correctly, click on the "Refresh Device Information" button at the bottom right of the window (green circle in the previous screenshot above). When connecting frequently to devices, this device detection process may not be desired.  By default, the CLI Analyzer will cache this info for up to 30 days (detection frequency is configurable in the settings).  This means that if you upgrade the software version on a device, it will still appear with the previous software version in the "Devices" tab for up to 30 days.  You may want to click on the "Refresh Device Information" button at the bottom right of the window (green circle in the previous screenshot above) after an upgrade.       Step 3. Run the TAC Data Collection Tool     Once connected to the correct device, click on the "Tools" button in the top right corner:     Click on the "TAC Data Collection" and a first form will appear:     The goal of this first form is to enter a TaskID. This is the TaskID you should have received from the TAC engineer via email.   If your CCO ID is the case contact, then the TaskID should appear in the "Select recent TaskID" dropdown and you just need to select the correct one in the dropdown (you may have multiple TaskID's for the same case or from different cases). Note: Be sure the "CCO Login field in CLI Analyzer reflects the same CCO ID associated with the TAC case in question. Otherwise, use the process that follows below. If the email from the TAC engineer was forwarded to you by a colleague who is the case contact, then your username will not be associated with the service request and the CLI Analyzer will NOT be able to display the TaskID in the dropdown. Therefore, you will have to copy-paste the TaskID from the email to the "Enter TaskID manually" text box.    Note: If there's a TaskID selected in the dropdown and also one entered manually, then the one entered manually takes precedence.   Click "Continue" and the CLI Analyzer will retrieve the list of commands associated with this TaskID, display the list and ask you whether you want to proceed and collect the commands:     The "term len 0" is inserted as the first command and the original terminal length is reset at the end. So the 2 interesting commands are the ones in the middle in the example above. Press "Continue" if you agree to collect these 2 commands and send their outputs to the TAC case.   Commands are collected:     Once all commands are collected, the outputs are posted through the Cisco APIs, attached to the TAC service request and a result window appears:     Your Cisco TAC engineer is notified of the collection so the next step is to review the outputs and get back to you with the analysis and action plan.   Please review this video for a demo of the TAC Data Collection process.   Other CLI Analyzer Features   Apart from the TAC Data Collection tool, here are some other CLI Analyzer features that you may find useful:   Contextual Help & Highlighting (CHH) Tools (System Diagnostics, Packet Capture, Top Talkers, IP Route Analysis...) Analyzing files offline Create and Update TAC Cases Shared device sessions Jump servers ... View more

The Cisco CLI Analyzer is a smart SSH and telnet client with internal TAC tools and knowledge integrated. Version 2.0.0 released on March 17th 2016 now supports IOS-XR. You can download it from: https://cway.cisco.com/go/sa/ There are 2 main features for IOS-XR: Contextual Help & Highlighting (CHH). Some show command outputs are highlighted and can be clicked to get more information about that counter. For instance for IOS-XR:  process names in the "show processes" commands, some counters in "show interface" (MTU, input drops...),  NP counters on the ASR9000,  PSE statistics counters on the CRS and NCS6000, DDTS id in "show install" commands (to get the headline of the DDTS when a SMU is installed) etc. Tools. System Diagnostics is the only tool currently available for IOS-XR. It parses the output of some show commands against the Cisco TAC knowledge and reports alerts and recommendations when some known issues are detected. Please note that for IOS-XR, it will take a few minutes to collect all commands, especially on systems with a large scale. Here is a screenshot from the tool: In the top left pane, you can see the "show process blocked" command highlighted by the CHH with one process being clicked to get the description of what the process does. The top right pane appears when clicking on Tools and we can see the "System Diagnostics" tool being listed. After clicking on "System Diagnostics", alerts are displayed in the bottom pane and they can be expanded to display more information. Please provide feedback on the tool under this page or by clicking on the feedback button in the top right corner of the tool. This is a Beta tool so we're looking to improve it in future releases. Any counter that you'd like to see documented ? Any idea for a new tool ? Thank You for helping us improve this tool. ... View more

There is a new behavior introduced by CSCse46790 which should  be introduced soon (5.1.2 and above) but we still need to understand how XR behaves in previous releases. There are 2 scenarios where this problem comes into the pictures: Non local ARP entry. Forwarding entry of /32 (or /128 for IPv6) RIB routes overridden when there is a covering connected or attached route. Let's have a look at an example for each problem. 1. Non local ARP entry. IOS XR learns ARP entries for non directly connected IPv4 addresses by default and these ARP entries will break connectivity to the corresponding /32 CEF prefix. Workaround: configure "arp learning local" on all layer 3 interfaces but it's only available since 4.3.4 through CSCty06696 or through a SMU in some earlier releases. Lab example: These 2 routers are running OSPF so that router1 learns the loopback of router2 as an OSPF route: RP/0/RSP0/CPU0:router1#sh route 10.0.0.107 Routing entry for 10.0.0.107/32   Known via "ospf core", distance 110, metric 2, type intra area   Installed Feb 10 22:52:40.812 for 01:27:00   Routing Descriptor Blocks     10.0.1.3, from 10.0.0.107, via BVI2       Route metric is 2   No advertising protos. RP/0/RSP0/CPU0:router1# The CEF entry points at 10.0.1.3 as next hop accordingly: RP/0/RSP0/CPU0:router1#sh cef 10.0.0.107 location 0/0/CPU0 10.0.0.107/32, version 1447, internal 0x4004001 (ptr 0xa4442b08) [1], 0x0 (0xa3d61eb0), 0x440 (0xa555b5f0) Updated Feb 11 00:18:21.516 local adjacency 10.0.1.3 Prefix Len 32, traffic index 0, precedence n/a, priority 1    via 10.0.1.3, BVI2, 4 dependencies, weight 0, class 0 [flags 0x0]     path-idx 0 [0xa59a4b58 0x0]     next hop 10.0.1.3     local adjacency      local label 16008      labels imposed {None} RP/0/RSP0/CPU0:router1# Now... if for some weird reason router2 sends an ARP reply or request with its loopback address 10.0.0.107 as "sender protocol address", router1 will learn that address in its ARP table even though this is not a local address on the subnet: RP/0/RSP0/CPU0:router1#sh arp location 0/0/CPU0 Address         Age        Hardware Addr   State      Type  Interface 10.0.0.107      00:00:03   0001.0001.0001  Dynamic    ARPA  BVI2 10.0.1.1        -          4055.3912.ece5  Interface  ARPA  BVI2 10.0.1.2        00:00:00   f025.72a7.ac3d  Dynamic    ARPA  BVI2 10.0.1.3        00:27:36   001d.4603.1f42  Dynamic    ARPA  BVI2 A normal router or host is not supposed to send such an ARP for a non local address but we've seen some types of routers doing that. Or when different subnets are configured on the same broadcast domain. When there's an ARP entry, CEF tries to add a corresponding adjacency prefix (/32 host route) with that IP/MAC mapping. When there is an existing host route from the routing table (RIB) like the 10.0.0.107/32 OSPF route, that RIB prefix route is removed from the FIB to be replaced by the FIB adjacency prefix since FIB prefers the adjacency prefixes over the RIB prefixes due to CSCse46790. But the problem here is that the adjacency prefix 10.0.0.107/32 will be declared as unresolved because the IP address of the non local ARP entry is not covered by the connected subnet configured on the interface. Since the RIB host route has been removed and the FIB adjacency prefix is marked as unresolved, we don't have a forwarding entry anymore for the original /32 RIB route (10.0.0.107/32 in our example) and traffic for that destination might be dropped (it might not be dropped if there is a less specific prefix like a default route for instance which can forward the packets towards the destination). RP/0/RSP0/CPU0:router1#sh cef 10.0.0.107 10.0.0.107/32, version 1447, internal 0x4004001 (ptr 0xada9bfb0) [1], 0x0 (0xad4579f8), 0x440 (0xae07e500) Updated Feb 10 22:52:40.833 Prefix Len 32, traffic index 0, precedence n/a, priority 1    via 10.0.1.3, BVI2, 2 dependencies, weight 0, class 0 [flags 0x0]     path-idx 0 [0xae39e0e0 0x0]     next hop 10.0.1.3     local adjacency      local label 16008      labels imposed {None} RP/0/RSP0/CPU0:router1#sh cef 10.0.0.107 loc 0/0/CPU0 0.0.0.0/0, version 1407, proxy default, internal 0x4000021 (ptr 0xa4442060) [1], 0x0 (0x0), 0x0 (0x0) Updated Feb  6 11:35:42.788 Prefix Len 0, traffic index 0, precedence n/a, priority 3    via 10.48.32.1, 3 dependencies, recursive [flags 0x0]     path-idx 0 [0xa4445edc 0x0]     next hop 10.48.32.1 via 10.48.32.1/32 RP/0/RSP0/CPU0:router1# We can see that the 10.0.0.107/32 prefix is missing from the CEF table on 0/0/CPU0 as we are now matching the default route 0.0.0.0/0. The prefix is actually unresolved: RP/0/RSP0/CPU0:router1#sh cef unresolved detail location 0/0/CPU0 10.0.0.107/32, version 0, internal 0x6484003 (ptr 0xa4442b08) [1], 0x0 (0x0), 0x40 (0xa555c2b0) Updated Feb 11 00:45:57.790 Prefix Len 32, traffic index 0, Adjacency-prefix, precedence n/a, priority 0    via 10.0.0.107, BVI2, 0 dependencies, weight 0, class 0 [flags 0x0]     path-idx 0 [0x0 0x0]     unresolved      local label 16008      labels imposed {None} RP/0/RSP0/CPU0:router1# There are 2 solutions: Configure "arp learning local" on all layer 3 interfaces when the router is running an IOS XR image which contains the fix for CSCty06696 (Add CLI option to handle out-of-subnet ARP requests ) so that the router will not learn non local arp entries (and hence not cause a problem with FIB adjacency prefixes being preferred over RIB routes). Upgrade to an IOS XR version with the fix for CSCse46790 (CEF prefers arp adjacency over RIB next hop ) where the default XR behavior will be changed to prefer RIB prefixes over adjacency prefixes (with a new config command "cef adjacency route override rib"  to maintain the old behavior for those who have come to rely on it). One of the 2 options should be enough to protect the router. Another option if you don't have one of the 2 fixes is to identify the hosts sending the non local arp packets and fix their config or block them... but you won't really be protected for long. 2. Forwarding entry of /32 (or /128 for IPv6) RIB routes overridden when there’s a covering connected or attached route When an IPv4 host or IPv6 host is supposed to be directly connected on an interface and we want to redirect traffic for that host through another interface by configuring a /32 IPv4 route or /128 IPv6 route, then this route may not be taken into account due to CSCse46790 (CEF prefers arp adjacency over RIB next hop) so that we may still forward traffic over the interface with the covering prefix instead of the other interface where we configured the /32 or /128 route to point to. Example: If router1 wants to reach 10.0.2.3, it would normally used the directly connected prefix 10.0.2.0/24 over BVI3. But if we want to manually route traffic for 10.0.2.3 over BVI2, we would configure a static route like: router static address-family ipv4 unicast   10.0.2.3/32 BVI2 10.0.1.3 This static route would look good on the RP/RSP: RP/0/RSP0/CPU0:router1#sh route 10.0.2.3 Routing entry for 10.0.2.3/32   Known via "static", distance 1, metric 0   Installed Feb 11 01:14:46.207 for 00:21:48   Routing Descriptor Blocks     10.0.1.3, via BVI2       Route metric is 0   No advertising protos. RP/0/RSP0/CPU0:router1#sh cef 10.0.2.3 10.0.2.3/32, version 1448, internal 0x4004001 (ptr 0xada98578) [1], 0x0 (0xad457098), 0x440 (0xae07e140) Updated Feb 11 01:14:46.217 Prefix Len 32, traffic index 0, precedence n/a, priority 3    via 10.0.1.3, BVI2, 2 dependencies, weight 0, class 0 [flags 0x0]     path-idx 0 [0xae39e0e0 0x0]     next hop 10.0.1.3     local adjacency      local label 16010      labels imposed {None} RP/0/RSP0/CPU0:router1# But on the linecard, the CEF adjacency prefix created from the ARP entry for 10.0.2.3 over BVI3 will take precedence over the RIB prefix from the static route for 10.0.2.3 pointing at BVI2 so forwarding will still be through BVI3: RP/0/RSP0/CPU0:router1#sh cef 10.0.2.3 loc 0/0/CPU0 10.0.2.3/32, version 0, internal 0x4480001 (ptr 0xa444343c) [1], 0x0 (0xa3d649d0), 0x0 (0x0) Updated Feb 11 01:14:46.227 local adjacency 10.0.2.3 Prefix Len 32, traffic index 0, Adjacency-prefix, precedence n/a, priority 0    via 10.0.2.3, BVI3, 2 dependencies, weight 0, class 0 [flags 0x0]     path-idx 0 [0xa59a41b8 0x0]     next hop 10.0.2.3     local adjacency RP/0/RSP0/CPU0:router1# This can only be avoided by running an image with the fix for CSCse46790 (CEF prefers arp adjacency over RIB next hop ) where the default XR behavior will be changed to prefer RIB prefixes over adjacency prefixes (with a new config command "cef adjacency route override rib" to maintain the old behavior for those who have come to rely on it). ... View more

    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)         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)     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):   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. 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.     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. ... View more