Introduction - Freerabdoul.free.fr/SPADVROUTE12/MCAST/Introduction to... · IOS XR multicast is based on the MFIB architecture which has been introduced recently in IOS too. IOX XR

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.


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:





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:


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",


5 sur 45 15/06/2017 09:43

you can jump to the appropriate section below.


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

the Drop flag:


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:


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


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.


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.


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:


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:


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.


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.


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.


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:


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:


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).


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:


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):


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):


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.


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.


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:


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.


24 sur 45 15/06/2017 09:43

Receiver DR:


25 sur 45 15/06/2017 09:43


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:


27 sur 45 15/06/2017 09:43


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.


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.


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.


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:


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:


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:


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:


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:


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.


Bidir PIM is significantly simpler in operation than Sparse-Mode. Bidir eliminates the maintenance of


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:


37 sur 45 15/06/2017 09:43

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


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).


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:


40 sur 45 15/06/2017 09:43


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


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 !


43 sur 45 15/06/2017 09:43

Documents

Introduction - Freerabdoul.free.fr/SPADVROUTE12/MCAST/Introduction to... · IOS XR multicast is based on the MFIB architecture which has been introduced recently in IOS too. IOX XR