hydroxy

Can you test a physical switch client on the same VLAN as the Multicast source, so you avoid multicast routing issues? This isn't a solution, but it's a fallback position in case nothing else works. Put multicast source and destination on the same subnet.

Understand the pain. Flat network with 10x 5406zl's is a big ask. Been a while since your post, so I'm curious how your going. I look after 6x 8200zl/5400zl's on a 2 campus enterprise, use collapsed core/dist for backbone/building distribution, and plenty of other edge switches 2910al/2810-48/2520, etc. Have ASA's, and other virtual/physical devices for other network services. First step before anything else is layer 1, 2 and 3 network diagrams. Then perform a baseline analysis. Really need to know what is currently happening before making any design changes. Where's the DC's, wheres the DMZ, Border, what clients are where, what numbers, etc. Also need to know protocols and applications. For example, if layer 2 is required from point A to point F to support some application, then how do you segment that? I use MSTP and OSPF, but that tends to get quite complicated. Unfortunately, the Procurves haven't kept up with recent developments in the switching world, and don't support TRILL, SPB or similar - which would be far more suitable. Plus, you're likely using virtual somewhere along the line, and that can complicate matters. I'd suggest looking at upgrading your core network to the latest technology if you get the chance (in terms of HP that's the new lines 59xx/58xx). If you're stuck with Procurve, then KISS. Don't try to be too tricky. Get rid of RIP asap, not worth the effort, it doesn't scale well and can be buggy. Try and simplify the STP design as much as possible. Have multiple smaller STP domains rather than a single large one, this stops STP problems propagating across the network. Use UDLD on any trunk links. Enable STP on ALL switches (to prevent loops), but only after design is considered. Manually prune STP domains using BPDU-filter with or without routing links. Less trunk links the better - always opt for 802.3ad between switches. One or two 10Gbps trunks is enough for most designs. Only enable ip routing on core/dist. Edge switches should be "no ip routing". But before doing anything, you need your documentation of the current network up to date and detailed, and need to know about every application that is used and where and how it talks. Taking that information, you have a chance to know where you want to go, and work on a new network design document. Then you can figure how to get there. To migrate, do one application or change at a time, test. Try to avoid making multiple changes at once, because if it fails, it can be very difficult to troubleshoot on the procurve platform.