How to Configure eBGP Peering on Cisco (Step by Step)
eBGP is the protocol that runs the internet edge — it peers two routers sitting in different autonomous systems, whether that's your network and an upstream ISP, or two sites that don't share an IGP. Unlike OSPF or EIGRP, BGP doesn't discover neighbors or advertise routes on its own: you tell it exactly who to peer with and exactly what to originate. Here's the whole flow on Cisco IOS — start the process, define the neighbor, advertise your prefixes, and confirm the session is actually exchanging routes.
Step 1 — Start BGP and define the eBGP neighbor
Turn on the BGP process with your own autonomous system number — 65001 below. Every neighbor and network statement you configure sits under this router bgp context, the same way OSPF settings live under router ospf.
Then define the neighbor by its IP address and its AS number. Because the neighbor's AS (65002) is different from your own (65001), this is automatically an eBGP session — no extra keyword required. eBGP also assumes the neighbor is directly reachable: it sends packets with a TTL of 1 by default, so if the peer isn't on a directly attached link, the session will never come up.
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.12.2 remote-as 65002Step 2 — Advertise your networks
BGP doesn't originate anything by default — you have to tell it which of your own prefixes to advertise. The network command isn't injecting a route the way it would in an IGP; it's telling BGP 'if this exact prefix and mask already exist in the routing table, advertise it.' No exact match, no advertisement.
That means the mask matters as much as the network address. If your routing table shows 192.168.1.0/24 but you configure a /16 mask here, BGP won't find a match and won't advertise anything — even though the network is technically 'yours.'
R1(config)# router bgp 65001
R1(config-router)# network 192.168.1.0 mask 255.255.255.0Step 3 — Verify the session and the routes
Run show ip bgp summary first and look at the State/PfxRcd column. A number there means the session is Established and that many prefixes have been received; a word like Idle, Active, or Connect means the session is still trying to come up and no routes are flowing yet.
Once it's Established, show ip bgp lists everything in the BGP table, and show ip route bgp shows which of those routes made it into the routing table, marked with a B. This is exactly what a graded lab checks — the config only counts if the session actually reaches Established and the expected routes show up, not just because the commands were typed correctly. That's a good reason to run this against real IOS and grade the result, rather than trust that it 'looks right' on paper.
R1# show ip bgp summary
R1# show ip bgp
R1# show ip route bgpCommon mistakes (and the fix)
Wrong remote-as is the most common failure. The value you configure has to be the neighbor's actual AS number, not your own — get it backwards and the session won't form.
Second most common: the neighbor IP isn't directly reachable. eBGP sends with TTL 1 by default, so a hop in between, a down interface, or a simple addressing mismatch leaves the session stuck in Active or Idle and it never reaches Established.
Third: the network statement's mask doesn't exactly match an entry in the routing table. BGP won't advertise a 'close enough' prefix — fix the mask, or fix the route, so they line up exactly.
Finally, don't expect routes on either side until show ip bgp summary shows Established. Active, Idle, or Connect means the session itself is broken — that's what to troubleshoot first, before you start second-guessing your network statements.
Worked example: bring up a full eBGP session between two ASes
The existing steps only ever show R1's side, but a BGP session is a two-way agreement — nothing comes up until both routers point at each other with mirror-image config. Consider R1 in AS 65001 and R2 in AS 65002, joined by a /30 transit link (10.0.12.0/30, R1 = .1, R2 = .2). Each router owns a LAN it wants to originate: 192.168.1.0/24 behind R1 and 192.168.2.0/24 behind R2. Here we model each LAN with a loopback configured with a /24 mask, which puts the exact 192.168.1.0/24 and 192.168.2.0/24 prefixes in each router's routing table so the network statements have something to match.
Notice how the two configs are reflections of each other: R1 uses 'neighbor 10.0.12.2 remote-as 65002' and R2 uses 'neighbor 10.0.12.1 remote-as 65001'. The remote-as value on each side is always the OTHER router's AS, and the neighbor IP is always the interface on the far end of the transit link. Until R2's half exists, R1 will sit in the Active state because there's no one on the other end completing the TCP handshake — that is expected, not a bug.
Once both halves are in place, the session moves to Established, R1 receives R2's 192.168.2.0/24 and R2 receives R1's 192.168.1.0/24. Each router then installs the other's LAN as a BGP route (marked B) in 'show ip route', which is exactly what a graded lab confirms end to end rather than trusting the typed commands.
R1 = AS 65001, R2 = AS 65002 across the 10.0.12.0/30 link.
! ----- R1 (AS 65001) -----
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip address 10.0.12.1 255.255.255.252
R1(config-if)# no shutdown
R1(config)# interface Loopback0
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.12.2 remote-as 65002
R1(config-router)# network 192.168.1.0 mask 255.255.255.0
! ----- R2 (AS 65002) -----
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip address 10.0.12.2 255.255.255.252
R2(config-if)# no shutdown
R2(config)# interface Loopback0
R2(config-if)# ip address 192.168.2.1 255.255.255.0
R2(config)# router bgp 65002
R2(config-router)# neighbor 10.0.12.1 remote-as 65001
R2(config-router)# network 192.168.2.0 mask 255.255.255.0Reading "show ip bgp summary" line by line
The verification step leans on 'show ip bgp summary', so it's worth decoding the whole line rather than just glancing at the last column. The header confirms your local identity — the BGP router-id and 'local AS number 65001' — and each neighbor then gets one row. Left to right the columns are: Neighbor (the peer IP), V (BGP version, always 4), AS (the peer's autonomous system), MsgRcvd/MsgSent (cumulative message counters), TblVer, InQ/OutQ (queued messages), Up/Down (how long the current state has held), and State/PfxRcd.
Two fields carry most of the diagnostic weight. The AS column is a fast sanity check that the neighbor really is in the AS you expected — if it doesn't match the remote-as you configured, your peering assumptions are wrong. State/PfxRcd is the verdict: a number means the session is Established and that many prefixes were received, while a word (Idle, Active, Connect, OpenSent) means no routes are flowing yet. The Up/Down timer tells you about stability — a value that keeps resetting to seconds is a flapping session, and MsgRcvd that never increments on a supposedly Established peer hints that keepalives aren't actually arriving.
In the healthy output below, the peer is in AS 65002 (matching the remote-as set earlier), the session has held for about eight minutes, and PfxRcd 1 means a single prefix — 192.168.2.0/24 — arrived. If that final column instead read Active or Idle, you'd stop and troubleshoot reachability and neighbor config before ever questioning your network statements. With a number showing, the natural next command is 'show ip route bgp' to confirm the prefix installed as a B route.
R1# show ip bgp summary
BGP router identifier 192.168.1.1, local AS number 65001
BGP table version is 3, main routing table version 3
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.12.2 4 65002 12 12 3 0 0 00:07:41 1
! Number under State/PfxRcd = Established + prefixes received (healthy).
! A word there (Active/Idle/Connect) = session not up; fix reachability first.
R1# show ip route bgp
B 192.168.2.0/24 [20/0] via 10.0.12.2, 00:07:35Frequently asked questions
What's the difference between eBGP and iBGP?
iBGP peers sit inside the same autonomous system, while eBGP peers sit in different ASes. eBGP routes carry an administrative distance of 20 versus 200 for iBGP, and eBGP peers are normally directly connected (TTL 1) whereas iBGP peers are reached through your IGP. The operational catch is the iBGP split-horizon rule: a route learned from one iBGP peer is not re-advertised to another iBGP peer, so iBGP needs a full mesh or a route reflector, while eBGP has no such restriction.
Why is my BGP neighbor stuck in "Active," and how is that different from "Idle"?
Idle means BGP isn't even attempting the connection yet — usually there's no route to the neighbor or the neighbor statement hasn't taken effect. Active means BGP is actively trying to open the TCP session on port 179 but isn't completing the handshake, which points to a reachability problem, a wrong neighbor address, an ACL blocking TCP 179, or a remote-as mismatch. A session that keeps cycling between Active and Idle almost always means the underlying TCP path to the peer is broken, not a routing-policy problem.
How do I peer eBGP over loopbacks when the two routers aren't directly connected?
By default eBGP sends packets with a TTL of 1, so any peer more than one hop away — including loopback-to-loopback peering — fails until you raise the TTL with 'neighbor x.x.x.x ebgp-multihop 2'. You also add 'neighbor x.x.x.x update-source Loopback0' so the session sources from the loopback, plus a route (often static) to reach the peer's loopback address. This design is common when you want the eBGP session to survive the loss of any single physical link between the two routers.
Why does a prefix appear in "show ip bgp" but never install in the routing table?
show ip bgp lists everything BGP knows, but only the single best path per prefix is offered to the routing table, and it still must win on administrative distance against other sources. The usual reasons a prefix stays out of the RIB are an unreachable BGP next hop (flagged as inaccessible), the path not being selected as best, or the same prefix already learned from a lower-AD source like a connected or OSPF route. Check next-hop reachability first, because an unreachable next hop invalidates the path even when the prefix looks fine in the BGP table.
Should I use the network command or redistribute to advertise routes into BGP?
The network command advertises a specific prefix only when an exact match already exists in the routing table, so you list precisely what you originate and nothing more. redistribute pulls routes wholesale from another source — connected, static, or an IGP — and can leak far more than you intend unless you filter it with a route-map or prefix-list. For CCNA-style eBGP and most internet-edge designs, the network command is preferred because it keeps you in explicit control of what you inject into the outbound table.
Practice on real Cisco IOS
A fresh, graded Cisco Modeling Labs scenario every day — start with the free sample.