Multiple RPs defined for ovelapping ranges.

[tenbucker]

Afternoon all!

I'm trying to work through some issues that I've been experiencing with multicast, and I suppose it's sparked my curiosity.

The setup I have is about 5 RPs. The 5th one being 225.0.0.0/8, and effectively covers the other ranges.

One router in my topology is showing an RP for a particular mroute, whilst the device which the RP sits on shows a different RP for the same mroute. Both devices have the same RP/Group config.

Can anyone explain how an RP is picked if there are multiple that fit the group? I assumed it would be prefix length for the group, but that isn't the case in the aforementioned issue.

One point of note - one of the devices is NX-OS and the other is XE.

Any thought?

[Georg Pauwen]

Hello,

post a topology map, as well as the configs of the devices involved...

[tenbucker]

Hi Georg,

Thanks for responding. I've attached the four devices involved in the Multicast. Below is output which shows the problem I previously described:

NXOS01# show ip mroute vrf IPN | BEG 225.0.137.16

(*, 225.0.137.16/32), bidir, uptime: 6w0d, igmp ip pim
Incoming interface: loopback1, RPF nbr: 192.168.0.194
Outgoing interface list: (count: 2)
loopback1, uptime: 1d04h, pim, (RPF)
Ethernet1/2.4, uptime: 6w0d, igmp

NXOS01# SHOW IP PIM Neighbor Vrf IPN
PIM Neighbor Status for VRF "IPN"
Neighbor Interface Uptime Expires DR Bidir- BFD
Priority Capable State
192.168.0.25 Ethernet1/3 7w1d 00:01:44 1 yes n/a
192.168.0.17 port-channel112 1y3w 00:01:43 1 yes n/a

ASR-02#show ip mroute vrf IPN 225.0.137.16

(*, 225.0.137.16), 1d02h/00:03:11, RP 192.168.0.226, flags: B
Bidir-Upstream: TenGigabitEthernet0/0/0, RPF nbr 192.168.0.24
Outgoing interface list:
Tunnel0, Forward/Sparse, 1d02h/00:03:11
TenGigabitEthernet0/0/0, Bidir-Upstream/Sparse, 1d02h/stopped

ASR-02#show ip pim vrf IPN NEighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
192.168.0.21 Tunnel0 6w2d/00:01:22 v2 1 / B S P G
192.168.0.24 TenGigabitEthernet0/0/0 7w1d/00:01:42 v2 1 / B G

NXOS02# SHOW IP MROute VRF IPN | BEG 225.0.137.16
NXOS02# show ip pim neighbor vrf IPN
PIM Neighbor Status for VRF "IPN"
Neighbor Interface Uptime Expires DR Bidir- BFD
Priority Capable State
192.168.0.27 Ethernet1/3 13w6d 00:01:39 1 yes n/a
192.168.0.16 port-channel112 1y3w 00:01:32 1 yes n/a

I'm starting to think it may be the fact that the SPT goes through a device with the 'secondary RP' on it's path to the preferred?

Ben

[tenbucker · Accepted solution]

Thankfully I was able to find a resolution to this issue.

NX-OS static RP config-

ip pim rp-address 192.168.0.130 group-list 225.1.128.0/17 bidir
ip pim rp-address 192.168.0.162 group-list 225.1.0.0/17 bidir
ip pim rp-address 192.168.0.194 group-list 225.0.128.0/17 bidir
ip pim rp-address 192.168.0.226 group-list 225.0.0.0/15 bidir
ip pim rp-address 192.168.0.226 group-list 239.255.255.240/28 bidir
ip pim ssm range 232.0.0.0/8

ASR Static RP config-

ip pim vrf IPN rp-address 192.168.0.130 IPN-MULTICAST-GROUP-1 bidir
ip pim vrf IPN rp-address 192.168.0.162 IPN-MULTICAST-GROUP-2 bidir
ip pim vrf IPN rp-address 192.168.0.194 IPN-MULTICAST-GROUP-3 bidir
ip pim vrf IPN rp-address 192.168.0.226 IPN-MULTICAST-GROUP-4 bidir
ip pim vrf IPN ssm default
!
ip bgp-community new-format
ip scp server enable
!
!
ip access-list standard IPN-MULTICAST-GROUP-1
permit 225.1.128.0 0.0.127.255
ip access-list standard IPN-MULTICAST-GROUP-2
permit 225.1.0.0 0.0.127.255
ip access-list standard IPN-MULTICAST-GROUP-3
permit 225.0.128.0 0.0.127.255
ip access-list standard IPN-MULTICAST-GROUP-4
permit 239.255.255.240 0.0.0.15
permit 225.0.0.0 0.1.255.255

So, it looks like the ASR was evaluating the ACLs in a manner I didn't expect. I'm guessing XE must pick the RP with the highest IP if the mcast groups fits multiple statements. Whereas, NX might be doing according to order of statement. I might be wrong, I havent confirmed.

To resolve this issue I configured a deny statment on IPN-MULTICAST-GROUP-4 which matched the mcast routes which were intended to go to 192.168.0.194, but were defaulting to 192.168.0.226