OK, I'm re-aligning my thinking here.  Essentially, I wanted to have a 'server LAN' that was isolated from the 'desktop LAN' rather than having 'one big happy LAN', so that:

a) the servers are not in the same broadcast domain as the desktops;

b) IP-based ACLs could be applied between networks to control desktop<->server, desktop<->internet, and server<->internet access

Of course, the link between the 'server LAN' and the 'desktop LAN' should be better than 100Mbit.

Layer 3 routing is one way to achieve this.  But as I complained, the only switches 'close' to the SB Pro range which support Layer 3 routing are:

a) the ex-Linksys SFE* switches ... which don't have appropriate support or service options for deployment in a business;

b) the beautiful-but-expensive 3650 series switches

... none of which can be managed by CCA anyhow.

There are 2 routers with gigabit ports in the SB Pro range as Dave Hornstein pointed out: 3 x L2 gigabit ports on the UC 560, 6 x L3 gigabit ports on the SA 500.

The SA 500 would be perfect if I didn't already have an 877 doing an adequate job on the network edge.  The UC 560 might be useful if I also had a sizeable telephony deployment, and if I could configure inter-vlan routing via CCA (since use of UC 540/560 via the CLI is frowned on by the support organisation for those units).

So I'm back to looking at the only switch in the SBCS profile ... the ESW 500 series.  OK, let's re-examine my design goals here:

a) "the servers are not in the same broadcast domain as the desktops" .... well, this is technically the right thing to do from a number of angles, but hey - it's just a small network with 10 or fewer desktops, and the servers are within 100m of the desktops.  The servers will have to cope with that L2 broadcast traffic.  (Actually, it's kind of convenient, since I don't have to make any special arrangements for forwarding desired broadcast traffic - such as DHCP - across the L3 routing boundary).  Happily, with an ESW-520-24P-K9 I get 4 gigabit ports to dedicate as uplinks to my 'server farm', and for the important types of L2 address-related broadcast traffic - DHCP and ARP - the switch declines to broadcast nonsense packets anyhow.

b) "IP-based ACL's" ... well, these are supported by the ESW 500's anyhow.

It turns out that, for the price of a few stray ARP requests which could really have been answered by the switch instead of the servers themselves, the ESW 500 series meets my needs pretty well.  They're an attractively priced, well-featured switch with a good support story.

So no, there is not a gap in the SB Pro line.

regards,

David.

PS.  You switch guys can give yourselves a pat on the back, but the UC guys need dunking in ice cold water.  I can't believe that the UC 520 and UC 540 don't come with at least one gigabit uplink port ... the whole value proposition of having data and voice trunked over the same ethernet access cable is destroyed ... do you really think the desktops connected to the built-in switch are going to talk to *each other* instead of all talking to a server?  Even if you cripple it so that it'll *only* function at 1gbit when used as an uplink to an ESW swtich, please give us the option of actually using the switch ports on the UC5xx for desktops.

Maybe if 'proxy ARP' were supported on the ESW series, practically all the requirements for my scenario would be met.

Good evening,

I do not think you want proxy arp on a L2 device, since the arp request should travel within the L2 network.  This might make a little more sense for L3 interfaces and for when you want other devices to fake the identity of another.

You raise a good question though - how to keep the workstations from 'disturbing' the servers?   This kind of question is golden ...

Security and QoS in every install.

During good times all is happy, but what happens when a HP jet-direct card goes bad, or an application misbehaves, or a guest plugs into your lan and all heck brakes loose ... etc ...?

Security and QoS ensure that applications will always be available, protected, etc ...

I like you thinking.  ;-)

While this would complicate your install, have you considered multiple vlans for your workstations and servers?  This would keep bcasts to only the vlan from where they came from.

Once you start looking at vlans, then having a router that can route between becomes a must. Kind of starts adding to the complication ... Might be best just to look at some ACLs and QoS like you mention.

BTW - the CNA tool is completely awesome for Cisco switches ... you can do all your management via this tool, even clustering of multiple switches.  A very nice tool ... and when you launch it, you will see that the CCA tool was built to resemble it.

Excellent posts ... thanks for adding so much!

Andrew Lissitz