BGP

Inside one AS, routing is controlled by one organization. The administrator can normally choose one routing objective, for example:

• shortest path,
• lowest link cost,
• load distribution,
• fast convergence.

Examples of intra-AS routing protocols:

• OSPF,
• IS-IS,
• EIGRP,
• RIP.

Inside an AS, routers usually trust each other more and can expose detailed topology information.

Between ASes, the situation is different.

Each AS is owned by a different organization. These organizations may be customers, providers, peers, or competitors.

So inter-AS routing must answer questions like:

• Which routes do I accept from another AS?
• Which routes do I prefer?
• Which routes do I advertise to another AS?
• Do I want to carry transit traffic for this neighbor?
• Am I being paid to carry this traffic?
• Should customer routes be preferred over peer or provider routes?

This is why policy often matters more than shortest distance in BGP.

A prefix is an IP address block, for example:

192.0.2.0/24
160.10.0.0/16
2001:db8:1::/48

BGP routes are routes to prefixes, not routes to individual hosts.

An Autonomous System is a network under one administrative domain.

Each AS has an AS number, for example:

AS64496
AS64497
AS64498

A BGP speaker is a router running BGP.

Two BGP routers that exchange BGP messages are called peers or neighbors.

Important detail:

BGP peering does not necessarily correspond to a direct physical link. A BGP session is a logical TCP connection.

A BGP session is a semi-permanent TCP connection between two BGP peers.

BGP uses TCP port 179.

Because BGP runs over TCP, BGP itself does not need to implement its own reliable transport mechanism.

eBGP means external BGP.

It is used between routers in different ASes.

Example:

AS64496 router 1c  <--- eBGP --->  AS64497 router 2a

eBGP is used to exchange reachability information between ASes.

iBGP means internal BGP.

It is used between routers inside the same AS.

Example:

AS64497 router 2a  <--- iBGP --->  AS64497 router 2c

iBGP is used to distribute externally learned BGP routes inside one AS.

A gateway router often runs both eBGP and iBGP:

• eBGP to talk to external ASes,
• iBGP to share learned routes with routers inside its own AS.

Suppose destination prefix X is inside AS64498.

1. AS64498 advertises X to AS64497 over eBGP.
2. A gateway router in AS64497 receives the route.
3. AS64497 uses iBGP to distribute this route inside AS64497.
4. Another gateway router in AS64497 may advertise the route further to AS64496 over eBGP.
5. Routers that learn the route can install forwarding entries for prefix X.

So BGP reachability information travels between ASes through eBGP, and inside an AS through iBGP.

When an AS advertises a route, it prepends itself to the AS path.

Example:

AS64498 originates prefix X.

AS64498 advertises:
  AS-PATH: AS64498

AS64497 receives it and advertises to AS64496:
  AS-PATH: AS64497 AS64498

The AS path tells other ASes which ASes would be traversed to reach the prefix.

If AS64498 advertises a path to X to AS64497, it is essentially promising:

If you send traffic for X to me, I know how to forward it toward X.

BGP advertisements therefore describe reachability, but they also imply willingness to carry traffic.

The OPEN message starts a BGP session.

It opens the BGP connection and includes information used to establish the session.

It can also be used for authentication-related negotiation.

UPDATE messages are the most important BGP messages.

They are used to:

• advertise new routes,
• update route attributes,
• withdraw old routes.

BGP does not periodically send the whole table forever. After the initial exchange, BGP mostly sends incremental updates.

KEEPALIVE messages keep the connection alive when there are no UPDATE messages.

They also acknowledge an OPEN message.

A NOTIFICATION message reports an error and closes the connection.

For example, if a peer sends a malformed BGP message, the other side may respond with NOTIFICATION and terminate the session.

If a router sees its own AS number in the AS-PATH, it rejects the route.

Example:

AS64497 receives:
  AS-PATH: AS64496 AS64497 AS64498

AS64497 sees itself in the AS-PATH, so accepting this route would create a loop. Therefore, it rejects the route.

A shorter AS-PATH is often preferred, but only after higher-priority policy rules such as local preference.

So shortest AS-PATH does not always win.

Import policy is applied when a route is received.

It can:

• reject a route,
• accept a route,
• change attributes,
• set LOCAL_PREF,
• attach communities,
• modify MED or other attributes.

After import policy, the router may have multiple routes to the same prefix.

It then chooses one best route according to BGP route selection rules.

Export policy is applied before advertising routes to neighbors.

It can decide:

• which routes to advertise,
• which routes not to advertise,
• which attributes to modify before advertisement.

This is how BGP enforces business policy.

Longest-prefix matching is fundamental.

Example:

192.0.2.0/24
192.0.2.128/25

For destination:

192.0.2.150

Both prefixes match, but /25 is more specific than /24, so /25 wins.

This rule is not only a BGP rule. It is also the basic IP forwarding rule.

LOCAL_PREF is usually the most important policy knob inside an AS.

Example:

Route through provider:
  LOCAL_PREF = 100

Route through peer:
  LOCAL_PREF = 200

Route through customer:
  LOCAL_PREF = 300

The customer route wins.

This reflects the common business policy:

customer > peer > provider

MED is used when one neighboring AS advertises multiple possible entry points.

Lower MED is usually better.

MED is weaker than LOCAL_PREF.

So if one route has a higher LOCAL_PREF, it may win even if its MED is worse.

If policy attributes do not decide the route, BGP may prefer the shorter AS path.

Example:

Route A:
  AS-PATH: 64497 64498

Route B:
  AS-PATH: 64499 64500 64498

Route A is shorter, so it may be preferred.

But this rule is not absolute. Policy can override it.

Hot potato routing means:

Send traffic out of my own AS as quickly as possible.

If an AS has multiple exit points for a destination, it may choose the exit point with the lowest internal IGP cost.

Example:

A router inside AS64497 learns two routes to X:

Route 1 exits via router 2a.
Route 2 exits via router 2c.

If router 2d is internally closer to 2a than to 2c, it chooses 2a.

This may happen even if the external AS path after 2a is longer.

Hot potato routing optimizes internal cost, not global path quality.

A provider sells connectivity to customers.

A provider may offer transit to the rest of the Internet.

A customer buys connectivity from a provider.

Customer routes are usually attractive to providers because customers pay.

Peers exchange traffic between their own customers, usually without payment.

A peer normally does not want to provide free transit between another peer and an upstream provider.

Sibling ASes are related organizations with a special relationship. The lecture lists siblings as another category.

A transit AS allows traffic to pass through even if neither the source nor the destination is inside the AS.

Example:

Source: AS701
Destination: AS144
Traffic crosses AS1

If AS1 allows this, AS1 is acting as a transit AS.

Large ISPs are often transit ASes.

A non-transit AS only allows:

• traffic originating inside the AS,
• traffic destined to the AS.

It does not want to carry traffic between two external ASes.

Many enterprise networks are non-transit ASes.

A stub AS has only one connection to the Internet.

It does not need to carry transit traffic.

A simple stub AS may not need full BGP.

It can use:

• a default route toward the upstream provider,
• a static route from the provider toward the customer’s prefix.

Example:

Customer prefix:
  192.0.2.0/24

Customer sends unknown destinations to provider using default route:
  0.0.0.0/0 -> upstream provider

Provider routes customer prefix statically:
  192.0.2.0/24 -> customer

A multihomed AS has connections to multiple providers.

This improves reliability and possibly performance.

But routing becomes harder.

The AS may need BGP because:

• it has multiple possible exits,
• providers need to know how to reach the customer’s prefix,
• the customer may want traffic engineering,
• static routes are not flexible enough.

Suppose the customer receives address space from ISP1.

Example:

ISP1 aggregate:
  2001:db8::/32

Customer prefix:
  2001:db8:1::/48

ISP1 may advertise the aggregate /32.

The customer may advertise the more specific /48 through ISP2.

Because longest-prefix matching prefers /48 over /32, traffic from some parts of the Internet may go through ISP2.

This can create traffic imbalance.

Suppose ISP1 internally aggregates routes to reduce table size.

ISP1 may still announce the /32 aggregate externally.

But if ISP1 learns the customer’s /48 from ISP2, longest-prefix matching may cause ISP1 to send traffic to the customer through ISP2, even though the customer is directly connected to ISP1.

Workaround:

ISP1 must inject the customer’s more specific /48 into iBGP internally.

The customer may get one prefix from ISP1 and another prefix from ISP2.

This can help split traffic, but it has a reliability problem.

If the link to ISP1 fails, the prefix from ISP1 may become unreachable unless it is also advertised through ISP2.

So address space from both providers does not automatically solve failover.

The customer can obtain provider-independent address space.

This gives the most control, but it reduces aggregation and increases global routing table entries.

In practice, the global routing table usually filters very small prefixes.

Common rough limits:

• IPv4: usually /24 or shorter is globally routable.
• IPv6: usually /48 or shorter is globally routable.

Here “shorter” means a less specific prefix, for example /23 is shorter than /24.

Suppose AS B learns a route to customer W through AS A.

B could advertise this route to AS C, allowing C to reach W through B.

But B may choose not to advertise this route to C.

Why?

Because B would be carrying traffic from C to W, but neither C nor W is B’s customer. So B gets no revenue.

Therefore, B does not advertise the route to C.

As a result, C must choose another route, for example through A.

Suppose customer X is connected to both B and C.

X does not want to carry traffic from B to C.

Therefore, X does not advertise routes learned from C to B.

This prevents B from using X as a transit path to C.

An iBGP peer does not advertise a route learned from one iBGP peer to another iBGP peer.

This is the iBGP readvertisement restriction.

Reason:

It prevents routing loops inside the AS.

Consequence:

All iBGP peers must be logically fully meshed, unless route reflectors or confederations are used.

If an AS has N iBGP routers, a full mesh requires:

\[ \frac{N(N-1)}{2} \]

iBGP sessions.

This does not scale for large networks.

Example:

N = 100 routers

Number of iBGP sessions:
  100 * 99 / 2 = 4950

That is too many sessions to manage manually.

A route reflector is an iBGP router that is allowed to pass routes between its clients.

Clients peer with the route reflector instead of forming a full mesh with every other router.

The route reflector passes updates to its client routers.

However, route reflectors themselves often need to be carefully connected, and multiple route reflectors may need to be fully meshed.

Intuition:

Route reflectors reduce the number of iBGP sessions by replacing full mesh with a hub-and-spoke-like structure.

A BGP confederation splits one large AS into multiple smaller internal ASes.

To the global Internet, the whole confederation still looks like one AS.

Example:

Global view:
  AS64496

Internal confederation:
  AS65536
  AS65537
  AS65538

Inside, the AS is divided for scaling. Outside, other ASes see only AS64496.

Suppose two routers in different ASes are connected directly:

AS64496 R1 --- R2 AS64497

There is an eBGP session over that physical link.

If the physical link fails:

• the TCP connection breaks,
• the BGP session goes down,
• routes learned through that session are removed.

This is desired behavior.

If the external link is down, routes through that external neighbor should no longer be used.

Inside one AS, the physical link between two iBGP peers may fail, but they may still be reachable through another internal path.

Example:

R1 --- R2
 \     /
   R3

If the direct link R1-R2 fails, R1 and R2 may still communicate through R3.

For iBGP, this is acceptable.

iBGP sessions can run over multiple internal hops.

So:

• eBGP is usually tied more closely to the external link.
• iBGP is often multi-hop and can survive internal link failures if the IGP still provides connectivity.

Prefer routes in this order:

customer routes > peer routes > provider routes

Why?

• Customer routes generate revenue.
• Peer routes are usually settlement-free.
• Provider routes cost money.

Export routes according to valley-free routing:

• Routes learned from customers can be exported to everyone.
• Routes learned from providers or peers should only be exported to customers.

This prevents an AS from providing unpaid transit between providers and peers.

A valley-free AS path has this rough shape:

uphill customer-to-provider links
then maybe one peer-to-peer link
then downhill provider-to-customer links

It should not go:

provider -> customer -> provider

in a way that gives unpaid transit.

The valley-free principle is one of the most important policy ideas in Internet routing.

Discovery is mostly configured manually.

BGP does not automatically discover neighbors like some IGPs.

Neighbor maintenance is done with TCP and BGP KEEPALIVE messages.

The database granularity is prefixes.

BGP stores routes to network prefixes, together with attributes.

Updates are incremental and filtered by policy.

At session startup, peers exchange their relevant routes.

After that, they exchange incremental updates.

The “metric” is not a simple numeric distance.

The route choice is based on policy and attributes.

The route calculation is BGP best-route selection.

Inter-AS routing needs policy because each AS has its own administrative and business goals.

Intra-AS routing usually has one administrator, so policy conflicts are less central.

The Internet is too large for everyone to know every internal topology.

Hierarchical routing with ASes reduces routing table size and update traffic.

Intra-AS routing can focus more directly on performance.

Inter-AS routing is often dominated by policy.

A path that is technically shorter may be rejected because it violates business policy.