| 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
|