iBGP vs eBGP

The main difference

eBGP is used to receive routes and exchange it to the uplinks while iBGP will be used to make connection within your own system.

iBGP does not modify any BGP attributes! This includes next-hop that is why you need to use an IGP or next-hop-self.
Note: IGP is the best practice!


Since iBGP doesn’t modifies the AS-Path (which is the primary loop prevention mechanism in BGP)  it will have some additional rules:

BGP split horizon
“Never advertise a route you received via iBGP to another iBGP peer.”


This means that you must have a full-mesh between your iBGP neighbors. Fortunately you can make iBGP neighborship between not directly connected devices:




eBGP will modify the BGP parameters for example the next-hop IP.
However PE-01 will not know how to reach for example. To resolve this the routers will run IGP and PE-03 will advertise the network. IGP is also necessary to build the iBGP connection between 2 not directly connected iBGP peers.




Advertising routes with BGP


The network command works differently than in IGP:

  • will not send hello packets
  • will not advertise every route that are matching to IP/wildcard

It will take an existing route from the routing table and send it to the neighbors.
So this will not work, since you don’t have in your routing table:


Exact match is needed.


The network command has an additional feature called “backdoor“.
When a route is sent from R1 to R2 via eBGP the AD is 20. If you configure

network x.x.x.x mask x.x.x.x backdoor

on R2, the AD will be overwritten to 200. So it will act like the route was received via iBGP.


BGP tie breakers

Weight (largest)
Local preference (highest)
Locally originated
AS Path (shortest)
Origin type ( i < e < ?)
MED (lower)
Neighbor type (eBGP over iBGP)
IGP metric to next-hop (smallest)
   <maximum path checks>
Oldest eBGP route (sho ip bgp lists the older path last in the list)
Lowest neighbor BGP RID


Weight (largest, not advertised)

When a router originates a route locally it will automatically set the weight to 32768.


Local preference (highest, local AS)

Locally originated

AS Path (shortest)

If the router finds its own AS in the AS Path, it will drop the packet.

Origin type ( i < e < ?)

i – internal / advertisement with network command
e – EGP ( THE exterial gateway protocol, the one before BGP )
? – Redistributed routes.

MED (lower, only advertised to neighbor)

With MED we can recommend a preferred route to the neighbor. The BGP neighbor will not advertise this attribute further!!
This attribute is also called metric“.

Neighbor type (eBGP over iBGP)

IGP metric to next-hop (smallest)

Oldest eBGP route

(sho ip bgp lists the older path last in the list)

Lowest neighbor BGP RID

The RID is unique.

Local Preference

Local preference is an indication to the AS about which path is preferred
to exit the AS in order to reach a certain network. A path with a higher
local preference is more preferred. The default value for local
preference is 100.

Local preference is an attribute that is exchanged among routers in the
same AS.

The bgp default local-preference <value> command will set the local preference
on the updates out of the router going to peers in the same AS.

Another way to set Local Preference is using route maps (see the example below).


router bgp 100
 no synchronization
 bgp log-neighbor-changes
 redistribute connected
 neighbor remote-as 100
 neighbor remote-as 200
 neighbor route-map SET-LOCAL-IN in
 no auto-summary
ip prefix-list SET-LOCAL-IN seq 5 permit
ip prefix-list SET-LOCAL-IN seq 10 deny ge 32
route-map SET-LOCAL-IN permit 10
 match ip address prefix-list SET-LOCAL-IN
 set local-preference 150
route-map SET-LOCAL-IN permit 20
 set local-preference 100

When R1 receives the routing update via BGP with local pref setting it will send the traffic to through R3.


When R1 receives BGP advertisements from R2 it will have a route to with a better local preference (150). This will lead the traffic to through R2 -> R4 -> R5.

Moreover R1 will not send any routes to R2 regarding as it has already received a better one from R2. R1 will have only one route in it’s routing table and it will be with the loc pref of 150. The same route will not be sent back to R2 (split horizon).


Multipath Load Sharing

Load sharing allows a router to distribute the outgoing and incoming traffic among multiple paths. By default, BGP selects only a single best path and does not perform load balancing.

BGP Multipath does not affect bestpath selection. For example, a router still designates one of the paths as the best path, according to the algorithm, and advertises this best path to its neighbors.
These are the BGP Multipath features:

  • eBGP Multipath—maximum-paths n
  • iBGP Multipath—maximum-paths ibgp n
  • eiBGP Multipath—maximum-paths eibgp n


However the BGP attributes

  • Local Preference
  • Multi-Exit Discriminator
  • Origin
  • AS-Path

of the selected multipath routes have to be identical to the best path. The AS-path of all multipath routes has to be an exact match of the AS-path of the best path!

This requirement can be relaxed with the bgp bestpath as-path multipath-relax router configuration command, resulting in eBGP load balancing across multiple autonomous systems.

BGP performs equal-cost load balancing between all multipath routes, unless the bgp dmzlink-bw is configured within the BGP routing process and dmzlink-bw option is configured on EBGP neighbors.


maximum-paths eibgp

To configure multipath load sharing for external BGP (eBGP) and internal (iBGP) routes, use the maximum-paths eibgp command in address family configuration mode.


Weight (largest)
Local preference (highest)
Locally originated
AS Path (shortest)
Origin type ( i < e < ?)
MED (lower)
Neighbor type (eBGP over iBGP)
    When the “eibgp” parameter is used, this tiebreaker is ignored.
IGP metric to next-hop (smallest)
   <maximum path checks>
Oldest eBGP route (sho ip bgp lists the older path last in the list)
Lowest neighbor BGP RID


eBGP and iBGP Multipath Load Sharing Configuration Example

This following configuration example configures a router in address-family mode to select six BGP routes (eBGP or iBGP) as multipaths:

Router(config)# router bgp 40000 
 Router(config-router)# address-family ipv4 vrf RED 
 Router(config-router-af)# maximum-paths eibgp 6 
 Router(config-router-af)# end

This feature is supported by:


Source: http://www.cisco.com/c/en/us/td/docs/ios/12_2sx/feature/guide/fsxeibmp.html

Common BGP config


router bgp 100
bgp router-id
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor remote-as 10
neighbor password cisco
neighbor version 4
neighbor fall-over bfd
address-family ipv4
 bgp redistribute-internal
 network mask
 neighbor activate
 neighbor send-community both
 neighbor advertisement-interval 5
 neighbor soft-reconfiguration inbound
 neighbor route-map SET-PRIMARY-WAN-OUT out
address-family ipv4 vrf CustomerA
 network mask
 redistribute ospf 100 match internal external 1 external 2 route-map FromLanToBGP
 neighbor remote-as 10
 neighbor password cisco
 neighbor version 4
 neighbor fall-over bfd
 neighbor activate
 neighbor send-community both
 neighbor advertisement-interval 5
 neighbor soft-reconfiguration inbound
 neighbor route-map SET-PRIMARY-WAN-OUT out

neighbor activate

This command enables the exchange of information with a (BGP) neighbor.

The exchange of addresses with BGP neighbors is enabled for the IPv4 address family. Enabling address exchange for all other address families is disabled.

Address exchange for address family IPv4 is enabled by default for each BGP routing session configured with the neighbor remote-as command unless you configure the no bgp default ipv4-activate command before configuring the neighbor remote-as command, or you disable address exchange for address family IPv4 with a specific neighbor by using the no form of the neighbor activate command.

More information about address families here.

neighbor   as-override

BGP has a simple loop prevention mechanism for external BGP. When you see your own AS number in the AS path, we do not accept the prefix.

as-override-simpleIn this example both CE1 and CE2 are using AS 65000 so they wouldn’t receive each others advertisement because of BGP loop prevention mechanism.

neighbor  version 4

We can set BGP version 2,3 and 4. Version 4 is the latest and it is used by default.
Anyways it might be a good idea to hardcode it.

neighbor  advertisement-interval

To set the Minimum Route Advertisement Interval (MRAI) between the sending of BGP routing updates, use the neighbor advertisement-interval command in address family or router configuration mode.

Default values:

eBGP sessions not in a VRF: 30 seconds
eBGP sessions in a VRF: 0 seconds
iBGP sessions: 0 seconds

When the MRAI is equal to 0 seconds, BGP routing updates are sent as soon as the BGP routing table changes.

neighbor  send-community [both | standard | extended]

To specify that a communities attribute should be sent to a BGP neighbor, use the neighbor send-community command in address family or router configuration mode.

More information about communities here.  <<<<<< unfinished

neighbor maximum-paths

neighbor  fall-over bfd

BFD packets will be sent to the neighbor this way connectivity problems are detected much faster. If error detected bfd will tear down the BGP connection.
The BFD timer can be set on interface:

bfd interval [send-timer] min_rx [receive-timer] multiplier [number]

More details here.

BGP – address families

The BGP, as you surely know, has a multi-protocol capability – in a single session, it is capable of carrying information about diverse routed protocols (IPv4 Unicast, IPv4 Multicast, IPv6 Unicast, IPv6 Multicast, VPNv4, CLNP), in BGP’s parlance called “address families”. With BGP being a true multiprotocol routing protocol, however, you need some means to tell BGP which address families should be exchanged with a particular neighbor. We are accustomed to the fact that if we define an IPv4 neighbor, we are planning to exchange IPv4 routes with that neighbor – but why should that actually be a rule? Why should we make hasty assumptions about the address family just because the address of the neighbor is from a particular family itself?

This is the point behind diverse address-family commands. Defining a neighbor under a particular address family means that we want to exchange routes from the particular address family with that neighbor. Not having a neighbor listed under a particular address family means that we are not planning to exchange information from that address family with that neighbor.

Now, the address-family ipv4 declares neighbors with whom we want to exchange normal IPv4 unicast routes. This may be surprising because to exchange IPv4 routes with a neighbor, it is sufficient to simply define that neighbor by its address. The fact is that for backward compatibility with older BGP versions that have not been multiprotocol-capable, the BGP implicitly assigns all defined neighbors to an invisible address-family ipv4 section. In other words, as soon as you define a neighbor, it is automatically being added to an invisible address-family ipv4 section so that you don’t have to do it manually.

You can change it, however. First of all, if you enter the BGP configuration and issue the command bgp upgrade-cli you will find out that the BGP configuration has been fully converted to the address family style of configuration. Outside any address-family stanzas, only the basic neighbor settings are configured like their addresses, AS numbers, update sources. However, all remaining per-address-family commands will be automatically moved into address-family stanzas. The behavior or operations of BGP do not change with this new style of configuration, only the configuration format is changed.

Furthermore, if you enter the no bgp default ipv4-unicast command in the BGP configuration, you will prevent BGP from automatically assigning each newly defined neighbor into address-family ipv4 section. You will then be required to add every defined neighbor to each intended address family automatically – it won’t be done automatically for you anymore.

So to wrap it up – the address-family ipv4 is in fact an omnipresent section in the BGP configuration but for backward compatibility purposes, it is not visible by default. However, the configuration can be converted to a strict per-address-family configuration, and in fact, I would recommend that for all new deployments.

Peter Paluch – Cisco forum

Create a free website or blog at WordPress.com.

Up ↑