8.7 The Routing Process
8.7.1 Route exchange
Up until now, this chapter has focused on peering relationships within BGP, and EBGP vs. IBGP specific issues, such as synchronization. Before diving into more detail on routing, it makes sense to examine the process BGP uses to make routing decisions.

BGP is so flexible because it is a fairly simple protocol. Routes are exchanged between BGP peers via UPDATE messages. BGP routers receive the UPDATE messages, run some policies or filters over the updates, and then pass on the routes to other BGP peers. The Cisco implementation of BGP keeps track of all BGP updates in a BGP table separate from the IP routing table. In case multiple routes to the same destination exist, BGP does not flood its peers with all those routes; rather, it picks the best route and sends it. In addition to passing along routes from peers, a BGP router may originate routing updates to advertise networks that belong to its own AS. Valid local routes originated in the system and the best routes learned from BGP peers are then installed in the IP routing table. The IP routing table is used for the final routing decision.

To model the BGP process, imagine each BGP speaker having different pools of routes and different policy engines applied to the routes. The model would involve the following components (see the Figure to the left):

  • A pool of routes that the router receives from its peers
  • An input policy engine that can filter the routes or manipulate their attributes
  • A decision process that decides which routes the router itself will use
  • A pool of routes that the router itself uses
  • An output policy engine that can filter the routes or manipulate their attributes
  • A pool of routes that the router advertises to other peers