BGP – Controlling the Entry Point (HLD)

From the BGP Design point of view (HLD), there are four options to manipulate the inbound traffic, MED, AS-path prepending, using communities, and breaking aggregated routes.


This is not really useful, as it has to meet some conditions:

  • The AS-path of learned routes should be identical. Thus, this could be only useful when multihoming to the same AS.
  • The BGP peer might use Local-Preference in the Path Selection process.
  • Usually, Service Providers reset or strip received MED.

AS-Path Prepending

It’s not always helpful.

Continue reading “BGP – Controlling the Entry Point (HLD)”

Share this!

Tuning BGP Capabilities

OSPF external routes are automatically blocked from being redistributed in BGP by default.

A solution to minimize Internet route instability is using Aggregation. Fluctuation of any single route in an Aggregation does not cause fluctuation in  the Aggregate itself.

Backdoor routes offer an alternative IGP path instead of external BGP path. Using Backdoor for specific routes, cause the administrative distance to be equal to BGP Local (200), so the IGP with the lower AD will be preferred.

By default, MED is not compared when routes are learned from different ASs. This behavior could be changed using the bgp always-compare-med command. When the bgp deterministic-med command is enabled, routes from the same autonomous system are grouped together, and the best entries of each group are compared. (useful link) An example of BGP table looks like this:

entry1: AS(PATH) 100, med 200, external, rid
entry2: AS(PATH) 500, med 100, internal, rid
entry3: AS(PATH) 500, med 150, external, rid

bgp deterministic-med Enabled, bgp always-compare-med Disabled: There is a group for AS 100 and a group for AS 500. The best entries for each group are compared. Entry1 is the best of its group because it is the only route from AS 100. Entry2 is the best for AS 500 because it has the lowest MED. Next, entry1 is compared to entry2. Since the two entries are not from the same neighbor autonomous system, the MED is not considered in the comparison. The external BGP route wins over the internal BGP route, making entry1 the best route.

When passing an EBGP route to an IBGP neighbor, the EBGP neighbor is set as the next-hop.

In NMBA partial-mesh networks, sometimes the next-hop-self command is required.

When connecting to an Internet eBGP neighbor, AS_PATH list that contains Private ASs, should be stripped.

An AS that advertises an Aggregate, considers itself the originator of that route, irrespective of where that route came from. This issue can cause a loop, so the solution is to use the AS_SET parameter before an aggregate-address.

Sometimes, customers prepend fake ASes, to prevent becoming a transit AS for providers.

Combine route injection in BGP with static Routes (with distance 254, for example) to Null0 if you want to prevent route fluctuation even if your IGP routing is not stable.

In most of the situations, METRIC is used for inbound traffic management and LOCAL_PREFERENCE is used for outbound traffic administration.

BGP multipath can be used to install multiple paths in the IP routing table if the paths are learned via the same neighboring AS. The maximum-paths command can be used to install up to six paths to a single destination. The following attributes of parallel paths have to match with the best path:

  • Weight
  • Local Pref
  • Origin
  • AS-Path Length
  • MED
  • Neighbor AS or Sub-AS match for (eBGP multipath)
  • AS-PATH match (for eiBGP multipath)
  • IGP metric to BGP next hop
Share this!

BGP Routing using Policy Controls

  • Service Provider should filter some IP prefixes in incoming updates, such as RFC1918. Because a customer should only advertise its global networks to the Service Provider.
  • Multihomed Customers should avoid becoming a Transit-AS. As by default in most of the cases the tie breaker for BGP is the Shortest AS-Path, so the providers connected to the to customer will use the customer link as a Transit-AS to reach each other.
  • Service Providers should filter Private addresses in incoming updates of Customers.
  • In a scenario where a customer has two border routers without IBGP, and IGP inside the AS, there will be no loops, but if running IBGP between the border routers, special care should be taken or a direct link between the two border routers is required.
  • Policy Routing only affects the Next-Hop. The destination is unchanged!
  • Policy Routing is CPU intensive, because it is based on the source unlike Dynamic and static routing. So, when routing based on the destination there is no need of Policy Routing.
  • Customers can only affect their outgoing traffic, and can’t directly affect incoming traffic.
    (config)# ip as-path access-list# [permit/deny] regexp
    (config-router)# neighborip-address filter-list as-path-filter# [in/out]

Continue reading “BGP Routing using Policy Controls”

Share this!