[nsp] Weird Problem - 6509 rate limiting
Paul Stewart
pauls at nexicom.net
Wed Mar 17 11:29:21 EST 2004
Tried something different in the meantime and it didn't work.... Can anyone
tell me (my apologies if this was already answered and I missed it).... Why
are the counters not increasing on the rate-limit itself?
Output:
interface FastEthernet4/3
ip address xxx.xxx.xxx.xxx 255.255.255.252
rate-limit input 64000 15000 15000 conform-action transmit exceed-action
drop
rate-limit output 64000 15000 15000 conform-action transmit exceed-action
drop no cdp enable
FastEthernet4/3 is up, line protocol is up (connected)
Hardware is C6k 100Mb 802.3, address is 00d0.047f.cc0a (bia
00d0.047f.cc0a)
Internet address is xxx.xxx.xxx.xxx/30
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:03:16
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
L2 Switched: ucast: 82 pkt, 2296 bytes - mcast: 0 pkt, 0 bytes
L3 in Switched: ucast: 1920 pkt, 1855245 bytes - mcast: 0 pkt, 0 bytes
mcast
L3 out Switched: ucast: 1458 pkt, 608915 bytes
1952 packets input, 1892552 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
1502 packets output, 637676 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
gw-cust-nrtco#sh interfaces FastEthernet 4/3 rate-limit
FastEthernet4/3
Input
matches: all traffic
params: 64000 bps, 15000 limit, 15000 extended limit
conformed 0 packets, 0 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 87754136ms ago, current burst: 0 bytes
last cleared 00:04:09 ago, conformed 0 bps, exceeded 0 bps
Output
matches: all traffic
params: 64000 bps, 15000 limit, 15000 extended limit
conformed 49 packets, 5488 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 4880ms ago, current burst: 0 bytes
last cleared 00:04:09 ago, conformed 0 bps, exceeded 0 bps
-----Original Message-----
From: Ian Cox [mailto:icox at cisco.com]
Sent: Wednesday, March 17, 2004 11:01 AM
To: Paul Stewart; cisco-nsp at puck.nether.net
Cc: 'Jay Greenberg'
Subject: RE: [nsp] Weird Problem - 6509 rate limiting
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