cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
554
Views
5
Helpful
3
Replies
tenbucker
Beginner

Multiple RPs defined for ovelapping ranges.

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?

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
tenbucker
Beginner

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

View solution in original post

3 REPLIES 3
Georg Pauwen
VIP Expert

Hello,

 

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

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
Beginner

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

View solution in original post