introduction - freerabdoul.free.fr/spadvroute12/mcast/introduction to... · ios xr multicast is...
TRANSCRIPT
Share
Introduction to IOS XR Multicast
Jean-Christophe Rode 5 years ago (May 14th, 2012)
Table of Contents [hide]
Introduction
Multicast
PIM Source Specific Multicast (SSM)
PIM Sparse Mode (SM)
PIM Sparse Mode with Anycast RP
Bidirectional PIM (Bidir)
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.
Wed, 12/14/2016 - 00:41
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
2 sur 45 15/06/2017 09:43
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
3 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
4 sur 45 15/06/2017 09:43
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",
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
5 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
6 sur 45 15/06/2017 09:43
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:
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
7 sur 45 15/06/2017 09:43
There is one PIM router on that network connected to the receiver which is elected Designated
Router:
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
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
8 sur 45 15/06/2017 09:43
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).
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
9 sur 45 15/06/2017 09:43
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
10 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
11 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
12 sur 45 15/06/2017 09:43
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:
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
13 sur 45 15/06/2017 09:43
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
14 sur 45 15/06/2017 09:43
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":
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.
1.
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.
2.
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
15 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
16 sur 45 15/06/2017 09:43
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).
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
17 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
18 sur 45 15/06/2017 09:43
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):
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
19 sur 45 15/06/2017 09:43
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):
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
20 sur 45 15/06/2017 09:43
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
21 sur 45 15/06/2017 09:43
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
22 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
23 sur 45 15/06/2017 09:43
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
24 sur 45 15/06/2017 09:43
Receiver DR:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
25 sur 45 15/06/2017 09:43
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
26 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
27 sur 45 15/06/2017 09:43
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
28 sur 45 15/06/2017 09:43
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:
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
29 sur 45 15/06/2017 09:43
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.
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
30 sur 45 15/06/2017 09:43
Config on the RP:
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
31 sur 45 15/06/2017 09:43
When the receiver toprightce sends IGMP report, the receiver DR topright builds RPT with
bottomright as it's its closest RP:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
32 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
33 sur 45 15/06/2017 09:43
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:
The receiver DR starts getting packets and joins towards the source:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
34 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
35 sur 45 15/06/2017 09:43
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
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
36 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
37 sur 45 15/06/2017 09:43
So the first thing to check is where the router has been elected as DF:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
38 sur 45 15/06/2017 09:43
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).
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
39 sur 45 15/06/2017 09:43
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:
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
40 sur 45 15/06/2017 09:43
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
41 sur 45 15/06/2017 09:43
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:
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
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
42 sur 45 15/06/2017 09:43
kiprakas 5 years ago
Well written!
sanjeewa 3 years ago
Better than any book I have read. Thank you for your time.
ar 6 months ago
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
Overall Rating: 5 (5 ratings)
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.
jdive 5 years ago
brilliant !
Introduction to IOS XR Multicast | XR OS and Platforms | Cisco Suppo... https://supportforums.cisco.com/document/100301/introduction-ios-x...
43 sur 45 15/06/2017 09:43