Anycast RP & MSDP Configuration

Anycast means to route to the nearest. This can be achieved by configuring one or more RPs (Rendezvous Points) with same IP address and with the use of a protocol called MSDP (Multicast Source Discovery Protocol). This is basically a method of configuring redundancy to RPs.
Let's see how it is working with a practical example..

Assume all the interfaces are advertised in OSPF and all interfaces including loopbacks are configured with IP PIM Sparse Mode. Only Anycast and MSDP related configuration will be discussed here.

In the diagram, if you looked closer you would notice that the loopback addresses of R1 and R3 are both same, 1.1.1.1/32. This is the address we configure on all routers to be the RP.

R1(config)#ip pim rp-address 1.1.1.1

R2(config)#ip pim rp-address 1.1.1.1

R3(config)#ip pim rp-address 1.1.1.1

R4(config)#ip pim rp-address 1.1.1.1

Now let's join PC to 239.1.1.1 multicast group and send the feed from IPTV_Svr..

PC(config)#int e0/0  
PC(config-if)#ip igmp join-group 239.1.1.1

Well, it is not pinging..

Let's look at the routing tables of RPs,

R3 even does not have a SPT (Source Path Tree) entry in his table.
Reason for this is is that sender has joined a different RP than the receiver.
This is because the nearest RP for source is R1 and the nearest RP for destination is R3.

To fix this, there must be a mechanism for both RPs to share information about the sources they learn. This is where MSDP comes in.

To configure MSDP within R1 and R3, we should configure 2 new loopbacks.

R1(config)#int loopback 1                                            
R1(config-if)#ip address 11.11.11.11 255.255.255.255            

R1(config)#ip msdp originator-id loopback 1                  
R1(config)#ip msdp peer 33.33.33.33 connect-source loopback 1

Doing the same thing in R3;

R3(config)#int loopback 1                                            
R3(config-if)#ip address 33.33.33.33 255.255.255.255            

R3(config)#ip msdp originator-id loopback 1                  
R3(config)#ip msdp peer 11.11.11.11 connect-source loopback 1

These loopbacks become the sources of information exchange, so they should be routed from each other.

Note:-
If the originator ID is not specified, it will choose the highest active IP address.

Now the pings start working..

 Now the routing tables should be filled with expected entries of normal PIM Sparse Mode..

To show an MSDP created entry, M flag will be visible on R3's entry.

This can be verified by the show ip msdp sa-cache command on R3,

To verify peer info show ip msdp peer can be used in any peer.

Bidirectional Multicast with PIM & Behavior of Routing Tables

Applications like Video Conferencing demands multicast traffic to be bidirectional. In this mode, there is no (S, G) entry created in routing table which means no Source Path Trees. Only the Shared Tree will be built which uses (*, G) entry. Also in this mode traffic will move up and down the Shared Tree..

Another difference is that this mode does not use PIM Register / PIM Register Stop Mechanism.
Any source can send the feed any time to the RP and if no listeners, traffic will be dropped by RP.

Also there is no RPF check. Loops will be prevented using the Designated Forwarder (DF) concept.
DF is the only router which is permitted to send traffic to RP from a segment.

DF Election

1. Router with the best route to RP
2. If the route is equivalent, router with the highest IP address will be chosen

I am configuring the above network to support Bidirectional PIM,
What is needed is to enable it globally in all routers and specify a RP. I am taking R2 as the RP.

R1(config)#ip pim bidir-enable
R1(config)#ip pim rp-address 2.2.2.2 bidir

R2(config)#ip pim bidir-enable
R2(config)#ip pim rp-address 2.2.2.2 bidir

R3(config)#ip pim bidir-enable
R3(config)#ip pim rp-address 2.2.2.2 bidir

R4(config)#ip pim bidir-enable
R4(config)#ip pim rp-address 2.2.2.2 bidir

Routing tables will show a new entry with the Auto-RP default entry slightly changed..

Looks like a new entry is created for (*, 224.0.0.0/4). All the PIM enabled interfaces are Accepting.
Bidir-Upstream is pointed to the RP connecting interface.

You can also see the default (*, 224.0.1.40) group has become bidirectional too.

Let's look at the RP's routing table.

R3's table will look like the following..

Let's join the both ends to a group and ping from both sides..

PC(config)#int e0/0
PC(config-if)#ip igmp join-group 239.1.1.1

IPTV_Svr(config)#int e0/0
IPTV_Svr(config-if)#ip igmp join-group 239.1.1.1

From both sides the replies are coming.. Routing tables have changed in the following way..

Source Specific Multicast (SSM) & IGMPv3

In SSM there are no Shared Trees, means there are no RPs (Rendezvous Points), so no need to worry about Auto-RP or BSR too. Only the Source Path Tree (SPT) is built and listeners should support IGMPv3.

I am going to enable SSM on above network with Sparse Mode.
All the interfaces are enabled with OSPF and ip pim sparse-mode command.

What is required is to configure SSM globally using the following command.

R1(config)#ip pim ssm default

R2(config)#ip pim ssm default

R3(config)#ip pim ssm default

R4(config)#ip pim ssm default

Routing table has no effect by this command.

Don't forget to configure your router interfaces connect to the listeners to IGMPv3 (E0/1 of R4).

R4(config)#int e0/1
R4(config-if)#ip igmp version 3

Last thing to do is to configure PC with IGMPv3 on interface level.
No need to configure the IPTV_Svr (source).

PC(config)#int e0/0
PC(config-if)#ip igmp version 3
PC(config-if)#ip igmp join-group 232.1.1.1 source 192.168.1.10

Finally the routing tables of the router R1, R3, R4 are like the following.. (R2 has no change in the routing table as it does not participate in forwarding due to SPT)

Note :- 
If the multicast group is not specified when enabling the SSM, default range of 232.0.0.0/8 will be applied. Other ranges will be denied.

Troubleshooting Multicast RPF Failure in Control Plane

I have looked into a RPF (Reverse Path Forwarding) issue in data plane here. In this post let's look into an issue where the control plane may have an impact of RPF. This is basically the RP (Rendezvous Point) is learnt from a different interface on unicast routing table while the multicast feed is coming from another interface. Of course this example is in PIM Sparse Mode and I am configuring the RP manually.

OSPF is configured for all links in routers but PIM is not enabled on E0/2 of R1 and R3.
RP is configured to be the R1.

Let's join PC to the group 239.1.1.1

PC(config)#int e0/0
PC(config-if)#ip igmp join-group 239.1.1.1

Looks like the feed does not get replies..
Let's look at the multicast routing table of R3;

Looks like RPF issue is there to the RP because RPF neighbor seems to be 0.0.0.0 and incoming interface as Null.

So the issue is clear now. Unicast routing table shows 1.1.1.1 can be reached via 192.168.13.1 (E0/2) but the multicast packets can traverse through E0/0 only.

To fix this with a multicast static route, let's find out what can be the interface,

It should be via 192.168.23.2 (E0/0) so the command should be;

R3(config)#ip mroute 1.1.1.1 255.255.255.255 192.168.23.2

The RPF issue is resolved.

As soon as I hit this command, feed got the replies..

Now what can be the routing table looks like?

Now there is a new entry for (192.168.1.10, 239.1.1.1) group which is the Source Path Tree (SPT). But looks like the traffic is not using it because the incoming interface is Null and RPF neighbor is 0.0.0.0 So the traffic is using the old entry which is (*, 239.1.1.1) which I guess is the Root Path Tree (RPT).

Why can it be like this?

Because surely there must be a RPF issue in Data Plane with the source 192.168.1.10

This can also be solved by entering another static mroute for 192.168.1.10

Troubleshooting Multicast RPF Failure in Data Plane

Loop prevention mechanism of multicast is to check the source IP with it's unicast routing table and do a RPF check (Reverse Path Forwarding). If the source is learned from the interface which the feed is received, the traffic is allowed to go through the router.

Let's take an example.

OSPF is configured for all links in routers but PIM is not enabled on E0/2 of R1 and R3.
What will happen is 192.168.1.0/24 will be learnt by R3 via OSPF from R1 but the multicast traffic will come from R2..

Let's join PC to the group 239.1.1.1

PC(config)#int e0/0
PC(config-if)#ip igmp join-group 239.1.1.1

Well the pings are failing..
Let's look at the multicast routing table,

It shows the incoming interface as Null and RPF neighbor as 0.0.0.0

Let's look at the unicast routing table for the 192.168.1.10 source.

Well there was a good debug command debug ip mpacket which should be used along with no ip mroute-cache interface level command to see rpf issues in multicast routing. Unfortunately Cisco has removed it from IOS version 15.0

But you can still check for RPF for the source using the following command.
R3#show ip rpf 192.168.1.10

Let's fix this issue by using a static mroute. First have to find the next-hop using following command.
R3#show ip pim neighbor

Now the command to route is;
R3(config)#ip mroute 192.168.1.10 255.255.255.255 192.168.23.2

As soon as the route entered, IPTV_Svr has replies,

Now let's see the routing tabe of R3;

PIM Sparse Mode, BSR (Bootstrap) Protocol & Configuration

PIM Sparse mode requires a Rendezvous Point (RP) to work. We have to manually configure one or many RPs. Then we can manually configure all the routers in the network to tell what is the RP or we can use 2 protocols to advertise the RP information.

1. Cisco Auto-RP
2. BSR (Bootstrap Router)

In this post I am going to explore BSR protocol. To get basic idea about PIM Sparse mode and Cisco Auto-RP please go though the following posts.

PIM Sparse Mode Operation & Behavior of Multicast Routing Table
PIM Sparse Mode, Cisco Auto-RP Protocol & Configuration

Let's take the following topology..

In BSR, there are 2 special router roles.

1. Candidate RP
2. Candidate BSR

Candidate RP of course is the Rendezvous Point, Candidate BSR is the router which collects information about the RPs and advertise it to other routers. So it is the most important router in the BSR enabled network much like the Mapping Agent of Cisco Auto-RP.

One big difference is that the Mapping Agent is prioritizing the RP for a group and advertise while BSR is advertising all learned RP info and individual router should select the best RP for a group.

Another thing is that packets from BSR which is received by a directly connected router is resent to all it's other interfaces back so that all the routers in the network gets the update. So no need of additional Dense mode / listener command like in Cisco Auto-RP.

Also the RPs do not advertise them selves until they get a packet from BSR. When they get a packet from a BSR, they send a unicast update to BSR about their RP info.

Assume all other PIM Sparse mode configuration (interface level) is already completed, and note that unlike the manual configuration, the loopback interface which is configured as the RP and BSR must be enabled with PIM Sparse mode too..

Let's configure R1 as the RP and R2 as the BSR.

R1(config)#ip pim rp-candidate loopback 0

Let's see the routing table now.

There is no change in it as expected..

Now let's configure the BSR..

R2(config)#ip pim bsr-candidate loopback 0

Let's see the routing table of R2 now,

Well there is nothing new here too.. Looks like it is just working at backend..

Note :-
When BSR is configured, it sends packets to 224.0.0.13 which is the All PIM enabled routers.
TTL is 1 for this packet but when one router receives it, it forwards it as a new packet to all it's neighbors.. This is not shown in the multicast routing table.

Even at R4, the show ip pim rp mapping and show ip pim bsr-router will show the same info as all other routers.

Note :-
If you extend the BSR command further you will see a value called hash mask.

This is used to load balance between several RPs. As an example if configured 31, two multicast groups will be assigned to one RP. If configured 30, 4 multicast groups will be assigned to one RP.

2 and 4 of above comes with 2^[32 - (value configured)]

Let's say there are 2 RPs.

If hash 31 is configured for all the multicast addresses,
224.0.0.1 will be served by first RP
224.0.0.2 will be served by first RP
224.0.0.3 will be served by second RP
224.0.0.4 will be served by second RP

If hash 30 is configured for all the multicast addresses,
224.0.0.1 will be served by first RP
224.0.0.2 will be served by first RP
224.0.0.3 will be served by first RP
224.0.0.4 will be served by first RP
224.0.0.5 will be served by second RP
224.0.0.6 will be served by second RP
224.0.0.7 will be served by second RP
224.0.0.8 will be served by second RP

Note :- 
RP selection by routers.

When the RP list is received by a router, following order will select the best RP for a group.

1. Longest match (ex:- RP for 224.0.0.0/30 is preferred over 224.0.0.0/4)
2. Lowest priority configured for RP
3. Highest hash value
4. Highest IP address

PIM Sparse Mode, Cisco Auto-RP Protocol & Configuration

PIM Sparse mode requires a Rendezvous Point (RP) to work. We have to manually configure one or many RPs. Then we can manually configure all the routers in the network to tell what is the RP or we can use 2 protocols to advertise the RP information.

1. Cisco Auto-RP
2. BSR (Bootstrap Router)

In this post I am going to explore Cisco Auto-RP protocol. To get basic idea about PIM Sparse mode please go though the following post.

PIM Sparse Mode Operation & Behavior of Multicast Routing Table

Let's take the following topology..

In Auto-RP, there are 2 special router roles.

1. RP
2. RP Mapping Agent

RP of course is the Rendezvous Point, Mapping Agent is the router which collects information about the RPs and make the primary RP to a specific group and advertise it to other routers. So it is the most important router in the Auto-RP enabled network.

Assume all other PIM Sparse mode configuration (interface level) is already completed, and note that unlike the manual configuration, the loopback interface which is configured as the RP and Mapping Agent must be enabled with PIM Sparse mode too..

Let's configure R1 as the RP and R2 as the RP Mapping Agent.

R1(config)#ip pim send-rp-announce loopback 0 scope 10

Scope 10 means the TTL of these packets are 10.

The above command makes the R1's loopback 0 address (1.1.1.1/32) the IP address of the RP..
As soon as it is configured, following will be the routing table of R1,

This 224.0.1.39 is the reserved IP for Cisco Auto-RP Rendezvous Point announcements.

R2(config)#ip pim send-rp-discovery loopback 0 scope 10

The above command makes the R2's loopback 0 address (2.2.2.2/32) the IP address of the Mapping Agent..

As soon as the above command is entered, the routing table of R2 will be like the following..

This means it has started listening to RP announcements. After a short while, the tunnel will be flapped and the routing table will be like the following..

Now it has these new entries. Because it is listening to 224.0.1.39, it has identified the 1.1.1.1 as the RP. Now the R1's routing table will be like the following..

It has also identified 2.2.2.2 as the RP Mapping Agent. All the routers are listening to this by default.
So R3 should learn this too ryt? Let's see..

It has learned about the RP Mapping Agent. Also as a result of being neighbor to a Mapping Agent, it has an entry listening to 224.0.1.39 which is RP announcements.

Let's see RP Mappings learned by R3;

Looks like it knows that 1.1.1.1 is the RP.

Let's see the routing table of R4;

Well, looks like R4 does not know anything about any of the above. This is because R4 is not directly connected to Mapping Agent and the RP Mapping packets are not forwarded by R3 because of the Sparse mode of operation. Sparse mode only forwards the traffic if it is requested by a downstream listener..

In order to solve this we either have to configure R3 in Sparse-Dense mode or we have to configure ip pim autorp listener command globally in R3. What this command does at back end is that it will flood 224.0.1.39 and 224.0.1.40 traffic in Dense mode.

R3(config)#ip pim autorp listener

 

Now the RP Mappings are learned, let's send some feed from IPTV_Svr and take a look at the routing table of R4..

 Now the feed from IPTV_Svr will get to the PC..