Well it’s been said many times that you can’t teach an old dog new tricks…I seem to disagree with this statement (especially if you’re in the field of technology) and over the course of last night and today I now know that statement is completely false. Over the course of this period I have been configuring something know as QoS Policy Propagation via BGP (QPPB), this feature allows you to map BGP prefixes and attributes to CEF parameters that can be used to enforce traffic policy. The beauty of QPPB is that you can set policy in one area of the network and propagate this policy to other areas of the network where QoS policies can be created and enforced.

Let’s look at an example…In the figure below let’s say that AS65523 wants to create a forwarding policy where traffic between AS65521 and AS65524 destined to 192.168.0.0/16 gets rate-limited to a certain limit but other traffic is unaffected. When the prefix is first received from R1 via BGP, R2 tags the prefix with special attributes. As the prefix is propagated via BGP inside AS65523 to R3, those attributes are propagated also. When R3 receives the prefix, it can set various policies using the ‘table-map’ command under the BGP router process.

We will look at the configuration of R3…now before we get started I will tell you there are a few ways to configure the policy your wanting/needing and its best to read over the documentation for QPPB which will outline the various ways you can set policy…The documentation can be found here: QPPB Documentation. On R2, prefix 192.168.0.0/16 from R1 is tagged with a community of 521:524, and the prefix is propagated to R3 via iBGP. The interface connecting R3 to R4, in our case fast0/0 will be the interface that will set policy based on those received community attributes from R2. Let’s look at R3’s configuration for first classifying the traffic from R2.

Now that we have configured R3 to map prefixes with a community attribute of 521:524 to qos-group 2, we now need to apply the policy to R3 interface. This is where I would recommend reading the Doc CD because we apply the policy to an interface but which one? and to make matters worse we use the ‘bgp-policy’ command that accepts the keyword source or destination. So be sure you know which is which … In my case I am going to apply the policy to fast0/0 which connects R3 to R4 so that anytime AS65524 sends traffic destined to 192.168.0.0/16 network in AS65521 policy will be applied. In technical terms what this config will do is to enable a FIB lookup for traffic destined to 192.168.0.0/16. If there is a match for the destination address, a check is made into the FIB to determine if there are matching QoS entries. In my config there is, ip-qos-map and a QoS-group id is set to 2 in the FIB which means the QoS group ID can be used to set QoS policies. Committed Access Rate (CAR) is configured for traffic matching QoS group 2.

You can also apply a configuration for traffic sourced from 192.168.0.0/16 to AS65524. The incoming interface would be Fast1/0, the bgp-policy would reference the source and teh CAR policy would be output instead of input in that case.