I’m lucky enough to run a Juniper EX3200 as my home’s “core switch” (sounds good, right?). I love the Junos OS, and apart from the fans being tremendously noisy (in fact the hostname for this device is ‘noisy‘), it’s my pride and joy.
However, it is intended to be used in an enterprise environment not a home environment, so not every default setting is ideal for the kind of things a typical home user might want.
Multicast is one of those areas, it turns out.
The Multicast Problem
Like many home users I have a variety of networked media devices, including an Apple AirPort Express, a PS3 and a NAS that’s configured as a DLNA-compliant media server. I don’t stream music very much, and the AirPort had been a bit flaky in terms of whether it would actually show up on my iPhone, but it wasn’t too bad.
A few nights ago I tried to stream some music on the PS3, but the PS3 refused to discover the NAS for some reason. After troubleshooting for a while and assuming it was a software issue, I finally fired up Wireshark and took a look at what I could see on the network. After all, DLNA relies on multicast (SSDP) to find services, so I should be able to see multicast requests and advertisements on my laptop, right? Unfortunately not:
All I was seeing in the capture was Spanning Tree and LLDP traffic.
As a side note, in the WireShark GUI to apply a multicast filter, you can’t just use the keyword “multicast”. Instead, try this:
(eth.dst&1) && !eth.dst==ff:ff:ff:ff:ff:ff
That filter allows broadcast/multicast, then denies the broadcast traffic.
After digging around a little I found that there’s a default configuration on the EX that causes the problem – IGMP Snooping is enabled by default on all vlans.
That would be a problem, since there’s no IGMP happening for the SSDP multicast traffic, since it’s assumed that it’s all on the local subnet – which it is, in this case. However, since IGMP snooping is enabled and there are no IGMP join requests, the EX doesn’t bother forwarding the multicast to any ports because it believes nobody wants to receive it. Not so, Juniper!
The easiest way to fix this in a home network is to simply disable igmp snooping. In my case I don’t want it running anywhere, so the command is easy:
delete protocols igmp-snooping
Commit the configuration and the job is done – we now see multicast being flooded out on all switchports, which is what we need for SSDP to work:
And, as if by magic, the PS3 can now see the NAS and stream content from it.
But What About AirPlay?
I mentioned earlier that AirPlay (iPhone streaming music to the AirPort Express) was working intermittently. How did that work if multicast was broken?
The answer is all in the architecture. Due to the way my house is wired up, the AirPort Express is connected to a switchport on one of the wireless APs. If my iPhone associated with that particular AP, traffic between the phone and AirPort wasn’t transiting the Juniper EX, so it could see multicast through the AP’s built-in switch. However if my iPhone had associated with one of the other APs, it would not see the SSDP and thus could not see the AirPort. Ta-dah!
Multicast on my home network had been broken for quite a while now (since I installed the Juniper EX in fact), but since things seemed to work some of the time I had dismissed the problems I saw as just one of those things that happens, and mentally blamed flaky protocols without looking any deeper into it. It was only when something very specific was breaking that annoyed me sufficiently, that I spent time to diagnose the problem. There’s probably a lesson in that somewhere!
Over To You
Do you have a better way to fix it? Another solution? Please let me know! Obviously I could have just disabled snooping on the one VLAN impacted, but how could I support igmp snooping but also allow SSDP to work correctly?