05-20-2008 08:40 AM - edited 03-05-2019 11:06 PM
Hi,
I had an issue this morning and was wondering if it could be caused by enabling mls qos.
Around 11:18AM after enabling mls qos, the network seemed to have blipped, meaning all communication was lost for about 5-10 seconds.
We have SW1 connected to SW2 via Tengigi and MLS QOS was enabled on SW1 but systems all across both switches inclusing our ip sets seemed to have lost communication all together.
Everything is back to normal now, but was wondering if this is a fact of enabling mls qos on a switch...
05-20-2008 09:14 AM
If you've implemented QoS anywhere in the network and this switch is part of the transit path, enabling mls qos can cause problems if the packet classification isn't the same as the QoS implemented in the other switches.
With QoS disabled in this switch, it will forward the packets as is without applying any QoS tags while if you enable QoS, packet tagging will take place.
HTH,
__
Edison.
05-20-2008 09:19 AM
this is what I have as far as mls qos in my configs:
SW1:
mls ip multicast flow-stat-timer 9
mls aging fast time 16
mls aging long 64
mls aging normal 64
mls flow ip full
no mls flow ipv6
mls nde sender version 5
mls qos
no mls acl tcam share-global
mls cef error action freeze
SW2:
mls ip multicast flow-stat-timer 9
mls aging fast time 16
mls aging long 64
mls aging normal 64
mls flow ip interface-full
no mls flow ipv6
mls nde sender version 5
no mls acl tcam share-global
mls cef error action freeze
Im not sure what most of theses are for, im just starting to look into this now.
05-20-2008 09:17 AM
When you enable MLS QOS globally on a switch, it changes the way all ports on that switch trust cos/dscp.
The switch also changes the queues and how they're used. Without mls qos, all queue RAM is allocated to queue 1 and all cos values map to queue 1 (gigabit interfaces); and all 10/100 interfaces cos values map to queue 1 and use one of the eight minimum-reserve buffers which have a maximum packet size of 100.
Enabling mls qos, by default, causes gigabit interfaces to have 4 queues available, and cos is mapped to one of the four queues as follows: Q1=cos0,1; Q2=cos2,3; Q3=cos4,5; Q4=cos6,7.
(also mapped the same for 10/100 interfaces)
If this SW1 was a very utilized switch with decent traffic and resource utilization, it could have created a minor delay in communication when it had to run processes to begin forwarding the traffic to specific queues based on cos, depending on other switches connected to it.
Without mls qos enabled, the switch passes through all packets, regardless of cos/dscp setting.
When you enable mls qos, the switch sets all egress traffic to dscp 0/cos 0. (not trusted)
Please see the following link for more info:
05-20-2008 09:37 AM
so this means, enabling mls qos on SW2 will ultimately do the same thing?
All this, after TAC telling me this would not affect anything on the network if enabling mll qos...
05-20-2008 10:14 AM
apart from this, I also have Voip phones.
The IP Phones are actually on 3560's connected to the SW1-2-3.
The IP Phones are actually not Cisco, but Mitel.
The Phones are set to COS 6.
What is this config (on earlier message) doing to the packets coming from the phone on Vlan 108? if anything at all.
PC's connected to phones are on Vlan 104.
the ports on the 3560's that have phones and a pc connected to the phone are setup as trunkport native vlan 104.
I want to make sure that voice packets have priority, how can this be done?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide