Originally posted by: ScottMac
Pardon MY attitude, it's been an ugly week.
My point was that the instructor is presenting valid information (given your examples). While you may have a firm grip on networking as you currently know it, there is much much more out there in "the real world." Learning only one basic approach severely limits how well you can adapt a network for maximum efficiency. Learning as many points - of - view on any given topic concerning design gives you more tools, greater flexabillity.
The favorite axiom here is "When the only tool you have is a hammer, all the solutions start to look like nails"
To your situation:
If you look at that Dell switch: it has 24 ports @ 100 meg each, right?
Most or all of those ports are "aimed" at a single resource ... connected to one of the gig ports .... if more than 10 (well ~11-12) of those ports are active at one time, there is contention....someone is going to have to wait (i.e., is buffered). The gig port to the resource is oversubscribed @ 2.4X.
Something you can do to relieve that would be to light up TWO gig NICs in the server, split the switch into (at least) two VLANs (each VLAN / trunk on it's own gig port of the switch). Now you have a situation where you are just barely oversubcribed to your resource.
If each of the gig ports is trunked, use 802.1q on the server NICs to create multiple (logical) instances ... each on it's own subnet. If you can come up with a logical grouping of the clients, you can now apply a more modular security and/or filtering (via access lists / firewall rules, etc), and you don't have to apply it to all clients, just that particular subnet / vlan.
Another possibility is "teaming" the NICs, if the switch supports it. The problem with teaming is that you don't end up with a two gig pipe ... you get two one gig pipes to the same place ... and no control on how traffic is passed through the bonded link. In the past, it was not unusual to have most of the traffic passing on one of the links, while the other was underutilized (session -based distribution).
At least using VLANs, trunks, 802.1q etc, you can design the VLANs such as to balance the traffic, possibly provide some redundancy, maybe even set up VRRP (I don't know the Dell switch, and I don't remember if / how many routers you're looking at)). It's a little more work on the design side, but like many other things, the effort up front will pay off later as the network grows.
Excellent planning will beat out killer equipment pretty much every time. Planning is what separates the hacks from the pros.
Give it some thought, keep it simple, document the bejeezus out of it.
Good Luck
Scott