Need some suggestions..High demand network design

S

seanx

2[H]4U
Joined
Aug 1, 2001
Messages
3,191
Right now I am trying to draft up and idea for a network layout.

Its going to be a very basic network, only about 150 clients but there will be heavy traffic.

In the past I have used just a basic star pattern with one root switch that the rest of the switches plug into, but this creates major bottlenecks from the trunks to the root switch.

What I was thinking, and this is why I am asking, is this:

If I had layer3 switches and each switch had their own subnet and each switch was interconnected to eachother switch, could I just put a route for each different subnet pointing to what port the traffic had to go though.

This would reduce the bottleneck by sending only what is needed to each switch.

Im sure there are better ways but at the moment that is all I am comming up with.

--Sean
 
What's the application? What's your budget? How much bandwidth is being used? What kind of traffic is it ( high priority, low latency? Bulk traffic? ). Are individual workstations chatting amongst each other, or is it strictly client to server?
 
Yeah, you could do that. With 150 clients though, you'd really only need 2 VLAN's if you really wanted to break that network down. You could always VLAN by department too. That is what most people who are going to do VLAN's end up doing. Separate VLAN for each department, then a separate VLAN for the servers.
 
The budget Im not too sure on yet, nothing outrageous.
It is going to be mostly client to client for the heavy traffic with much less client to server. Nothing high priority, just lots of it.

But thank you for confirming that this setup would, indeed, work.
 
The major advantage you get (bandwidth wise) from segmenting into multiple subnets for 150 clients is reducing the broadcast domain. Overall there's less junk on the wire in each segment. If you've got so much broadcasting going on with a 150 client network that it's significantly affecting your bandwidth, then I would definately take a look at exactly what's going on. Not saying that segmenting isn't a OK thing, just that bandwidth reduction isn't usually a driving factor, especially when there's a lot of planned subnet to subnet traffic. Remember too, that routing does add some amount of latency that doesn't exist when a packet is simply switched (though I guess it's negligable in most of today's layer 3 switches).

Don't forget to plan multi-port trunks between switches. If your switch-to switch trunks are big bottlenecks, then just create a 4 port (or 8 port if your switch supports that many) trunk between switches. That way you can have 4Gb (or 8, again if supported) link between switches. You just need to get the wiring in place, and to plan for the extra port usage. Of course, 10Gb uplinks are available these days too if you have the money................................
 
I just re-read your post and noticed you're talking about connecting each switch to every other switch. That's not going to accomplish much as many links will ultimately be shut down to prevent loops.

What I would do is define two "root" switches, one primary and one secondary, and connect each switch to those two switches. Then connect the two root switches together. If you want, you could do as suggested and bind multiple ports together on each switch and create multi-gig links. That should be fine for your setup, even if you didn't segment out into VLANs.
 
Sorry to be a bit slow here but connecting the 2 root switches togeather, what would that accomplish? Also why 2 root switches?

Its late and Im not thinking too well.
 
Oh yes and I totally forgot about spanning tree kicking in and shutting down all links not deemed worthy;)
 
Out of interest, what sort traffic are you planning that would saturate client:client switched network if the switches are Gb connected and trunked? Since assuming the switch fabric was sufficient to not overload the backplane, you would effectively have node:node at wire speed, which even at 100Mbps (or 200Mbps full duplex) would be hard to saturate from a single client unless there was a heck of a lot of broadcast traffic.
 
seanx said:
Sorry to be a bit slow here but connecting the 2 root switches togeather, what would that accomplish? Also why 2 root switches?

Its late and Im not thinking too well.
Click to expand...


If you configured spanning tree properly, the connection between the two switches would be passing traffic, while all the links to the secondary root switch from the user switches would be blocking. If you don't do this, you're going to end up with a funky STP topology. Also, if you plug your servers into your root switches (instead of hanging them off another switch), this would allow servers to communicate easily across both switches - since you may have the primary server plugged into switch 1, and the backup plugged into switch 2.

Of course, the aforementioned STP topology assumes that you're adjusting STP priorities uniformly for all VLANs, thus making all VLANs flow in the same logical direction. You could adjust priorities to have certain links active for VLANs 2 and 3, and other links active for VLANs 4 and 5, then you'd end up with two logically different STP topologies.

This is a very common topology in smaller companies that don't need the whole Core-Distribution-Access architecture. Both with all VLANs flowing the same way, and doing STP load balancing based on VLANs.
 
Boscoh,
The original poster states it is mostly client:client, not client:server so I am not sure if standard topologies apply.
 
cyberjt said:
Boscoh,
The original poster states it is mostly client:client, not client:server so I am not sure if standard topologies apply.
Click to expand...

Granted. Standard topologies would still apply though. Even with the topology I recommended, you could still make each switch it's own VLAN. Traffic that is local to the switch would stay there, and traffic that needs to traverse switches would go down through the root switch, which could host just the servers.
 
Boscoh said:
Granted. Standard topologies would still apply though. Even with the topology I recommended, you could still make each switch it's own VLAN. Traffic that is local to the switch would stay there, and traffic that needs to traverse switches would go down through the root switch, which could host just the servers.
Click to expand...

If your segmenting it like that you would also need something to route the traffic between the subnets. Not a bad idea since it breaks down the broadcast domains, but it also adds one more part to complicate the structure and unless you have some form of redundancy for the router you now have a single point of failure with that topology.
 
Xipher said:
If your segmenting it like that you would also need something to route the traffic between the subnets. Not a bad idea since it breaks down the broadcast domains, but it also adds one more part to complicate the structure and unless you have some form of redundancy for the router you now have a single point of failure with that topology.
Click to expand...

You'd need something to route between the subnets no matter how you segmented it out with VLAN's, but the original poster was going to get L3 switches anyways. And you're right, you'd want redundancy too. Whether that's in the form of the second root switch, or by simply connecting one of the user switches to another user switch, you would need redundancy.
 
Lets get something straight before we get too far. Many companies sell L3 switches that don't perform any sort of routing, simply peak at the contents for QoS purposes. These won't get the job done to actually route and would require other hardware.
 
my company uses a similar topology as stated before, tho if a subswith goes down that segement goes and if the root switch goes it all goes, as all our servers run thru the master switch. tho our satellite offices are separated connected via a wan.

I would use gigabyte cisco switches, that use the interconnecting cable, in short dam fast, as your master switches then use subswitches (connected to master switch via gigabite cable) and separate areas into vlans. also you will need a dam good router/firewall between the root switch and the internet. if the root switch goes, you will be busy, that is why i would use cisco as my master switches.

IE, Firewall => Cisco Master Switches with servers => Sub switches/vlans (by department). if you are worried about bandwidth use gigabite switches, tho my company uses 100 megabit cables ( we have over 250 people and 126 servers) and its quick doesnt take long to send Gigabytes around.
 
Networking technologies are commonly measured in bits, not bytes. I assume you are talking about Gig-E or 1000mbps/1gbps Ethernet.
 
This is still not addressing the original posters concerns since he states client:client, fine if the physical arrangment allows the clients talking to each other the most o be on the same switches/vlans, BUT if all the clients have equal probability of needing to speak to each other then this breaks down. Without knowing more about the app which requires hi client:client connectiivity it is a mute question, whilst most of the advice given is applicable it can never be truly customised without knowing the specifics of the application.
 
Xipher said:
Lets get something straight before we get too far. Many companies sell L3 switches that don't perform any sort of routing, simply peak at the contents for QoS purposes. These won't get the job done to actually route and would require other hardware.
Click to expand...

Interesting. I've never seen a "Layer 3 Switch" that doesn't route. I've seen plenty of Layer 2 switches that boast being "Layer 3-aware" and do exactly what you say: provide L3/L4 services via ACL's, QoS, etc. A true "Layer 3 Switch" will route, and I think you'll find that all the major vendors fall in line with this thinking. Nevertheless, I was under the assumption that the L3 switches the poster was talking about do in fact route.

Cyberjt is right about not being able to tailor this without knowing the specific application. If all clients really need to talk to each other equally with high data rates, it may end up being a better idea to purchase a chassis-based or stackable solution to get access to the high-speed backplane. We'll just have to hope the poster posts more information. We can throw out topologies 'til we're blue in the face :D .
 
Exactly, I use a Fastiron 1500 - fully populated, effectively complete client client switching at 100Mb for the subnet with a Gbic blade for the server connection. This though only works of course if all the stations have passive patches back to the comms room, the clusters I have are on smaller fastirons which are Gb trunked over 2 Cat 6 cables, effectively the whole subnet is capable of end:end switching for the clients, that info still does not overly help the original poster!
 
Do something a bit more hierarchial (?).

I don't how know it is physically designed, but a switch for every room (5 PCs or so) is a good starting place (again... depends on the load we are talking about wether that would be cost effective).
A switch for every subnet may work too, depending how many PCs are in the subnet.

After every major section in the building, I would install a router, for a total of 3 routers or so. A central router wouldn't hurt, but not 100% needed, and just connect your server(s) on the other side of this router.

Routers don't forward broadcast storms, switches do. That is the primary reason for needing to break a larger network down with routers.

May I suggest Gigabit? If you build the network from the ground up with Gigabit in mind, you will have a much better network (some networks only contain the cabling for Gigabit, yet still have 100mbps Nics and they wonder why there has been no speed increase).
 
zacdl said:
Do something a bit more hierarchial (?).

I don't how know it is physically designed, but a switch for every room (5 PCs or so) is a good starting place (again... depends on the load we are talking about wether that would be cost effective).
Sorry, what????? a switch for every 5 PCs? I am assuming at 150 PCs as the original poster said it is not someones home network we are talking about, at that rate you are talking about 30 switches - the power use alone is a ridiculous overhead along with the management time, let alone mention the amount of port blocking due the hierchy especially since the original poster stated mainly client:client which could be several leaves over on diferrent branches in a hierchy - multiply that up by the combinations of 150PCs and even at gigabit switches you would start to port block under heavy loads.

Again will the original poster state more details before a sensible solution can be given.
Click to expand...
Click to expand...
 
True, but I am not talking about each switch being an industry sized one, either.

There were practically no details, like I said- one switch per room would probably the easiest way to do things. I don't know how big the rooms are, I don't know how many PCs are in a room, or anything.

I was also not suggesting Gigabit for the entire network right off the bat, either. I guessI should have clarified that. Mainly for the backbone and servers.

I agree though- more details. Size of building, number of PCs in a room, what kind of work the PCs are doing, how much bandwidth we are talking about, everything!
 
You must log in or register to reply here.
Back
Top