BGP Configuration

eBGP Configuration Example

router bgp 65000
 neighbor 192.168.1.2 remote-as 65001
 network 10.0.0.0 mask 255.255.255.0

iBGP Configuration Example

router bgp 65000
 neighbor 10.0.0.1 remote-as 65000
 neighbor 10.0.0.1 update-source Loopback0

Plan the BGP Session Before Entering Commands

A reliable BGP configuration starts with a small peering worksheet. Record the local autonomous system number, neighbor address, remote autonomous system number, source interface, address family, routes that may be advertised, and the policy expected in each direction. Confirm basic IP reachability before starting BGP. If the peer address is not reachable with the intended source, the BGP session cannot establish regardless of the routing policy.

Use directly connected interface addresses for a simple eBGP lab. In a resilient design, loopback addresses are often preferred because they remain available while at least one physical path is working. Loopback-based eBGP needs ebgp-multihop when the peer is more than one IP hop away, plus a route to the peer loopback. Loopback-based iBGP normally uses update-source Loopback0 on both routers.

Configure eBGP Carefully

The neighbor remote-as statement identifies the peer and determines whether the relationship is internal or external. After the session reaches Established, advertise only routes that exist in the local routing table. A BGP network statement does not create a route; its prefix and mask must match an installed route exactly. Use a static discard route only when you intentionally originate an aggregate and understand its effect.

Production eBGP should also include explicit policy. Apply prefix lists and route maps so the router accepts and advertises only approved networks. Configure a maximum-prefix limit to protect the routing table from accidental leaks. Add neighbor descriptions, authentication when both peers support the same method, and logging for session changes. Avoid relying on an unfiltered session even in a small enterprise edge design.

Understand the iBGP Rules

All iBGP speakers in one autonomous system must learn the required routes. A basic design uses a full mesh because routes learned from one iBGP neighbor are not advertised to another iBGP neighbor. Larger networks use route reflectors to reduce the number of sessions. When advertising an eBGP-learned route into iBGP, ensure the next hop is reachable internally or use next-hop-self at the correct boundary.

Do not confuse session establishment with successful forwarding. Two routers can show an Established BGP session while user traffic fails because the next hop is unreachable, the return route is missing, or a policy rejected the prefix. Validate the control plane and data plane separately.

Build the lab in stages so each result has one likely cause. First establish the neighbor relationship without filters. Next advertise one test prefix that already exists in the local routing table. Confirm that the peer receives it, selects a valid next hop, and installs it. Only then add route maps, prefix lists, communities, or path manipulation. Save the routing table and neighbor output after each stage; those snapshots make it much easier to identify which configuration change altered the session or route.

Verification and Troubleshooting Workflow

1. Use show ip bgp summary to verify the neighbor state, uptime and received-prefix count.
2. Use show ip bgp neighbors to confirm the local and remote AS, source address, timers, capabilities and policy.
3. Use show ip bgp to inspect valid, best and multipath routes plus their next hops and attributes.
4. Use show ip route bgp to confirm that selected BGP routes reached the routing table.
5. Use a source-specific ping and traceroute to test reachability between the exact peering addresses.

An Idle or Active neighbor usually indicates reachability, address, AS-number, ACL or TCP port 179 problems. An Established neighbor with no prefixes points toward missing network statements, route-policy filters, address-family activation or a route absent from the source routing table. If the prefix appears in BGP but is not installed, check next-hop reachability, administrative distance and whether another protocol already provides a better route.

Continue the BGP Lab

After the base session works, study BGP key concepts, path attributes, routing policies, and the BGP troubleshooting guide. Use the networking tools hub to verify public address, ASN, DNS and reachability information before treating a policy issue as a protocol failure.