How do I classify IS-IS traffic with an access-list??

[Jose Martin Villanueva Mauricio]

Hi cisco Guys:

I'm configuring Control Plane Police in a Catalyst 6509. This equipment is using IS-IS like its IGP routing protocol, and iBGP. In order to make CoPP work Im classifying the traffic entering the control plane like CRITICAL, IMPORTANT, NORMAL, UNDESIRABLE and DEFAULT. Obviously routing protocol traffic must be classified like CRITICAL. Doing so is easy to BGP because it runs over TCP/IP and I can configure the following access list to classify BGP:

ip access-list extended CP-CRITICAL-IN

remark #### CONTROL PLANE CRITICAL TRAFFIC INBOUND ####

remark #### ROUTING TRAFFIC - BGP ####

permit tcp host [BGP neighbor addr] eq bgp host [local BGP addr]

permit tcp host [BGP neighbor addr] host [local BGP addr] eq bgp

deny   ip any any

But IS-IS is also a CRITICAL traffic,  but IS-IS doent run over TCP/IP, rather it exchange its own PDUs. So, how do I classify IS-IS traffic with an access list?. It is possible to do that?

Thank you son much for your help.

Regards

Martin

[Giuseppe Larosa]

Hello Martin,

see the document of best practices for C6500 the problem of IS-IS with CoPP is still open, and the suggestion is to leave class default without a police action because as in modular QoS non IP traffic is put in default class.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/best/practices/recommendations.html#wp1286585

Currently the control plane policing (CoPP)  feature does not support non-IP classes except for the default non-IP  class (class-default). This means that if CoPP is used, since ISIS CLNS  packets are non-IP they will end up in the default non-IP class. If the  system is subject to a DoS attack and a policy is applied to the default  class, ISIS adjacencies could flap or could go down. For this reason it  is recommended not to configure a policy under the default class if  ISIS is running in the system.

To do this safely in a previous class you need to match any possible IP traffic and to police it.

Hope to help

Giuseppe

[Jose Martin Villanueva Mauricio]

Hi Giuseppe:

thank you so much for the answer. I find it very useful.

Correct me if Im wrong.

1. First I have to classify the critical TCP/IP traffic in the control plane (traffic like iBGP). I will do that with an access-list name CRITICAL-ACL (for example); I will create a class named CRITICAL-TRAFFIC, and all traffic that matches the accesss-list CRITICAL-ACL will belog to CRITICAL-TRAFFIC class. Then in the policy map I have to grant enough bandwidth to this class (called CRITICAL-TRAFFIC)

2. The second step is to create an access-list that permits all IP traffic (called ALL-IP-TRAFFIC-ACL). I will create a class named NON-CRITICAL-TRAFFIC; all traffic that matches the access-list ALL-IP-TRAFFIC-ACL wil belong to NON-CRITICAL-TRAFFIC class . Then in the policy map I have to grant to that class a little bandwidth, since this traffic is not important.

3. Since IS-IS traffic is a non-IP traffic it will belong to default class. I will not police the default class.

But I Have one question. If the default class is not being policed, how much traffic could the control plane receive from this kind of traffic?. If I remember well the class default only can have until the 75% of the bandwidth of the interface where the policy map is applied, since we aren't apllied the policy map to a interface how much traffic of the default class could the control plane receive?

Thanks so much Giuseppe

Regards.

martin

[Giuseppe Larosa]

Hello Martin,

in order to protect the RP you can add a class with a policer for ARP traffic as explained in the configuration guide the command to match arp is match protocol ARP.

In this way at the end of the policy in class-default you should have only the IS-IS PDUs.

About your question on how much traffic can be received in class-default, we can note that if all of the above configurations are in place no IP traffic and no ARP traffic is present in this class and so it should end up with normally low usage given by ISIS hellos and even if restarting the ISIS process and during rebuilding adjacencies with all neighbors it shouldn't be an issue.

The rule you are mentioning is that of max-reserved-bandwidth and should say that the sum of all user defined classes cannot be over 75%.  However, I may be wrong but I don't think it applies to this case.

Hope to help

Giuseppe