BGP Key Concepts

Autonomous systems and BGP neighbors

An Autonomous System, or AS, is a network or group of networks under one administrative policy. BGP uses AS numbers to identify who owns a route and how that route has traveled across the internet. When two routers in different autonomous systems form a BGP session, the relationship is called eBGP. When routers in the same autonomous system exchange BGP routes, the relationship is called iBGP. This distinction matters because eBGP normally changes the NEXT_HOP attribute and prevents loops with the AS_PATH, while iBGP preserves many attributes and usually requires a full mesh or route reflectors.

BGP neighbors do not discover each other automatically. Each peer must be configured with the remote address and remote AS. A session must pass TCP reachability, source address selection, AS number validation, authentication if configured, and update policy before it becomes useful. If the neighbor is stuck in Idle, Connect, Active, OpenSent, or OpenConfirm, the problem is usually reachability, TCP filtering, wrong update source, wrong remote AS, duplicate router ID, or authentication mismatch.

Path attributes that shape decisions

BGP path selection is driven by attributes rather than interface speed alone. Weight is local to a Cisco router. Local preference influences outbound path choice inside an autonomous system. Locally originated routes are preferred over learned routes. Shorter AS_PATH values are often preferred, but AS path prepending can intentionally make one path less attractive. Origin type, MED, eBGP over iBGP preference, IGP metric to the next hop, router ID, and neighbor address can also affect the final best path.

The NEXT_HOP attribute is one of the most important operational details. A route may exist in the BGP table but fail to install in the routing table if the next hop is unreachable. This is common in iBGP labs when a route learned from one edge router is passed to another internal router without next-hop-self. Always check both the BGP table and the normal routing table when troubleshooting path selection.

Policy, filtering, and communities

BGP becomes powerful when route policy is added. Prefix lists control which networks are allowed in or out. Route maps match prefixes, AS paths, communities, or other attributes, then set values such as local preference, MED, next hop, or community tags. AS path access lists can block routes that came from or passed through a particular AS. Communities make policy scalable because a route can carry a tag that tells another router or provider how to treat it.

A practical BGP policy should be explicit. Advertise only owned or approved prefixes, filter private ASNs at external boundaries when required, block bogon or unexpected routes, and document any local preference or prepending rules. In production, small policy mistakes can affect many destinations, so test changes in a lab and verify exactly which prefixes are advertised before and after the change.

BGP Key Concepts: Verification commands to practice

• show ip bgp summary confirms neighbor state, prefixes received, and session uptime.
• show ip bgp displays learned paths, best-path selection, AS_PATH, next hop, and attributes.
• show ip bgp neighbors advertised-routes checks what the local router sends to a peer.
• show ip bgp neighbors received-routes checks what the peer sent before inbound policy is applied, when soft reconfiguration or route refresh support is available.
• show ip route confirms whether the selected BGP path actually installed in the routing table.

Related BGP resources

• BGP configuration walks through neighbor setup and route advertisement.
• BGP path attributes explains the full best-path decision process.
• BGP routing policies covers prefix lists, route maps, and attribute changes.
• AS Number Calculator converts ASN formats used in BGP labs and provider documentation.
• Routing Practice Test checks BGP fundamentals alongside other routing protocols.

Connect the Control Plane to Forwarding

BGP can establish a session and exchange routes while traffic still fails. The peer address must be reachable for TCP port 179, and every selected route must have a reachable next hop. iBGP often depends on an IGP to carry loopbacks and external next hops; BGP does not replace that internal reachability design.

Separate three questions during verification: did the router receive the prefix, did BGP select it as best, and did the route reach the routing table? Policy, next-hop resolution, administrative distance or a competing route can produce different answers at each stage. Also verify the return path because asymmetric routing may interact with firewalls and stateful services.

Use the BGP overview for protocol roles, path attributes for selection, configuration examples, and policy controls.