[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