8.1 BGP Architecture and Peering

BGP connects routing policies

Border Gateway Protocol version 4 (BGP-4) exchanges destination prefixes and path attributes. It is the principal interdomain routing protocol of the Internet. The current NRS I course expects introductory BGP understanding: recognize autonomous systems, peer relationships, policy, and the difference between a working session and a usable route.

An Autonomous System (AS) presents a coherent routing policy. Public AS numbers (ASNs) identify domains in interdomain routing. Private ASNs are useful in private arrangements, but they require appropriate handling before public advertisement.

BGP chooses paths using policy and attributes. It does not measure real-time latency, and a shorter AS path need not contain fewer physical routers or offer better performance.

AS numbers and representation

ASNs originally used two octets; four-octet support expands the numeric space. Not every number in either space is publicly assignable.

Use IANA's registry for the complete allocation picture rather than treating every value outside the private ranges as a public assignment.

asplain writes an ASN as one decimal integer. asdot represents a four-octet value using high and low 16-bit portions. For example, 1.0 represents 1 × 65536 + 0 = 65536, and 2.0 represents 131072. Dotted notation does not turn the ASN into an IPv4 address.

For compatibility with a legacy two-octet speaker, four-octet BGP uses AS_TRANS (23456) where required and the AS4_PATH attribute to preserve information used for reconstruction. It does not replace every ordinary two-octet ASN in the path with 23456.

EBGP and IBGP

External BGP (EBGP) connects peers in different ASes. Internal BGP (IBGP) connects peers in the same AS. An IBGP session can span multiple underlying IP hops; the peers need not share a physical link.

An IGP commonly supplies internal peer reachability, but suitable static routes can also do so. Loopback peering improves independence from a single interface when alternate paths exist; it does not guarantee that every link failure leaves the TCP session unaffected.

Ordinary EBGP next-hop behavior usually identifies the advertising router on the external link. IBGP often preserves an external next hop. A receiving router must be able to resolve that next hop before using the route. The session can be Established while advertised routes remain unusable.

TCP and the state machine

BGP uses TCP port 179. TCP provides an ordered byte stream, retransmission, and flow control; IP handles IP fragmentation where applicable. A listening port is a transport endpoint, not the AS number.

The main session states are Idle, Connect, Active, OpenSent, OpenConfirm, and Established. “Active” is a connection-attempt state, not proof of a healthy routing session. After TCP succeeds and the local speaker sends OPEN, it is in OpenSent while awaiting the peer's OPEN. OpenConfirm follows successful OPEN processing, and Established permits routing updates.

Failure to reach TCP can reflect missing routes, filtering, an incorrect peer address, or source-address mismatch. Failure after OPEN can involve the expected peer AS, identifiers, or capabilities. Diagnose the actual state and error rather than assuming every failure is a password problem.

Messages and liveness

The four foundational RFC 4271 message types are:

• OPEN: Proposes session parameters and capabilities.
• KEEPALIVE: Maintains liveness without routing payload.
• UPDATE: Advertises reachability and attributes or withdraws routes.
• NOTIFICATION: Reports relevant session errors and closure conditions.

Extensions add messages such as Route Refresh. The negotiated Hold Time is not proof that the peers use identical locally configured keepalive intervals. UPDATEs also contribute to liveness. Error-handling extensions mean not every malformed route necessarily requires tearing down an otherwise usable session.

Basic MD-CLI peering fragment

Assume the link is configured and 192.0.2.2 is reachable. This private-AS example establishes a peering definition, not a complete public routing policy:

configure private
/configure router "Base" autonomous-system 64512
/configure router "Base" router-id 10.10.10.1
/configure router "Base" bgp admin-state enable
/configure router "Base" bgp group "external-lab" type external
/configure router "Base" bgp group "external-lab" peer-as 64513
/configure router "Base" bgp neighbor "192.0.2.2" group "external-lab"
compare
validate
commit

Inspect /show router bgp summary and the peer details. To exchange intended routes, configure appropriate address families and explicit import/export policies. Defining a neighbor does not automatically originate every connected route or authorize carrying a public Internet table.

Primary references

BGP specification, IANA special-purpose ASN registry, and Nokia peering reference, checked October 20, 2026.