Sep
11

People are often confused with per-VLAN classification, policing and marking features in the Catalyst 3550 and 3560 models. The biggest problem is lack of comprehensive examples in the Documentation CD. Let's quickly review and compare traffic policing features available on both platforms. The material below is a condensed excerpt of several Catalyst QoS topics covered in the “QoS” section of our IEWB VOL1 V5. You will find more in-depth explanations and large number of simulation-based verifications in the upcoming section of the workbook.

Per-Port QoS ACL based classification in the 3550 and 3560

This feature works the same in both switches. Even though it is common to see this method named as “QoS ACLs” classification, it actually uses MQC syntax with class-maps and policy-maps. The term “QoS ACL” comes from the Catalyst OS PFC-based QoS model where you apply QoS ACLs directly to ports. In IOS-based switches, you use the familiar MQC syntax.

Look at the following example. Here we mark IPX packets (classified based on SNAP Protocol ID) with CoS value of 5, ICMP packets with IP Precedence 2 and ICMP packets with DSCP value of 24 (CS3). All remaining traffic, be it IP or non-IP, matches class-default and the system trusts the CoS values in the frame header. If a packet matches “class-default” but has no CoS value in the header, the system uses the default value from the interface, specified with mls qos cos 1

Example 1:

!
! Access-Lists. IPX SNAP Protocol ID is 0x8137
!
mac access-list extended IPX
permit any any 0x8137 0x0
!
ip access-list extended ICMP
permit icmp any any
!
ip access-list extended TELNET
permit tcp any any eq telnet
permit tcp any eq telnet any

!
! Class Maps
!
class-map match-all TELNET
match access-group name TELNET
!
class-map match-all ICMP
match access-group name ICMP
!
class-map match-all IPX
match access-group name IPX

!
! Note that we set DSCP under non-IP traffic class. The switch computes
! the respective CoS value using DSCP-to-CoS table.
!
policy-map CLASSIFY
class IPX
set dscp ef
class ICMP
set dscp cs3
class TELNET
set precedence 2
class class-default
trust cos

!
! Apply the policy
!
interface FastEthernet 0/6
mls qos cos 1
service-policy input CLASSIFY

Note the use of set dscp command on non-IP packet. You cannot set CoS value directly, with one special case for the 3550 switches. Therefore, you should use the command set dscp for both IP and non-IP packets if you want to change the CoS field.

You may apply the same policy in the 3550 models, but with one special limitation. The “class-default” should be split into two user-defined classes matching IP and non-IP traffic. I never seen "class-default" working properly in the 3550 models, so if you have a working example with verifications, please let me know :). Here is a workaround, that shows how to police both IP and non-IP traffic simultaneously in the 3550 model:

Example 2:

!
! All IP traffic
!
ip access-list standard IP_ANY
permit any
!
! All non-IP traffic
!
mac access-list extended MAC_ANY
permit any any 0x0 0xFFFF
!
class-map IP_ANY
match access-group name IP_ANY
!
class-map MAC_ANY
match access-group name MAC_ANY
!
mls qos aggregate-policer AGG256 256000 32000 exceed-action drop
!
policy-map AGGREGATE_LIMIT
class IP_ANY
police aggregate AGG256
class MAC_ANY
police aggregate AGG256

Per-Port Per-VLAN Classification in the 3550 switches

This feature is unique to the 3550 switches. You may configure traffic classification that takes in account VLAN for input traffic. Unfortunately, you can only apply it at a port-level. There is no option to classify the traffic entering VLANs on any port using a single policy, like there is in the 3560 model. Note that you can apply per-port per-VLAN policy on a trunk or an access port. Of course, in this case the access port must be in a VLAN matched by the policy-map. Here is an example of per-VLAN classification and marking in the 3550 models. What it does, is sets different DSCP and CoS values for IPX and ICMP packets coming from VLAN146 only. Other VLANs on a trunk port will remain intact.

Example 3:

mls qos
!
! Acess-Lists
!
ip access-list extended ICMP
permit icmp any any
!
mac access-list extended IPX
permit any any 0x8137 0x0

!
! Second-level class-maps
!
class-map ICMP
match access-group name ICMP
!
class-map IPX
match access-group name IPX

!
! First-level class-maps
!
class-map VLAN_146_ICMP
match vlan 146
match class-map ICMP
!
class-map VLAN_146_IPX
match vlan 146
match class-map IPX

!
! Policy-maps. Note that we set DSCP for IPX packets
! In fact, this is the internal DSCP value, not the IP DSCP.
! You cannot set CoS directly – only when trusting DSCP.
! DSCP 16 translates to CoS 2 by the virtue of the
! default DSCP-to-CoS table.
!
policy-map PER_PORT_PER_VLAN
class VLAN_146_ICMP
set dscp CS3
class VLAN_146_IPX
set dscp 16

!
! Apply the policy-map
!
interface FastEthernet 0/4
service-policy input PER_PORT_PER_VLAN

Note the special syntax used by this features. All classes in the policy-map must use match vlan statement on their first line and match another class in their second line. The second-level class-map should use only one statement, e.g. match access-group name. The access-group itself may have variable number of entries.

Per-Port Per-VLAN Policing in the 3550

The following example is just a demonstration of applying policing inside VLAN-based policy-map in the 3550. This feature is a regular policer, just the same you can use in a per-port policy-map. You can either drop packet or re-mark the internal DSCP. With the 3550 it is even possible to use aggregate policer shared between several VLANs on a single port.

The example remarks IP traffic exceeding the rate of 128Kbps with DSCP value of CS1. Prior to metering, the policy map marks traffic with AF11. The policy map marks non-IP traffic with a CoS value of three, and drops packets that exceed 256Kbps. All classification and policing procedures apply only to packets in VLAN146.

Example 4:

mls qos
mls qos map policed-dscp 10 to 8

!
! Acess-Lists
!
ip access-list extended IP_ANY
permit IP any any
!
mac access-list extended NON_IP_ANY
permit any any 0x0 0xFFFF

!
! Second-level class-maps
!
class-map IP_ANY
match access-group name IP_ANY
!
class-map NON_IP_ANY
match access-group name NON_IP_ANY

!
! First-level class-maps
!
class-map VLAN_146_IP
match vlan 146
match class-map IP_ANY
!
class-map VLAN_146_NON_IP
match vlan 146
match class-map NON_IP_ANY

!
! Since we are not limited, we use any burst values
! Policy map matches first-level class-maps
!
policy-map POLICE_PER_PORT_PER_VLAN
class VLAN_146_IP
set dscp af11
police 128000 16000 exceed-action policed-dscp-transmit
class VLAN_146_NON_IP
set dscp cs3
police 256000 32000

!
! Apply the policy-map
!
interface FastEthernet 0/4
service-policy input POLICE_PER_PORT_PER_VLAN

Per-VLAN Classification in the 3560

Switch-wide per-VLAN classification is feature specific to the 3560. You can apply a service-policy to SVI, listing class-map and respective mark actions in the policy-map. Note that you cannot usethe police command in a service-policy applied to SVI. All packets in the respective VLAN entering the switch on the ports enabled for VLAN-based QoS are subject to inspection by service-policy on the SVI. The effect is that QoS marking policy is now switch-wide on all ports (trunks or access) having the respective VLAN activated (allowed and STP forwarding state).

The following example sets DSCP EF in the TCP packets entering VLAN146 and CoS 4 in the IPX packet transiting the switch across VLAN 146. Note that all ports with VLAN146 that are configured for VLAN QoS will be affected by this configuration.

Example 5:

mls qos
!
! Enable VLAN-based QoS on interfaces
!
interface FastEthernet 0/1
mls qos vlan-based

!
! Enable VLAN-based QoS on the trunks
!
interface range FastEthernet 0/13 - 21
mls qos vlan-based

!
! Access-Lists
!
ip access-list extended TCP
permit tcp any any
!
mac access-list extended IPX
permit any any 0x8137 0x0

!
! First-level class-maps
!
class-map TCP
match access-group name TCP
!
class-map IPX
match access-group name IPX

!
! VLAN-based policy-map
!
policy-map PER_VLAN
class TCP
set dscp ef
class IPX
set dscp 32

!
! Apply the policy-map to SVI
!
interface VLAN 146
service-policy input PER_VLAN

As mentioned above, you cannot use policing in SVI-level policy map. This eliminates the possibility of having policer aggregating traffic rates for all ports in a single VLAN. However, you can still police per-port per-VLAN in the 3560 using the following feature.

Per-Port Per-VLAN Policing in the 3560

This feature uses second-level policy-maps. The second-level policy-map must list class-maps satisfying specific restrictions. The only “match” criterion supported in those class-maps is match input-interface. You can list several interfaces separated by spaces, or use interface ranges, separating interfaces in a range by hyphen. The only action supported in the second-level policy-map is the police command. As usual, you can drop exceeding traffic or configure traffic remarking using policed DSCP map. The police action applies individually to every port in the range.

You cannot use aggregate policers in the second-level policy-maps. Another restriction – if you apply a second-level policy-map (interface-level map) inside “class-default” it will have no effect. You need to apply the second-level policy-map inside user-defined classes.

The following example restricts IP traffic rate in VLAN146 on every trunk port to 128Kbps and limits the IP traffic in VLAN146 on the port connected to R6 to 256Kbps.

Example 6:

mls qos map policed-dscp 18 to 8

!
! For 2nd level policy you can only match input interfaces
!
class-map TRUNKS
match input-interface FastEthernet 0/13 - FastEthernet 0/21

!
! The second class-map matches a group of ports or a single port
!
class-map PORT_TO_R6
match input-interface FastEthernet 0/6

!
! IP traffic: ACL and class-map
!
ip access-list extended IP_ANY
permit ip any any
!
class-map IP_ANY
match access-group name IP_ANY

!
! Second-level policy-map may only police, but not mark
!
policy-map INTERFACE_POLICY
class TRUNKS
police 128000 16000 exceed policed-dscp-transmit
class PORT_TO_R6
police 256000 32000

!
! 1st level policy-map may only mark, not police
! VAN aggregate policing is not possible in the 3560
!
policy-map VLAN_POLICY
class IP_ANY
set dscp af21
service-policy INTERFACE_POLICY
!
interface Vlan 146
service-policy input VLAN_POLICY

!
! Enable VLAN-based QoS on the ports
!
interface FastEthernet 0/6
mls qos vlan-based

!
! Enable VLAN-based QoS
!
interface range FastEthernet 0/13 - 21
mls qos vlan-based

This is it for the comparison of most common policing features on the 3550 and 3560 platforms. Digging deeper in the areas of Catalyst QoS would probably takes us far beyond the size of a post the a normal human can read :)

Mar
03

The 3560 QoS processing model is tightly coupled with it’s hardware architecture borrowed from the 3750 series switches. The most notable feature is the internal switch ring, which is used for the switch stacking purpose. Packets entering a 3560/3750 switch are queued and serviced twice: first on the ingress, before they are put on the internal ring, and second on the egress port, where they have been delivered by the internal ring switching. In short, the process looks as follows:

[Classify/Police/Mark] -> [Ingress Queues] -> [Internal Ring] -> [Egress Queues]

For more insights and detailed overview of StackWise technology used by the 3750 models, visit the following link:

Cisco StackWise Technology White Paper

Next, it should be noted that the 3560 model is capable of recognizing and processing IPv6 pacekts natively – this feature affects some classification options. Another big difference is the absence of internal DSCP value and the use of QoS label for internal packet marking. This feature allows the 3560 switches to provide different classes of services to CoS or DSCP marked packets, by allowing them to be mapped to different queues/thresholds etc. Many other concepts and commands are different as well, as is some nomenclature (e.g. the number of the priority queue). We will try to summarize and analyze the differences under the following paragraphs. The biggest obstacle is absence of any good information source on the 3750/3560 switches QoS, besides the Cisco Documentation site, which has really poor documents regarding both models.

1. Queue Scheduler: SRR

One significant change is replacement of WRR scheduler with SRR, where latter stands for either Shared Round Robin or Shaped Round Robin – which are two different modes of operation for the scheduler. As we remember, what WRR does is simply de-queue the number of packets proportional to the weight assigned to a queue walking through queues in round-robin fashion. SRR performs similar in shared more: each output queue has a weight value assigned, and is serviced in proportion to the assigned weight when interface is under congestion.

The implementation details are not documented to open public by Cisco; however, so far we know that Shared Round Robin tries to behave more “fairly” than WRR does. While on every scheduler round WRR empties each queue up to the maximum number of allowed packet, before switching to the next queue, SRR performs a series of quick runs each round, deciding on whether to de-queue a packet from the particular queue (based on queue weights). In effect, SRR achieves more “fairness” on per-round basis, because it does not take the whole allowed amount each time it visits a queue. On the “long run” SRR and WRR behave similarly.

The shaped mode of SRR is something not available with WRR at all. With this mode, each queue has weight that determines the maximum allowed transmission rate for a queue. That is, interface bandwidth is divided in proportions of queue weights, and each queue is not allowed to send packets above this “slice” of common bandwidth. The details of the implementation are not provided, so we can only assume it’s some kind of effective policing strategy. Pay special attention, that SRR weight values are *absolute*, not relative. That is, the proportion of interface bandwidth give to a particular queue is "1/weight*{interface speed}. So for a weight of "20" the limit is "1/20*Speed" and equals to 5Mbps with 100Mbps interface. Also, by default, queue 1 has SRR shaped weight 1/25, so take care when you turn MLS QoS on.

An interface could be configured for SRR shared and shaped mode at the same time. However, SRR shaped mode always take preference over SRR shared weights. Finally, SRR provides support for priority queue but this queue is not subject to SRR shaping limits as well. The weight assigned to the priority queue is simply ignored for SRR calculations. Note that unlike the 3550, on the 3560, egress priority queue has queue-id 1, not 4. Here is an example:

!
! By settings shape weight to zero we effectively disable shaping for the particular queue
!
interface gigabitethernet0/1
srr-queue bandwidth shape 10 0 0 0
srr-queue bandwidth share 10 10 60 20
!
! As expedite queue (queue-id 1) is enabled, it’s weight is no longer honored by the SRR scheduler
!
priority-queue out

Another interesting egress feature is port rate-limit. SRR could be configured to limit the total port bandwidth to a percentage of physical interface speed – from 10% to 90%. Don’t configure this feature if there is no need to limit overall port bandwidth.

!
! Limit the available egress bandwidth to 80% of interface speed
!
interface gigabitethernet0/1
srr-queue bandwidth limit 80

Note that the resulting port rate depends on the physical speed of the port - 10/100/1000Mbps.

2. Egress Queues

The 3550 has four egress queues identified by their numbers 1-4 available to every interface,. Queue number 4 could be configured as expedite. On the 3560 side, we have the same four egress queues, but this time for expedite services we could configure queue-id 1.

With the 3550, for “class-to-queue” mapping only CoS to queue-id table is available on a per-port basis. Globally configurable DSCP to CoS mapping table is used to map an internal DSCP value to the equivalent CoS. As for the 3560 model, DSCP and CoS values are mapped to queue-ids separately. That means IP and non-IP traffic could be mapped/serviced separately. What if an IP packet comes with DSCP and CoS values both set? Then the switch will use the marking used for classification (e.g. CoS if trust cos or set cos were used) to assign the packet to a queue/threshold.

The 3550 supports WTD and WRED as queue drop strategy (the latter option available on Gigabit ports only). The 3560 model supports WTD as the only drop strategy, allowing for three per-queue drop thresholds. Only two of the thresholds are configurable – called explicit drop thresholds - and the third one is fixed to mark the full queue state (implicit threshold).

Finally, the mentioned mappings are configured for queue-id and drop threshold simultaneously in global configuration mode - unlike the 3550 where you configured CoS to Queue-ID and DSCP to Drop-Threshold mappings separately (and on per-interface basis).

!
! CoS values are mapped to 4 queues. Remember queue-id 1 could be set as expedite
!

!
! The next entry maps CoS value 5 to queue 1 and threshold 3 (100%)
!
mls qos srr-queue output cos-map queue 1 threshold 3 5
!
! VoIP signaling and network management traffic go to queue 2
!
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0

!
! DSCP to queue/threshold mappings
!
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47

mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63

mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39

!
! DSCP 8 is CS1 – Scavenger class, mapped to the first threshold of the last queue
!
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7

Next, what we need to know is how to configure egress queue buffer spaces along with the threshold settings. With the 3550 we had two options: first, globally configurable buffer levels for FastEthernet ports, assigned per interface; second, one shared buffer pool for each of gigabit ports, with proportions (weights) configured on per-interface level too. With the 3560 things have been changed. Firstly, all ports are now symmetrical in their configurations. Secondly, a concept of queue-set has been introduced. A queue-set defines buffer space partition scheme as well as threshold levels for each of four queues. Only two queue-set are available in the system, and are configured globally. After a queue-set has been defined/redefined it could be applied to an interface. Of course, default queue-set configurations exist as well.

As usual, queue thresholds are defined in percentage of the allocated queue memory (buffer space). However, the 3560 switch introduced another buffer pooling model. There exist two buffer pools – reserved and common. Each interface has some buffer space allocated under the reserved pool. This reserved buffer space, allocated to an interface, could be partitioned between egress interface queues, by assigning a weight value (this resembles the gigabit interface buffer partitioning with the 3550):

!
! Queue-sets have different reserved pool partitioning schemes
! Each of four queues is given a weight value to allocate some reserved buffer space
!
mls qos queue-set output 1 buffers 10 10 26 54
mls qos queue-set output 2 buffers 16 6 17 61
!
interface gigabitEthernet 0/1
queue-set 1

What about the common buffer pool? Let’s take a look at the threshold setting command first:

mls qos queue-set output qset-id threshold queue-id drop-threshold1 drop-threshold2 reserved-threshold maximum-threshold

We see two explicitly configured thresholds 1 and 2 – just as with the 3550. However, there is one special threshold called reserved-threshold. What it does, is specifies how much of reserved buffer space is allocated to a queue – i.e. how much of reserved buffers are actually “reserved”. As we know, with the 3560 model every queue on every port has some memory allocated under reserved buffer pool. The reserved-threshold tells how much of this memory to allocate to a queue – from 1 to 100%. The unused amount of the reserved buffer space becomes available to over queues under the common buffer pool mentioned above. The common buffer pool could be used by any queue to borrow buffers above the queue’s reserved space. That allows to set drop-thresholds to values greater than 100%, meaning it’s allowable for queue to take more credit from common pool to satisfy it needs. The maximum-threshold specifies the “borrowing limit” – how much a queue is allowed to grow into the common pool.

Look at the command “mls qos queue-set output 1 threshold 1 138 138 92 138”. It says we shrink reserved buffer space for queue 1 to 92% sending the exceeding space to common pool. All the three drop-thresholds are set to 138% of the queue buffer space (allocated by buffer command), meaning we allow the queue to borrow from the common pool up to the levels specified. Drop thresholds may be set as large as 400% of the configured queue size.

Now we see that this model is a bit more complicated than it was with the 3550. We don’t know the actual sizes of reserved buffer pool, but we are allowed to specify the relative importance of each queue. Additionally, we may give up some reserved buffer space out to a common buffer pool to share with the other queues. Here is a detailed example from AutoQoS settings:

!
! Set thresholds for all four queues in queue-set 1
!
mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400

!
! Set thresholds for all four queues in queue-set 2
!
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242

interface gigabitEthernet 0/1
queue-set 1
!
interface gigabitEthernet 0/2
queue-set 2

An finally, if you are not sure what you’re doing, don’t play with thresholds and buffer space partitioning – leave the to the default values, or use AutoQoS recommendations. So says the DocCD!

3. Ingress Queues

The unique feature of the 3560 switches is possibility to configure two ingress queues on every port. Of these queues, you may configure any to be an expedite queue, with queue 2 being the default. The priority queue is guaranteed access to the internal ring when the ring is congested. SRR only serves the ingress queues in shared mode. All the weights are configured globally, not per-interface as it was with the egress queues:

!
! Disable the default priority queue and share the bandwidth on the ring in 1/4 proportion
!
mls qos srr-queue input priority-queue 2 bandwidth 0
mls qos srr-queue input bandwidth 25 75

The UniverCD has a very shallow description of how actually SRR algorithm serves the two queues, when one of them is configured as expedite. So far, it looks like that you should configure one queue as expedite, assign the priority bandwidth value to it (from 1 to 40% of the internal ring bandwidth), and also assign the bandwidth values to both of the ingress queues as usual:

mls qos srr-queue input priority-queue 1 bandwidth 10
mls qos srr-queue input bandwidth 50 50

What’s that supposed to mean? Seems like queue 1 is partially serviced as an expedite queue, up the limit set by priority-queue bandwidth. As this counter exhausts, it is then being served on par with the non-expedite queue, using the bandwidth weights assigned. With the example about that mean we have 10% of bandwidth dedicated to priority queue services. As soon as this counter exhausts (say on a per-round basis) SRR continues to service both ingress queues using the remaining bandwidth counter (90%) shared in the proportions of the weights assigned (50 & 50) – that means 45% of the ring bandwidth to each of the queues. Overall, it looks like SRR simulates a policer for priority queue, but rather than dropping the traffic it simply changes the scheduling mode, until enough credits are accumulated to start expedite services again. Now go figures how to use that in real life! Too bad Cisco does no give out to public any internal details on their SRR implementation.

Now, two things remain to consider for the ingress queues: class mappings to the queues, and buffer/threshold settings. The class mapping uses the same syntax as for the egress queues, allowing configuring global mapping of CoS and DSCP do queue-ids and thresholds.

!
! CoS to queue-id/threshold
!
mls qos srr-queue input cos-map queue 1 threshold 3 0
mls qos srr-queue input cos-map queue 1 threshold 2 1
mls qos srr-queue input cos-map queue 2 threshold 1 2
mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3 3 5

!
! DSCP to queue-id/threshold
!
mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue input dscp-map queue 1 threshold 3 32
mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47

As it seems reasonable, the classification option (CoS, DSCP) used determines that mapping table for ingress queue.

The buffer partitioning is pretty simple – there is no common pool, and you only specify the relative weight for every queue. Thresholds are also simplified – you configure just two too of them, in percentage of queue size. The third threshold is implicit, as usual.

!
! Thresholds are set to 8% and 16% for queue 1; 34% and 66% for queue-2
! Buffers are partitioned in 67/33 proportion
!
mls qos srr-queue input threshold 1 8 16
mls qos srr-queue input threshold 2 34 66
mls qos srr-queue input buffers 67 33

So far we covered enough for a single post. In the next post we will discuss how classification policing and marking techniques differ between the 3550 and 3560 models.

Subscribe to INE Blog Updates

New Blog Posts!