BGP speakers peer with one another using TCP, and possibly relying on an underlying IGP to provide IP reachability to its neighbors.

BGP peering uses the standard TCP port number 179

A BGP update contains Attributes (policies, groupings, metadata) and NLRI (IP destinations).

The Attributes in an update are common for all NLRIs in that update.

If two NLRIs have different policies/attributes, they will need to be sent in different updates.

BGP peering uses IP unicast over TCP.

If a BGP speaker has 1000 peers it will need to generate and send 1000 BGP updates.

The use of peer-groups can help. Updates are only generated once per peer-group (yet still sent to every neighbor)

Peer-groups also streamline the configuration when large group of neighbors have the same outbound policies

Another approach is to reduce the number of neighbors (iBGP neighbors) through the use of Confederations and Route Reflectors.

BGP aggregation uses an as-set attribute, which is a listing of AS’s the component prefixes my have used, but in no particular order.

When a component prefix changes in a way would affect the as-set, a BGP update must be sent with the changed as-set information. This sort of defeats the purpose of aggregation – hiding individual subnet topology changes.

BGP aggregation is not commonly used. Redistributed or injected summary static routes are more commonly used, where component prefixes can change without needing to change the summary. Simplified BGP Path Selection:

  • Make sure the path is not a loop. Look in the AS_PATH field – if the local AS number is found, ignore update.

  • Make sure the IP next hop is reachable. Look in Next Hop field – if no connected or local IGP route exists for the next hop IP, ignore update.

  • Prefer the path with the highest WEIGHT.

WEIGHT is a local setting on the router and is not passed in BGP updates.

  • Prefer the path with the highest LOCAL PREF.

LOCAL PREF is a setting for the local AS and is only passed to iBGP peers. Not passed to eBGP peers.

Paths without LOCAL PREF set will have a value of 100 by default. Paths learned from eBGP will have default LOCAL PREF value of 100 even though it is not shown in show ip bgp

  • Prefer the path with the shortest AS_PATH
  • Prefer the path with the lowest MED (Metric) Only consider MED if the paths are from the same AS, unless ‘bgp always-compare-med’ is enabled.
  • Prefer eBGP over iBGP
  • Prefer path with lowest IGP metric to the Next Hop
  • Prefer path with lowest Router ID

BGP Best Path Selection Algorithm

BGP Communities are way of grouping routes with a common policy (Attributes). Another simlple way to describe BGP communities is route tagging.

Controlling the BGP exit point:

  • IGP metric (cost to IP Next Hop)

Controlling the BGP entry point:

  • MED (often least effective) – only considered if AS_PATH is equal, only useful for two links connected to the same AS. Lower on the decision process than Local Pref, if the peering AS has Local Pref higher on one link, MED will be ineffective.
  • AS PATH prepend (most common) – pad AS_PATH attribute on least preferred path. May not always work as expected. Peering AS may have Local Pref which will override AS_PATH, or peering AS may have implemented BGP policies that make AS_PATH prepend useless.
  • BGP cost community (RFC 1998) – influence the eBGP peer on how to set is Local Pref
  • Route aggregation/summary – advertise longer prefixes (subnets) on the preferred paths, shorter prefixes (summary) on the least preferred path.

Controlling route advertisement:

  • The NO_EXPORT community tells the receiving peer not to advertise this route outside of its AS.
  • The NO_ADVERTISE community tells the receiving peer to advertise this router to any other neighbor, even within its own AS.

Distribute lists can be used to control the routes advertised to, or received by another peer.

BGP rib failure from ‘show ip bgp’ indicates that a route learned from a neighbor where a lower administrative distance (from a static, or other IGP) has already been installed into the routing table, thus the BGP route has failed to install into the IP routing table (RIB) because it has been trumped by the lower admin distance route.

BGP routes with rib failure will still be advertised to neighbors unless ‘bgp supress-inactive’ has been configured

iBGP speakers will NOT set the Next Hop to themselves unless explicitly configured to do, UNLESS the route is directly connected to the iBGP speaker. For all other routes not directly connected, the Next Hop in ‘show ip bgp’ will be set to the next hop IP address for that route as it was found in the IP Routing table (RIB) ‘show ip route’.

eBGP speakers will set the Next Hop to themselves (in most cases).

If the eBGP peers are on a shared medium, such as Ethernet, with other routers. For routes learned from the “other routers”, eBGP speakers will set the Next Hop to that of the other router. This allows direct communication to appropriate router for optimal forwarding behavior.

BGP dampening works for eBGP routes only.

BGP Backdoor:

You might be learning a route from eBGP via an external neighbor, and from an IGP such as EIGRP or OSPF. Since eBGP has a lower admin distance (20) than EIGRP (90) or OSPF (110), the router will choose the eBGP route to install in the IP routing table.

You might want to use the IGP route as the primary path and only use the eBGP path as a backup.

The best approach is to configure the route as a BGP backdoor.

BGP backdoor tells the router to treat the defined network with the admin distance of iBGP (200), which is higher than any IGP. Furthermore, the router will not advertise this network in BGP updates.

router bgp 100
  network mask backdoor

BGP origin “Incomplete” comes from routes redistributed into BGP with the redistribute command.

BGP origin “IGP” comes from networks injected into BGP with the network command.

BGP AS path regular expression examples:

  • originated from my AS: ^$
  • originated from AS 100: ^100 .*
  • AS 100 anywhere in the path: _100_
  • AS 100 is the last AS in the path: _100$
  • match any: .*
router bgp 100
  neighbor remote-as 200 filter-list 1 in
  ip as-path access-list 1 permit ^100$

(Permit only routes that originated in AS 100 and have not passed through any other AS)

router bgp 100
  neighbor remote-as 300 route-map check-as in
route-map check-as permit 10
  match as-path 1
ip as-path access-list 1 deny _400_
ip as-path access-list 1 permit .*

(Deny any route which has traversed through AS 400, permit everything else)

The AS Path will appear in {} when the route is an Aggregate using the as-set option

Parts of the AS Path will appear in () to show confederation sub-AS

BGP Case Studies: