Control Plane Protection inbound packet classification

The inability of Control Plane host interface to detect inbound OSPF packets has prompted Sebastian and myself to search for more documentation and conduct further tests. Sebastian already had a working configuration from which he could infer most of the configuration rules and he also found the well-written Understanding CPPr document on CCO. Together with the tests I ran in my router lab, we're pretty confident the CPPr inbound packet classification rules are (approximately) as follows:

Use the latest 12.4T software (at least 12.4(15)T5) if you want reliable CPPr operation.

  • control-plane aggregate service-policy disables any control-plane subinterface service policies.
  • If you want to use the per-subinterface (host, transit and cef-exception) policies, you have to remove the inbound service policy from the control-plane aggregate path.
  • Routed packets that cannot be CEF-switched (have to be punted to another switching mechanism) are classified as transit packets.
  • Local multicast packets with destination IP addresses within IP prefix 224.0.0.0/24 and packets with TTL <= 1 are classified as transit packets in 12.4(15)T5. These packets will be classified as cef-exception packets in the future (see the Understanding CPPr document).
  • Unicast packets without IP options addressed to the router and having TTL > 1 are classified as host packets.
  • Non-IP traffic (ARP, Frame Relay keepalives, CDP ...) is classified as cef-exception.

The TTL-related rules explain why the router classifies IBGP packets as host packets and EBGP packets as transit packets. As soon as you configure neighbor ebgp-multihop on the router router, inbound EBGP packets become host packets.

Recent posts in the same categories

4 comments:

  1. Anonymous 15 May 2008 16:35
    Thanks for the excellent post Ivan. I was surprised to read that if a policy is attached to the aggregate policy it would disable any control-plane subinterface policies. I didn't recall I read that caveat in the actual IOS CPPr config doc so this is an excellent piece of information.
  2. Anonymous 15 May 2008 18:01
    Ivan:

    I just finished reading the Understanding CPPr Doc and found the following statement about CoPP interesting:

    "Control Plane Policing: Control Plane Policing is a Cisco IOS feature that allows policing of traffic destined to the route processor. A packet will not be checked against the CPPr policy until it has been permitted by all configured forms of CoPP."

    So if I interpret it right...it appears that you can have a CPPr policy on specific control-plane subinterface(s) provided that the policy attached to the control plane aggregate interface has allowed it to go through.

    Also when I look at the flow diagram in that document the subinterfaces will be checked "after" the CoPP aggregate interface.

    I found this confusing and wonder if you have read it as well.
  3. Ivan Pepelnjak 15 May 2008 21:06
    As soon as I've applied the aggregate policy (CoPP), the counters on the subinterface policies (CPPr) stopped increasing (or stayed at zero after being cleared).

    I did not have the explicit 'class-default' in the aggregate policy, so I might do a few more tests. However, using 12.4(15)T5 the subinterface policies did not work at least for the traffic in the implicit default class of the aggregate policy.
  4. Anonymous 15 May 2008 22:17
    I also ran similar tests...have a permit all policy attached to the aggregate interface and as soon as I did that the counter stopped incrementing. Next I tried a single permit say eigrp any any so I intentionally excluded OSPF under aggregate and that didn't help. The only time where it worked was that I had to remove the policy from the aggregate.

    I will see if I can use the CPPr doc as a reference and ask my local SE to confirm. Stay tuned...
Add comment
Home
Sidebar