class-default matches control traffic?

Question

I'm seeing an issue with BFD on a link that's being policed egress where it appears during times where the policer is maxed BFD packets are not getting to the other side. I'm wondering if BFD hellos are subject to the policer or if they fall outside of the policer. If they are subject to a policer is it as simple as adding a match for DSCP CS6 and giving it priority? Below is the config:

interface GigabitEthernet1/1
 service-policy output 500meg
end

Router-1#sh policy-map 500meg
  Policy Map 500meg
    Class class-default
     police cir 500000000 bc 31250000 be 31250000
       conform-action transmit
       exceed-action drop
       violate-action drop

Answer 1

@Mud, you've pretty much got the answer to your question spread over several comments so I'm merely consolidating it here in a single answer.

On the 7600s/6500s you can filter BFD (control-plane traffic) at the interface level just like any other traffic (transit traffic passing through the device).

When you apply an ACL to a port on the line card its applied to all traffic on that interface. Traffic that needs to be process by the RSP or DFCs if you are using them needs to be punted there which is after the ACL is processed.

As a rule of thumb I have been including control-plane traffic in QoS policies of late, such as the following where "class NC" matches CS6 & CS7 only:

policy-map QoS-Example
 class NC
  bandwidth percent 2
 !
 class REALTIME
  police rate percent 10
   conform-action transmit
   exceed-action drop
  !
  priority level 1
 !
 class 1
  bandwidth percent 22
 !
 class 2
  bandwidth percent 24
 !
 class 3
  bandwidth percent 12
 ....... and so on

If you write a CoPP policy for your 7600s/6500s you need to write ACLs that match all your relevant kinds of control-plane traffic. So you can also match BFD traffic by matching traffic to/from UDP port 3784 (and lock that down further to your interface IP if possible).

As @ytti said you need to be wary of the BFD timers on your setup, if you haven't got DFCs your running BFD on the RSP/CPU power. In that case you might also want to look at tweaking you "process-max-time" global command and the process schedule "scheduler allocate xxx xxx".

The Cisco recommended minimum is bfd interval 100 min_rx 100 multiplier 3 but on some production boxes without DFCs I am actually running bfd interval 500 min_rx 500 multiplier 3 which has been fine, I think on the boxes with DFCs which I don't have access to right now I'm running the same.

You can see these references for more info, which cover BFD tuning and ACLs for control plane traffic (both CoPP and interface ACLs), and also some control-plane tuning that is generally good practice, also QoS behaviour with control-plane traffic:

http://www.cisco.com/c/en/us/td/docs/routers/7600/troubleshoot/guide/7600_Trouble_Shooting.pdf

http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/12-2SR/configuration/guide/swcg/dos.html

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html

Answer 2

Due to the critical nature of the BFD control packet, it does not go through the egress QoS policy-map on the way out, and is placed in the egress queue directly. Confirmed with TAC.

Answer 3

According to this cisco document "Users cannot, for example, filter or apply Quality of Service (QoS) to transmitted BFD packet". So I suppose those packets get the PAK_PRIORITY flag.