How BGP works
BGP is a link-state routing protocol and keeps link-state information about the status of each network link it has connected. A BGP router receives information from its peer routers that have been defined as neighbors. BGP routers listen for updates from these configured neighboring routers on TCP port 179.
A BGP router is a finite state machine with six various states for each connection. As two BGP routers discover each other and establish a connection, they go from the idle state and through the various states until they reach the established state. An error can cause the connection to drop and the state of the router to reset to either active or idle. These errors can be caused by TCP port 179 not being open, a random TCP port above port 1023 not being open, the peer address being incorrect, or the AS number being incorrect.
When BGP routers start a connection, they negotiate which (if any) optional features will be used, such as multiprotocol extensions, that can include IPv6 and VPNs.
This section covers the following topics:
- iBGP versus eBGP
- BGP path determination: Which route to use
- Decision phase 1
- Decision phase 2
- Decision phase 3
- Aggregate routes and addresses
iBGP versus eBGP
When you read about BGP, you often see eBGP or iBGP mentioned. These are both BGP routing, but BGP used in different roles. eBGP involves packets crossing multiple autonomous systems, and iBGP involves packets that stay within a single AS. For example, the AS_PATH attribute is only useful for eBGP where routes pass through multiple autonomous systems.
These two modes are important because some features of BGP are used only for one of eBGP or iBGP. For example, both confederations and RRs are used only in iBGP.
FortiSwitch units have some commands that are specific to eBGP, including the following:
- automatically resetting the session information to external peers if the connection goes down:
set fast-external-failover {enable | disable}
- setting an administrative distance for all routes learned from external peers (you must also configure local and internal distances if this is set):
set distance-external <distance_integer>
- enforcing eBGP multihops and their TTL (number of hops):
set ebgp-enforce-multihop {enable | disable}
andset ebgp-multihop-ttl <seconds_integer>
BGP path determination: Which route to use
Firstly, recall that the number of available or supported routes is not set by the configuration but depends on the available memory on the FortiSwitch unit. All learned routes and their attributes come into the BGP router in raw form. Before routes are installed in the routing table or are advertised to other routers, three levels of decisions must be made.
The three phases of BGP best path determination do not change. However, some manufacturers have added more information to the process, such as Cisco’s WEIGHT attribute, to allow an administrator to force one route’s selection over another.
There is one Adj-RIB-IN and Adj-RIB-OUT for each configured neighbor. They are updated when the FortiSwitch unit receives BGP updates or when the FortiSwitch unit sends out BGP updates.
The three phases of a BGP routing decision
Decision phase 1
At this phase, the decision is to calculate how preferred each route and its NRLI are the Adjacent Routing Information Base Incoming (Adj-RIBs-In) compared to the other routes. For internal routes (iBGP), policy information or LOCAL_PREF is used. For external peer learned routes, it is based strictly on policy. These rules set up a list of which routes are most preferred going into Phase 2.
Decision phase 2
Phase 2 involves installing the best route to each destination into the local Routing Information Base (Loc-RIB). Effectively, the Loc-RIB is the primary routing table. Each route from Phase 1 has their NEXT_HOP checked to ensure the destination is reachable. If it is reachable, the AS_PATH is checked for loops. After that, routes are installed based on the following decision process:
- If there is only one route to a location, it is installed.
- If there are multiple routes to the same location, use the most preferred route from Level 1.
- If there is a tie, break the tie based on the following, in descending order of importance: shortest AS_PATH, smallest ORIGIN number, smallest MED, eBGP over iBGP, smallest metric or cost for reaching the NEXT_HOP, BGP identifier, and lowest IP address.
Note that the new routes that are installed into the Loc-RIB are in addition to any existing routes in the table. Once Phase 2 is completed, the Loc-RIB will consist of the best of both the new and older routes.
Decision phase 3
Phase 3 is route distribution or dissemination. This is the process of deciding which routes the router will advertise. If there is any route aggregation or summarizing, it happens here. Also, any route filtering from route maps happens here.
Once Phase 3 is complete, an update can be sent out to update the neighbor of new routes.
Aggregate routes and addresses
BGP-4 allows classless routing, which uses netmasks as well as IP addresses. This classless routing allows the configuration of aggregate routes by stating the address bits the aggregated addresses have in common.
The ATOMIC_AGGREGATE attribute informs routers that the route has been aggregated and should not be de-aggregated. An associated AGGREGATOR attribute include the information about the router that did the aggregating including its AS.
The BGP commands associated with aggregate routes and addresses are the following:
config router bgp
config aggregate-address
edit <aggr_addr_id>
set as-set {enable | disable}
set prefix <address_ipv4mask>
set summary-only {enable | disable}
end
end
config aggregate-address6
edit <aggr_addr_id>
set prefix6 <address_ipv6mask>
set summary-only {enable | disable}
end
end