Jump to content

Recommended Posts

Posted
Correct me if I'm wrong but if you have phones on your network shouldn't these be on a separate VLAN / Network than your PC's because voice will completely annihilate your PC's on the network ??

 

I think I'm right but I don't deal with the phones :) - so a good idea for another VLAN if need be.....

 

Its the other way around, VOIP uses up comparitivly tiny amounts of bandwidth but is very sensitive to delays which can get caused by computers on the same segment chucking large amounts of data back and forth. Best to VLAN off VOIP and put QOS on to make sure you don't get stuttering calls.

  • Thanks 1
Posted
voice will completely annihilate your PC's on the network ??

 

I don't know either, but I'd like to know. From my thinking, a VLAN is simply a mechanism for your switches to separate traffic, possibly giving one set of traffic priority over another (i.e. giving the voice network priority over everything else as it has to carry live voice data). Does the IP protocol already do this, or is VLAN-ing the best / easiest / proper / only way to accomplish traffic prioritisation for voice data?

 

--

David Hicks

Posted
I don't know either, but I'd like to know. From my thinking, a VLAN is simply a mechanism for your switches to separate traffic, possibly giving one set of traffic priority over another (i.e. giving the voice network priority over everything else as it has to carry live voice data). Does the IP protocol already do this, or is VLAN-ing the best / easiest / proper / only way to accomplish traffic prioritisation for voice data?

 

IP does it to a limited extent but in a clumbsy way and not to the point where it actually works for stuff like VOIP, on smaller networks you can usually get away with just QOS but that relies on your routers/switches to inspect all of the traffic and prioritise it appropriatly. Putting the VOIP traffic into its own reserved space is the easiest and most robust way of giving it the best chance as it is a fixed solution that works on all of the required traffic. Otherwise you have to specify QOS priorities for each of the kinds of VOIP traffic on all of your network devices and end up hopeing that the trunks do not get too congested for even QOS to maintain the required lack of latency.

  • Thanks 1
Posted
IP does it to a limited extent but in a clumbsy way and not to the point where it actually works for stuff like VOIP, on smaller networks you can usually get away with just QOS but that relies on your routers/switches to inspect all of the traffic and prioritise it appropriatly. Putting the VOIP traffic into its own reserved space is the easiest and most robust way of giving it the best chance as it is a fixed solution that works on all of the required traffic. Otherwise you have to specify QOS priorities for each of the kinds of VOIP traffic on all of your network devices and end up hopeing that the trunks do not get too congested for even QOS to maintain the required lack of latency.

This is true. You'd need high spec switches (Cisco) to even to do this properly on a small network as the RAM in lower end switches would struggle. We've got a problem where our fat network digests everything (including VoIP, IP Cameras, IP Access Doors etc). The VoIP system is taking a hit by becoming slightly distorted at peak times. I'm planning a VLAN strategy at the moment for when it all becomes chaotic and my manager takes note that VLANs are the way to go.

 

With regards to the multiple domains; I'm sure once correctly configured, it's much easier to implement and secure data (splitting student and staff). You could in theory keep this in the same VLAN and use other VLANs to split different function streams (VoIP, IP Cameras etc). One domain per VLAN is much more tricky if you want to use shared mapped drives as you'll need a physical router or a layer 3 switch to allow two different VLANs to interact. Then again, you'd need to put ACLs in place to make sure there's a point to securing the data between the VLANs.

 

A network without VLANs is dangerous if the network grows personally (naturally schools do, especially with more student laptops and technology using IP etc). It's worth the hassle of configuring it and is something I need to do if I'm going to advise it.

Posted
This is true. You'd need high spec switches (Cisco) to even to do this properly on a small network as the RAM in lower end switches would struggle.

 

Just to be clear, you don't need Cisco switches for this. HP 2600 range works fine, and they're by no means 'high spec'.

Posted
HP 2600 range works fine, and they're by no means 'high spec'.

 

So, what specification of switches would people recommend for a network as discussed above, capable of utilising VLANs and running a VoIP system? I assume support for IEEE 802.1Q VLANs would be a good idea? Does IEEE 802.1Q specify how the switch handles VLAN / traffic prioritisation, or does the switch need some extra feature? What do switches need to support by way of backplane bandwidth capacity - simply double the number of ports (so, as a base reference, a Dell PowerConnect 2848 has 48 gigabit ports and has a backplane capable of 96 Gbps)?

 

The Dell PowerEdge 2848 costs around £500 - what do other switches do that makes them any more expensive?

 

--

David Hicks

Posted (edited)

The Dell PowerEdge 2848 costs around £500 - what do other switches do that makes them any more expensive?

 

The type of switch you need depends heavily on the ype and amount of traffic you are pumping throught it along with the topology of the network. If you have a large network with multiple VLANs and multiple distribution cabinets in other areas it changes how you do stuff. I have no idea what the spec of the dell switch is as a quick google search does not find it. Anyhow the 802.11Q is just for VLANs and does not specify QoS stuff.

 

The features are really bunched up into layers of the OSI model (7 layers), layer 1 is hardware stuff, basicly cables and plugs with no inteligence at all. Layer 2 is transport which is the low level protocol for ethernet, this knows about stuff like frames, MAC addresses and usually includes authentication and authorisation stuff like 802.11x, TACACS and VLANs. This level (layer 2 managed can mess with everything that is at the low layers much better as it actually understands it and can work with it to manage it much better than an unmanaged switch that just knows the very basics. These will also generally have QoS but as stated above depending on how much traffic you are dealing with and how much ram/CPU the switch has can choke up.

 

Layer 2+ switches are basicly Layer2 switches with limited routing built in so that you can move stuff between VLANs without a seporate router, these generally only offer static routes but do offer flexibility.

 

Layer 3 is where the real work happens for managing between VLANs and also comes with a big jump in CPU/RAM. These generally have full routing ability with a number of routing protocols, usually at least RIP and maybe OSPF. These can inspect the data at the IP level aking into account the source and destination IP address and making decisions based on those. Layer 3 switching is even better than layer 3 routing as it only has to do the slow routing calculation once then it keeps the path in memory and does the rest at switching speed (1ms as opposed to 10-20ms) this usually comes in the higher end switches and again comes with a boost in memory/CPU.

 

Some layer 3 switches give you limited layer 4 control which is the transport layer, this means the router can see what type of traffic it actuall is by ripping open the TCP packet and reading its headers. This allows you to use access lists etc to limit certain types of traffic or even foward them along a different path.

 

QoS is offered as a feature in many switches and to works in the layer 4 section inspecting every packet down to the IP headers which is very costly in terms of memory and performance of switches hence depending on traffic you may need a good midrange switch like a hp 2600 to use it without a large performance hit.

 

The backplane capacity is usually that high that it doen't need to be factored in much unless you are stacking huge amounts of them housing high use workstations.

 

The general pattern for a larger network is to have reasonable clientside switches that can handle the basics well, even hp 2500 series and a high performance high feature level switch at the core. This means that most of the grunt work is done by your large central switch that has the capacity to deal with it all. Even larger switches usually have more and more features being able to inspect all the way up to layer 7 and layer 3 route between hundreds of thousands of hosts a second.

 

osi_model.png

Edited by SYNACK
  • Thanks 1
Posted

Having done a fair bit of reading around and research I've designed a nice VLAN config that I'm testing on a spare switch at the moment to see if it does the trick for us.

 

Would be VLANs for...

 

- servers accessible to all workstations

- restricted servers accessible only to admin workstations

- admin PCs

- teaching PCs

- printers

- guest wireless (can't access anything but the Internet gateway)

 

I've found out the info for DHCP-Helpers, VLAN ACLs etc and made up a theoretical config that I'm trying on a switch at the moment. We've got a 5406zl at the core which will be doing all the grunt and 2610s at the edge which I believe won't need to do any routing as it's all done at the core? I remember a few years back when we looked at the edge switches, Gigabit ones were too pricey at the time to buy the 20 or so that we needed so went for solid 100Mb devices that seem to handle everything pretty well.

 

One quick qu, if I put the Internet gateway in its own VLAN am I right in thinking I'll need to add a static route to the firewall internal interface so when it port fowards Internet traffic to an internal server it knows where to go to get off the VLAN?

 

Any other common gotchas that you've encountered when moving from flat to VLAN? I know WOL packets can be troublesome if trying to send cross-VLAN, anything else spring to mind?

Posted
For the internet you will need to have a default route at the default gateway that points all traffic to unknowen networks out to your internet gateway. Your internet gateway will also need to know how to get back to the VLANs so it will need either static routes pointing to the router inside your network core for each of the internal networks or even better advertised routes. If you can set up your core router to advertise its routes via RIP or OSPF then your internet gateway should be able to pick them up dynamicly and always know what networks are configured on your internal network without having to enter them manually. Getting your gateway device to listen to the RIP advertisments shouldn't be to difficult and it does save time in the long run.
  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...