1. Introduction
This a summary of the final few sections of chapter 4 in the book BGP Design and Implementation. An additional source that I’ve used is Dan Massameno’s 5 part series on secret CEF attributes over at Packetpushers; I wouldn’t have been able to write this post without his articles.
2. QoS Policy Propagation
QoS Policy Propagation is a way to set policy parameters in the CEF FIB using BGP. What does that mean? This feature is a bit strange unless you’re already a CEF guru. The short story is that each prefix installed in the FIB can carry three different policy parameters, or tags.
- Precedence
- QoS-Group
- Traffic Index
Once these tags are set, they can be referenced by other features on the router. Depending on what tag we use, we have different capabilities available. If we use the precedence tag, we are able to set the IP precedence bits on matching packets, possibly influencing how that traffic is handled by other routers as well. The QoS-Group tag allows you to set the QoS-Group ID which is a value local to the router that you can reference in other QoS features. Traffic index is used for BGP Policy Accounting, a feature that lets you track how much data is sent to or from prefixes tagged by each index number.
Before we get into the actual propagation part, let’s talk about how these tags are inserted into the CEF table. As we know, the CEF FIB is created mainly by synchronizing with the main IP RIB (routing/forwarding table). The key then to this policy parameter business is to insert the tags into the IP RIB, something that’s done using a BGP Table Map. Once the tags are in the IP RIB, they are sent to the FIB automatically. The table map is a route map that’s referenced with the router(config-router)#table-map <route-map> command. In this route map we can use various match statements and, more importantly, set the policy parameters:
route-map MAP_NAME permit 10 <Possible match statements> set ip precedence <0-7> set ip qos-group <0-99> set traffic-index <1-64>
Once these tags have been downloaded into the FIB, and that requires clearing the IP RIB (clear ip route), resetting the BGP session or reloading the router, we can reference them in other commands. You can verify using show ip route <specific route> or show ip cef <specific route> detail:
R3#show ip route 172.16.0.0 Routing entry for 172.16.0.0/16 Known via "bgp 100", distance 200, metric 0 Tag 200, precedence flash (3), qos-group 5, type internal Last update from 192.168.23.2 00:05:03 ago Routing Descriptor Blocks: * 192.168.23.2, from 192.168.23.2, 00:05:03 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 200 MPLS label: none R3#show ip cef 172.16.0.0 detail 172.16.0.0/16, epoch 0, flags rib only nolabel, rib defined all labels QOS: Precedence flash (3), qos-group 5 BGP: traffic_index 10 recursive via 192.168.23.2 attached to GigabitEthernet1/0
Now, let us talk about how this information is propagated within BGP. Because the route map referenced with the table-map command can contain match statements, we can use certain attributes of the prefixes as a criteria for applying the policy parameters. For example, we could say that prefixes from a certain AS (match as-path) should have a particular precedence tag, or that prefixes with a matched community value should have taffic-index x. Using community values is what makes this feature scalable. If you only use the prefixes themselves as matching criteria, adding a new prefix to the network could require extensive reconfiguration. However, if you simply add a predetermined community value to the prefix at the router where it enters the AS, this community attribute would be carried to all routers and thus integrating the prefix into the overall policy.
A basic configuration could look something like this:
ip community-list 1 permit 100 ip community-list 2 permit 200 ip community-list 3 permit 300 ! route-map TABLE_MAP_NAME permit 10 match community 1 set ip precedence 3 set traffic-index 1 route-map TABLE_MAP_NAME permit 20 match community 2 set ip precedence 4 set traffic-index 2 route-map TABLE_MAP_NAME permit 30 match community 3 set ip qos-group 54 set traffic-index 3 !
The important thing to note here is that it’s the community attributes of the prefixes that determine what tags are inserted into the RIB/FIB. This means that you only need to set the community at the edge of the AS for any new prefixes that you want this policy to apply to.
We’ve now covered what the policy parameters are and how you propagate these tags across the AS (or to other ASes as well I guess, technically) using the community attribute. That of course begs the question, what can we do with them? As the name QoS Policy Propagation suggests, it’s primarily about QoS. I’m not going to cover any actual QoS configuration since I’m not particularly well versed in it. However, what I am going to do is to explain how this feature interacts with QoS. Using the bgp-policy {source | destination} {ip-prec-map | ip-qos-map} interface command we’re able classify incoming traffic according to the FIB policy parameters. Think of this command as a “translator” from the CEF policy parameters into parameters that can be used by the QoS features.
The source and destination keywords tell the router whether look at the source or destination IP addresses of the incoming traffic when doing the classification. Earlier in this post I showed output containing the prefix 172.16.0.0/16, and if the interface’s position in the topology suggests that someone would use that as the destination address for their traffic, you would obviously use the destination keyword. Similarly, on interfaces pointing in other directions, you could use the source version of the command. If the policy parameter in the FIB contains a precedence value and you use the ip-prec-map keyword, the IP header of the traffic will have its ToS field modified in accordance with that value. If you use ip-qos-map, the QoS-group ID is set – a local value that’s referenced by other QoS features.
3. BGP Policy Accounting
Policy accounting uses the traffic index parameter. What it does is log how many packets and bytes have been received or sent on an interface for each possible traffic index. Earlier, we set the traffic index to 10 for 172.16.0.0/16, and if we configure the bgp accounting input interface command, the router will start collecting statistics for traffic with a destination address within that range. The source keyword makes the accounting feature look at the source instead of the destination address. Once we’ve sent a few packets, we can verify by using the show cef interface policy-statistics command:
R3#show cef interface policy-statistics ... GigabitEthernet2/0 is up (if_number 4) Corresponding hwidb fast_if_number 4 Corresponding hwidb firstsw->if_number 4 BGP based Policy accounting on input is enabled Index Packets Bytes 1 0 0 ............ 9 0 0 10 7 700 11 0 0
Fredrik's Networking Blog 