What BGP is and the problem it solves
Border Gateway Protocol (BGP) is the routing protocol used to exchange reachability information between autonomous systems and, in many designs, to distribute policy-controlled routes inside a large routing domain. Unlike an IGP such as OSPF, BGP is designed around path attributes and policy rather than a simple shortest-path metric.
On the public Internet, BGP allows independently administered networks to advertise IP prefixes and apply policy to which routes they accept, prefer, or announce.
Autonomous systems, eBGP, and iBGP
An Autonomous System (AS) is a routing domain under a defined administrative policy and is identified by an Autonomous System Number. BGP sessions between different ASes are called eBGP; BGP sessions inside the same AS are called iBGP.
The two session types serve related but different purposes. eBGP exchanges reachability across administrative boundaries, while iBGP distributes BGP routes and policy inside an AS without pretending that internal routers are separate Internet organizations.
BGP sessions run over TCP
BGP establishes a session between peers using TCP port 179. TCP provides reliable ordered transport for BGP messages, while BGP itself manages routing state, keepalives, updates, withdrawals, attributes, and policy.
A BGP session therefore depends first on IP reachability between the peer addresses. If TCP cannot be established, there is no point debugging route attributes yet. Start with interfaces, routing, ACLs, and the chosen source addresses.
Prefixes and BGP path attributes
BGP advertises reachability information, commonly described as NLRI, together with path attributes. Important attributes include AS_PATH, NEXT_HOP, LOCAL_PREF in many iBGP designs, and other values used for policy and route selection.
AS_PATH records which autonomous systems a route has traversed and also helps prevent inter-AS loops. NEXT_HOP tells a router where traffic should be sent next. Attributes are not merely descriptive; they are the raw material used by routing policy.
Route selection: do not memorize one “universal” list
BGP implementations compare multiple attributes when several paths exist for the same prefix. The exact decision process includes protocol rules plus vendor-specific details and configurable policy. It is useful to understand common attributes, but risky to memorize one vendor's ordered list as if it were the protocol specification.
Always ask first whether the route was accepted by policy, whether the next hop is reachable, and which attributes were changed locally before interpreting a final best-path decision.
Policy, filtering, and controlled advertisements
BGP is powerful because it lets administrators express routing policy. Networks can filter which prefixes are accepted, limit what is exported to each neighbor, set preference attributes, prepend an AS path, attach communities, or steer selected traffic according to business and engineering requirements.
That flexibility also creates risk. A broad export policy can leak internal or customer routes to the wrong neighbor. A weak import policy can accept routes that should never influence forwarding. BGP configuration should therefore be explicit, reviewed, and monitored.
Aggregation, more-specific routes, and defaults
BGP can advertise aggregate prefixes when the address plan and policy allow it. More-specific routes can coexist with aggregates because normal IP forwarding still follows Longest Prefix Match. Policy decides which routes are advertised; forwarding decides which matching prefix is used for a packet.
Default routes also appear in BGP designs, especially when a downstream network does not need a full Internet table. The right level of detail depends on multihoming, traffic-engineering, and failure requirements.
BGP security: filters, limits, and origin validation
Operational BGP security starts with strict prefix filters, maximum-prefix limits, neighbor authentication or session-protection features supported by the platform, and careful control of what can be announced. Internet operators can also use RPKI-based Route Origin Validation to evaluate whether an AS is authorized to originate a prefix.
Origin validation does not prove that every path attribute is correct and does not replace local routing policy, but it helps reduce one important class of route-origin mistakes and hijacks.
Scaling BGP: full tables, route reflectors, and address families
Large BGP deployments can carry hundreds of thousands of routes and many policy attributes. Inside one AS, a full mesh of iBGP sessions does not scale indefinitely, so designs commonly use route reflectors to reduce the number of peer relationships.
BGP also supports multiple address families and is used beyond simple IPv4 Internet routing, including IPv6 and several VPN technologies. The fundamental ideas remain peer sessions, reachability information, attributes, and policy.
Troubleshooting a BGP session and a BGP route
Separate session problems from route problems. First confirm peer IP reachability, TCP/179 connectivity, correct AS numbers, source interface, authentication, and neighbor state. Once the session is established, inspect whether a specific prefix was received, filtered, selected, and exported as expected.
- Is the BGP session established?
- Is the prefix present in received routing information?
- Did an import policy reject it?
- Is NEXT_HOP reachable?
- Did another path win selection?
- Is export policy actually advertising the route to the next peer?
Use the routing table together with BGP-specific state. A route can exist in BGP's control plane without becoming the active forwarding route.