Input BGP Policy Accounting

This chapter describes the BGP Policy Accounting features in Cisco IOS. You will see how to apply this feature for a source- and destination-sensitive billing scheme, and you'll see the practical configuration details on the routers. Furthermore, you will understand the similarities between BGP Policy Accounting and the destination-sensitive billing feature.

Border Gateway Protocol (BGP) Policy Accounting measures and classifies traffic to and from different BGP peers. It allows accounting for IP traffic differentially by assigning counters based on BGP community list, BGP Autonomous System (AS) number, and/or AS_PATH, on a per-interface basis. This policy classification is performed via a Cisco IOS policy-based classifier that maps the traffic into one of the possible buckets, representing different traffic classes. Packet and byte counters are incremented for each bucket per interface and per direction (ingress or egress). A user can access the counters either through the CLI or via SNMP.

Even though the Cisco documentation refers to it as a single feature, this chapter divides BGP Policy Accounting into different variations for the sake of clarity:

• Input BGP Policy Accounting is the incoming feature applied on the interface where the traffic arrives, with a classification on the destination (according to the route the traffic will take). This is the initial BGP Policy Accounting variation developed, called BGP Policy Accounting in the Cisco documentation.

• Output BGP Policy Accounting is the outgoing feature applied on the interface where the traffic exits the network element, with a classification on the source (according to the route the traffic comes from). Refer to "Output BGP Policy Accounting" in the documentation for further details.

• The section "Summary of All Four BGP Policy Accounting Combinations" completes the remaining possibilities of the input versus output interface combination with the source versus destination lookup classification. Those extra combinations were developed as improvements to the initial BGP Policy Accounting feature.

This chapter also covers the destination-sensitive billing feature, which is quite similar to BGP Policy Accounting. It is available on only specific platforms. The Destination-Sensitive Traffic Shaping (DSTS) feature is addressed briefly because it takes the BGP Policy Accounting statistics as input to shape the traffic.

This chapter concludes by comparing the BGP Accounting features to the questions raised in Chapter 2, "Data Collection Methodology":

• What to collect?

• Where and how to collect?

• Who is the user?

• Potential scenarios

When classifying the BGP traffic sent to different BGP peers (destination lookup), BGP Policy Accounting allows accounting for traffic according to the route it traverses.

Input BGP Policy Accounting gives Internet service providers (ISP) the means to charge their customers according to the route that the traffic flows through: traffic routed domestically, internationally, terrestrially, or via a satellite. After the traffic classification is applied, different destination-sensitive billing schemes can be applied.

Leveraging this, the ISP can identify and account for all traffic on a per-customer basis, as shown in Figure 8-1.

In this example, BGP Policy Accounting enabled in Router A measures the packet and byte volumes in buckets. The buckets represent ISP1, ISP2, and the satellite link to ISP3.

The classification per bucket can be done per BGP AS, assuming that each of the three exits has a different BGP AS.

All traffic destined for a particular set of autonomous systems could be accounted for at one rate, and traffic going to destinations that are more distant could be billed at a second rate. Differentiated billing for different parts of the Internet is a good idea, because it allows the ISP to offer various destination-sensitive billing scenarios.

Note that "billing back" the customer for differently priced upstream providers (passing one's own cost structure to customers) might not be the best model for ISP pricing. There are no incentives for the ISP to lower the costs, and it could confuse the customers, who have no influence on which path packets are routed.