Lesson text for this page (click to expand)

iBGP

Lessons (6, study in order)

Lesson 1 - Why an AS still needs iBGP internally

Basics · about 8 min

Goal: Get clear on the one and only reason iBGP exists.

The problem: how do external routes get into the AS

Suppose AS100 has three devices R1, R2, R3, and only R1 has an eBGP session with AS200 outside.
R1 learns 20.2.2.0/24 from AS200. Now how do R2 and R3 find out about this route?

You can't import it into OSPF. The Internet has over 900,000 routes; stuffing all of them into OSPF would overwhelm the devices immediately -- an IGP's design goal is fast convergence over a small-scale topology, not carrying a massive number of routes.

So a second BGP needs to run inside the AS: iBGP. Its one and only job is to carry external routes around inside the AS.

The behavioral differences between iBGP and eBGP (just these)

| | eBGP | iBGP |
|---|---|---|
| AS number | different | same |
| requires direct connection | yes (TTL=1) | no, IGP reachability is enough |
| AS_PATH | its own AS added | unchanged |
| NEXT_HOP | changed to itself | unchanged |
| LOCAL_PREF | not sent | sent |
| loop prevention | AS_PATH | split horizon |

The next several lessons are entirely about the pitfalls the last two rows create.

Hands-on: look at an iBGP neighbor

Load the "Unreachable Next Hop" topology, go to the Topology & Neighbors page.
Notice that the three devices in AS100 all have iBGP neighbor relationships with each other (fully meshed), and sessions are built over Loopback.

Key takeaways

  • iBGP's one and only job is carrying external routes around inside the AS
  • You cannot import BGP routes into OSPF -- the scale simply doesn't match
  • When iBGP advertises a route, neither AS_PATH nor NEXT_HOP change

Lesson 2 - Why iBGP uses Loopback + the cost of a full mesh

Basics · about 10 min

Goal: The reasoning behind two common conventions.

Why sessions are built over Loopback

If a physical interface goes down, a session built on it goes down too, and BGP has to reconverge.
But inside an AS there are usually multiple paths, and as long as the device itself is alive, it should be reachable.

A Loopback is a logical interface -- it stays up as long as the device is alive. Using it for the session means that if one link goes down and the IGP reroutes, the BGP session is completely unaffected.

Command: peer <peer's Loopback> connect-interface LoopBack0
Prerequisite: the AS's internal IGP must advertise the Loopback address, or the session address is unreachable.

The full-mesh explosion

Because of split horizon (next lesson), iBGP requires a full mesh between every pair of devices.

n devices need n(n-1)/2 sessions:
- 5 devices -> 10
- 10 devices -> 45
- 50 devices -> 1225

This isn't just a configuration-volume problem: every session needs a maintained TCP connection and its own copy of Adj-RIB-In, which memory and CPU simply can't keep up with.

So real networks use a Route Reflector (RR) (lesson 5) or a confederation instead of a full mesh.

Hands-on: count them

On the Topology & Neighbors page, look at the number of iBGP sessions in AS100, then think about how many you'd need to configure if it grew to 10 devices.

Key takeaways

  • iBGP builds sessions over Loopback, so a link failure doesn't affect the session
  • The prerequisite is that the IGP advertises the Loopback address
  • A full mesh needs n(n-1)/2 sessions -- it stops scaling once the network gets large

Lesson 3 - iBGP split horizon (pitfall #1)

Troubleshooting · about 14 min

Goal: Understand why iBGP inside an AS can't be chained into a line.

The rule, verbatim

A route learned from an iBGP neighbor is never re-advertised to another iBGP neighbor.

Shorthand: iBGP only propagates one hop.

Why this rule needs to exist

eBGP relies on AS_PATH for loop prevention -- every time it crosses an AS, an AS number is added, and a route containing your own is dropped.

But when iBGP propagates inside an AS, AS_PATH doesn't change at all, so there's no way to use AS_PATH to tell "has this route looped back around".

Since there's no way to detect the loop, the solution is simply not to let it propagate a second time -- that's split horizon.
The cost is that a full mesh becomes mandatory; the benefit is that a loop is absolutely impossible.

Hands-on: watch R3 fail to learn the route with your own eyes

Load the "iBGP Split Horizon" topology: inside AS100 only R1<->R2 and R2<->R3 are configured, R1<->R3 is missing.
R4 (in AS200) advertises 20.2.2.0/24.

Go to the Topology & Neighbors page and click "Control-plane Traffic":
(1) R1 learns it from eBGP -> advertises it to iBGP neighbor R2 (this hop is fine);
(2) R2 tries to advertise it on to R3 -> blocked by split horizon, and the explanation panel on the right will tell you the rule and the fix directly;
(3) click "Data-plane Traffic" and you'll see R3's row marked "unreachable".

Three ways to fix it

(1) Full iBGP mesh: add the missing R1<->R3 session. The most direct fix for a small network.
(2) Route Reflector (RR): make R2 an RR, with R1 and R3 as its clients. An RR is allowed to reflect a client's routes to other iBGP neighbors.
(3) Confederation: split a large AS into several sub-AS's that run eBGP-like sessions between them. More complex to configure, used less than RR in real networks.

Hands-on: go back to the Topology & Neighbors page, add an R1<->R3 neighbor, and come back to check.
Warning: you'll find that R3 receives the route but still can't use it -- because this newly built iBGP session also needs next-hop-local configured on the R1 side (covered in the next lesson). These two pitfalls frequently show up together, which is exactly why BGP troubleshooting has to be peeled back one layer at a time, in order.

Key takeaways

  • A route learned from iBGP isn't re-advertised to other iBGP neighbors -- iBGP only propagates one hop
  • The root cause is that AS_PATH doesn't change as iBGP propagates it, so it can't detect loops
  • The fix: full mesh / RR / confederation

Lesson 4 - Unreachable next hop (pitfall #2)

Troubleshooting · about 14 min

Goal: Understand exactly what's going on when "the route is in the table but doesn't work".

Symptom

display bgp routing-table shows the route, but:
- there is no * marker in front of it (invalid)
- it hasn't made it into the IP routing table
- ping fails

while the neighbor state is completely normal, and the route really was received. This is where beginners usually get stuck.

Root cause

R1 (the AS100 border device) learns 20.2.2.0/24 from R4 (AS200), with NEXT_HOP 172.16.14.2 (R4's address on the interconnect link).

When R1 advertises this route to iBGP neighbor R2, NEXT_HOP doesn't change -- it's still 172.16.14.2.

But R2's IGP (OSPF) only contains AS100's internal subnets -- it has no route for 172.16.14.0/30 at all, because that's an inter-AS interconnect address, and AS100's IGP never advertises it.

So R2 ends up with a next hop it can never reach -> rule 1 of path selection immediately marks it invalid.

Hands-on: look at the diagnostics

Load the "Unreachable Next Hop" topology, go to the Topology & Neighbors page, click "Control-plane Traffic" and play back 20.2.2.0/24.
At the R1 -> R2 step, the explanation panel on the right will flag "NEXT_HOP unchanged" and warn about an unreachable next hop;
then click "Data-plane Traffic" and you'll see both R2 and R3 marked "unreachable", with the reason given as an unreachable next hop, not split horizon.

The fix: next-hop-local

On the border device (R1), for its iBGP neighbor, configure:

peer 2.2.2.2 next-hop-local

(Cisco: neighbor 2.2.2.2 next-hop-self)

Meaning: for routes advertised to this iBGP neighbor, change the next hop to myself (R1's Loopback). R1's Loopback is inside AS100's IGP, so R2 can reach it.

Memory aid: next-hop-local is configured on the border device, in the direction facing an iBGP neighbor.

Hands-on: go to the Topology & Neighbors page, select the R1<->R2 neighbor, check next-hop-local, and come back to see the route become valid.

Another theoretically workable but not recommended approach: also advertise the inter-AS interconnect subnet into the IGP. Not recommended because importing external addresses into the internal IGP is neither secure nor easy to maintain.

Key takeaways

  • iBGP advertisements don't change NEXT_HOP, so internal devices end up with another AS's address
  • The IGP never advertises inter-AS interconnect subnets, so that next hop is unreachable
  • Signs of an invalid route: no * marker, doesn't make it into the IP routing table
  • The fix: configure next-hop-local on the border device, facing iBGP neighbors

Lesson 5 - Route Reflectors (RR)

Advanced · about 14 min

Goal: Use an RR to escape the iBGP full mesh, and understand its own loop-prevention mechanism.

What an RR does

An RR is a granted exception to the split-horizon rule:

designate one device as the RR, then mark some of its iBGP neighbors as its clients, with the rest being non-clients. The reflection rules are:

- a route learned from a client -> reflected to all iBGP neighbors (other clients + non-clients)
- a route learned from a non-client -> reflected only to clients
- a route learned from eBGP -> sent to all iBGP neighbors (already allowed anyway)

Clients don't need to change anything themselves -- they don't even know the other side is an RR.
So n devices go from n(n-1)/2 sessions down to n-1.

How an RR prevents loops on its own

Once split horizon is relaxed, a new loop-prevention mechanism is needed, based on two attributes:

- ORIGINATOR_ID: records which device originally injected the route into the AS (its Router-ID). A device that receives a route whose Originator_ID equals its own knows it has looped back, and drops it.

- CLUSTER_LIST: every time it's reflected by an RR, that RR's Cluster-ID gets prepended. If an RR sees its own Cluster-ID already in the list, it knows it's gone in a circle, and drops it.
As a side effect, a shorter Cluster_List is preferred (path-selection rule 10).

Hands-on: watch an RR reflect a route

Load the "Route Reflector" topology: RR is the reflector, R1 and R3 are its clients, and R3 also has an eBGP session with R4 in AS200.
Go to the Topology & Neighbors page, click "Control-plane Traffic" and play back 20.2.2.0/24:
(1) R3 learns it from eBGP and advertises it to RR;
(2) RR reflects it to client R1 -- note that without an RR, this step would be blocked by split horizon;
(3) click this step and the "Attribute Changes" panel shows two new attributes: Originator_ID and Cluster_List.

Key takeaways

  • An RR is a granted exception to iBGP split horizon
  • Routes from a client are reflected to all iBGP neighbors; routes from a non-client are reflected only to clients
  • Clients require no special configuration at all
  • An RR prevents loops using Originator_ID and Cluster_List

Lesson 6 - LOCAL_PREF and a unified AS-wide exit policy

Advanced · about 10 min

Goal: Understand why LOCAL_PREF is the tool for controlling outbound traffic.

What LOCAL_PREF is for

- Default 100, higher is better, path-selection rule 3 (very early in the list, which is exactly why it's so useful).
- Propagated only within the AS, never sent to eBGP neighbors.

Precisely because it propagates internally via iBGP, it expresses the unified will of the entire AS: no matter which internal device originates the traffic, everyone agrees on exiting through a particular gateway.

A typical scenario

AS100 is dual-homed to two ISPs: AS200 is primary (large bandwidth), AS300 is backup.

Approach: on the border device connected to AS200, apply local-preference 200 to inbound routes.
This LOCAL_PREF=200 propagates via iBGP to every device in AS100, so the entire AS consistently prefers exiting through AS200. If AS200 goes down, it automatically switches to AS300.

Comparison to remember:
- to change the path traffic takes leaving your own AS -> adjust LOCAL_PREF (this AS calls the shots on its own)
- to change the path traffic takes coming in from others -> adjust AS_PATH prepend or MED (these can only be suggestions -- the other side is free to ignore them)

Hands-on: flip the outcome in your head

Walk through these two hypothetical candidate routes yourself:

A: AS_PATH=[200]           LOCAL_PREF=100
B: AS_PATH=[200,300,400]   LOCAL_PREF=200

First guess who wins by intuition, then actually compute it in rule order: Preferred-Value ties (rule 2) -> LOCAL_PREF breaks the tie right at rule 3, B's 200 beats A's 100, and AS_PATH length after that is never even looked at.

The conclusion is quite counterintuitive: B, with the much longer AS_PATH, wins anyway, because LOCAL_PREF is rule 3 while AS_PATH doesn't get a turn until rule 5 -- once an earlier rule has broken the tie, the later rules have zero effect on the result.

Key takeaways

  • LOCAL_PREF defaults to 100, higher is better, and it's path-selection rule 3
  • It propagates only within the AS, representing the entire AS's unified exit policy
  • Use LOCAL_PREF to change outbound paths, AS_PATH prepend / MED to change inbound paths
  • LOCAL_PREF is compared earlier than AS_PATH, so it overrides it