ok... I'm still confused on this whole vlan concept with respect to local tagging and queuing and transport to other switches.
I can see how I can separate the traffic within a switch via vlans, and it becomes basically 2 logical lans within the same switch.
Now what happens as I connect that switch to the next upstream switch over a single Ethernet high speed connection ? Where and how does the packet priority queuing take place ?
Even with some kind of priority queuing on the inter-switch trunk, how can I tell when that Ethernet trunk is being over-committed ?
ie - we have a warehouse with several smaller switches that feed back into a central warehouse switch in a rack in the mfg office. The mfg office switch in turn is connected to the main admin building via a single fiber run that in turn connects to a central admin switch and then finally into our main router.
Currently - we only have 2 subnets - admin & mfg - The warehouse is a different subnet than the main admin and we "route" via a PC connected to both physical segments with 2 nics (the PC runs an application for the warehouse, and it was easy to add a nic that connects to a small switch that connects to the fiber run out to the warehouse)
So - how does all this change or evolve as we migrate to a converged VoIP network ? How do the voice packets connected to the warehouse switches make it across the fiber - in a priority scheme - to the main building switch and ultimately the main router ?
Depending on what the switch has implemented and what you have configured, priority queueing will take place just before frames are put on to the trunk link. Actually, the notion of priority is typically carried through the switch, so priority queues are typically maintained at all places where queueing takes place in the switch.
You would have to set up a classifier policy that tells which traffic gets mapped to which priority. This depends on what the switch has implemented. The only think required by 802.1Q is that a switch be able to classify all packets coming in on a port to a certain traffic class (priority).
You can tell by check the number of frames dropped over different periods of time. If no frames are ever dropped, then you can be certain that the trunk is not overcommitted. If you have excessive loss, then you know it's overcommitted and you need more capacity. You might be able to add some easily using link aggregation.
One possibility is to give the voice traffic its own VLAN and make sure it gets higher priority over all data traffic (since it tends to be sensitive to jitter).
You could put the voice devices on their own subnet/VLAN so that you now have 2 VLANs, and set the switches to mark packets coming in from ports connected to voice devices to use a higher priority.
the whole point of marking packets in some way is that you can set 1 device to decide priority for some packets, and other devices can use those decisions as the packet flows thru the network.
each switch can choose an arbitary scheme to decide which frames get sent in what order - ie "priority" etc.
if the link between 2 switches is set for 802.1Q formatting, then each frame also has an 802.1p header, and that supports 8 levels of priority.
The switch may then choose to put some indicator in those bits of the frame priority - although there are suggestions for what those mean the switch is free to use any markings, and the recieving device might use them, ignore them and so on.
in a lot of switches, the device just treats the vlan tag and priority as 2 separate variables - it doesnt try to handle per vlan priority, bandwidth ring fencing, hierarchical QoS and bunch of related pain (my employer buys WAN MPLS routers that can do this for our MPLS network - cost per Mbps is orders of magnitude more than on a LAN switch).
you cannot directly.
the markings are just about what bit pattern some upstream device applied. How the set of packets with that marking correspond to overall load on a switch, port, vlan or anything are a separate issue (and usually ignored unless you buy high end boxes).
The same set of ideas applies to other QoS CoS schemes - from context in your Q this is likely to be IP ToS or Diffserv.
The big improvement in the IP schemes is if you have an IP network with routers, in that IP QoS is marked in the IP part of the packet, and that doesnt get thrown away once you leave the local Ethernet VLAN switches.
the golden rule with QoS is to only work with the exceptions.
So - everything should be default apart from the stuff that needs to be treated differently - in this case probably the VoIP real time packets. It probably already is default (although often paranoid network designers force all "non priority" traffic to have a low priority marking - just in case some application programmer, virus etc doesnt deserve to be trusted).
in reality it is probably going to work nearly all the time even if you ignore QoS entirely in a LAN environment.
But - QoS gives you some room for voice to carry on working when your network is overloaded or ill in some way and that is pretty useful.
Finally - QoS doesnt help if your network is sick - for example if you have a flapping link causing spanning tree to block traffic periodically, voice is going to hiccup or stop working and you will have a lot of unhappy users.
you need to remember that QoS is full of complex ideas, but the low level decisions are very basic. If i have more than 1 packet to send - which do i choose to send first?
So - QoS cannot make a significant difference unless there is some build up of transmit Q somewhere in your network, such that packets get significantly delayed.
the saving grace is that VoIP traffic doesnt need much bandwidth - even without compression and silence suppress it "only" uses 100 Kbps or so per conversation.
Since your Ethernet network probably has 100 Mbps per link and up, VoIP will be using sub 1% of load in a typical network. So - if you get an "overload" of VoIP traffic on a LAN something is fundamentally wrong.....
However if you allow someone to change traffic priorities (such conversations usually start as "xxx is business critical so all its traffic must be high priority") without considering the effect on the network then priority misconfigs can melt your network just like any other design issue.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.