PIM BiDir Phantom RP Load Sharing¶
In this post, I am going to build on the post for Using PIM BiDir Phantom RP in a VXLAN Fabric. In this post, we will add another RP but this time make spine-2 primary in order to bring in some load sharing, albeit manual.
As this post builds on the previous one, its assumed that you have that configuration in place and working.
Lets add a 2nd RP to the topology.
Multicast Configuration¶
In this example, we will make spine-2 the primary RP for this mcast group.
The configuration on spine-1 should be:
ip pim rp-address 10.99.99.74 group-list 237.0.0.0/24 bidir
interface loopback2
ip address 10.99.99.73/28
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
ip pim sparse-mode
The configuration on spine-2 should be:
ip pim rp-address 10.99.99.74 group-list 237.0.0.0/24 bidir
interface loopback2
ip address 10.99.99.73/29
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
ip pim sparse-mode
Now the mask is smaller on spine-2. We also have to use a different group subnet too, so we can pick which RP we use. If we do a route lookup for the RP address on a leaf, we can see which its going to use:
leaf-1# show ip route 10.99.99.74
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.99.99.72/29, ubest/mbest: 1/0
*via 10.0.0.2, Eth1/2, [110/41], 02:38:52, ospf-UNDERLAY, intra
This is going via spine-2 as we expect. However, if we dig deeper into the route table, we should see the other route via spine-1
leaf-1# show ip route | inc 10.99.99.72|10.99.99.64 next 1
10.99.99.64/28, ubest/mbest: 1/0
*via 10.0.0.1, Eth1/1, [110/41], 02:40:40, ospf-UNDERLAY, intra
10.99.99.72/29, ubest/mbest: 1/0
*via 10.0.0.2, Eth1/2, [110/41], 02:40:21, ospf-UNDERLAY, intra
Again, longest match routing occurs and we pick the path via spine-2.
We still have to add the new RP to the leaf switches:
ip pim rp-address 10.99.99.74 group-list 237.0.0.0/24 bidir
Now if we add or change a VNI to have a mcast-group address in 237.0.0.0/24, that VTEP will join this new RP and therefore we begin to load balance traffic between RPs.
We can validate the Multicast setup with the following command on the spines:
spine-1# show ip pim rp
PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP disabled
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None
RP: 10.99.99.74, (2),
uptime: 02:42:45 priority: 255,
RP-source: (local),
group ranges:
237.0.0.0/24 (bidir)
RP: 10.99.99.100, (1),
uptime: 03:14:15 priority: 255,
RP-source: (local),
group ranges:
238.0.0.0/24 (bidir)
We see both RPs now. This is the same output on both Spines.
Switching a VNI to an IP in the new mcast group we can do some verification.
If we check the multicast routing table on leaf-1 we should see an entry for 237.0.0.20/32:
leaf-1# show ip mroute 237.0.0.20
IP Multicast Routing Table for VRF "default"
(*, 237.0.0.20/32), bidir, uptime: 01:33:37, nve ip pim
Incoming interface: Ethernet1/2, RPF nbr: 10.0.0.2
Outgoing interface list: (count: 2)
Ethernet1/2, uptime: 01:33:37, pim, (RPF)
nve1, uptime: 01:33:37, nve
The above output from the leaf shows its joined the new mcast group and it shows the interface in which it needs to use to get there and forward traffic towards. In this case using Ethernet1/2 via spine-2.
If we do that same command on spine-2 we should see a similar output:
spine-2# show ip mroute 237.0.0.20
IP Multicast Routing Table for VRF "default"
(*, 237.0.0.20/32), bidir, uptime: 02:43:55, pim ip
Incoming interface: loopback2, RPF nbr: 10.99.99.74
Outgoing interface list: (count: 4)
Ethernet1/1, uptime: 01:34:36, pim
Ethernet1/3, uptime: 02:43:48, pim
loopback2, uptime: 02:43:55, pim, (RPF)
Ethernet1/2, uptime: 02:43:55, pim
This output has some more outgoing interfaces because other VTEPs have also joined the group. So this spine knows how to forward the traffic if it received a packet destined for the group IP.
So now we have two RPs and two multicast groups that we can pick from when creating VNIs, we can see them both on a leaf:
leaf-1# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 232.0.0.0/8), uptime: 03:29:43, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
(*, 237.0.0.0/24), bidir, uptime: 02:46:33, pim ip
Incoming interface: Ethernet1/2, RPF nbr: 10.0.0.2
Outgoing interface list: (count: 1)
Ethernet1/2, uptime: 02:46:33, pim, (RPF)
(*, 237.0.0.20/32), bidir, uptime: 01:35:56, nve ip pim
Incoming interface: Ethernet1/2, RPF nbr: 10.0.0.2
Outgoing interface list: (count: 2)
Ethernet1/2, uptime: 01:35:56, pim, (RPF)
nve1, uptime: 01:35:56, nve
(*, 238.0.0.0/24), bidir, uptime: 03:33:53, pim ip
Incoming interface: Ethernet1/1, RPF nbr: 10.0.0.1
Outgoing interface list: (count: 1)
Ethernet1/1, uptime: 03:16:19, pim, (RPF)
(*, 238.0.0.10/32), bidir, uptime: 03:32:43, ip pim nve
Incoming interface: Ethernet1/1, RPF nbr: 10.0.0.1
Outgoing interface list: (count: 2)
nve1, uptime: 01:35:56, nve
Ethernet1/1, uptime: 03:16:19, pim, (RPF)
And thats it! We now have a way of load balancing BUM traffic between RPs where ordinarily it wasn't possible in the same way as Anycast RP.