SSDP multicast routing

asked 2020-05-17 16:06:43 +0000

net_tech gravatar image

updated 2020-05-19 01:25:04 +0000

Hi,

We have several SONOS speakers on the same network with our corp systems. As more and more AV equipment is being added to the network, we stared moving AV equipment in to a separate VLAN, SONOS devices have not been moved yet.

Looking at the traffic generated by SONOS we are seeing SSDP packets sent as Mutlicast and Broadcast. If we move SONOS in to an AV vlan, SSDP will get blocked by the router. While we can allow Multicast traffic to bypass the router using IGMP, don't think it's an option for broadcast. The data in both broadcast and multicast messages is identical, so hopefully clients will be able to locate SONOS devices once they are moved in to an AV VLAN and we are forwarding only multicast messages from AV VLAN to data VLAN.

Questions:

Should we see SSDP traffic generated by the clients looking for SONOS ?

Do we need to allow multicast in both directions? From AV VLAN to DATA VLAN and from DATA VLAN to AV

image description

Edit:

Additional Info

image description

image description

Thasnks

edit retag flag offensive close merge delete

Comments

Also check to be sure the TTL is greater than 1, as that would not route anyway without effort to mangle the packets.

Bob Jones gravatar imageBob Jones ( 2020-05-17 17:29:55 +0000 )edit

Bob,

The TTL is 1 on the multicast packets and 64 on the broadcast

net_tech gravatar imagenet_tech ( 2020-05-17 18:17:19 +0000 )edit

I've moved my SONOS speakers to a different VLAN too, and I had to forward the SSDP requests from the VLAN with the SONOS app clients to the VLAN with the SONOS speakers only. The big point here is the TTL of 1 as @Bob Jones already mentioned.

JasMan gravatar imageJasMan ( 2020-05-18 09:01:53 +0000 )edit

You are in a tough spot - though multicast is routable with protocols like PIM, as the TTL is 1 these will be dropped anyway at the point of L3 forwarding.

I don't do it, but I have seen some routers with the option to forward subnet directed broadcast. With the broadcast TTL of 64, it could in theory cross a router but your broadcast does not appear to be subnet broadcast, but rather all hosts with ip.dst == 255.255.255.255. If the destination IP was more like 192.168.20.255 (assuming a /24 mask) then this might be an option.

An option is to mangle the TTL; you could increase the TTL of the multicast packets and then route successfully.

Bob Jones gravatar imageBob Jones ( 2020-05-18 09:12:59 +0000 )edit

@JasMan

Do you recall if the TTL on the mulitcast traffic was higher than 1?

net_tech gravatar imagenet_tech ( 2020-05-18 11:36:58 +0000 )edit
see more comments