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 184.108.40.206 to 220.127.116.11.
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.
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.
- On each L3 interface between each Receiver and RPs,
- Each L3 interface between the RP and Source/s,
- 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.
- The following are guidelines taken from RFC4610 for configuring the RPs
- Statically assign an IP to be used as the RP address on each node providing RP services
- A routable loopback must be used as the Anycast source interface to communicate between each RP node
- The following are guidelines taken from RFC4610 for configuring the RPs
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.
- This is needed to create a state on all participating RPs
- At that instance, we do not know to which RP the receiver’s (*,G) will hash
- 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 18.104.22.168 anycast-rp 10.255.245.10 22.214.171.124 sh run int lo0 interface Loopback0 ip address 126.96.36.199/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 188.8.131.52 anycast-rp 10.255.245.10 184.108.40.206 sh run int lo0 interface Loopback0 ip address 220.127.116.11/32 sh run int l99 interface Loopback99 ip address 10.255.245.10/32
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 18.104.22.168 Anycast Peers address is 22.214.171.124
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 126.96.36.199 Ethernet3 sparse 0 30 1 188.8.131.52 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 184.108.40.206 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 220.127.116.11 RP 18.104.22.168 PIM v2 Hash Values: RP: 22.214.171.124 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 firstname.lastname@example.org
SW# show tech-support all | gzip > /mnt/flash/show-tech-$HOSTNAME-$(date +%m_%d.%H%M).log.gz