> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # BGP Configuration on Cisco IOS XE: eBGP and iBGP - URL: https://www.pinglabz.com/bgp-configuration/ - Published: 2026-06-24T13:00:00.000Z - Updated: 2026-08-24T09:43:36.000Z - Description: Basic BGP peering takes half a dozen lines; what trips people up is eBGP vs iBGP behavior, getting routes into BGP, and the iBGP next-hop quirk that silently breaks reachability. A full IOS XE walkthrough. - Author: Jaime - Tags: BGP, Fundamentals, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/bgp/). ## 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. Remote-as eBGP Different from local AS iBGPSame as local AS Typical peering address eBGP Directly connected interface iBGP Loopback (for resilience) TTL default eBGP 1 (peers must be adjacent) iBGP255 Next-hop on advertised routes eBGPChanged to self iBGP Left unchanged - the gotcha ## 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 network statement How Explicitly name each prefix; needs an exact route-table match When to use A small, known set of prefixes you deliberately advertise redistribution How `redistribute ospf 1`, `redistribute connected`, etc. When to use Many prefixes from an IGP - but filter carefully, it is easy to leak 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 Neighbor stuck in Active or Idle No IP reachability to the peer address, wrong remote-as, or an ACL blocking TCP 179. Neighbor is up but advertises nothing The network statement has no exact-match route in the table, or a prefix-list/route-map is filtering outbound. iBGP route in BGP table but not the routing table Unreachable next-hop. Apply `next-hop-self` on the router with the eBGP session. iBGP session flaps when a link fails Peering on a physical interface instead of a loopback. Peer loopback-to-loopback with `update-source`. eBGP neighbor will not come up across a router in between eBGP TTL is 1 by default. Multi-hop eBGP needs `neighbor x.x.x.x ebgp-multihop`. ## 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](https://www.pinglabz.com/bgp/).