Rate limiting at vlan interface on Cat6509

Unanswered Question
Apr 1st, 2010

I would like to rate limit the users on vlan 2099 - it is for guest users.  I have already put a filter on that vlan to limit the protocols and it works fine.  The rate-limiting does not work at all. Can someone tell if I am missing something? vlan access-map Filter_Guest 10 match ip address Guest_WLAN_Restriction action forward ! vlan filter Filter_Guest vlan-list 2099 ip access-list extended Guest_WLAN_Restriction permit udp any any eq bootps permit udp any any eq bootpc permit udp any any eq domain permit tcp any any eq domain permit udp any any eq 80 permit tcp any any eq www permit tcp any any eq 443 deny  ip any any interface Vlan2099 description = Dilbert_Development ip address 10.128.254.254 255.255.255.0 ip helper-address 123.123.133.1 ip helper-address 123.123.32.1 rate-limit input access-group 175 64000 8000 8000 conform-action transmit exceed-action drop rate-limit output access-group 175 64000 8000 8000 conform-action transmit exceed-action drop

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (8 ratings)
Loading.
Lei Tian Thu, 04/01/2010 - 20:35

Hi,

CAR is the legacy way of doing rate limiting; have you try policy-map and policing instead?

HTH,

Lei Tian

tdennehy Fri, 04/02/2010 - 07:32

I did try a policy-map and policing and it did not work. I believe I had it misconfigured since I read something last night that leads me to that conclusion.

allan.thomas Fri, 04/02/2010 - 03:11

Hi,

The only aspect from your description that I see has no correlation to what you are attempting to limit is the access-group 175.  Under the rate-limit command you specify the match criteria as a specific access-group, do you have the ip access-list 175 configured as it does not appear within the information you have provided?

Regards

Allan.

tdennehy Fri, 04/02/2010 - 07:36

Allen,

I forgot to put that in the question.  The ACL is as follows:

access-list 175 permit ip any any

I must be missing something... because it just isn't working!

Thanks,

Tim

tdennehy Fri, 04/02/2010 - 08:29

I found this statement on this webpage:

"In order to enable CAR, you must enable Cisco Express Forwarding (CEF) on the box. In addition, you must configure a CEF-switched interface for CAR"

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_tech_not...

I want to enable it on an VLAN, since the machines are downstream and not directly connected to this 6509. The VLAN interface is on the 6509.

James Coyne Fri, 04/02/2010 - 08:45

ip access-list extended RATELIMIT
permit ip any any
!
class-map RATELIMIT
match access group RATELIMIT
!
policy-map RATELIMIT

class RATELIMIT
  police 64000 8000 8000 conform-action transmit exceed-action drop
!
int Vlan 2099
service-policy output RATELIMIT
service-policy input RATELIMIT

tdennehy Fri, 04/02/2010 - 09:31

Jim,

I tried that already. My policy is identical to yours, but I plugged yours in just in case I mistyped something. Your policy doesn't work either. I must be missing some other global command is all I can think.

Here's what I have below. I have a laptop on my desk on that vlan, IP is 10.128.254.152, and can hit the speed test site on the internet and has unrestricted downloads and uploads.

mls qos

!

class-map match-all identify_Guest_WLAN_Ratelimit

match access-group name Guest_WLAN_Ratelimit

class-map match-all RATELIMIT

match access-group name RATELIMIT

!

!

policy-map police-WLAN-Guest-traffic

class identify_Guest_WLAN_Ratelimit

police cir 64000 bc 8000 be 8000 conform-action transmit exceed-action drop violate-action drop

policy-map RATELIMIT

class RATELIMIT

police cir 64000 bc 8000 be 8000 conform-action transmit exceed-action drop violate-action drop

interface Vlan2099

description = Dilbert_Development

ip address 10.128.254.254 255.255.255.0

service-policy input RATELIMIT

service-policy output RATELIMIT

ip access-list extended Guest_WLAN_Ratelimit

permit ip any any

ip access-list extended RATELIMIT

permit ip any any

Thanks,

Tim

tdennehy Fri, 04/02/2010 - 10:29

CSFC6503#sh policy-map interface vlan 2099

Vlan2099

Service-policy input: RATELIMIT

class-map: RATELIMIT (match-all)

Match: access-group name RATELIMIT

police :

64000 bps 8000 limit 8000 extended limit

Earl in slot 5 :

0 bytes

5 minute offered rate 0 bps

aggregate-forwarded 0 bytes action: transmit

exceeded 0 bytes action: drop

aggregate-forward 0 bps exceed 0 bps

Class-map: class-default (match-any)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Service-policy output: RATELIMIT

class-map: RATELIMIT (match-all)

Match: access-group name RATELIMIT

police :

64000 bps 8000 limit 8000 extended limit

Earl in slot 5 :

5190 bytes

5 minute offered rate 0 bps

aggregate-forwarded 5190 bytes action: transmit

exceeded 0 bytes action: drop

aggregate-forward 0 bps exceed 0 bps

Class-map: class-default (match-any)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

allan.thomas Fri, 04/02/2010 - 09:55

Hi Tim,

I suspect that object criteria is falling into the class-default which is specifically for traffic that is not specifically classified.  As you have all one class which consist of essentially everything could you try configuring the policy-map as follows so that you only have the class class-default within it, and then try testing again:-

policy-map RATELIMIT

  class class-default

   police cir  64000 bc 8000 be 8000 conform-action transmit exceed-action drop  violate-action drop

interface Vlan2099

description =  Dilbert_Development

ip address 10.128.254.254 255.255.255.0

service-policy input RATELIMIT

service-policy output RATELIMIT

Could you post the show policy-map, and show interface policy-map command.

Thanks

Allan.

tdennehy Fri, 04/02/2010 - 11:05

Allen,

Here is what the config looks like now:

policy-map RATELIMIT

class class-default

police cir 64000 bc 8000 be 8000 conform-action transmit exceed-action drop violate-action drop

class-map match-all RATELIMIT

match access-group name RATELIMIT

ip access-list extended RATELIMIT

permit ip any any

interface Vlan2099

description = Dilbert_Development

ip address 10.128.254.254 255.255.255.0

service-policy input RATELIMIT

service-policy output RATELIMIT

CSFC6503#sho policy-map

Policy Map police-WLAN-Guest-traffic

Class identify_Guest_WLAN_Ratelimit

police cir 64000 bc 8000 be 8000 conform-action transmit exceed-action d

rop violate-action drop

Policy Map RATELIMIT

Class class-default

police cir 64000 bc 8000 be 8000 conform-action transmit exceed-action d

rop violate-action drop

CSFC6503#sh policy-map interface vlan 2099

Vlan2099

Service-policy input: RATELIMIT

class-map: class-default (match-any)

Match: any

police :

64000 bps 8000 limit 8000 extended limit

Earl in slot 5 :

0 bytes

5 minute offered rate 0 bps

aggregate-forwarded 0 bytes action: transmit

exceeded 0 bytes action: drop

aggregate-forward 0 bps exceed 0 bps

Service-policy output: RATELIMIT

class-map: class-default (match-any)

Match: any

police :

64000 bps 8000 limit 8000 extended limit

Earl in slot 5 :

602 bytes

5 minute offered rate 0 bps

aggregate-forwarded 602 bytes action: transmit

exceeded 0 bytes action: drop

aggregate-forward 0 bps exceed 0 bps

CSFC6503#

allan.thomas Fri, 04/02/2010 - 12:34

Hi Tim,

From the show policy-map interface vlan2099, the outbound service-policy appears to have bytes matched.  To specifically test whether the policed cir is working you could revise the policy so that the conform action is set to drop, this will ensure that any traffic matched which conforms within the CIR is dropped directly.

This would prove that the policy is working as desired and that the your testing is not exceeding the CIR.  I would also configure the access-list to be more explicit and configure it so initially only your testing IP host is configured to any, and any to your IP host.  The example I provided in my previous post simply negates the requirement to have a separate access-list to match-on as the class class-default provides the same catch-all.

Regards

Allan.

tdennehy Fri, 04/02/2010 - 12:39

Allan,

I have another box that I use for testing, and I applied the config to it and it works. The main difference is the machine I'm hitting the bandwidth server is on copper, plugged into a copper port on the 6509.

The box that isn't working is a user that enters the box through a vlan trunk. What are the odds that traffic entering through a trunk isn't supported?

I'm going to go prove my theory in a few minutes.

Thanks,

Tim

allan.thomas Fri, 04/02/2010 - 13:20

Hi Tim,

That shouldn't be a problem, if that is the case, then I assume that you have not configured the physical trunk interface on the 6500 for vlan based QoS?  If you haven't could add this command 'mls qos vlan-based' to the appropriate interface and try your tests again?

Regards

Allan.

tdennehy Fri, 04/02/2010 - 14:02

Allen,

I just plugged in to gig5/2 on this 6509, configured the port and hit the bandwidth test site from my laptop and was unrestricted.

Te policy did not do anything to my knowledge. There is a FWSM in this 6509 which all traffic default-routes to. That's vlan 30. Traffic comes out on vlan 31, then goes out of the box on port channel 10. I'm thinking the QoS has to be placed on the vlan before it leaves for vlan 30, the default gateway. The traffic comes in to vlan 3099 from a WiSM that is in this chassis. Of course vlan 3099 is trunked, and the traffic flows normally from the laptop when connected to the wlan which is mapped to vlan 3099.

Why that would break it is beyond me, but it might? I'm at a loss as to where I would place 'mls qos vlan-based'. Sorry for the headache you are about to get...

Thanks,

Tim

firewall module 9 vlan-group 1

firewall vlan-group 1 30,31

!

vlan 30

name inside_fwsm

!

vlan 31

name outside_fwsm

!

!

interface Port-channel10

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 31

switchport mode trunk

mtu 9216

no ip address

load-interval 30

!

mls qos

no mls flow ip

no mls acl tcam share-global

mls ip multicast flow-stat-timer 9

mls cef error action freeze

!

vlan 3099

name ELL_Dilbert_Development

!

class-map match-all RATELIMIT

match access-group name RATELIMIT

policy-map RATELIMIT

class RATELIMIT

police cir 64000000 bc 32000 be 32000 conform-action transmit exceed-action drop violate-action drop

interface GigabitEthernet5/2

switchport

switchport access vlan 3099

switchport mode access

no ip address

media-type rj45

!

interface Vlan3099

description = Dilbert_Development

ip address 10.130.254.254 255.255.255.0

ip helper-address 129.237.133.1

ip helper-address 129.237.32.1

service-policy input RATELIMIT

service-policy output RATELIMIT

!

ip access-list extended RATELIMIT

permit ip any any

allan.thomas Fri, 04/02/2010 - 14:31

Hi Tim,

I think essentially as you are concerned with limiting traffic from the WiSM coming in on interface GigabitEthernet 5/2 within VLAN 3099, then this should be the inferace where you apply the 'mls qos vlan-based'.

Regards

Allan.

Hope this help, pls rate helpful posts.

tdennehy Fri, 04/02/2010 - 14:38

Allen,

The gig port 5/2 is a copper port that I plugged my laptop in and placed it in vlan 3099 to test. The policy didn't work when I was hard wired in. Gig port 5/2 is a user port, not a trunk port. The WiSM creates a dynamic trunk that cannot be modified, so I don't know how I would place a command on a trunk port that is created automagically.

The problem still exists - I can't even get the laptop on gig5/2 to get policed. I placed the port in vlan 3099 and it is not restricted at all. There must be some other global command that I'm missing, I guess.

Thanks,

Tim

Lei Tian Fri, 04/02/2010 - 15:29

Hi Tim,

As Allen suggested, apply vlan-based under the physical interfaces. For testing purpose, you can lower the policer's cir, so that is easier to see the result.  Also vlan-based might not work on intra-vlan traffic; if you want restrict traffic within the vlan you might need to use user based or microflow policing.

HTH,

Lei Tian

tdennehy Fri, 04/02/2010 - 16:02

My brain is full, so I'm going to have to pick this up on Monday.

Thanks for all your help so far.  You guys rock!

tdennehy Fri, 04/02/2010 - 16:04

How do I rate helpful posts, by the way?

And thanks for all your help today.  I'm sure I'll get it figured out on Monday thanks to you!

allan.thomas Fri, 04/02/2010 - 16:39

Hi Tim,

Hmmm this is rather strange behaviour, I would expect service-policy on the SVI to be applicable to traffic on ingress from VLAN3099?  I assume the SVI 3099 is the default-gateway for VLAN3099 traffic from the WiSM?  If the PC was connected to this Gigabit5/2 interface as an access, then the ACLs applied on the SVI would take precedent and police the traffic accordingly with vlan-base qos applied to the interface?

As I'm not familiar with how the WiSM trunk interface is negotiated, an alternative would be to match the input-interface instead of a given as access-group as shown below.  However this requires mls qos vlan-based applied to interface as stipulate previously, whether the object match criteria is an access-group or particualr interface/trunk the behaviour or outcome should still be the same.

class-map match-all RATELIMIT
match input-interface GigabitEthernet5/2
!
policy-map RATELIMIT
class RATELIMIT
  police cir 64000000 bc 32000 be 32000 conform-action transmit exceed-action drop violate-action drop
!
interface vlan3099
service-policy input RATELIMIT
!

Rating posts is simply a case of clicking on the appropriate star to merit the level of helpfulness provided.

Regards

Allan

tdennehy Mon, 04/05/2010 - 09:54

Allen,

I just put the following commands into the 6509, and plugged a laptop into gig7/11. Speed test indicates the policy is working one way... I can download at about 1.5 mb/s, but uploading to our bandwidth server is unrestricted. I figured I would fix it first going through the copper, then after I get it working, to look at the WiSM end.

Do you know if this is only supported one way? Sure looks that way...

Thanks,

Tim

policy-map RATELIMIT

class RATELIMIT

police 4000000 32000 32000 conform-action transmit exceed-action drop

!

class-map match-all RATELIMIT

match access-group name RATELIMIT

interface GigabitEthernet7/11

switchport

switchport access vlan 3099

switchport mode access

no ip address

load-interval 30

interface Vlan3099

description = Dilbert_Development

ip address 10.130.254.254 255.255.255.0

service-policy input RATELIMIT

service-policy output RATELIMIT

ip access-list extended RATELIMIT

permit ip any any

tdennehy Mon, 04/05/2010 - 11:47

IOS (tm) s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-VM), Version

12.2(18)

System image file is

"sup-bootdisk:s72033-ipservicesk9_wan-vz.122-18.SXF11.bin"

tdennehy Tue, 04/06/2010 - 15:03

Here's what I ended up with for a solution below. Basically, I could

not put "mls qos vlan-based" on the trunk port because it is a WiSM and

it is a dynamic trunk that is not configurable. So I ended up deploying

the policies on the vlans, 3099 is in the trunk to a wlan, and vlan 30

is the vlan that is the gateway to the FWSM - and eventually the

Internet. So it works. A wlan user on the SSID mapped to vlan 3099

gets policed to about 2mb/s, not 4mb/s as the policy is written.

Another thing I noticed is that when I plug my laptop into a copper port

on the 6509, I can only get a 1 mb/s connection to our bandwidth server.

Strange, but good enough for me.

I was thinking of taking an 8 port 3560 and trunking it to the 6509 and

placing the "mls qos vlan-based" command on that switch just to see if

it works. If not, I'll stick with what I have configured right now.

!

class-map match-all Identify_WLAN_Guest_outbound

match access-group name Guest_WLAN_UBRL_Outbound

class-map match-all Identify_WLAN_Guest_inbound

match access-group name Guest_WLAN_UBRL_Inbound

!

policy-map police_WLAN_Guest_traffic_outbound

class Identify_WLAN_Guest_outbound

police 4000000 32000 32000 conform-action transmit exceed-action

drop

policy-map police_WLAN_Guest_traffic_inbound

class Identify_WLAN_Guest_inbound

police 4000000 32000 32000 conform-action transmit exceed-action

drop

ip access-list extended Guest_WLAN_UBRL_Outbound

permit ip 10.130.254.0 0.0.0.255 any

!

ip access-list extended Guest_WLAN_UBRL_Inbound

permit ip any 10.130.254.0 0.0.0.255

interface Vlan3099

description = Dilbert_Development

ip address 10.130.254.254 255.255.255.0

service-policy output police_WLAN_Guest_traffic_inbound (dnld police)

!

interface Vlan30

service-policy output police_WLAN_Guest_traffic_outbound (upld police)

ericgarnel Wed, 01/12/2011 - 12:36

If I understand your config statements correctly, you are defining the acl for the entire subnet and then policing per flow?   Not sure why it is capping at 2 instead of 4.

We are looking to do something similar, but for a larger address space.  I would love to get away with a single acl for the whole subnet.

tdennehy Wed, 01/12/2011 - 16:30

Yes, I am doing the entire subnet.  It is working fine, actually

.

I did get different bandwidth results from what was configured, so I just bumped it up a bit until I got the desired bandwidth limitation and left it there.

Actions

This Discussion