VLAN - switch -> trunk -> switch - priority queuing ?

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.

Anoop

 

--
Regards

- replace xyz with ntl

 

try again without the finger trouble....

it depends.

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.