• Recommended Configurations for Multicast Using Anycast-RP

 
 
Print Friendly, PDF & Email

Overview

Multicast is a means of sending data from one source to many receivers.  To understand what one to many looks like no further than a TV streaming service and or a paging system which calls only certain phones.  Unlike broadcast which multicast may act like depending on the design, typically multicast packets are not meant for the whole network but to a set of end points for a specific group.  Sending to a group is achieved by sending data to a multicast IP whose range is from 224.0.0.1 to 239.255.255.255.  

For data to flow from its publisher or source, that data must be sent to a specific multicast group address.  In addition, a request for that traffic must be sent from one or more end users known as receivers or subscribers.  At this point it is also important to understand that at a minimum 3 critical IPs must be identified in testing out the new multicast build or in working an issue with an existing but now broken multicast network:  Source IP; at least 1 Receiver IP; Multicast Group IP.

Most networks require multicast traffic to cross VLAN domains.  PIM or Protocol Independent Multicast was developed for inter-VLAN traffic.  In a PIM sparse-mode model, a point must exist where the multicast data stream and a request for the stream meet.  That point where they rendezvous is known as the Rendezvous Point or RP.  The RP is the shared common point in the network to link receivers with the data being sent from the sources. There are multiple design models for RP configuration.  This article focuses on Anycast-RP which allows for multiple devices to share a common RP address as a collective RP for a PIM domain.

While this article covers configuring Anycast-RP, it does not cover the use of Anycast-RP with MSDP as that is not supported by Arista.

Use Cases

In the campus example, you may use a single or any pair of core multilayer switches can be used as RP for redundancy at that location.  Also, having RPs at each site will do the local work as RP for that location and thus distributing the workload.  

Some engineers may prefer to have their RPs closer to their DataCenters.  As in the example below, Corporation XYZ has two data centers that service different regions and constantly back each other up.  The advantage to this design is an administrative advantage in that there are fewer RPs to configure and manage.

RFC 4610 states:

Anycast-RP as described in [I1] is a mechanism that ISP-based backbones have used to get fast convergence when a PIM Rendezvous  Point (RP) router fails. 
To allow receivers and sources to Rendezvous to the closest RP, the packets from a source need to get to all RPs to find joined receivers.”

A couple of conditions must be met for Anycast-RP to work.

PIM-Sparse must exist at the proper places.

      1. On each L3 interface between each Receiver and RPs, 
      2. Each L3 interface between the RP and Source/s,
      3. Last on each L3 interface between each intended receiver and the Source/s

Identify the L3 nodes will be used to provide RP services to be configured as AnycastRPs.  Best practices are to have either the Spine or Core devices as RP as they have the most central access to all devices.

      1. The following are guidelines taken from RFC4610 for configuring the RPs
        1. Statically assign an IP to be used as the RP address on each node providing RP services
        2. A routable loopback must be used as the Anycast source interface to communicate between each RP node

Once this is done, the DR will send the multicast source register messages up to the closest RP based upon the best path selected by the unicast routing table.  The local RP is responsible for updating the other RPs by forwarding copies of the register messages.  

      1. This is needed to create a state on all participating RPs
      2. At that instance, we do not know to which RP the receiver’s (*,G) will hash
      3. Ensures all RPs are aware of the source in the event one RP fails an active RP may now provide services

 

Per RFC 4610, the use of a loopback address is mandatory.  The use of any other L3 interface is not supported.

Core-SwithA#

!
router pim sparse-mode
   ip pim rp-address 10.255.245.10
   !
   ipv4
      anycast-rp 10.255.245.10 1.1.1.1
      anycast-rp 10.255.245.10 1.1.1.2

sh run int lo0
interface Loopback0
   ip address 1.1.1.1/32

sh run int l99
interface Loopback99
   ip address 10.255.245.10/32
 

Core-SwitchB#
router pim sparse-mode
   ip pim rp-address 10.255.245.10
   !
   ipv4
      anycast-rp 10.255.245.10 1.1.1.1
      anycast-rp 10.255.245.10 1.1.1.2

sh run int lo0
interface Loopback0
   ip address 1.1.1.2/32

sh run int l99
interface Loopback99
   ip address 10.255.245.10/32

Troubleshooting Steps

1.Determine the source, receiver and group that you are debugging.  Locate the First Hop Router (Source DR) and the RPs involved in Anycast-RP.

2. Take a look at the Anycast-RP state.  If you do not have state, confirm your configurations

#sh ip pim anycast-rp
Anycast Rp address is 10.255.245.10
Anycast Peers address is 1.1.1.1
Anycast Peers address is 1.1.1.2
 

3.To confirm your configurations use  show run section pim  and show ip interfaces brief to check for typos in the ip addresses or any missing configurations.

4. Use #show ip pim interface to confirm that the correct interfaces have pim configured on them and neighbor correctly with the next hop.  

sh ip pim interface

Address   Interface  Mode    Neighbor  Hello  DR   DR Address  PktsQed  PktsDropped
                             Count     Intvl  Pri

10.0.0.5  Ethernet1  sparse  1         30     1    10.0.0.5    0        0
72.3.3.0  Ethernet3  sparse  0         30     1    72.3.3.0    0        0
10.0.0.1  Ethernet4  sparse  1         30     1    10.0.0.1    0        0
10.0.0.3  Ethernet5  sparse  1         30     1    10.0.0.3    0        0

5. Use show ip mroute to see if you are getting a join request on that device (*,G) and if you are, if you are getting a source IP (S,G).  Determine which RP is the source registration being hashed to and which one the interested *,G is being hashed to. 

#sh ip mroute

PIM Bidirectional Mode Multicast Routing Table
RPF route: U - From unicast routing table
           M - From multicast routing table
PIM Sparse Mode Multicast Routing Table
Flags: E - Entry forwarding on the RPT, J - Joining to the SPT
    R - RPT bit is set, S - SPT bit is set, L - Source is attached
    W - Wildcard entry, X - External component interest
    I - SG Include Join alert rcvd, P - (*,G) Programmed in hardware
    H - Joining SPT due to policy, D - Joining SPT due to protocol
    Z - Entry marked for deletion, C - Learned from a DR via a register
    A - Learned via Anycast RP Router, M - Learned via MSDP
    N - May notify MSDP, K - Keepalive timer not running
    T - Switching Incoming Interface, B - Learned via Border Router
RPF route: U - From unicast routing table
           M - From multicast routing table

239.30.30.30
  192.168.13.2, 0:04:13, flags: SL
    Incoming interface: Vlan13
    RPF route: [U] 192.168.13.0/24 [0/1] via 192.168.13.2

6. Use sh ip pim rp-hash (group IP) to see if the group is hashing properly:

#sh ip pim rp-hash 239.30.30.30 RP 1.1.1.1   
PIM v2 Hash Values:   
RP: 1.1.1.1     
Uptime: 16:11:31, Expires: never, Priority: 0, HashMaskLen: 30, HashMaskValue: 1848010381, Override: False Hash Algorithm: Default

7. If anycast RP source registration sync is suspected, use tcpdump on the egress interface to the peer IP to determine if the RP which received the native source registration is sending a copy of the registration to other RPs.

If the issue is still seen, collect the below outputs and reach out to Arista TAC support by sending an email at support@arista.com

CLI commands:

​SW# show tech-support all | gzip > /mnt/flash/show-tech-$HOSTNAME-$(date +%m_%d.%H%M).log.gz 
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: