Configuring BGP on Cisco IOS: neighbours, network statements, next hop and reading the BGP table

A basic eBGP and iBGP configuration

In this example, AS 64500 is an enterprise with two edge routers, R1 and R2. R1 has eBGP to its provider in AS 64510; R1 and R2 run iBGP between their loopbacks, which OSPF makes reachable. Documentation ASNs and addresses are used throughout.

router bgp 64500
 bgp router-id 10.255.0.1
 bgp log-neighbor-changes
 neighbor 198.51.100.1 remote-as 64510
 neighbor 198.51.100.1 description ISP-A
 neighbor 10.255.0.2 remote-as 64500
 neighbor 10.255.0.2 update-source Loopback0
 neighbor 10.255.0.2 next-hop-self
 network 203.0.113.0 mask 255.255.255.0
!
ip route 203.0.113.0 255.255.255.0 Null0

If remote-as matches the local AS, the session is iBGP; otherwise it is eBGP. update-source Loopback0 makes the iBGP session use the loopback address, so it survives the failure of any one physical link.

Advertising networks

The network command does not enable BGP on interfaces, unlike in an IGP. It tells BGP to advertise a prefix if exactly that prefix and mask is already in the routing table. That is why the example adds a static route to Null0 for the whole /24: it keeps the prefix in the table and stable, even if the internal subnets change. Other ways to inject routes are redistribute (with filters, to avoid leaking everything) and aggregate-address, which creates a summary when at least one more specific route exists in the BGP table; add summary-only to suppress the specifics.

Auto-summary, which summarised redistributed routes to classful boundaries, is disabled by default on current IOS releases and should stay off.

eBGP to loopbacks: multihop

eBGP packets use a TTL of 1, so they cannot reach a neighbour's loopback that is one hop further away. When two routers are connected by two parallel links and you want one eBGP session between loopbacks, you need a route to the peer's loopback, update-source, and either neighbor x ebgp-multihop 2 or neighbor x disable-connected-check. The TTL security feature, ttl-security hops, is a safer alternative that also blocks spoofed packets from far away.

The next hop: eBGP versus iBGP

When a router advertises a route to an eBGP peer, it sets the next hop to its own address. When it passes an eBGP-learned route to an iBGP peer, the next hop is left unchanged, still pointing at the provider's address. If R2 has no route to 198.51.100.1, the route is unusable and never becomes best. Two fixes: advertise the provider link into the IGP, or configure next-hop-self on R1 towards its iBGP peers, as in the example. The second is the usual choice.

Reading the BGP table

show ip bgp summary
show ip bgp
show ip bgp 203.0.113.0/24
show ip bgp neighbors 198.51.100.1 advertised-routes

In show ip bgp each line is one path to a prefix:

• Status codes: * valid, > best (installed and advertised), i learned via iBGP, r RIB failure (a better route from another source already exists), s suppressed by an aggregate.
• Next Hop: 0.0.0.0 means the router originated the prefix itself.
• Metric (MED), LocPrf (local preference) and Weight: attributes used in best path selection.
• Path: the AS_PATH, followed by the origin code: i IGP (network statement), e EGP (historic), ? incomplete (redistributed).

show ip bgp summary lists each neighbour with its state; a number in the last column means the session is Established and shows how many prefixes were received.

Real-world example: after a new engineer added a second edge router at a logistics company, users behind it could not reach some cloud services. show ip bgp on the new router showed the provider routes without the > best-path marker. Their next hop was the provider's address on the other router's link, which the new router had no route to. Adding next-hop-self on the first router's iBGP session fixed it within seconds.