Historically, there was EGP. then came BGP which is a popular Exterior Gateway Protocol. It falls under neither the distance vector, nor the link state family; it is a path vector protocol.
The Border Gateway Protocol is a policy-based routing protocol; we can manipulate the routing packets according to various criteria. It is the protocol with the slowest convergence time.
Without tuning it, it behaves like RIP; path selection occurs based on the hop count, where hops are the autonomous system numbers.
The Border Gateway Protocol is used to interconnect between autonomous systems, such as:
- multihoming Internet connection: when the company has more than one Internet connection with more than one ISP
- ISP-to-ISP peering.
The Border Gateway Protocol builds path vectors. Each one of them contains:
- a path to a network prefix, and
- a list of path attributes (for example: the ORIGIN attribute which describes how the prefix was introduced into the Border Gateway Protocol). We’ll discuss them in the Attributes paragraph.
The path is a series of ASN in reverse order.
A BGP router chooses the best path based on its BGP routing policy.
A BGP announcement – aka BGP update message – is an update about one and only one path. It contains the following:
- a list of prefixes within the path
- the path attributes
Each autonomous system advertises the best path to reach the prefixes of the autonomous system behind it. In the figure, AS2 advertises to AS1 only the best path it has for AS11 prefixes.
BGP updates are triggered and incremental.
The BGP connection runs over TCP port 179. And despite that, the only reliability mechanism that the Border Gateway Protocol has is TCP ACKs.
When designing a network with BGP and you have some filtering in the network (such as a firewall or ACLs), make sure to allow the TCP/179 connection between BGP routers, in both ways, because you don’t know which router will initiate the BGP connection first.
BGP router vs BGP peer
A BGP router is also called a BGP speaker. It’s a router that runs the Border Gateway Protocol. However, a BGP peer is more than just that; it has established BGP neighborship with some other BGP routers.
it is recommended to establish BGP peering over loopback interfaces, because loopback interfaces never go down in a network.
- Notification: informs the Border Gateway Protocol that something “bad” happened.
When the UPDATE messages are exchanged, BGP does not need to exchange the KEEPALIVE messages.
Some connection scenarios
When a company is multihomed, there could be one of these BGP connection scenarios:
- ISPs send default routes to the company’s BGP routers. This is obviously the simplest scenario,
- ISPs send default routes and a portion of their BGP table.
When you have a connection to a single ISP, there is no need for the EGP. A simple default route would suffice.
There are four stages before two BGP routers become neighbors:
Between a company and an ISP, there could exist a peering agreement.
For example, an ISP could require network blocks of /18 to be announced by the client enterprise network, as part of the peering agreement.
There are three tables used by the Border Gateway Protocol. Two of them are typical:
- BGP neighbor table: list of peering relationships
- BGP table: list of BGP prefixes
- RIB: Routing Information Base. This is the classical routing table we used to see in a router. The best paths of BGP are inserted here.
Methods to advertise a BGP route
You can advertise a BGP route in one of the following ways:
– with the “network” statement
– with redistribution
– with an aggregate route
– with a default route “default-information originate”
Filtering routes in BGP can be done with one of the following commands:
- neighbor … prefix-list …
- neighbor … distribute-list …
- neighbor … filter-list …
- neighbor … route-map …
The protocol provides flexibility in the fact that it can customize individual route properties, while IGPs provide only the capability of customizing the metric (or cost) of the whole protocol. These properties are called attributes.
BGP attributes -aka BGP path attributes– are the massive metrics of BGP. There is about 80 attributes. And they fall under one of these categories:
- well-known attributes,
- optional attributes.
BGP route aggregation: it is the mechanism of route summarization, but specific to the Border Gateway Protocol.
The 10 rules of BGP path selection
Before giving the famous list of BGP path selection criteria, the network must have the following properties:
- Routes are synchronized
- there is are no AS loops
- the next hops are valid
Here are the 10 rules for path selection, ordered:
- highest Weight
- highest Local Preference
- existence of route with next hop 0.0.0.0
- shortest AS Path
- lowest Origin
- lowest MED
- EBGP routes are privileged over IBGP routes
- route through the closest IBGP neighbor
- prefer the oldest route
- lowest neighbor’s Router ID
The “Network” command
Without mask subcommand, we need to have a subnet in the routing table, that belongs to the classful network. But in my lab, even I have a subnet 188.8.131.52/16, I still don’t see it in the BGP Table:
However, with the mask subcommand, and by specifying the subnet, I can see it. I don’t still get it:
Auto Summary feature
If there’s auto-summary, a subnet that’s redistributed into Border Gateway Protocol will be shown in the BGP table in its classful network form. Otherwise, it’ll be shown as it is in the routing table.
Recall that the router will choose a best route from the BGP table and will advertise it.
with auto-summary: both subnets (off the routing table) will be summarized to 184.108.40.206/24, their classful network. Don’t forget to clear the session with neighbor after auto-summary:
Network 220.127.116.11/30 is there because it is advertised with a network command. But 18.104.22.168/29 is summarized to its classful network 22.214.171.124/24.
A shutdown on int ser1/0 of ROutside, and a debug is launched on R1.
The EGP searches for a route to its configured neighbor. Here, R1 has neighbor 126.96.36.199, and it is directly connected, as we can see in show ip route
Since ROutside serial interface is down, then 188.8.131.52 is no longer reachable, and BGP neighborship went to “Idle”:
no shutdown on R1:
And a no shutdown under ROutside serial1/0. We see that the neighborship is reestablished:
We see that OPEN messages are sent and expected to be received.
– if I receive a route from an IBGP peer, I do not advertise it, unless I have a route to its network in my routing table learned by an IGP
– is off by default
grouping some ASes into a new AS (AS-X). Routers external to AS-X only see AS-X –> useful to apply the same update policy to a group of ASes