Initially, BGP Policy Accounting was available only on an input interface—that is, for ingress traffic. The Output BGP Policy Accounting feature introduces several extensions: the possibility to account for egress traffic and also accounting based on source addresses for both ingress and egress traffic. Table 8-1 summarizes the four possibilities of source versus destination lookup combined with ingress versus egress traffic.
Table 8-1. Four Different Combinations of BGP Policy Accounting
|Source lookup classification on the ingress trafficExample 1: Checking the peering and transit agreement for the ingress traffic||Destination lookup classification on the ingress trafficExample 2: Destination-sensitive billing|
|Source lookup classification on the egress trafficExample 3: Source-sensitive billing||Destination lookup classification on the egress trafficExample 4: Checking the peering and transit agreement for the egress traffic|
Combining Examples 1 and 4 from Table 8-1 allows ISPs to monitor and verify their peering agreements with neighbor ISPs. In Figure 8-2, classifying the ingress and egress traffic per BGP AS_PATH on the external interface of Router A could indicate that all the traffic back and forth to ISP2 is actually targeted for ISP4. Therefore, directly peering with ISP4 may be the better option in this example, assuming that there is an option for direct peering between ISP1 and ISP4.
Figure 8-2. Verifying the Peering and Transit Agreements