L3 Mutlicast - need some help

[mendicus]

Hi there!

I need some help on the setup, although I have got it nearly configured and working - well for most parts.

Here a brief overview of the network:

My goal:

Multicast from Source A & B gets routed into VL200
Mutlicast from Source D & E gets routed into VL200

Mutlicast from Source B & C gets routed into vl 96


I want to use pim sparse dense mode for this with Auto-RP configuration.

For Source E & D there is already an rp address configured in vl 13: 172.19.20.4
SVI 13 on Router A is sparse-dense mode.

For Source A & B I am using sparse-dense mode on the SVIs 27 & 196

Router A:

interface VL13
ip address 172.19.20.11 255.255.255.0
ip pim sparse-dense mode

interface vl200
ip address 172.20.11.11 255.255.255.0
ip pim sparse-dense mode

ip pim rp-address 172.19.20.4 13
no ip pim dm-fallback
ip pim send-rp-announce VL200 scope 5 group-list 12
ip pim send-rp-discovery Vlan200 scope 5

access-list 13 permit 239.198.19.0 0.0.0.255
access-list 13 permit 239.198.17.0 0.0.0.255

access-list 12 permit 239.70.230.0 0.0.0.255
access-list 12 permit 239.90.59.0 0.0.0.255

I did not setup any ip multicast-routing distributed on any of the
L2 switches involved and just rely on IGMP snooping.

Connecting now from VL200 should allow me to receive MC for desired groups.

Now I want that MC Source from B and C get routed into VL96

interface VL96
ip address 10.91.59.4 255.255.255.0
ip pim sparse-dense mode

interface vl196
ip address 10.90.59.4 255.255.255.0
ip pim sparse-dense mode

I need to send additional RP for this two MC groups on SVI 96
How can I make this possible without interferring with the other MC groups, as there is already an access-list with those groups configured? It will override the RP then -> highest IP wins.

I also now about the loopback interfaces, which should send  rp announce and discovery packets. But also here, I would

override the RP if I want to send MC Source from B&C via different RP.

I was able though to accomplish this with dense mode - but don't really want to run this mode.

I hope this is understandable.
Please let me know, if you need any more information.
Many thanks in advance for looking into this

[Georg Pauwen]

Hello,

my first thought would be that you can configure a priority for the RP, but not with auto RP. You would needs BSR and rp-candidates for which you could then assign priorities...

[mendicus]

Thanks Georg for getting involved.

I am not too familiar with BSR and was thinking to switch to sparse-mode with static RPs, as my network is quite manageable and it shouldn't be a big deal to configure this on the router.

I also would like to explain my problem maybe a little bit more:

The Receiver in VL96 is a customer sitting behind its own firewall and router. I am providing the IP Addresses scope for them inside that VL, so I want to make sure, that they can make hold of an RP inside VL96 in order to join the two MC groups.

So if I provide an RP for group 239.91.59.0/24 for VL200 receivers, which would be in my case currently 172.20.11.11, the receiver in VL96 cannot join this group, because of RPF failures.

One idea I had was to make hold of the "ip pim neighbor-filter x" feature.

How about setting up "multicast routing distributed" on the last hop switch and to assign "access-list x deny 172.20.11.11"

Then I could provide for VL96 new static RP with IP 10.91.59.4 which would be reachable via L2 unicast for customers in this VL.

Would  this work? Or have you got a different idea on this?

Many thanks once again!

[paul driver]

Hello

---

@mendicus wrote:

Thanks Georg for getting involved.

I am not too familiar with BSR and was thinking to switch to sparse-mode with static RPs, as my network is quite manageable and it shouldn't be a big deal to configure this on the router.

I also would like to explain my problem maybe a little bit more:

The Receiver in VL96 is a customer sitting behind its own firewall and router. I am providing the IP Addresses scope for them inside that VL, so I want to make sure, that they can make hold of an RP inside VL96 in order to join the two MC groups.

So if I provide an RP for group 239.91.59.0/24 for VL200 receivers, which would be in my case currently 172.20.11.11, the receiver in VL96 cannot join this group, because of RPF failures.

---

Apologies first as I am not able read your entire OP from  my phone however i see you mention RPF -So if you are getting rpf have you tried adding a static mroute to direct you mc traffic the correct way!

[mendicus]

Hi Paul,

yes and no. Providing an mroute for the receivers in VL96 could do it.

I suppose it would look like this ?

ip mroute 172.20.11.11 255.255.255.255 10.91.95.4

Both networks would be directly connected on the RouterA. So no OSPF etc needed.

But would it be also possible to provide the group transparent to the customer, like with my idea of an rp filter?

Cheers!

[mendicus]

If have played around in a lab with the rp-filter and gave up on it.

But I have got this working now with sparse mode.

Maybe some additional unicast tcp information for this scenario:

Source IP for Multicast Group 239.91.59.0/24 is: 10.90.54.100

Source IP for Multicast Group 239.90.59.0 is: 10.90.54.200

The client I used to verify that the multicast is properly working, has IP: 10.91.59.110 and was sitting behind last hop switch.    I added static route on the client for destination net 10.90.54.0 /24 10.91.59.4 (which is VL96 interface on RouterA)

Source of both multicast feeds (.100 and .200) also got static route entry for net:10.91.59.0

When checking mroute on RouterA, I can see that muclticast for both groups is properly rooted into this VL from input interface VL196 and is going out now on vl 200 and vl 96 on RouterA.

The two switches in between are just igmp snooping these groups.

My concern is now, that the receiver inside VL96 will need an RP for the groups, as I already mentioned, the customer is sitting behind a firewall and is running his own piece of kit incl. routers.

If I do need to provide an RP for them in VL96, which is once again Net:10.91.59.0/24, how would they be able to get to RP in VL200 on 172.20.11.11 which is the RP for this groups?

[mendicus]

If have played around in a lab with the rp-filter and gave up on it.

But I have got this working now with sparse mode.

Maybe some additional unicast tcp information for this scenario:

Source IP for Multicast Group 239.91.59.0/24 is: 10.90.54.100

Source IP for Multicast Group 239.90.59.0 is: 10.90.54.200

The client I used to verify that the multicast is properly working, has IP: 10.91.59.110. I added static route on the client for destination net 10.90.54.0 /24 10.91.59.4 (which is VL96 interface on RouterA)

Source of both multicast feeds (.100 and .200) also got static route entry for net:10.91.59.0

When checking mroute on RouterA, I can see that muclticast for both groups is properly rooted into this VL from input interface VL196 and is going out now on vl 200 and vl 96 on RouterA.

The two switches in between are just igmp snooping these groups.

My concern is now, that the receiver inside VL96 will need an RP for the groups, as I already mentioned, the customer is sitting behind a firewall and is running his own piece of kit incl. routers.

If I do need to provide an RP for them in VL96, which is once again Net:10.91.59.0/24, how would they be able to get to RP in VL200 on 172.20.11.11 which is the RP for this groups?

[paul driver]

Hello

You could also specify what vlans are able to receive the mc groups you wish via an igmp group list.

ip access-list standard vl113
permit 239.198.17.0 0.0.0.255
permit 239.198.19.0 0.0.0.255

int vlan 113
ip igmp access-group v113


ip access-list standard vl196
permit 239.91.59.0 0.0.0.255

int vlan 196
ip igmp access-group v196


ip access-list standard vl200
permit 239.70.230.0 0.0.0.255
permit 239.198.17.0 0.0.0.255
permit 239.198.19.0 0.0.0.255
permit 239.90.59.0 0.0.0.255

int vlan 200
ip igmp access-group v1200

ip access-list standard vl27
permit 239.70.230.0 0.0.0.255

int vlan 27
ip igmp access-group vl27



ip access-list standard vl96
permit 239.90.59.0 0.0.0.255
permit 239.198.19.0 0.0.0.255

int vlan 96
ip igmp access-group vl96