Border Gateway Protocol (BGP)

The Border Gateway Protocol (BGP) is an exterior routing protocol used for exchanging routing information between autonomous systems. BGP is used for the exchange of routing information between multiple transit autonomous systems as well as between transit and stub autonomous systems. BGP is related to EGP but operates with more capability, greater flexibility, and less required bandwidth. BGP uses path attributes to provide more information about each route, and in particular maintains an AS path, that includes the AS number of each autonomous system the route has transited, providing information sufficient to prevent routing loops in an arbitrary topology. Path attributes also include an origin parameter that indicates whether the source of the routing information is from within the autonomous system of the sending gateway (igp), external from the autonomous system (egp), or from some other source (incomplete). Path attributes may be used to distinguish between groups of routes to determine administrative preferences, allowing greater flexibility in determining route preference to achieve a variety of administrative ends.

BGP supports two basic types of session between neighbors, internal (sometimes referred to as IBGP) and external. Internal sessions are run between routers in the same autonomous system, while external sessions run between routers in different autonomous systems. When sending routes to an external peer, the local AS number is prepended to the AS path. Hence, routes received from an external peer are guaranteed to have the AS number of that peer at the start of the path. A route received from an internal neighbor will not in general have the local AS number prepended to the AS path, and hence, will in general have the same AS path that the route had when the originating internal neighbor received the route from an external peer. Routes with no AS numbers in the path may be legitimately received from internal neighbors; these indicate that the received route should be considered internal to your own AS.

The BGP implementation supports two versions of
the BGP protocol: Versions 2, and 3. BGP Versions 2 and 3 are quite similar in capability and function. They will only propagate classed network routes, and the AS path is a simple array of AS numbers.

External BGP sessions may or may not include a single metric, which BGP calls the Multi-Exit Discriminator (MED), in the path attributes.
For BGP Versions 2 and 3 this metric is a 16-bit unsigned integer. Smaller values of the metric are to be preferred. Currently, this metric is used only to break ties between routes with equal preference from the same neighbor AS. Internal BGP sessions carry at least one metric in the path attributes, which BGP calls the LocalPref. The size of the metric is identical to the MED. For BGP Versions 2 and 3, this metric is considered better when its value is smaller.

BGP collapses routes with similar path attributes into a single update for advertisement. Routes that are received in a single update will be readvertised in a single update. This minimizes the churn caused by the loss of a neighbor and maximally compresses the initial advertisement sent during peer establishment. BGP does not read information from the kernel message-by-message but fills the input buffer. It processes all complete messages in the buffer before reading again.

All unreachable messages are collected into a single message and sent prior to reachable routes during a flash update. For these unreachable announcements, the next hop is set to the local address on the connection, no metric is sent, and the path origin is set to incomplete. On external connections, the AS path in unreachable announcements is set to the local AS; on internal connections the AS path is set to zero length.

The BGP implementation expects external peers to be directly attached to a shared subnet and expects those peers to advertise next hops that are host addresses on that subnet (though this constraint can be relaxed by configuration for testing). For internal peers, however, there are two alternatives that may be selected from by specifying the ``internal'' or ``igp'' group type. See ``gated BGP protocol statement'' for a discussion of specifying group types.

When group type ``internal'' is specified, BGP expects all peers in the group to be directly attached to a shared subnet so that, like external peers, the next hops received in BGP advertisements may be used directly for forwarding. When group type ``igp'' is specified, BGP expects routes from the peers in the group not to be used for forwarding at all. Instead, they expect that copies of the BGP routes received will also be received via an IGP (interior gateway protocol such as RIP) and that the BGP routes will only be used to determine the path attributes associated with the IGP routes. Such groups also support distant peers and also need to be informed of the IGP they are running with.

For ``internal'' BGP group types (and for ``test'' groups), where possible, a single outgoing message is built for all group peers based on the common policy. A copy of the message is sent to every peer in the group, with possible adjustments to the next hop field as appropriate to each peer. This minimizes the computational load of running large numbers of peers in these types of groups. BGP allows unconfigured peers to connect if an appropriate group has been configured with an allow clause.

BGP Version 1 is described in RFC 1105, Version 2 in RFC 1163, and Version 3 in RFC 1267. The Version 3 MIB is described in RFC 1269. The two documents, RFC 1164 and RFC 1268, describe the application of Versions 2 and 3 in the internet. A protocol analysis of and experience with BGP Version 3 are available in RFC 1265 and RFC 1266. RFC 1397 talks about advertising a default route in BGP Versions 2 and 3. RFC 1403 describes BGP-OSPF interaction.

Home Notes   Home   MCSE   MCSE + Security   CCNA   CCNP   Schedule   Register   Frequently Asked Questions   Course Fees   Contact US   Boot Camp Location   Compare us to our competitors   Testimonials   Sitemap

Testimonials

Join MCSE Boot Camp & CCNA Boot Camp Back to Back Certification Today. links  270    290    291  293    294  298  299  Security  640-801  routing 811  821   831  Resources MCSE + CCNA  Training  Card pay  Papal  MCSE Notes  CCNA Notes    index main  root link  resources home    Ref1 Ref2

Vibrant offers MCSE certification training boot camp for $5400 all inclusive, instructor led at California and Baltimore.

Vibrant Bootcamp Participants come from All Around the World. Vibrant has trained students from more than 15 countries like USA, UK, (Scotland, Ireland, Wales), Switzerland, Germany, Australia, Canada, France, Holland, Japan, Belgium, Bahrain, New Zealand, Tanzania, Turkey, Kenya and more.