[nsp] Weird Problem - 6509 rate limiting

Ian Cox icox at cisco.com
Wed Mar 17 11:01:16 EST 2004


Supervisor 2 only supports input policing on an interface or vlan, and not 
output policing. (Supervisor 720 supports both input and output policing).

Yes you are on the right track with Supervisor 2. Another way to accomplish 
output policing (when only input policing is available) is like this 
(Besides upgrading to Supervisor 720):

If you have multiple uplinks then you will need to create a aggregate 
policer with "mls aggregate" and use that policer on all the uplinks.


[snip from Jan 2002]
Topology
========


   ---- Gig 9/2
                   --- Gig 9/4 Uplink
   ---- Gig 9/3


Gig 9/2 and 9/3 are customer facing interfaces and Gig 9/4 is the uplink to
the rest of the network. Customer attached to Gig 9/2 is to get 500000000 
in and
out, and customer attached to Gig 9/3 gets 10000000.


### Configuration

class-map match-all rate_uplink1
    match access-group name up_link1

class-map match-all rate_limit_2
    match access-group name in_intf2

class-map match-all rate_limit_1
    match access-group name in_intf1

class-map match-all rate_uplink2
    match access-group name up_link2
!
!
policy-map in_uplink
    class rate_uplink2
       police 10000000 312500 312500 conform-action transmit exceed-action
drop
    class rate_uplink1
       police 500000000 15625000 15625000 conform-action transmit
exceed-action drop

policy-map in_1
    class rate_limit_1
       police 500000000 312500 312500 conform-action transmit exceed-action
drop

policy-map in_2
    class rate_limit_2
       police 10000000 312500 312500 conform-action transmit exceed-action
drop


interface GigabitEthernet9/2
   mtu 9216
   ip address 10.1.1.1 255.255.255.0
   ip pim sparse-dense-mode
   service-policy input in_1
!
interface GigabitEthernet9/3
   mtu 9216
   ip address 10.1.2.1 255.255.255.0
   ip pim sparse-dense-mode
   service-policy input in_2
!
interface GigabitEthernet9/4
   mtu 9216
   ip address 7.50.4.1 255.255.255.0
   ip pim sparse-dense-mode
   service-policy input in_uplink



ip access-list extended in_intf1
   permit ip any any
!
ip access-list extended in_intf2
   permit ip any any
!
ip access-list extended up_link1
   permit ip any 10.1.1.0 0.0.0.255
!
ip access-list extended up_link2
   permit ip any 10.1.2.0 0.0.0.255


####
albury#sh mls qos ip
   QoS Summary [IP]:      (* - shared aggregates, Mod - switch module)

         Int Mod Dir  Class-map DSCP  AgId Trust
FlId   AgForward-Pk   AgPoliced-Pk
   --------------------------------------------------------------------------
-------
        Gi9/2  9  In
rate_limit    0    1   dscp    0              0             0
        Gi9/3  9  In
rate_limit    0    2   dscp    0              0             0
        Gi9/4  9  In
rate_uplin    0    3   dscp    0              0             0
        Gi9/4  9  In
rate_uplin    0    4   dscp    0              0             0

          All  1   -    Default    0    0*    No    0             45
       0
          All  9   -    Default    0    0*    No    0             36
       0
albury#


[end snip]


Ian


At 07:24 AM 3/17/2004 -0500, Paul Stewart wrote:
>Hmmmm....
>
>I've spent a lot of time researching this overnight and have some
>questions...  Thank you for all the answers (as much as I don't like some of
>them)
>
>One of the postings said that it can only be applied to an inbound
>interface?  These VLAN's are serving traffic out to customers so is this
>considered an outbound interface?  If that is true, does the police
>statement limit traffic in *both* directions?  I'm confused as to what
>defines an interface as an outbound or inbound interface... These VLAN's
>that I'm trying to find a way to limit bandwidth on obviously have
>inbound/outbound traffic on them.... Some serve traffic out to customers and
>one is our pipe to the outside world bringing traffic in (did I just answer
>my own question?)
>
>For example I have gotten to this point now:
>
>gw-cust-nrtco#sh mls qos ip Vlan205
>    [In] Policy map is PUC_Testing_Port-Inbound
>  QoS Summary [IP]:      (* - shared aggregates, Mod - switch module, F -
>install error)
>
>Int            Mod Dir Cl-map DSCP AgId Trust FlId   AgForward-Pk
>AgPoliced-Pk
>----------------------------------------------------------------------------
>----
>Vl205            1 I fiber256k  0    1   dscp    0              0
>0
>
>The policy-map is this:
>
>policy-map PUC_Testing_Port-Inbound
>   class fiber256k
>      police 256000 10000 10000 conform-action transmit exceed-action drop
>
>The map is fiber256k which looks like this:
>
>class-map match-all fiber256k
>   match access-group 105
>
>access-list 105 permit ip any any
>
>Interface:
>
>interface Vlan205
>  ip address 216.xxx.xxx.xxx 255.255.255.252
>  service-policy input PUC_Testing_Port-Inbound
>
>Am I heading in the right direction at all with this?  I have no way of
>testing this for quite some time unfortunately...
>
>When I try to apply a service-policy output PUC_Testing_Port-Outbound it
>gives me:
>
>gw-cust-nrtco(config-if)#service-policy output PUC_Testing_Port-Outbound
>QoS: Vlan205 doesn't support policy PUC_Testing_Port-Outbound for class
>fiber256k in Out direction
>
>Which kind of seems to bring me back to a problem again....
>
>I thought I had found a missing part in the config as I did *not* have mls
>qos vlan-based on the Ethernet interface but it doesn't appear to have made
>any difference...:(
>
>interface FastEthernet3/1
>  mls qos vlan-based
>  switchport
>  switchport trunk encapsulation isl
>  switchport trunk allowed vlan 2,50,99,200-205
>  switchport mode trunk
>  no cdp enable
>
>
>Failing that,
>
>There was a discussion about using several ethernet ports to "loop" the
>traffic at which point traffic policing could be applied (if I understood
>that correctly)... Anyone have a sample config for this?  We have lots of
>extra ports on the 10/100 card so if that's the best method to make this
>work I'm game to try it but need some help if someone could spare a few
>minutes :)
>
>Also, does the version of IOS that we are running play any relevance?  We
>are running c6sup22-jk2sv-mz.121-20.E2.bin ?  Is there any features in the
>12.2.x train, OR in perhaps different feature version that could help me?
>
>If we converted the chassis to hybrid catos/ios will this create the
>possibility to doing traffic limiting better?  I can convert the chassis but
>perfer the native ios if possible....
>
>Sorry for all the questions. I'm kinda desperate as I have to leave this
>site tomorrow morning so hoping to have this resolved before then... Wasn't
>planning on surprises...;)
>
>Thanks very much.. Appreciate everyone's help...
>
>Paul
>
>
>-----Original Message-----
>From: Ian Cox [mailto:icox at cisco.com]
>Sent: Tuesday, March 16, 2004 4:11 PM
>To: Paul Stewart; cisco-nsp at puck.nether.net
>Subject: Re: [nsp] Weird Problem - 6509 rate limiting
>
>
>
>"match any" is not supported. You have to create at ip access list with
>match ip any any to do what you want to do.
>
>
>Ian
>
>At 11:30 AM 3/16/2004 -0500, Paul Stewart wrote:
> >I'm hoping someone has come across this or that I've done something
> >stupid...;)
> >
> >We have installed a 6509 at a remote site today.  It's a really simple
> >setup.. 2 sup2/msfc2 engines, 1 10/100 card.
> >
> >Port 3/1 has some vlan's on it to customers and also one of the vlan's
> >is a p2p lan extension to our core router at another location.
> >Everything is working fine on the device, vlan's are up and passing
> >traffic, switchports are up etc. etc..
> >
> >Our problem is with rate limiting the vlan's.  Traditionally I have
> >used "rate-limit input xxxxx" on each vlan to limit them to their
> >amount of bandwidth purchased.  The old 3662 router did this just fine
> >as a subinterface on the FastE
> >
> >Things are a little different on the 6509 as the rate-limit command
> >isn't supported (even though it shows up on a command).  When trying to
> >use  it I
> >get:
> >
> >Rate-limit command is not supported in hardware  use service-policy
> >command
> >
> >This 6509 is running native ios version 12.1(20)E2
> >(c6sup22-jk2sv-mz.121-20.E2.bin)
> >
> >Why is it not supported by the hardware??
> >
> >So, I try creating a service-policy:
> >
> >class-map match-all fiber_customers
> >   match any
> >
> >policy-map PUC
> >   class fiber_customers
> >      police 1000000 15000 15000 conform-action transmit exceed-action
> >drop
> >
> >gw-cust-nrtco(config-if)#service-policy input PUC
> >QoS: match type in class fiber_customers not supported on Vlan106
> >QoS: policy PUC actions for class fiber_customers are not supported on
> >Vlan106
> >QoS: match type in class fiber_customers not supported on Vlan106
> >QoS: match type in class fiber_customers not supported on Vlan106
> >
> >
> >
> >Can anyone help?
> >
> >gw-cust-nrtco#sh mls qos
> >   QoS is enabled globally
> >   Microflow policing is enabled globally
> >Vlan or Portchannel(Multi-Earl) policies supported: Yes
> >
> >
> >  ----- Module [1] -----
> >   QoS global counters:
> >     Total packets: 40374
> >     IP shortcut packets: 0
> >     Packets dropped by policing: 0
> >     IP packets with TOS changed by policing: 104
> >     IP packets with COS changed by policing: 0
> >     Non-IP packets with COS changed by policing: 0
> >
> >Thanks in advance,
> >
> >Paul
> >
> >_______________________________________________
> >cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/cisco-nsp
> >archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list