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

Discussion in 'VOIP' started by Phil Schuman, Aug 19, 2006.

  1. Phil Schuman

    Phil Schuman Guest

    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
    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
    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 ?
    Phil Schuman, Aug 19, 2006
    1. Advertisements

  2. Phil Schuman

    anoop Guest

    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, Aug 20, 2006
    1. Advertisements

  3. Phil Schuman

    stephen Guest


    - replace xyz with ntl
    stephen, Sep 4, 2006
  4. Phil Schuman

    stephen Guest

    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

    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

    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.
    stephen, Sep 4, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.