eBGP and iBGP

BGP uses the same wire messages for eBGP and iBGP, but the meaning of a route changes at the autonomous-system boundary. eBGP exchanges routes between different policy domains and normally sends them with the local AS added to AS_PATH. iBGP exchanges routes within one policy domain and does not add a new AS hop.

That distinction drives transport, filtering, convergence, and scale. A router that treats an iBGP session like eBGP may advertise a route with the wrong next hop or accept a path that should have been filtered. A router that treats eBGP like iBGP may miss the split- horizon protection and create a routing loop.

The relationship is decided by ASN

The local BGP process is created once. Each neighbor is classified by comparing its remote AS with the local system ASN:

flowchart LR
  A["Customer edge<br/>AS 65001"] -->|"eBGP<br/>TTL starts at 1"| B["Provider edge<br/>AS 65002"]
  B -->|"iBGP<br/>same AS 65002"| C["Provider core<br/>AS 65002"]
  C -->|"iBGP"| D["Provider edge<br/>AS 65002"]
  D -->|"eBGP"| E["Customer edge<br/>AS 65003"]

The diagram is a policy map, not a physical path map. The transport between provider routers may traverse several IGP hops even though the BGP relationship is iBGP.

eBGP is direct by default

An eBGP speaker normally sends packets with IP TTL 1. The destination must therefore be directly connected from the chosen source address, or the design must explicitly change the TTL and validate the path. The common safe choices are:

• peer the provider address on the directly connected transit;
• peer loopback-to-loopback with update-source lo and a deliberate ebgp-multihop value;
• use a routed path with filters, GTSM, and a documented hop count;
• use a tunnel or routing-instance model when the session is intended to cross a logical boundary.

ebgp-multihop is not a substitute for route reachability. A high TTL cannot repair a missing return route, an ACL, an MTU problem, or a firewall that drops return packets. It only makes the IP packet capable of reaching the peer under the configured design.

iBGP uses a full mesh

Inside one AS, every router that participates in the iBGP mesh must learn every route directly from every other iBGP speaker. For N routers, a full mesh has N multiplied by N minus 1 divided by two sessions. Ten routers require 45 sessions; fifty routers require 1,225 sessions. The arithmetic explains why large networks adopt route reflectors or confederations.

The requirement exists because iBGP does not advertise a route learned from one iBGP peer to another iBGP peer. This is the split-horizon rule. It prevents a route received inside the AS from being copied around the same AS without a new policy decision.

flowchart TB
  R1["R1<br/>AS 65000"] <--> R2["R2<br/>AS 65000"]
  R2 <--> R3["R3<br/>AS 65000"]
  R3 <--> R1
  R1 -->|"learned from R2"| X["R1 must not re-advertise<br/>to R3 by iBGP"]
  X -. "exception: route reflector or confederation" .-> RR["Route reflector"]

The rule is about advertisement, not about local use. R1 may install and use a route learned from R2. It may also advertise that route to an eBGP customer or provider, because that advertisement crosses an autonomous-system boundary. It must not present the route to R3 as a new iBGP path unless a route reflector is configured or another explicit exception applies.

Canonical VyOS configuration

A direct eBGP session:

configure
set protocols bgp system-as 65000
set protocols bgp neighbor 192.0.2.2 remote-as 65100
set protocols bgp neighbor 192.0.2.2 description "Customer transit"
commit
save

A loopback-based iBGP session between two routers in AS 65000:

configure
set protocols bgp system-as 65000
set protocols bgp neighbor 192.0.2.2 remote-as 65000
set protocols bgp neighbor 192.0.2.2 update-source lo
commit
save

The older course shorthand places the ASN under the protocol node:

set protocols bgp 65000 neighbor 192.0.2.2 remote-as 65100

Use the current system-as form in a VyOS 1.5 LTS change record. The ASN-node form is useful when comparing FRR output, but it is not a reason to mix two configuration trees.

Scale and the two exceptions

A route reflector is an iBGP speaker that is allowed to break the split-horizon rule for routes received from a client. A reflector adds ORIGINATOR_ID and CLUSTER_LIST attributes so loops can be detected. A confederation divides a large public AS into private member ASes; member sessions use confederation-specific AS_PATH semantics.

Neither exception is free. Route reflectors require cluster and client discipline, and confederations add complexity to policy and troubleshooting. Use a full mesh when the router count is small and the operational team needs simple evidence. Introduce an exception when session count, convergence behavior, or topology scale justifies it.

How it fails

• Same ASN configured on both sides of a customer link. The operator expected eBGP, but FRR classifies the session as iBGP. The route may be present locally while the AS_PATH lacks the intended boundary.
• A directly connected address is unavailable. The source is a loopback or a routed address, but the peer expects a link-local adjacency. The session is not a valid eBGP session by default.
• One iBGP speaker is missing from the mesh. The route is visible on one edge and absent on another, even though every visible session is Established.
• An eBGP multihop path is one-way. The local router can open the TCP connection, but return packets are filtered or take a different path. The result is an intermittent session and misleading IGP reachability evidence.
• A route reflector is deployed without a cluster design. The reflection solves session count but creates a new loop domain that must be monitored and documented.

Validation

Use the state and the path together:

show bgp summary
show bgp neighbor 192.0.2.2
show bgp ipv4 unicast 198.51.100.0/24
show ip route 198.51.100.0/24

A healthy direct eBGP session shows the remote AS in the summary and Established in the state column. A healthy iBGP session shows the same AS and reaches Established over the intended source address. Then verify that the route selected on each router has the expected NEXT_HOP and AS_PATH.

Rollback

For a wrong ASN relationship, remove the affected neighbor and restore the known-good value:

configure
delete protocols bgp neighbor 192.0.2.2
commit
save

For a multihop change, first restore the single-hop or loopback design and then remove the TTL override. Do not leave disable-connected-check in place after its reason has disappeared. If the session is the operator access path, use commit-confirm and retain console access.

Cross-course references

XVII-VyOS-RoutingFund covers adjacency and the difference between control plane and data plane. XXIII-VyOS-BGPFund continues with AS_PATH and the RIB, while XXX-VyOS-BGPRouteReflectors covers the scalable iBGP exception. XXXI-VyOS-BGPTroubleshoot provides the state-based diagnostic method for a missing iBGP path. The OPNsense dynamic-routing material is useful for comparing FRR behavior on a different operating system.

Quiz