BGP Configuration on Cisco IOS XE: eBGP and iBGP

BGP configuration is mechanically simple. The command set is small, and a basic peering comes up in half a dozen lines. What trips people up is not the syntax, it is the handful of non-obvious requirements: eBGP and iBGP behave differently, getting a route into BGP is a separate step from forming a neighbor, and iBGP has a next-hop quirk that silently breaks reachability. This post is a configuration walkthrough on Cisco IOS XE that covers all of it.

For the full picture, see the BGP complete guide.

What you are actually configuring

A working BGP setup has three parts, and it helps to keep them mentally separate:

• The local AS - the autonomous system number this router belongs to.
• The neighbors - each BGP peer is configured by hand with its IP address and its AS number. BGP does not discover peers; you tell it about every one.
• The routes to advertise - which prefixes this router originates into BGP. Forming a neighbor and advertising a route are two unrelated steps.

eBGP vs iBGP at configuration time

The single command neighbor x.x.x.x remote-as N decides everything. If the remote AS is different from your local AS, that session is eBGP. If it matches your local AS, it is iBGP. You never type "ebgp" or "ibgp" anywhere; the AS numbers decide.

Minimum viable eBGP

Two routers, two different ASes, peering over a directly connected link. R1 is in AS 65001, R2 is in AS 65002, and the link between them is 192.0.2.0/30.

! R1 - AS 65001
router bgp 65001
 bgp router-id 10.255.0.1
 neighbor 192.0.2.2 remote-as 65002
 network 10.20.0.0 mask 255.255.255.0

That is a complete, working eBGP speaker. The network statement is what originates 10.20.0.0/24 into BGP. Mirror the config on R2 with its own AS and prefixes, and the session comes up.

The network statement has an exact-match rule

The network command does not "advertise whatever is in that range." It only originates a prefix if an exact match for it already exists in the routing table - same network, same mask. If you write network 10.20.0.0 mask 255.255.255.0 but the router only has 10.20.0.0/16 in its table, nothing is advertised. This is the most common reason a brand-new BGP config forms a neighbor but advertises no routes.

iBGP and the next-hop trap

iBGP exists to carry external routes across your AS. The catch: when a router passes a route to an iBGP peer, it does not change the next-hop attribute. So an internal router learns a prefix whose next-hop is an address in some other AS - an address it has no route to. The prefix shows up in the BGP table but never makes it into the routing table, because the next-hop is unreachable.

The fix is next-hop-self, applied on the router that has the eBGP session, for its iBGP neighbors:

! R2 - AS 65001, has the eBGP session AND an iBGP peer R3
router bgp 65001
 neighbor 192.0.2.1 remote-as 65002
 neighbor 10.255.0.3 remote-as 65001
 neighbor 10.255.0.3 update-source Loopback0
 neighbor 10.255.0.3 next-hop-self

Now R3 receives external routes with R2's loopback as the next-hop - an address R3 can reach via the IGP. Note update-source Loopback0: iBGP sessions are peered loopback-to-loopback so the session survives any single link failure, and both sides must agree on the source address.

Getting routes into BGP: network vs redistribution

For most edge routers the network statement is the safer choice: it is explicit, and you cannot accidentally advertise the entire internal routing table to a provider. Redistribution into BGP without a route-map filter is a classic way to cause an outage.

Verifying

R1# show ip bgp summary
Neighbor        V    AS  MsgRcvd  MsgSent  TblVer  InQ OutQ Up/Down  State/PfxRcd
192.0.2.2       4 65002       21       23      12    0    0 00:14:22        3

Read the rightmost column. A number (here 3) means the session is Established and you have received 3 prefixes. A word - Idle, Active, Connect, OpenSent - means the session is not up yet. Active is the one that misleads people: it does not mean "working," it means the router is actively trying and failing to connect.

R1# show ip bgp
   Network          Next Hop      Metric LocPrf Weight Path
*> 10.20.0.0/24     0.0.0.0            0         32768 i
*> 10.30.0.0/24     192.0.2.2          0             0 65002 i

The *> means a route is valid and the best path. 0.0.0.0 as the next-hop marks a prefix this router originated itself.

Common gotchas

Key takeaways

BGP configuration is three separate jobs: set the local AS, define each neighbor by IP and remote-as, and originate prefixes with network or filtered redistribution. The remote-as value alone decides eBGP versus iBGP. The network statement needs an exact route-table match or it advertises nothing. iBGP does not rewrite the next-hop, so next-hop-self on the eBGP-facing router is almost always required, and iBGP sessions should peer loopback-to-loopback with update-source. When you verify, read the State/PfxRcd column of show ip bgp summary - a number is good, a word is not.

For the BGP cluster, see the BGP pillar.