eBGP vs. iBGP:

  • eBGP is peering and advertising routes via two different BGP Autonomous Systems. An eBGP peering connection is often times connecting and sharing routes between two different entities.
  • eBGP route advertisements received from one peer will be automatically advertised to other existing BGP peers – eBGP or iBGP.
  • Routes received from an iBGP peer will not be advertised to other existing BGP peers.
  • eBGP by default assumes a peer is directly connected – ie. TTL of 1. This is not the case for iBGP. To fix this with eBGP the operator can allow BGP multi-hop.
  • eBGP administrative distance is 20.
  • iBGP administrative distance is 200.
  • When eBGP advertises routes to iBGP, the next hop for the iBGP peer does not get updated. If the iBGP peer does not have alternate reachability to the network eBGP advertised, then the iBGP peer will not be able to reach the new destination, and it will not be added to the routing table.

BGP Route Reflector:

  • Due to the protocol behavior of not advertising iBGP received routes to other iBGP peers, having numerous routers running iBGP within the same Autonomous system requires many point to point links/peering. Using a route reflector allows an operator to setup a ‘hub and spoke’ type of model with iBGP sessions. One iBGP peer will become the Route Reflector (RR) server and the other iBGP routers will become a RR client. When one router advertises a route to the server, that server then ‘reflects’ that route down to all the other iBGP nodes or ‘spokes. This drastically reduces how many point to point connections/direct peerings that need to be made.

BGP Path Attributes:

Well-Know, Mandatory – RFC Compliant. Must be supported

  1. AS-Path
  2. Next-Hop
  3. Origin

Well-Known, Discretionary – RFC Compliant. Does not have to be propagated.

  1. Local Preference
  2. Atomic Aggregation

Optional, Transitive – Not required – will transit to other BGP speakers.

  1. Aggregator
  2. Community

Optional, Non-Transitive – Not required – Doesn’t have to pass along to other speakers.

  1. MED
  2. Originator ID
  3. Cluster

BGP Path Selection Metrics:

  • Weight – Cisco Only
  • Local Preference – Higher number wins
  • Self-originated – Prefers paths originated locally
  • AS Path – shortest AS Path
  • Origin – IGP-learned routes over EGP.
  • MED – Lowest value wins

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s