If you want L2 then do what you were proposing. I'm not entirely sure why you think it's not scalable and certainly Q-in-Q wouldn't help between 3 sites.
You asked for feasible solutions and that's why I suggested routing because it is better, in my opinion, to route rather than switch. If you don't need the same vlan at all sites routing is the best way to go but like i say if you don't want to then don't.
If you have the advanced IP services images on your 3560 switches then you can run a routing protocol between the 3 switches, otherwise you could run RIP or use static routing. Each 3560 would do the inter-vlan routing for it's own vlans and then you would route between sites.
However as i say, if what you really want is to use L2 which i get the impression you do then just stick with trunk links.
Apologies for the rather terse last response, i was in a bit of a hurry.
If each site has it's own vlans then there is no benefit to running trunks because you do not need to send traffic from the same vlans across sites. The server vlan needs to be accessible from all sites but you can route to this, you don't need to have the server vlan in all sites.
If you summarise your addressing in each sites a single static route could be used per site eg.
Site A = 172.16.0.0/24 -> 172.16.7.0/24 -> summary 172.16.0.0 255.255.248.0 or 172.16.0.0/21
Site B = 172.16.8.0/24 -> 172.16.15.0/24 -> 172.16.4.0 255.255.255.248 172.16.8.0/21
Site B = 172.16.16.0/24 -> 172.16.23.0/24 -> 172.16.16.0 255.255.255.248 172.16.16.0/21
note you want to leave spare subnets in each site summarised range for future growth so you can allocate more /24's to each site and use a larger summary address if you want.
Then each 3560 on each site would be responsible for routing that sites vlans. So on each 3560 you would have the relevant vlans in the vlan database and the relevant L3 vlan interfaces.
Finally you need to add a static route to the switches eg.
Site A switch
ip route 172.16.8.0 255.255.248.0 192.168.5.2 <-- note 192.168.5.2 is used from my previous thread as are the rest of the next-hops
No worries, I didn't notice it - until you pointed it out
Actually the reason I want L2 is because there will be multicast traffic (delay sensitive) in this network. I presume with the network configured to route - I will have to learn multicast routes - which may add to overall delay.
Based on your description of the network and your requirements, if you need to communicate between the users on different VLANs and the server VLAN, you do need to have routing enabled somewhere. The big question will be where you want to do the routing. One option would be to do it at individual sites which makes your design simple and scalable. You can configure dynamic routing protocols between the sites and all routes will be synchronized. If you decide that all routing should be done in site A (hub), then you need to trunk all the VLANs to the Site A and then have a router/switch that has enough juce to route/handle traffic from multiple sites. But in either case, you do need routing somewhere.
As far as your requirement of multicast traffic is concerned, you can configure multicast routing at each site. Using multicast routing will help you control traffic over the inter-site links as the routing protocol will build the tree and forward traffic only if there is a client across the link. On the other hand, some switches treat multicast traffic as broadcast and send it across all the ports creating traffic floods.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...