VLANs Multicast Isolation

JKnott

I gather English is not your first language, which is making it difficult to comprehend what you're saying. Multicasts should never pass between VLANs, unless specifically enabled. IGMP is often used to enable multicast to pass through a router and sometimes a switch.

johnpoz

I can understand they want to make it easy for your home user to plug shit in and just "find" the device they want to connect to via a discovery process.. Works ok when user is on 1 flat network..

But would it really be that difficult to allow for simple directed unicast connection to the device as well.. Where you just put in the IP of the device, or for that matter the fqdn..

Roku App allows for just putting in the IP of the device.. Plex allow for manual entry of the server you want to connect too.

They can hide such setup in an advanced menu location so you typical user won't ever see them... But you shouldn't have to circumvent your networks security to use a chromecast device ;) Or understand networking protocols like multicast or igmp.. Put in the IP of the device on the client/server and there you go... A nice listing of the ports actually used -- is it really that hard to list this stuff in the documentation?

mikekoke

I apologize for my English, but the only reason I use Avahi is that so I can share the sound of Chrome cards with the Sony speaker.
However from what it seems to me is that Chrome searches for devices via Avahi traffic between the iot and the lan and then connects to the cashier via port 8009.

johnpoz

While that might be true.. And while it might only be the search and then a unicast connection. How much "search" traffic is it sending? Does it only send the search when you call for it - or is there in the background sending out multicast every X seconds ;) Or have seen even multiple times a second nonsense..

These companies would be better off just allowing you to put in the IP or fqdn of the device, vs having to hope the users network is flat, or allow for multicast across vlans via the likes of avahi, which is just the lame ass mdns nonsense.. If I want something to resolve, then I will put in my DNS ;) hehehe

chpalmer

There are very valid reasons to cross Vlans with multicast. While it might not make sense in every case I have a very specific reason for doing so.

Broadcasting audio streams seems to be a quite common need for such.

Just hate to see "Multicast should never cross between VLANs" when someone brings up the idea because "never" is just not true.

johnpoz

What is your specific reason? Curious.. While I agree in a corp environment I could see a few reasons - pushing images to multiple machines, while the server is in a different vlan - this would be very controlled setup. And the client could join the multicast group when it ready to receive the image, etc.

Streaming multiple audio to speakers or something ok - yup that is great for multicast use.. Why does the streamer and the streamies have to be in different L2s?

I don't think I ever said NEVER... But if your thinking passing multicast from vlan x into vlan y you should really be clear on what your doing..

Say user machines in a corp setup, viewing a muticasted video stream - again would be valid.. But again should be controlled where the client joins the specific multicast group to view the stream.

avahi being used to send mdns from one vlan into another - seems like a hack from just doing it correctly.

mikekoke

I have analyzed the requests of Chrome and the sony speaker with wireshark and it seems that only the speaker continues to report its presence, while Chrome sends requests only when necessary. The sony speaker is on the vlan iot because it connects to the internet for updates.
Even if there is multicast traffic between the LAN and the IOT I think that the IOT devices cannot connect to the LAN because of the denial rules, am I wrong?

JKnott

@chpalmer said in VLANs Multicast Isolation:

Broadcasting audio streams seems to be a quite common need for such.

This is one of those specifically enabled situations I mentioned. In this situation, the client would contact the server, to be put on the multicast list. IGMP would then be used to enable passing the multicast traffic down to the client. Don't forget, multicasts use addresses that are not normally routeable. The router, through IGMP, has to be enabled to pass the mulitcast destination address towards the client. This is something that a router otherwise would not do.

Typically, on a LAN, multicasts are local network only. In fact, on IPv6, multicasts can use the hop count to ensure the packet didn't come from beyond the router.

johnpoz

If you forward multicast traffic from 1 L2 into a different L2... In "theory" that could be used for bad things..

Are you sending it in such a way that all devices on the dest L2 are seeing this traffic, even if they don't need too? Ie didn't join the group. Or have you limited this on your switches acls to only allow the multicast to the device that needs to see this and act upon this traffic?

When you create a boundary, you need to be aware of what can cross that boundary is all.. You would be the only one that can determine if crossing that boundary with traffic X is acceptable to you. A vlan is a boundary, where you can limit what passes between from who to whom..

What I find troublesome in the whole thing is just passing everything to everyone on the other L2.. If that is the case - they might as well just be on the same L2, ie no boundaries. Even if only a discovery method, a compromised system could use it to discover stuff that is different network than itself, and then direct attack to that IP which may or may not be open, etc. etc. I could be used for discovery, that if boundary was in place would not be possible.

This might be an interesting read for you?
https://www.cisco.com/c/en/us/about/security-center/multicast-toolkit.html

Could this be considered over the top for home network - more than likely yes ;) But good security practices are good no matter what the network.

chpalmer

@johnpoz said in VLANs Multicast Isolation:

While I agree in a corp environment I could see a few reasons

Then "never" is the wrong word to use.

We use mulicast for simulcast audio in multi site radio systems. The system is designed to use multicast addresses. We deal in microseconds. .000001 of a second.

Again.. My only issue is the word "Never!" Sometimes it is needed.

johnpoz

@chpalmer said in VLANs Multicast Isolation:

never

Ah your comments are directed at @JKnott but they seem directed at me.. Sorry. I never stated never ;)

chpalmer

@johnpoz said in VLANs Multicast Isolation:

@chpalmer said in VLANs Multicast Isolation:

never

Ah your comments are directed at @JKnott but they seem directed at me.. Sorry.

Still trying to get ahead of this forum software..

johnpoz

So your doing multicast over a wan? I don't see multi sites being over a lan ;) Are you using a tunnel sort of method to connect these sites?

Really don't see how you could be multiple sites, and be worried about microseconds ;)

While sure you can have extended L2s -- this is really a whole different ball of wax when what someone does in their home or even most enterprises.. If you worried about timing at a high level, your going to want minimal "hops" in the wire, etc.. So I would assume where your sending the data would be in some sort of extended L2 where the devices you sending the audio to is in the same L2, you sure and the F are not using avahi ;)

chpalmer

No..noooooo No passing the WAN. Im not sure I saw that idea presented here.

"but I would like to know if on the other two vlan that I have I should block the multicast traffic" I do not see that in the OP's input either..

This is a question as I see it about Multicast between local subnets.

I do it between routers. But no WAN involved.. Totally private networks. But at this point on Cisco routers.

johnpoz

So you have multiple sites radio systems all on the same campus? Just because its some private line doesn't mean its not a wan circuit. How far apart are they sites?

chpalmer

Western part of the state all connected by microwave. Different subnet at all sites. Not my design. but necessary. One of the largest private VOIP networks in the world.

JKnott

@johnpoz said in VLANs Multicast Isolation:

@chpalmer said in VLANs Multicast Isolation:

never

Ah your comments are directed at @JKnott but they seem directed at me.. Sorry. I never stated never ;)

I used "never" when talking about how traffic shouldn't pass between VLANs. I don't recall using it elsewhere, so I'm also not sure what he's referring to.

JKnott

@chpalmer said in VLANs Multicast Isolation:

Western part of the state all connected by microwave. Different subnet at all sites. Not my design. but necessary. One of the largest private VOIP networks in the world.

This is getting confusing. I thought you were talking about a single network where VLANs are used, now it's multiple sites. Also, it's entirely normal to have different subnets between sites. Otherwise you'd need a bridge between sites. It's doable, but that means everything, broadcasts included, can pass over the link. That's generally avoided.

johnpoz

Yeah what he is talking about is this

https://en.wikipedia.org/wiki/Multicast_routing

Completely different ball game to be honest ;) This is NOT what the OP was talking about.. not at all!!