BGP Complete Guide

What is BGP?

Border Gateway Protocol is the Internet’s inter-domain routing protocol. It exchanges reachability information between autonomous systems and applies policy to decide which paths should be accepted, preferred and advertised.

BGP is described as a path-vector protocol because an advertisement carries the autonomous-system path and other attributes. Unlike OSPF, it does not select a route merely because a link has the lowest technical cost. Operators can influence routing with attributes and policy.

Exam point: BGP-4 uses TCP port 179. TCP provides reliable delivery, while BGP itself manages routing policy, state and route advertisements.

eBGP versus iBGP

Feature	eBGP	iBGP
Purpose	Exchanges routes between different autonomous systems.	Distributes BGP routes within the same autonomous system.
Neighbour AS	Different AS number.	Same AS number.
Typical use	Enterprise-to-ISP, ISP-to-ISP, multi-homing.	Route reflectors, edge-to-core policy distribution.
Loop prevention	AS_PATH detects the local AS in the path.	Routes learned from one iBGP peer are not normally advertised to another iBGP peer unless route reflection or confederations are used.
Next hop	Commonly changed when advertising externally.	May remain unchanged, so internal reachability to the next hop is essential.

A basic iBGP design requires full-mesh peering because of the iBGP advertisement rule. Large networks usually use route reflectors to reduce the number of sessions.

BGP message types

Message	Purpose	Key point
OPEN	Starts the BGP session and negotiates parameters.	Carries BGP version, autonomous system, hold time, BGP identifier and optional capabilities.
UPDATE	Advertises new reachable prefixes and withdraws unreachable ones.	Carries path attributes and NLRI.
KEEPALIVE	Confirms that the peer is reachable and prevents hold-timer expiry.	Contains only the fixed BGP header.
NOTIFICATION	Reports an error and closes the session.	Useful for diagnosing capability, ASN, timer and malformed-message problems.
ROUTE-REFRESH	Requests re-advertisement after policy changes.	Capability-based extension; avoids resetting the session in supported implementations.

BGP finite-state machine

Idle

Connect

Active

OpenSent

OpenConfirm

Established

Idle: resources are initialised and the router waits to begin.
Connect: the TCP connection is in progress.
Active: TCP failed or is being retried. A peer stuck here often points to reachability, ACL, source-address or TCP/179 problems.
OpenSent: an OPEN has been sent and the router validates the peer’s OPEN.
OpenConfirm: the router waits for KEEPALIVE or NOTIFICATION.
Established: UPDATE, KEEPALIVE and ROUTE-REFRESH messages can be exchanged.

Common misunderstanding: “Active” does not mean the BGP session is healthy. Established is the operational state.

Important BGP path attributes

Attribute	Category	How it is used
ORIGIN	Well-known mandatory	Indicates whether the route originated through IGP, EGP or incomplete information.
AS_PATH	Well-known mandatory	Lists traversed autonomous systems; prevents loops and commonly favours a shorter path.
NEXT_HOP	Well-known mandatory	Specifies the next-hop address that must be reachable.
LOCAL_PREF	Well-known discretionary	Higher value is preferred inside an AS; commonly controls outbound exit choice.
MED	Optional non-transitive	Lower value is commonly preferred; suggests the preferred entry point to a neighbouring AS.
COMMUNITY	Optional transitive	Tags routes so policy can be applied to groups of prefixes.
ATOMIC_AGGREGATE / AGGREGATOR	Aggregation-related	Signal aggregation details and possible loss of path specificity.
Weight	Vendor-specific	Cisco-local attribute; higher is preferred and it is not advertised to peers.

Attribute classification matters in interviews. “Well-known” attributes must be understood by every BGP implementation. “Transitive” optional attributes can be passed onward even when a router does not recognise them.

How BGP selects the best path

The exact decision process varies by vendor, features and configuration. A common enterprise sequence checks that the route and next hop are usable, then considers locally significant policy before later tie-breakers.

Highest vendor-local weight, where supported.
Highest LOCAL_PREF.
Prefer a route originated locally.
Shortest AS_PATH.
Lowest ORIGIN type: IGP before EGP before incomplete.
Lowest MED when the implementation considers the paths comparable.
Prefer eBGP over iBGP.
Lowest IGP metric to the BGP next hop.
Additional tie-breakers such as oldest path, router ID and neighbour address.

Memory idea: Policy first, path length next, origin and MED after that, then session type and internal reachability.

Do not memorise one vendor’s list as a universal standard. In a practical answer, say which platform you are describing.

Core design concepts

Route reflectors

A route reflector can advertise routes learned from one iBGP client to another client, avoiding a full mesh. The design must still provide redundancy and avoid creating a single control-plane failure point.

Communities

Communities allow operators to attach policy labels. They are useful for controlling local preference, export scope, blackholing workflows and provider-specific routing actions.

Route filtering

Prefix lists, AS-path filters, route maps and policy statements should restrict what is accepted and advertised. Never assume that a BGP peer will send only intended routes.

Maximum-prefix and session protection

Maximum-prefix limits, authentication where supported, control-plane ACLs and infrastructure reachability checks reduce operational risk.

Basic BGP configuration example

Cisco IOS-style example

router bgp 65010
 bgp log-neighbor-changes
 neighbor 203.0.113.2 remote-as 65020
 neighbor 203.0.113.2 description ISP-EDGE
 !
 address-family ipv4 unicast
  network 198.51.100.0 mask 255.255.255.0
  neighbor 203.0.113.2 activate
  neighbor 203.0.113.2 prefix-list ISP-IN in
  neighbor 203.0.113.2 prefix-list OUR-PREFIXES out
  maximum-paths 2
 exit-address-family
!
ip prefix-list OUR-PREFIXES permit 198.51.100.0/24
ip prefix-list ISP-IN permit 0.0.0.0/0

The syntax is illustrative. Before advertising a network, confirm that the exact prefix exists in the routing table or use an intentional aggregation/static-route design. Apply filters in both directions.

BGP troubleshooting workflow

Check IP reachability: verify the peer address and source interface.
Check TCP/179: inspect ACLs, firewalls, NAT and control-plane policy.
Check neighbour parameters: remote AS, update source, multihop and authentication.
Check state and notification reason: Active, OpenSent and repeated resets narrow the fault domain.
Check received and advertised routes: policy may be filtering everything.
Check next-hop reachability: a route can be received but unusable.
Check RIB/FIB installation: another protocol or administrative preference may win.

Verification commands

show ip bgp summary
show ip bgp neighbors 203.0.113.2
show ip bgp
show ip bgp 198.51.100.0/24
show ip route 203.0.113.2
show ip bgp neighbors 203.0.113.2 advertised-routes
show logging | include BGP

Scenario: If the session is Established but no routes appear, investigate address-family activation, inbound policy, received-route capability, network origination and next-hop validity before restarting the session.

Interview questions and model points

Why does BGP use TCP? Reliable ordered delivery and session management let BGP focus on routing information and policy.
What is the difference between LOCAL_PREF and MED? LOCAL_PREF is used inside the local AS and higher is preferred; MED is a suggestion to a neighbouring AS and lower is commonly preferred.
Why is iBGP full mesh required? An iBGP-learned route is not normally sent to another iBGP peer, which prevents loops but creates scaling pressure.
Why can a BGP route be present but not installed? The next hop may be unreachable, another route may be preferred, policy/RIB rules may reject it, or the path may be invalid.
How would you secure a BGP edge? Strict prefix and AS-path filtering, maximum-prefix, session authentication where supported, TTL security or equivalent, control-plane filtering, monitoring and route-origin validation processes.

Quick self-check

1. Which transport protocol and port does BGP use?

Answer: TCP port 179.

2. Which state means a BGP neighbour is operational?

Answer: Established.

3. Which attribute is generally preferred when its value is higher: LOCAL_PREF or MED?

Answer: LOCAL_PREF. MED is generally preferred when lower.

4. Why does AS_PATH help stop loops?

Answer: A router can reject an advertisement that already contains its own autonomous-system number.

5. Is Cisco Weight advertised to another router?

Answer: No. It is local to the router and is vendor-specific.

6. What is a route reflector used for?

Answer: To scale iBGP by reflecting routes between clients instead of requiring every router to peer with every other router.

7. What should be checked first when a peer is stuck in Active?

Answer: Basic reachability and TCP/179, then source address, ACL/firewall, ASN and session settings.

8. Can BGP choose a longer AS path?

Answer: Yes. Higher-priority policy such as weight or LOCAL_PREF can cause a longer AS path to be selected.

Frequently asked questions

1. Is BGP only used by Internet service providers?

Answer: No. Enterprises use BGP for multi-homing, cloud connectivity, data-centre edge routing and policy control.

2. What is the difference between the BGP table and routing table?

Answer: The BGP table can hold multiple BGP paths. Only the selected usable path is considered for installation in the main routing table.

3. Does a shorter AS_PATH always win?

Answer: No. Attributes evaluated earlier by the implementation, such as LOCAL_PREF or vendor-local Weight, can override it.

4. Why does a received BGP route show an unreachable next hop?

Answer: iBGP may preserve the external next hop. The internal network must know how to reach it, or the design may use next-hop-self.

Standards and further reading

Editorial note: Vendor commands and best-path tie-breakers can differ by platform and software release. Always verify production configuration against the device vendor documentation.