cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1954
Views
0
Helpful
3
Replies

7609 RSP vlan based internet bandwidth rate limit

sajism220
Level 1
Level 1

Hi,

I have a requirements to restrict the bandwidth for CORP internet users in our metro network, Could you check this template is good to go for to restrict the download and upload speed in Users WAN interface which is VLAN, my bandwidth limitations is 5  Mbps downlink and 5 Mbps uplink.

class-map match-all corp_traffic1
  match access-group name corp_traffic
!
policy-map CORP_ingress
  class corp_traffic1
    police 5000000 500000 conform-action transmit exceed-action drop
!
ip access-list extended corp_traffic
permit ip 172.25.5.0 0.0.0.255 any
permit ip any 172.25.5.0 0.0.0.255
!
!
!
Interface vl 351

service-policy input CORP_ingress
service-policy output CORP_ingress
!

Thanks&Regards

-Saji

3 Replies 3

rsimoni
Cisco Employee
Cisco Employee

Hi Saji,

in general the template looks fine, however when you configure QoS on a 7600 you need to be aware of some requirements and be 100% aware of which engine performs the QoS action.

If on your chassis there are no WAN cards (SIP, ES20, ES+ etc) you will have PFC QOS for sure, meaning that the policer (in this case) is handled eiher by the central PFC or by the DFC, if you have LCs with DFCs.

In that case you need to be aware of 2 things:

1. Since you applied the service policy to the SVI you need to configure on the physical layer 2 ports (the switchports) of vlan351 "mls qos vlan-based"

2. Each PFC or DFC polices independently, which might affect QoS features being applied to traffic that is distributed across the PFC and any DFCs. Examples of these QoS feature are:

Policers applied to a port channel interface.

Policers applied to a switched virtual interface.

Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs egress policing decisions at the ingress interface, on the PFC or ingress DFC.

Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.

regards,

Riccardo

Riccardo,

Thank you for your response..

I have RSP as SUP and ES20 as uplink card..

but I have clarfication...Is service policy input is realy required...

It seems input position is not working from this below logs..It is not matching the same

ABR#sh policy-map interface vlan 3xx

  Service-policy input: CORP_ingress

    class-map: corp_traffic1 (match-all)
      Match: access-group name corp_traffic
      police :
        5000000 bps 156000 limit 156000 extended limit
      Earl in slot 1 :
        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
      Earl in slot 2 :
        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
      Earl in slot 3 :
        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
      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 0000 bps, drop rate 0000 bps
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps

  Service-policy output: CORP_ingress

    class-map: corp_traffic1 (match-all)
      Match: access-group name corp_traffic
      police :
        5000000 bps 156000 limit 156000 extended limit
      Earl in slot 1 :
        3739884 bytes
        5 minute offered rate 20576 bps
        aggregate-forwarded 3739884 bytes action: transmit
        exceeded 0 bytes action: drop
        aggregate-forward 17464 bps exceed 0 bps
      Earl in slot 2 :
        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
      Earl in slot 3 :
        105048931 bytes
        5 minute offered rate 539032 bps
        aggregate-forwarded 105048931 bytes action: transmit
        exceeded 0 bytes action: drop
        aggregate-forward 545760 bps exceed 0 bps
      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


I will post more update on this...as I am waiting for the clients to test the same..

well, if you need to police both download and upload traffic you need to apply the service policy in both directions (you might create a specific ACL per direction rather than the cumulative's one but the one you have will do fine the same).

About input policer not working:

1 - Have you checked whether "mls qos vlan-based" is configured on the switchports that actually receive the traffic?

2 - after checking 1, vlan351 is the LAN VLAN which sends/receives IP traffic while you have MPLS on the WAN uplinks on the ES20? Or the opposite? It is important to check whether the ACL can match the correct type of traffic.

Also, as I mentioned  you have a chassis with multiple PFC/DFC -  as you can see from the outputs you have the Earls in slots 1 and 3 apply the policer independently... that means that you might end up allowing more than 5Mbs.