Multicast Anycast RP and MSDP

Anycast
- One to nearest routing.
- Multiple destinations share same address.
- Route to closest one based on routing protocol.
- Poor man’s load balancing and HA.

Anycast Operations:
- Mirrors application data to multiple devices in topology.
- Assign each device the same duplicate IP and advertise it
  - Same /32 Loopback into routing protocol.
- Use the routing table for load balancing and HA.
  - Routing to specific destination depends on where you are physically in the topology.
  - If anycast device fails, use routing convergence to find the next closest device.
Anycast RP
- Uses Anycast load balancing to decentralize placement of PIM Sparse Mode RPs.
  - PIM Register and Join messages go to closest RP in topology.
  - If one RP goes down, convergence is up to IGP.
  - As long as one anycast RP is up, new trees can be built.
  - RP failure does not necessarily impact current trees.
- Design Issues:
  - Requires all RPs to share information about senders and receivers.
    - MSDP helps with this.

Multicast Source Discovery Protocol (MSDP)
- Used to advertise (S,G) pairs between RPs.
  - Listen for PIM Registers regarding (S,G)
  - Tell other RPs about (S,G) through an MSDP Source Active (SA) message.
  - Essentially like an inter-RP PIM Register message.
- Allows PIM domains to use independent RPs
  - Originally designed for Inter-AS Multicast
  - CCIE Use Case is Anycast RP for Intra-AS Multicast.

Setup:
- Anycast RPs assign duplicate Loopback address and advertise into IGP.
- All routers point to anycast RP address.
  - Can be static or dynamic assignment.
- Anycast RPs are MSDP peers using a unique address.
  - Each device has a globally routable Loopback plus the Anycast Loopback.
  - If three or more RPs, usually a mesh group.
- When PIM Register is received, MSDP SA is sent to MSDP peers.
  - Results in sync of (S,G) information.
  - RP that knows about receiver can now join the (S,G) tree.
Caveats:
- Requires duplicate addresses
  - Ensure control plane protocols don’t use duplicate IP as identifier
    - ie. router-id
- Requires unique address to sync the application data
  - App is hosted on Anycast
  - App data sync between Anycast peers needs to be routable (unique).
    - Similar to VIP in HA pairs, etc.

Configuration:

The image above is the topology being worked on. Every router has ip multicast enabled, is running OSPF in area 0, and is advertising unique loopbacks/addresses into OSPF. There are no IGMP groups currently running, but PIM is enabled on each transit interface.

The two routers that will be performing Anycast and acting as Rendezvous Point (RP) are R6 and R4. On each router we’ll create Loopback interface 20 and give the interface an IP of 20.20.20.20. That interface will join the OSPF process with ‘ip ospf 1 area 0’

After advertising the loopbacks into OSPF, R1, the router in the middle, now has two destinations to 20.20.20.20/32. R6 and R4.

Next step is to have all the routers in the topology pointing to 20.20.20.20 for their PIM RP mapping. This command will be applied to all routers.

Now to verify the routers are using 20.20.20.20 as their RP, the command is run below.

Now we’ll add a group into the mix. On R8 we’ll do an IGMP join then take a look at the mroute tables.

On R4 everything is behaving normally. The RP found the listener and is waiting for a sender to complete the SPT. On R6 however, the group is not found because the two RPs are not syncing data with each other.

If I go over to R9 on the other side of the topology and ping 127.0.0.1, the two RP mroutes for this group will appear like below:

R6 shows it created the full tree, but it has an outgoing interface of Null. This is because it has no idea about where the listener/receiver is located.

R4 shows it only has the listener/receiver location and no idea where the source would be.

Below are the commands to enable MSDP.

On R6 we’re peering with R4 at 4.4.4.1, and on R4 we’re peering with R6 at 6.6.6.1. Note the peering needs to happen on unique addresses, cannot use the Anycast address.

After the commands are entered we get a session up message in the terminal. Now when pinging from R9 to 227.0.0.1 I’m getting responses and the mroute tables look like this on the two RPs: