moltra wrote:Is there a UPNP or DLNA setting on your routers? if so change it to the opposite and see if there is any changes. Can you post your serviio.log files, so we can see if there is any errors in the log.
Moltra, thank you for a useful and constructive reply. There are no routers involved here so no uPNP settings.
To reiterate, I have two switches connected to each other via an 802.1Q trunk. Traffic from the server will enter switch A, get tagged with the VLAN ID, pass to switch B where it is de-tagged and delivered to the client device, and vice-versa for the return traffic. This works correctly for all traffic except Serviios DLNA traffic. If I connect Serviio directly to switch B then the client also on switch B will see Serviio and work correctly. This leads me to the assumption that it is not a basic Serviio configuration error.
When Serviio is connected to switch A and the client to switch B, traffic has to cross the trunk circuit and then the client device does not see Serviio at all. Because no server is seen it is not possible to start a session with Serviio so there is nothing in the logs. Other DLNA devices connected in the same way will work as expected over the trunk circuit so from this I assume it is not an inherent problem in the DLNA protocols.
Non DLNA traffic will work correctly over the trunk circuit. Eg Serviio is running on a Windows box so I can see it using SMB, ping, FTP etc. so this leads to the conclusion that it is not a layer 2 fault. I am fairly sure also it is not an MTU issue as non of the frames transmitted are anywhere near maximum size until the data stream starts, and as I don't get to this stage MTU is never approached.
npuser wrote:It is kind of interesting that you setup multiple vlans to isolate broadcast traffics then immediately turn a round try to find ways to break the limitation.
DLNA sends announcement as broadcast packets with TTL of 4. The broadcast packets are not route able and won't get forwarded to other vlans in some cheap consumer oriented switch. The broadcasts will be forwarded on a Layer 3 switch, but ONLY within ports that are part of the same VLAN from which the broadcasts came. Other VLANs, other IP subnets, won't receive the broadcasts.
npuser
npuser, I appreciate your effort in providing a response, it is clear that you have a very basic understanding of networks from your reply and that you lack somewhat in your comprehension of the English language and your ability to understand what was posted. Nowhere in my post did I mention crossing traffic between multiple VLAN's, my issue is entirely contained within a single VLAN.
Also you might like to note that the cost of a switch makes no differences whatsoever to the handling of broadcast traffic, neither the cheapest 'consumer oriented switch' nor the most expensive pro switch will forward broadcast traffic between multiple VLANs, and similarly both WILL forward it to all ports within the same VLAN group, so I am struggling to see the relevance of your comment. Similarly TTL is only significant when crossing routers, so again I can't see any relevance to your comment. Layer 3 switching is also a complete red herring, broadcast traffic will be forwarded at layer 2, whether or not a switch has layer 3 functionality makes no difference when dealing with general broadcast traffic. Don't be taken in by the marketing guys, fundamentally a layer 3 switch is not so different from a layer 2 switch, it just looks at a few more bytes to make it's switching decision so it builds it's forwarding table based on the IP address as well as the mac address. All in all I am struggling to find anything either useful or relevant in your post but thank you all the same.
Wed Mar 21, 2012 3:06 pm 