Multicast issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Multicast issue

L4 Transporter

multicast.pngAE1.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

1 accepted solution

Accepted Solutions

L4 Transporter

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.

View solution in original post

1 REPLY 1

L4 Transporter

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.

  • 1 accepted solution
  • 2703 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!