- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
07-23-2021 09:36 AM - edited 07-23-2021 04:01 PM
AE1.1 is the static RP(10.1.1.1/24) and ae1.1 has 10.1.1.1/24 assigned to it. All the 10.0.0.0/8 routes are served by this sub interface and RP configured on switch is 10.1.1.1
AE1.2 hosts the mcast server and AE1.2 has gateway of 172.16.0.1/24.
Multicast clients in 10.5.0.0/24 are able to join MCAST streamed on 172.16.0.20
AE1.3 connects to a separate switch vrf routing table and RP configured on switch for this vrf is 10.1.1.1. AE1.3 has 192.168.0.1/24 and server 192.168.0.0/16. This switch vrf does not see the mcast group served by 172.16.0.20 although it is a PIM neighbor in PA. None of the clients then cannot get access to stream hosted on 172.16.0.20
If i add multiple remote RP's instead only 1 gets chosen. Since IGMP messages are sent to only 1 RP this is out of question.
Zones for which firewall is directly itself is the gateway multicast works. There are other interfaces AE1.4,5,6 and multicast works in all of them.
But the real problem is clients are not able to join from zones for which switch has to join PA-RP from another zone, although PA shows them as neighbors. And I don't see this as a limitation of VRF's on cisco switch as both vrf's become PIM neighbor on their respective interfaces towards PA. Cisco switch in the xyz VRF does not receive information from PA about available sources. Although is see in the xyz vrf clients wanting to joint the group which works well in ABC vrf.
I don't know if this can be solved by multiple virtual routers and if that is even supported, and i even tried to test this but was not successful.
PA
------------------------------
interface address secondary address up time expiry time generation id dr priority
--------- ------- ----------------- ------- ----------- ------------- -----------
ae2.56 10.1.1.20 0.0.0.0 5827.95 90.49 3611216514 1
ae2.6 192.168.1.4 0.0.0.0 5800.72 91.54 2738550118 1
(*, G):
group RP up time upstream join st upstream join timer RPF interface RPF next hop
----- -- ------- ---------------- ------------------- ------------- ------------
239.255.100.101 10.1.1.1 4792.17 Joined 0.00 0 0.0.0.0
===============================
VRF ABC
--------------------
(*, 239.255.100.101), 1d02h/00:02:35, RP 10.1.1.1, flags: S
Incoming interface: Vlan6, RPF nbr 10.1.6.10
Outgoing interface list:
Vlan607, Forward/Sparse, 01:18:00/00:02:35
(172.16.0.20, 239.255.100.101), 00:02:19/00:00:40, flags: T
Incoming interface: Vlan6, RPF nbr 10.1.1.1
Outgoing interface list:
Vlan607, Forward/Sparse, 00:02:19/00:03:08
VRF XYZ
---------------------
(*, 239.255.255.250), 00:01:38/00:02:51, RP 10.1.1.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan256, Forward/Sparse, 00:01:38/00:02:51
07-27-2021 12:33 AM
This was resolved after moving the RP from AE1.1 to AE1.2. Not sue if this is some protocol limitation or firewall/switch issue. In the working solution here all vrf instances on directly connected switch are equal(2 hops) away from RP interface, while they were not when AE1.1 was the RP.
07-27-2021 12:33 AM
This was resolved after moving the RP from AE1.1 to AE1.2. Not sue if this is some protocol limitation or firewall/switch issue. In the working solution here all vrf instances on directly connected switch are equal(2 hops) away from RP interface, while they were not when AE1.1 was the RP.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!