Inter-domain routing

Routing between 2 or more Autonomous Systems (AS)

BGP General ideas

BGPv4
Based on path-vector routing
Between distance vector and link-state routing
Uses (often non-coordinated) routing policies
Which can be problematic for convergence
BGP routers are also called BGP Speakers

You don't always need BGP
If there is only 1 (default) route

Path Vector vs Distance Vector vs Link-State

Distance vector:
Advertise the world to your neighbours
You know how to reach X with Y hops and tell your direct neighbours about it
Need iterations to learn the whole network
Link-state:
Advertise your links (neighbours) to the world
Get a complete view of the network
Use Dijkstra to calculate the shortest path

Path vector:
In between distance vector and link state
Only talk to their direct peers (similar to distance vector)
Pass information more similar to link state (pass the entire path instead of "to X takes Y hops)

Autonomous System (AS)

A connected group of networks and routers
Representing some set of assigned IP prefixes
Having a single, consistent routing policy, both internally, and externally

There can be multiple BGP speaker per AS
They need to advertise the same policies (consistent)
Use the same AS number

AS numbers get assigned by a registry (RIPE)

Providers, Customers and Peers

Customers pay providers to get internet service
One can be both a customer and provider at the same time

In OSPF performance is key, in BGP you need to make sure your customers do not sue you

Peers are nodes on the same level, e.g. ISP to ISP
They each have their own customers
If there are multiple routers, the node from which the routes split gets to make the decision based on it's policies

Routes

Customer -> provider relationship:
Customer advertises to it's provider all it's routes/prefixes that it has learned from it's own customers
Allows routes of the customer domain to be known throughout the internet
Advertisement and traffic go in opposite ways: if you advertise a route you want to receive traffic for that
Provider -> customer relationship:
The provider will advertise the routes it knows to it's customer
The customer receives a route towards all destinations reachable via the provider
Shared-cost peering relationship:
Established between domains having similar size and coverage
Domain only advertises internal routes, and from customers, but not those from other peers
If they were to advertise the routes of other peers, the traffic to said peer would flow through you, which is not always desirable

The AS abstraction

The AS peering does not have to reflect the topological reality
Members of a singular AS can also be spread geographically
If everyone were to peer with said router, all traffic would have to go quite far, increasing latency

AS Types

Stub:
Sends and receives to traffic from it's own hosts
Does not connect to others
If connected to one transit domain: single honed stub
If connected to multiple transit domains: multi-honed stub
Can also be classified on how much traffic goes in and out access-rich (receive) vs content-rich (send) stub domains
Transit:
Carry traffic that are not for their own networks
Internet Exchange Point (IXP)

Peering

Can either connect directly: private peering
Or go through an Internet Exchange like AMSIX

Path Attributes and BGP Routes

Advertised routes: prefix + attributes
Prefix: the destination being advertised
Two important attributes:
AS-PATH: list of ASes through which the advertisement has passed
NEXT-HOP: indicates specific AS-internal router to next-hop AS

Routing policies:
Gateways that receive advertisements use import policy to accept/decline paths
E.g. never route through as Y
Use export policy to determine whether learned routes get advertised to neighbouring ASes

Advertisements

An advertisement is an agreement to receive traffic

Import filter: specifies which routes will be accepted from which peers, non-acceptable routes are ignored and never used
Export filter: specifies which routes to advertise to peers
Ranking algorithm: used to select the best route among all the learned routes to the same prefix

Routing Preferences

1. Customers
2. Peers
3. Providers

Transit relationships are enforced by export filtering. Based on what you do or do not export you will have a transit relationship
Outgoing advertisements attract incoming traffic
DO NOT advertise provider or peer routes to other providers or peers
DO advertise all routes to customers
DO advertise customer routes to providers and peers

Routes received from customers should be validated to not advertise wrong prefixes

External and Internal BGP

eBGP:
Used to BGP neighbours between different ASes
Exchange route prefixes
Implement routes policies
iBGP:
Used for BGP neighbours inside one AS
Distribute learned prefixes inside the network to create a consistent view among all nodes in the domain
Insert locally originated prefixes, e.g. for customers that do not speak BGP

Routes imported from one iBGP peer are not distributed to another iBGP peer
To prevent possible loops
Loop detection is based on duplicates in AS paths
eBGP detects this between ASes
iBGP cannot detect this, as it is inside one AS

BGP Routing Information Bases (RIBs)

Adj-RIB-In (one per peer)
Holds unprocessed routes received from said peer
Loc-RIB (one per BGP speaker)
Holds routes after input filtering and best path selection
Needs an input policy per AS
A fixed algorithm is used for path selection
Adj-RIB-out(one per peer)
Routes after output filtering
Needs an output policy per AS

Route processing

Receive BGP update

• Install route in Adj-RIB-In
• Apply import policy: filter routes and tweak attributes
• Apply “best route selection”-algorithm
• Install selected route in Loc-RIB
• Influence IP forwarding table
• Apply export policy: filter routes and tweak attributes
• Possibly apply route aggregation
• Install exported routes in Adj-RIB-Outs

Transmit BGP update

• Send (modified parts of) Adj-RIBs-Outs to peers

We do all this to limit the size of the RIBs, otherwise:
Need more resources
Takes more time for processing/finding a prefix
Ballpark accuracy is usually good enough, the next hop will take care of it

BGP Protocol

Uses TCP port 179
eBGP usually connects directly to a neighbour on L2
Uses a TTL of 1, unless using multi-hop eBGP (which is rare)

Exchanges Network Layer Reachability Information (NLRI)
Prefixes that can or can no longer be reached through the router
Accompanied by BGP attributes used by the "best route selection" algorithm

Attributes

• LOCAL_PREF (Local Preference)
  • I prefer AS X over AS Y?
• AS_PATH: prefer shorter paths (not necessarily the best, e.g. low bandwidth AS)
• ORIGIN (historical)
• MULTI_EXIT_DISC (MED; Multi-exit-disctriminator)

Next Hop in eBGP and iBGP

F does not know how to get to A, so next hop becomes E

Attribute Types

Well-known, mandatory:

• AS_PATH
  • Sequence of ASes
  • Used for loop detection (if you find your own AS number)
  • Shortest path wins
  • Always prepend yourself to the path to make yourself part of it
    • Possibly multiple times to discourage the use of this route
• NEXT_HOP
• ORIGIN
  Well-known, discretionary
• LOCAL_PREF
  • Advertised inside an OS
  • Used for local policies
  • Default 100, highest wins
  • Prefer the routes that come from a certain node
• ATOMIC_AGGREGATE
  Optional, transitive
• COMMUNITIES
• AGGREGATOR
  Optional, non-transitive:
• MULTI_EXIT_DISC

Traffic usually follow AS_PATH in reverse

Multi-Exit Discriminator (MED)

Meant to be advertised between neighbouring ASes
Not transitive
Lowest wins

Both ASes have 2 speakers talking to one another
Internally, there are routes for network E and F, which I want to send to AS 2
We want to advertise these over both links, for redundancy
We want to influence AS 2 to use certain routes (lowest MED wins)
To E via A
To F via B
Only one best path is selected

Usually used for load balancing

Route selection:

1. Lowest IGP cost to BGP egress (Next Hop)
2. “Oldest” (that is already existing) received path
3. Lowest Router ID
4. Lowest neighbor IP addres