Home > Articles > Cisco Network Technology > General Networking > Effective BGP Policy Control

Effective BGP Policy Control

Chapter Description

Micah Bartell and Randy Zhang explore the various aspects of BGP policy control, including Policy control techniques, Conditional advertisement, Aggregation and deaggregation, Local AS, QoS policy propagation, and BGP policy accounting.

BGP Policy Accounting

BGP policy accounting (BPA) is another BGP feature that takes advantage of the FIB policy parameters. In this case, the parameter is traffic index. Traffic index is a router internal counter within a FIB leaf with values between 1 and 8. Think of the traffic index as a table of eight independent buckets. Each can account for one type of traffic matching certain criteria. The number of packets and bytes in each bucket of an interface is recorded.

You can use this feature to account for IP traffic differentially on an edge router by assigning counters based on BGP prefixes and attributes on a per-input interface basis.

Configuration of BPA generally involves the following steps:

Step 1

Identify BGP prefixes that require preferential treatment and tag them with appropriate BGP attributes.

Step 2

Set a FIB traffic index for each type of traffic.

Step 3

Enable BPA on an incoming interface.


Figure 4-10 shows how BGP policy accounting works. As prefix 172.16.0.0/16 is propagated from AS 200 to AS 300, certain BGP attributes are modified. On R4, a traffic index number can be set when a match is made for the attributes using the table-map command. A total of eight traffic classes can be accounted.

Figure 10Figure 4-10 How BGP Policy Accounting Works

NOTE

Remember that changes to the FIB/RIB tables are updated when the IP RIB is cleared using clear ip route *, the BGP session is reset, or a router is reloaded. All these actions can be disruptive to the traffic.

On each incoming interface, you can enable policy accounting by using the command bgp-policy accounting. With this command, using destination IP addresses, traffic matching the criteria is accounted for in its respective bucket. The show cef interface policy-statistics command displays the per-interface table of traffic counters. The counters can be cleared using the clear cef interface policy-statistics command.

Using the topology shown in Figure 4-9, an example of BGP policy accounting is demonstrated here. For the prefix 172.16.0.0/16, the BGP community is set as before. On R3, a route map is created to update the FIB traffic-index, as shown in Example 4-37.

Example 4-37 Sample BGP Configuration on R3

router bgp 100
 table-map Set-policy
 neighbor 192.168.23.2 remote-as 100
 neighbor 192.168.34.4 remote-as 300
!
ip community-list 1 permit 100:200
!
route-map Set-policy permit 10
 match community 1
 set traffic-index 1

The updated FIB for the prefix is shown in Example 4-38. To account for the prefix, policy accounting is enabled on FastEthernet 10/0. This is the incoming interface for traffic destined for 172.16.0.0. Note that this interface doesn't account for the return traffic, because the matching is done on the destination address. To account for the return traffic, policy accounting must be enabled on GigabitEthernet 6/0, and appropriate criteria must be set using the addresses of AS 300. Example 4-39 shows the accounting statistics on FastEthernet 10/0.

Example 4-38 FIB Traffic Index for 172.16.0.0

R3#show ip cef 172.16.0.0
172.16.0.0/16, version 23, cached adjacency 192.168.23.2
0 packets, 0 bytes, traffic_index 1
 via 192.168.23.2, 0 dependencies, recursive
  next hop 192.168.23.2, GigabitEthernet6/0 via 192.168.23.2/32
  valid cached adjacency

Example 4-39 Policy Accounting Statistics on FastEthernet10/0

R3#show cef interface policy-statistics | begin FastEthernet10/0
FastEthernet10/0 is up (if_number 19)
 Corresponding hwidb fast_if_number 19
 Corresponding hwidb firstsw->if_number 19
BGP based Policy accounting is enabled
 Index     Packets      Bytes
   1     867256    86725600
   2        0        0
   3        0        0
   4        0        0
   5        0        0
   6        0        0
   7        0        0
   8        0        0
7. Case Study: AS Integration via the Local AS | Next Section Previous Section