[c-nsp] QoS on 6500

Peter Salanki peter.salanki at bahnhof.net
Wed Jun 27 15:49:44 EDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NBAR is not supported in hardware on the Sup2. You will need the  
Sup32-PISA for that, or switch to a software routing platform.

Sincerely

Peter Salanki
CTO
Bahnhof AB (AS8473)
www.bahnhof.se
Office: +46855577132
Cell: +46709174932


27 jun 2007 kl. 20.23 skrev Corneliu Tanasa:

> I have the following scenario on 6000 with Sup2/PFC2/MSFC2, Native IOS
> (ipservices), version 12.2.18 SXF9
>
>
>
> For one customer, I have multiple interfaces for ingress traffic and
> multiple interfaces for egress traffic.
>
> I want to use NBAR to classify the traffic and then to police the  
> traffic.
> Because I have multiple incoming interfaces, I choose to use police
> aggregate.  So, I have for example one physical interface where the  
> customer
> is directly connected.  I have also one defined VLAN attached to that
> interface:
>
>
>
> interface fastethernet 3/1
>
> switchport
>
> switchport mode access
>
> switport acces vlan 100
>
> !
>
> Interface vlan 100
>
> ip address 10.10.10.1 255.255.255.0
>
>
>
> Now, I have the policy
>
>
>
> mls qos
>
> mls qos aggregate-policer TEST-aggregate 1024000 1024000 conform- 
> action
> transmit exceed-action drop
>
> !
>
> ip access-list extended TEST-acl
>
>  permit ip 10.10.10.0 0.0.0.255 any
>
> !
>
> class-map match-all name TEST-class
>
>  match access-group name TEST-acl
>
> !
>
> policy-map TEST-policy
>
>  class TEST-class
>
>     police aggregate TEST-aggregate
>
> !
>
>
>
> Please note there is no match protocol statement.
>
>
>
> Now, I'm going to apply the TEST-policy to the interface.
>
>
>
> interface fastethernet 3/1
>
>  service-policy input TEST-policy
>
>
>
> With this configuration, all the ingress traffic is policed to  
> 1024000 bps
> and works fine.  Now, without any other change, if I'm going to the  
> vlan
> interface and activate ip nbar protocol-discovery, then, the police  
> remains
> attached to this interface, but the traffic is flowing this  
> interface as
> there is no policy.  In the same time, I'm seeing that the counters  
> are
> increasing when looking at the output of:
>
>
>
> # show mls qos ip fastEthernet 3/1
>
>
>
> and this makes me think the policy is applied and is doing the job,  
> but
> still, the traffic is not policed at all.  What happens is that  
> without NABR
> protocol discovery the policy is working, but with NBAR, not, even  
> is there
> is no change into the policy (no match protocol statement added).
>
>
>
> Could somebody help me understand what I am missing?  Are there any
> limitations with aggregate-policer?
>
>
>
> Thank you,
>
> Corneliu
>
>
>
> _______________________________________________
> 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/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFGgr9YiQKhdiFGiogRAhZIAJ49WAoNFB8VhMSQ2pZwAS0ow6J5/gCgi0jM
F3n37WE6fMpOA1tTzIUXaLg=
=auKp
-----END PGP SIGNATURE-----


More information about the cisco-nsp mailing list