[nsp] Weird Problem - 6509 rate limiting
Ian Cox
icox at cisco.com
Wed Mar 17 11:35:51 EST 2004
rate-limit only effects traffic that is software switched. There is very
little traffic that gets software switched on a Cat6k platform (normally it
is just exception packets). That is why it is not working. In newer
software, we removed the ability to configure "rate-limit" make this fact
more obvious.
Ian
At 11:29 AM 3/17/2004 -0500, Paul Stewart wrote:
>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