"stephen" <> wrote in message
news:iyRKg.3270$...
>
>
> --
> Regards
>
> - replace xyz with ntl
try again without the finger trouble....
> "Phil Schuman" <> wrote in message
> news:eOIFg.9667$ t...
> > 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 ?
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).
> >
> > Even with some kind of priority queuing on the inter-switch trunk,
> > how can I tell when that Ethernet trunk is being over-committed ?
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.
> >
> > 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 ?
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.
> > 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 ?
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.
--
Regards
- replace xyz with ntl
Similar Threads
