Catalyst 3650: Multicast issues with Private VLANs

[newparadime]

I have the following configuration on a Catalyst 3650 smart switch:

Primary VLAN 101

Community Secondary VLANs 201, 202, 203, 204

VTP mode transparent

IGMP snooping globally off (although I have tried globally enabling snooping as well as enabling on each secondary VLAN).

Assets can all send/receive pings and regular unicast traffic as expected.

Assets within a community secondary VLAN can send/receive to/from each other, and promiscuous ports. 

Assets connected to a promiscuous port can send/receive to/from any asset within the primary VLAN.

Multicast traffic is a different story however:

Assets connected to secondary VLAN 204 can SEND and RECEIVE multicast between themselves

Assets connected to secondary VLANs 201,202 and 203 cannot send/receive multicast between themselves at all

Assets connected to all secondary VLANs can RECEIVE multicast from promiscuous ports, but cannot SEND multicast to promiscuous ports.

Assets connected to promiscuous ports can SEND and RECEIVE multicast between each other.

I really need to get this working. It may be worth noting, that secondary VLAN 204 (the functional secondary VLAN with respect to multicast functioning) was the first secondary VLAN configured.

[chrihussey]

Hello, 

For starters I would have IGMP snooping enabled for the primary VLAN and don't think it should be necessary for the secondaries. If the L3 interface for the primary VLAN is multicast enabled then the switch should show it.

A question I have is are the multicast addresses identical for the secondary VLANs? If so, perhaps mixing PVLANs and identical multicast addresses may cause this issue and if so can you adjust one to see if it works?

[newparadime]

I have tried all sorts of different multicast addresses, all work on PVLAN 204, none work on the other PVLANs.

When you say "If the L3 interface for the primary VLAN is multicast enabled", how would I verify that? 

I will admit I am in slightly over my head here. I understand that layer 3 is IP routable, and layer 2 is MAC routable only, but I am having trouble understanding specifically what a 'layer 3 interface' is in this context. Is that just the switch port? Is it the primary VLAN as a whole?

In the meantime, I am going to update to the latest firmware, and reconfigure a fresh switch (we have a few).

[chrihussey · Accepted solution]

The primary VLAN should have a L3 interface with an IP address to route traffic to and from the private VLAN. This would be either a router connected to a promiscuous port or VLAN interface. If this L3 interface is multicast enabled it would have "ip pim sparse / dense mode" configured for it to route multicast from different networks to and from this VLAN. If that's the case, on the switch with IGMP snooping enabled, if you do "sh ip igmp snooping querier" it should show the IP address of the L3 interface for that VLAN. Generally, if you see this no other config is necessary and IGMP should be operational.

If you are not routing multicast as described, just let me know and we can address the IGMP snooping by perhaps making the switch an IGMP querier which may help your situation. 

[newparadime]

I should provide more information about our network topology

This is for an airgapped network, and there is no routing outside the single subnet (13.0.0.0/12) configured for the primary VLAN.

We have 4 benches simulating various aircraft. We have simulation hardware that needs to be able to talk to assets on all of the benches / secondary VLANs, but the benches need to remain isolated from one another.

All multicast traffic is originating from 13.0.0.0/12 and also destined to 13.0.0.0/12. Due to the fact that this network is simulating an RF network which treats multicast as broadcast (i.e. no IGMP snooping), I would be satisfied with flooding multicast to all switch ports (IGMP snooping disabled), but even that doesn't work.

In the meantime, I will ensure that I have a layer 3 interface setup for the primary VLAN, and see if it resolves my issues. I will also re-enable IGMP snooping globally, and for primary VLAN only.

[chrihussey]

Knowing this it does make sense that trying to flood multicast to all ports and implementing private vlans you are getting these results. You're trying to implement two things that are in opposition with each other. Look forward to your next post.

[newparadime]

I am not opposed to IGMP snooping if it will make this work, I just figured disabling it was a simpler configuration. 
Cisco indicates from their docs, that multicast should be propogated to all ports in a community private vlan, and additionally to promiscuous ports. Multicast to/from isolated VLAN ports is only delivered to/from promiscuous ports.

Shouldn't flooding still work in that regard?
I.e. With IGMP snooping disabled, if I send a multicast packet from a community PVLAN port, I would expect it to be flooded to all other ports in the same secondary community VLAN, and to all promiscuous ports.

[newparadime]

I added an SVI on Primary VLAN 101, and then turned on sparse-dense pim for that SVI, and bingo bango, mutlicast is working!

Thank you so much!

[chrihussey]

Awesome

[newparadime]

One further question, I am seeing the first multicast packet dropped, but all others are delivered. This may not be a big deal, but I was curious if that is just because the switch is autoconfiguring the routing?

I am using ssmping to validate multicast communication. Here is the output...

[ateam veh:13.2.52.150 ~]$ ssmping -Ieth0 -c 10 13.2.51.150
ssmping joined (S,G) = (13.2.51.150,232.43.211.234)
pinging S from 13.2.52.150
unicast from 13.2.51.150, seq=1 dist=0 time=1.875 ms
unicast from 13.2.51.150, seq=2 dist=0 time=0.749 ms
multicast from 13.2.51.150, seq=2 dist=0 time=0.973 ms
unicast from 13.2.51.150, seq=3 dist=0 time=0.989 ms
multicast from 13.2.51.150, seq=3 dist=0 time=1.124 ms
unicast from 13.2.51.150, seq=4 dist=0 time=0.888 ms
multicast from 13.2.51.150, seq=4 dist=0 time=1.044 ms
unicast from 13.2.51.150, seq=5 dist=0 time=0.903 ms
multicast from 13.2.51.150, seq=5 dist=0 time=1.048 ms
unicast from 13.2.51.150, seq=6 dist=0 time=0.930 ms
multicast from 13.2.51.150, seq=6 dist=0 time=1.065 ms
unicast from 13.2.51.150, seq=7 dist=0 time=0.895 ms
multicast from 13.2.51.150, seq=7 dist=0 time=1.033 ms
unicast from 13.2.51.150, seq=8 dist=0 time=0.847 ms
multicast from 13.2.51.150, seq=8 dist=0 time=0.989 ms
unicast from 13.2.51.150, seq=9 dist=0 time=0.928 ms
multicast from 13.2.51.150, seq=9 dist=0 time=1.067 ms
unicast from 13.2.51.150, seq=10 dist=0 time=0.904 ms
multicast from 13.2.51.150, seq=10 dist=0 time=1.045 ms

--- 13.2.51.150 statistics ---
10 packets transmitted, time 10001 ms
unicast:
10 packets received, 0% packet loss
rtt min/avg/max/std-dev = 0.749/0.990/1.875/0.303 ms
multicast:
9 packets received, 0% packet loss since first mc packet (seq 2) recvd
rtt min/avg/max/std-dev = 0.973/1.043/1.124/0.044 ms

[chrihussey]

Can't really answer that one...there is the switch first seeing an initial packet and then getting things set up so I wouldn't worry about it...if that's the only issue you should be good to go...