Common QOS configurations for a WAN link using MQC

Document

Dec 24, 2009 5:07 AM
Dec 24th, 2009

Technical background:

Qaulity Of Service (QOS) become a crucial service and feature in the modern IP networks specially with the implementations of VOIP and video over IP networks. QOS works as the gear of the modern networks because it mark/remark traffic ( classifications) reserve and prioritize some sort of traffic over others ( queuing) and in case of congestion it is able to start drop less important traffic based on classifications before the important traffic ( Weighted random early detection WRED). All the above features and services can be implemented and deployed to achieve what is know as end-to-end QOS network. with this approach we can grantee to a large extent that our sensitve traffic such as voice and video is guaranteed and prioritized over none sensitive traffic ( none real time ) such as web traffic and FTP.

In addition to the congestion management and congestion avoidance mechanisms mentioned above QOC can be used for security and/or rate limiting to make sure that the traffic going over the WAN link is not over subscribing the actual WAN link bandwidth and not over utilized, by policing or shaping the traffic going out that WAN interface, also we can deploy the policing and shaping to limit some traffic to certain amount of bandwidth which is useful also to have some level of security, for example we may use it to limit the management traffic such as telnet or SNMP traffic distend to the WAN router or any other device in the network.

Cisco IOS has several ways and mechanisms that can be used to implement and configure QOS, one of the best and commonly used method now is Modular Quality of service Command-Line MQC

Inthis document we will discuss a configuration example of how to use and configure MQC to meet a businesses requirements example, also we will see how to achieve the same goal by using more than one method

QOS Requirements:

company xyz.com has a WAN link between the HQ office and a branch office the WAN link bandwidth is 1Mbps

the comapny run VOIP traffic over this WAN link with the following marking:

VOIP RTP DSCP EF

VOIP Signaling CS3

VOIP RTP traffic must be serviced first in the case of interface congestion and guaranteed and limited at all times to 30 % of the WAN interface bandwidth

VOIP Signaling need a guaranteed bandwidth of 8 % of the interface in case of congestion

Telnet traffic need 3 % to be guaranteed in case of  congestion

However telnet traffic to a host with the IP address 130.1.1.1 needs 5 % of the interface bandwidth to be guaranteed in the case of congestion

Routing traffic:

if there are 30 packets in the queue with CS 6 ( routing traffic ) the router has to start drop from these packets, if the packets reach 40, a 25 % of the packets must be dropped,  if it go beyond 40 packet all the packet with CS 6 must be dropped

Configurations:

to achieve the above requirements we need first to identify our traffic classes this will be done by using class maps

access-list 100 permit tcp any host 130.1.1.1 eq telnet

this ACL used to match Telnet traffic going to the host 130.1.1.1 as required to have differnt QOS treatment than other tenet traffic

class-map match-all VOIP_SIG
match  dscp cs3
class-map match-all TELNET
match protocol telnet
class-map match-all RTP_VOIP
match ip dscp ef
class-map match-all TELNET_HOST130
match access-group 100

as it shown above we matched the traffic based on the specified requirements above ( for end to end QOS you need to make sue that your end point or the switch send the traffic with the appropriate DSCP marking or you can use port numbers to match traffic with ACLs)

after we have our traffic class maps created now we need to create a policy to give the traffic the required bandwidth and QOS treatment in the case of interface congestion, this will be achieved by using policy maps:

But before we see the configurations of the policy map lets review the VOIP RTP requirement above, the requirement need VOIP traffic to have a prioritization and traffic guaranteed as 30 % of the WAN link bandwidth and also at all times

this imply that we need to give a guaranteed bandwidth of 30 % from the 1Mbps and also this need to be serviced first in the case of congestion

this can be archived by using low latency queuing mechanism LLQ, but LLQ will NOT police or limit this class bandwidth in the case of NO congestion.

to limit the VOIP RTP traffic at all times to 30 % of the WAN link we can use a nested policy map under the class map configuration this is also called Hierarchal Quality of service HQOS

policy-map VOIP
class class-default
  police cir 300000     --- 1Mb = 100000 x 0.3 = 300000 bps

for the routing traffic

the requirements:

routing traffic by default marked as CS 6 and as stated in the requirements above traffic with CS 6 need to be configured with WRED

please note that WRED to be configured under class default or any cither class you need to configure either bandwidth command or enable fair queuing for that class

min CS 6 queue dropping threshold 30  max 40   dropping probability 25 % = 1/4

class class-default
fair-queue
random-detect
random-detect precedence 6   30    40    4

the outbound policy config:

policy-map P1
class RTP_VOIP
  priority percent 30
  service-policy VOIP
class VOIP_SIG
  bandwidth percent 8
class TELNET_HOST130
  bandwidth percent 5
class TELNET
  bandwidth percent 3
class class-default
  fair-queue
  random-detect
  random-detect precedence 6   30    40    4

now we nned to apply the above policy map under the WAN interface in the OUTBOUND direction

interface FastEthernet1/0

service-policy output P1

verification:

WAN_rtr#show policy-map interface fastEthernet 1/0
FastEthernet1/0

  Service-policy output: P1

    Class-map: RTP_VOIP (match-all)
      4 packets, 456 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp ef (46)
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 30 (%)
        Bandwidth 30000 (kbps)
Burst 750000 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

      Service-policy : VOIP

        Class-map: class-default (match-any)
          4 packets, 456 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any
          police:
              cir 300000 bps, bc 9375 bytes
            conformed 4 packets, 456 bytes; actions:
              transmit
            exceeded 0 packets, 0 bytes; actions:
              drop
            conformed 0 bps, exceed 0 bps

    Class-map: VOIP_SIG (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match:  dscp cs3 (24)
      Queueing
        Output Queue: Conversation 265
        Bandwidth 8 (%)
        Bandwidth 8000 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: TELNET_HOST130 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 100
      Queueing
        Output Queue: Conversation 266
        Bandwidth 5 (%)
        Bandwidth 5000 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: TELNET (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol telnet
      Queueing
        Output Queue: Conversation 267
        Bandwidth 3 (%)
        Bandwidth 3000 (kbps
)
Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any)
      375 packets, 37786 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 256
        (total queued/total drops/no-buffer drops) 0/0/0
         exponential weight: 9

  class    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
      0     347/34921           0/0              0/0           20      40  1/10
      1       0/0               0/0              0/0           22      40  1/10
      2       0/0               0/0              0/0           24      40  1/10
      3       0/0               0/0              0/0           26      40  1/10
      4       0/0               0/0              0/0           28      40  1/10
      5       0/0               0/0              0/0           30      40  1/10
      6       0/0               0/0              0/0           30      40  1/4
      7       0/0               0/0              0/0           34      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10


as it obvious from the above show command we have the bandwidth allocated incorrectly by our policy map !!!

for example the VOIP allocated under the LLQ calss 30000 Kbps which is 30 Mbps while it supposed to be 300 Kbps

same for other classes !!

this is because we are using the default interface bandwidth in our case fastethernet with 100Mbos and the policy map reference the interface bandwidth to allocate the bandwidth and also to consider the interface congested or not,

lets change the interface bandwidth to 1 M bps and see the difference

interface FastEthernet1/0
bandwidth 1000

WAN_rtr#show policy-map interface fastEthernet 1/0
FastEthernet1/0

  Service-policy output: P1

    Class-map: RTP_VOIP (match-all)
      1569 packets, 1051356 bytes
      5 minute offered rate 5000 bps, drop rate 0 bps
      Match: ip dscp ef (46)
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 30 (%)
        Bandwidth 300 (kbps)
Burst 7500 (Bytes)
        (pkts matched/bytes matched) 3/402
        (total drops/bytes drops) 0/0

      Service-policy : VOIP

        Class-map: class-default (match-any)
          1569 packets, 1051356 bytes
          5 minute offered rate 5000 bps, drop rate 0 bps
          Match: any
          police:
              cir 300000 bps, bc 9375 bytes
            conformed 1011 packets, 318144 bytes; actions:
              transmit
            exceeded 558 packets, 733212 bytes; actions:
              drop
            conformed 0 bps, exceed 0 bps

    Class-map: VOIP_SIG (match-all)
      30 packets, 3420 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match:  dscp cs3 (24)
      Queueing
        Output Queue: Conversation 265
        Bandwidth 8 (%)
        Bandwidth 80 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: TELNET_HOST130 (match-all)
      23 packets, 1283 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 100
      Queueing
        Output Queue: Conversation 266
        Bandwidth 5 (%)
        Bandwidth 50 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: TELNET (match-all)
      22 packets, 1229 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol telnet
      Queueing
        Output Queue: Conversation 267
        Bandwidth 3 (%)
        Bandwidth 30 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any)
      899 packets, 323243 bytes
      5 minute offered rate 2000 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 256
        (total queued/total drops/no-buffer drops) 0/0/0
         exponential weight: 9

  class    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
      0      55/5653            0/0              0/0           20      40  1/10
      1       0/0               0/0              0/0           22      40  1/10
      2       0/0               0/0              0/0           24      40  1/10
      3       0/0               0/0              0/0           26      40  1/10
      4       0/0               0/0              0/0           28      40  1/10
      5       0/0               0/0              0/0           30      40  1/10
      6     428/275592          0/0              0/0           30      40  1/4
      7       0/0               0/0              0/0           34      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10


now everything is working as expected and the bandwidth allocation is as required

now lets remove our policy map P1 also we put the bandwidth of the Fa0/1 to tdefault vhe alue which is 100Mbps

int fa1/0

no service-policy output P1
no bandwidth 1000


we can achieve the same result as we did above but without changing the interface bandwidth, this time we will use HQOS with a shaper

we are going to create a parent policy and shape all traffic for that policy to 1Mb and then we apply our policy map P1 under it

policy-map P2
class class-default
  shape average 1000000
  service-policy P1


interface FastEthernet1/0
  service-policy output P2


verification:

WAN_rtr#show int fa1/0 | include BW
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

WAN_rtr#show policy-map interface fastEthernet 1/0
FastEthernet1/0

  Service-policy output: P2

    Class-map: class-default (match-any)
      218 packets, 238044 bytes
      5 minute offered rate 8000 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
          1000000/1000000   6250   25000     25000     25        3125

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         213       231474    24        31536     no

      Service-policy : P1

        Class-map: RTP_VOIP (match-all)
          102 packets, 134028 bytes
          5 minute offered rate 4000 bps, drop rate 0 bps
          Match: ip dscp ef (46)
          Queueing
            Strict Priority
            Output Queue: Conversation 72
            Bandwidth 30 (%)
            Bandwidth 300 (kbps)
Burst 7500 (Bytes)
            (pkts matched/bytes matched) 0/0
            (total drops/bytes drops) 0/0

          Service-policy : VOIP

            Class-map: class-default (match-any)
              102 packets, 134028 bytes
              5 minute offered rate 4000 bps, drop rate 0 bps
              Match: any
              police:
                  cir 300000 bps, bc 9375 bytes
                conformed 97 packets, 127458 bytes; actions:
                  transmit
                exceeded 5 packets, 6570 bytes; actions:
                  drop
                conformed 4000 bps, exceed 0 bps

        Class-map: VOIP_SIG (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match:  dscp cs3 (24)
      Queueing
        Output Queue: Conversation 73
        Bandwidth 8 (%)
        Bandwidth 80 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

        Class-map: TELNET_HOST130 (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: access-group 100
      Queueing
        Output Queue: Conversation 74
        Bandwidth 5 (%)
        Bandwidth 50 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

        Class-map: TELNET (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol telnet
      Queueing
        Output Queue: Conversation 75
        Bandwidth 3 (%)
        Bandwidth 30 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

        Class-map: class-default (match-any)
          116 packets, 104016 bytes
          5 minute offered rate 4000 bps, drop rate 0 bps
          Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 64
        (total queued/total drops/no-buffer drops) 0/0/0
         exponential weight: 9

  class    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
      0      40/4152            0/0              0/0           20      40  1/10
      1       0/0               0/0              0/0           22      40  1/10
      2       0/0               0/0              0/0           24      40  1/10
      3       0/0               0/0              0/0           26      40  1/10
      4       0/0               0/0              0/0           28      40  1/10
      5       0/0               0/0              0/0           30      40  1/10
      6      76/99864           0/0              0/0           30      40  1/4
      7       0/0               0/0              0/0           34      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10


Although the interface bandwidth is 100M but our policy now allocating bandwidth percentage based on 1M this is because it is a nested policy under a shaped policy with 1Mbp

Note:

I intended to put multiple ways of QOS configurations such as matching with and without ACL using a class map, shaping and policing to cover most of the common simple and standard methods used in configuring QOS

Thank you

Marwan Alshawi

Average Rating: 5 (3 ratings)

Comments

PATRICK GESCHWINDNER Thu, 09/02/2010 - 16:56

I see that in your second example you shaped the traffic first, but for my understanding this will shape all traffic including the RTP voip traffic. This will introduce unnecessary jitter and if your WAN link will not be able to handle the proposed 1Mbit, possibly drop VoIP packets. Shouldn't there be a priority queue for VoIP first and then shape the remaining BW??

Patrick

Marwan ALshawi Thu, 09/02/2010 - 17:24 (reply to PATRICK GESCHWINDNER)

With hierarchal QOS

There will be two QOS policies

The first policy used above t shape the entire link to the amount allocated to that interface

Lets say the interface 100Mb and you shape it to 10 Mb

This shaping is just to make sure you not seeding to the other end more traffic than the amount allocated to that interface otherwise this extra traffic will be dropped in the other end

One more important thing is that when you shape it to 10Mb and the interface get congested the QOS policy will get kicked and the policy maps will start prioritize traffic as configured

In other words the first policy just to shape the interface to the actual bandwidth

The second policy ( sub policy ) will be used for LLQ.. etc

PATRICK GESCHWINDNER Thu, 09/02/2010 - 19:02 (reply to Marwan ALshawi)

I understand absolutely what you are trying to do with this construct. I only want to clarify what happens when more traffic than the 10mb will arrive on that router. When you first shape all traffic and the shaper buffers the surplus traffic, all packets (incl voice) will be delayed to be transferred later. If the stream will continue at a higher input rate than 10mb, the shaper possibly will be exhausted and starts dropping packets. Because the shaper is first, all kinds of packets will be dropped before we look for the second policy, which only prioritizes the traffic which will make it through the shaper. How can you take the voice traffic out of the shaping process, so that we shape only data, because we should neither shape nor drop voip?

JosephDoherty Thu, 09/29/2011 - 02:54 (reply to PATRICK GESCHWINDNER)

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

What should happen is the shaper, for the packets it delays, should push them into the child policy's queues and also dequeue from those queues as it transmits packets.  If this is done, LLQ should be not be dropped if its traffic meets its bandwidth restraints regardless of other traffic's bandwidth offering.  In other words the parent policy's shaper should act much like a physical interface would with a bound single level CBWFQ policy.

However, reason I use the word should, I've seen some platform/IOS combinations, which support showing active flow queues, appear to indicate that a parent policy shaper might continue to maintain it's own set of queues in addition to the child policy queues.  Before HQF, CBWFQ embedded shapers, alone, acted like an interface's GTS actually queued using their own WFQ.  For these, it seemed child LLQ packets were delayed a little more than I thought they should be, here too, perhaps similar to an actual interface's FIFO TX ring queue that's has an attached CBWFQ policy.  The two differences being, the shaper using WFQ instead of FIFO and often the platform not allowing any adjustment to the shaper's WFQ overall queue limit or per flow queue limit.  Regardless, in practice, beyond perhaps a little more latency and jitter than expected, I've not seen it adversely impact end-to-end VoIP service requirements.

If you find a case where Cisco's actual implementation does adversely impact the service requirements of LLQ traffic, you can define a LLQ in the parent policy, bypassing the shaper, add an explicit policer to the parent LLQ and reduce the shaper's bandwidth allocation by the amount provided the parent's LLQ policer.  The disadvantage of this, unused LLQ bandwidth will not be available to the child policy traffic.

Robert Ho Fri, 11/16/2012 - 22:29 (reply to Marwan ALshawi)

So, is this the entire outout with the second option?

Basically, P2 will shape the outbound to 1Mbps, and P1 will handle QoS once congestion occurs.

policy-map P1

class RTP_VOIP

  priority percent 30

  service-policy VOIP

class VOIP_SIG

  bandwidth percent 8

class TELNET_HOST130

  bandwidth percent 5

class TELNET

  bandwidth percent 3

class class-default

  fair-queue

  random-detect

  random-detect precedence 6   30    40    4

!

policy-map P2

class class-default

  shape average 1000000

  service-policy P1

!

interface FastEthernet1/0

  service-policy output P2

!

JosephDoherty Sat, 11/17/2012 - 05:22 (reply to Robert Ho)

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Basically, what you have now is correct.  However, you might want to decrease the shaper's Tc.  It look like yours is an older version that defaults to 25 ms.  To support VoIP, I would recommends 10 ms.  This can be done (if supported by your IOS) by setting the shaper's 2nd parameter to 1/100 (?) of the first value.

Other "tweaks" you might consider: removing WRED from class-default (as you're already configured FQ), combining your 3 defined non-LLQ classes into one class with the bandwidth aggregated, using FQ in the other defined non-LLQ classes (feature only available in later HQF versions of IOS).

Robert Ho Mon, 11/19/2012 - 20:35 (reply to JosephDoherty)

This is the config that we are testing in the lab.

Basically, we are handed off a 12Mbps circuit from the carrier. Under congestion, SSH would be guaranteed 50% of the bandwidth. While FTP would get 50% of the remaining bandwidth (3Mbps), WWW would get 25% of the remaining bandwidth (1.5Mbps), and everything else would get 25% of the remaining bandwidth (1.5Mbps).

Does this look right? Thank you.

class-map match-any SSH

match protocol ssh

class-map match-any WWW

match protocol http

class-map match-any FTP

match protocol ftp

!

policy-map QOS-OUT

class SSH

  priority percent 50

class WWW

  bandwidth remaining percent 25

class FTP

  bandwidth remaining percent 50

class class-default

  bandwidth remaining percent 25

!

policy-map 12MBPS

class class-default

  shape average 12000000

  service-policy QOS-OUT

!

interface FastEthernet1/0

  service-policy output 12MBPS

!

JosephDoherty Tue, 11/20/2012 - 02:25 (reply to Robert Ho)

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

"Does this look right?"

Well, depends on what your goals are.  It should "guarantee" bandwidth as you describe.  That said, normally you only use LLQ for real-time traffic, which SSH really isn't.  (Also for SSH, it will match against SCP.  [Something I overlooked years ago in one of my production policies.])

You might find just placing all your traffic into a class-default using fair-queue might work as well or better than the policy you've defined.  (Depending on whether your version of IOS is pre-HQF, the shaper, alone, may use FQ.)

PS:

BTW, Cisco documentation is somewhat unclear whether all shapers include L2 overhead.  If your does not, you may need to shape 5 to 15% slower than nomimal bandwidth to allow for L2 overhead.

Robert Ho Mon, 11/26/2012 - 09:28 (reply to JosephDoherty)

it was a sample config with ssh, to simulate using a traffic generator and test the qos.

in the live environment, we adjusted the LLQ for sip, h323, etc ... and it works well!

aamercado Mon, 05/07/2012 - 22:07

What if you have subinterface off the FA and want to limit the bandwidth on the subint. For example:

Int fa 1/0.1

bandwidth 10000

Do you still keep the main interface FA1/0 with "no bandwidth" or put in either "bandwidth 10000" also. Thanks

Actions

Login or Register to take actions

This Document

Posted December 24, 2009 at 5:07 AM
Stats:
Comments:11 Avg. Rating:5
Views:19005 Contributors:6
Shares:0

Related Content

Documents Leaderboard

Rank Username Points
1 177
2 64
3 60
4 50
5 23
Rank Username Points
5
0