BGP

BGP contains two distinct subsets: internal BGP (iBGP) and external BGP (eBGP). iBGP is intended for use within your own networks. eBGP is used to connect many different networks together and is the main routing protocol for the Internet backbone. FortiGate devices support iBGP, and eBGP only for communities.

BGP was first used in 1989. The current version, BGP-4, was released in 1995 and is defined in RFC 1771. That RFC has since been replaced by RFC 4271. The main benefits of BGP-4 are classless inter-domain routing and aggregate routes. BGP is the only routing protocol to use TCP for a transport protocol. Other routing protocols use UDP.

BGP makes routing decisions based on path, network policies, and rulesets instead of the hop-count metric as RIP does, or cost-factor metrics as OSPF does.

BGP-4+ supports IPv6. It was introduced in RFC 2858 and RFC 2545.

BGP is the routing protocol used on the Internet. It was designed to replace the old Exterior Gateway Protocol (EGP) which had been around since 1982, and was very limited. BGP enabled more networks to take part in the Internet backbone to effectively decentralize it and make the Internet more robust, and less dependent on a single ISP or backbone network.

Parts and terminology of BGP

In a BGP network, there are some terms that need to be explained before going ahead. Some parts of BGP aren't explained here because they're common to other dynamic routing protocols. When determining your network topology, note that the number of available or supported routes isn't set by the configuration but depends on the available memory on the FortiGate. For more information about the parts of BGP that aren't listed here, see Dynamic routing.

BGP and IPv6

FortiGate devices support IPv6 over BGP using the same config router bgp CLI command as IPv4 but different subcommands.

The main CLI keywords have IPv6 equivalents that are identified by the “6” on the end of the keyword, such as config network6 or set allowas-in6. For more information about IPv6 BGP keywords, see the FortiOS CLI Reference.

IPv6 BGP commands include:

config router bgp

set activate6 {enable | disable}

set allowas-in6 <max_num_AS_integer>

set allowas‑in‑enable6 {enable | disable}

set as-override6 {enable | disable}

set attribute-unchanged6 [as-path] [med] [next-hop]

set capability-default-originate6 {enable | disable}

set capability‑graceful‑restart6 {enable | disable}

set capability-orf6 {both | none | receive | send}

set default-originate-route-map6 <routemap_str>

set distribute‑list‑in6 <access-list-name_str>

set distribute-list-out6 <access-list-name_str>

set filter-list-in6 <aspath-list-name_str>

set filter‑list‑out6 <aspath-list-name_str>

set maximum-prefix6 <prefix_integer>

set maximum-prefix-threshold6 <percentage_integer>

set maximum-prefix-warning-only6 {enable | disable}

set next-hop-self6 {enable | disable}

set prefix-list-in6 <prefix-list-name_str>

set prefix-list-out6 <prefix-list-name_str>

set remove-private-as6 {enable | disable}

set route-map-in6 <routemap-name_str>

set route‑map‑out6 <routemap-name_str>

set route-reflector-client6 {enable | disable}

set route-server-client6 {enable | disable}

set send-community6 {both | disable | extended | standard}

set soft-reconfiguration6 {enable | disable}

set unsuppress-map6 <route-map-name_str>

config network6

config redistribute6

end

Role of routers in BGP networks

Dynamic routing has a number of different roles that routers can fill, such as those covered in . BGP has a number of custom roles that routers can fill. These include speaker routers, peer routers or neighbors, and route reflectors.

Speaker routers

Any router that's configured for BGP is considered a BGP speaker. This means that a speaker router advertises BGP routes to its peers.

Any routers on the network that aren't speaker routers aren't treated as BGP routers.

Peer routers or neighbors

In a BGP network, all neighboring BGP routers or peer routers are routers that are connected to a FortiGate. A FortiGate learns about all other routers through these peers.

You need to manually configure BGP peers on a FortiGate as neighbors. Otherwise, these routers won't be seen as peers, but simply as other routers on the network that don't support BGP. Optionally, you can use MD5 authentication to password-protect BGP sessions with those neighbors (see RFC 2385).

You can configure up to 1000 BGP neighbors on a FortiGate. You can clear all or some BGP neighbor connections (sessions), using the execute router clear bgp CLI command.

For example, if you have 10 routes in the BGP routing table and you want to clear the specific route to IP address 10.10.10.1, enter the following CLI command:

execute router clear bgp ip 10.10.10.1

To remove all routes for AS number 650001, enter the following CLI command:

execute router clear bgp as 650001

To remove route flap dampening information for the 10.10.0.0/16 subnet, enter the following CLI command:

execute router clear bgp dampening 10.10.0.0/16

In the following diagram, Router A is directly connected to five other routers in a network that contains 12 routers. These routers (the ones in the blue circle) are Router A’s peers or neighbors.

Router A and its five peer routers

As a minimum, when configuring BGP neighbors, you must enter their IP address and the AS number (remote-as). This is all of the information the GUI allows you to enter for a neighbor.

The BGP commands related to neighbors are quite extensive and include:

config router bgp

config neighbor

edit <neighbor_address_ipv4>

set activate {enable | disable}

set advertisement-interval <seconds_integer>

set allowas-in <max_num_AS_integer>

set allowas-in-enable {enable | disable}

set as-override {enable | disable}

set attribute-unchanged [as-path] [med] [next-hop]

set bfd {enable | disable}

set capability-default-originate {enable | disable}

set capability-dynamic {enable | disable}

set capability-graceful-restart {enable | disable}

set capability-orf {both | none | receive | send}

set capability-route-refresh {enable | disable}

set connect-timer <seconds_integer>

set description <text_str>

set distribute-list-in <access-list-name_str>

set distribute-list-out <access-list-name_str>

set dont-capability-negotiate {enable | disable}

set ebgp-enforce-multihop {enable | disable}

set ebgp-multihop {enable | disable}

set ebgp-multihop-ttl <seconds_integer>

set filter-list-in <aspath-list-name_str>

set filter-list-out <aspath-list-name_str>

set holdtime-timer <seconds_integer>

set interface <interface-name_str>

set keep-alive-timer <seconds_integer>

set maximum-prefix <prefix_integer>

set maximum-prefix-threshold <percentage_integer>

set maximum-prefix-warning-only {enable | disable}

set next-hop-self {enable | disable}

set passive {enable | disable}

set password <string>

set prefix-list-in <prefix-list-name_str>

set prefix-list-out <prefix-list-name_str>

set remote-as <id_integer>

set remove-private-as {enable | disable}

set retain-stale-time <seconds_integer>

set route-map-in <routemap-name_str>

set route-map-out <routemap-name_str>

set route-reflector-client {enable | disable}

set route-server-client {enable | disable}

set send-community {both | disable | extended | standard}

set shutdown {enable | disable}

set soft-reconfiguration {enable | disable}

set strict-capability-match {enable | disable}

set unsuppress-map <route-map-name_str>

set update-source <interface-name_str>

set weight <weight_integer>

end

end

end

Route reflectors

Route reflectors (RR) in BGP concentrate route updates so other routers only need to talk to the RRs to get all of the updates. This results in smaller routing tables, fewer connections between routers, faster responses to network topology changes, and less administration bandwidth. BGP RRs are defined in RFC 1966.

In a BGP RR configuration, the AS is divided into different clusters that each include client and reflector routers. The client routers supply the reflector routers with the client’s route updates. The reflectors pass this information along to other RRs and border routers. Only the reflectors need to be configured, not the clients, because the clients find the closest reflector and communicate with it automatically. The reflectors communicate with each other as peers. A FortiGate can be configured as either reflectors or clients.

Since RRs are processing more than the client routers, the reflectors should have more resources to handle the extra workload.

Smaller networks running BGP typically do not require RRs. However, RRs are a useful feature for large companies, where their AS may include 100 routers or more. For example, a full mesh 20 router configuration within an AS, there would have to be 190 unique BGP sessions just for routing updates within the AS. The number of sessions jumps to 435 sessions for just 30 routers, or 4950 sessions for 100 routers. Based on these numbers, updating this many sessions will quickly consume the limited bandwidth and processing resources of the routers involved.

The following diagram illustrates how RRs can improve the situation when only six routers are involved. The AS without RRs requires 15 sessions between the routers. In the AS with RRs, the two RRs receive route updates from the reflector clients (unlabeled routers in the diagram) in their cluster, as well as other RRs, and pass them on to the border router. The RR configuration requires only six sessions. This example shows a reduction of 60% for the number of required sessions.

Required sessions within an AS with and without RRs

The BGP commands related to RRs include:

config router bgp

config neighbor

set route-reflector-client {enable | disable}

set route-server-client {enable | disable}

end

end

Confederations

Confederations were introduced to reduce the number of BGP advertisements on a segment of the network and reduce the size of the routing tables. Confederations essentially break up an AS into smaller units. Confederations are defined in RFC 3065 and RFC 1965.

Within a confederation, all routers communicate with each other in a full mesh arrangement. Communications between confederations is more like inter-AS communications because many of the attributes are changed as they would be for BGP communications leaving the AS, or eBGP.

Confederations are useful when merging ASs. Each AS being merged can easily become a confederation, which requires few changes. Any additional permanent changes can then be implemented over time, as required. The diagram below shows the group of ASs before merging and the corresponding confederations afterward, as part of the single AS with the addition of a new border router. It should be noted that after merging, if the border router becomes a route reflector, then each confederation only needs to communicate with one other router instead of five others.

AS merging using confederations

Confederations and RRs perform similar functions: they both sub-divide large ASs for more efficient operation. They differ in that route reflector clusters can include routers that aren't members of a cluster, whereas routers in a confederation must belong to that confederation. Also, confederations place their confederation numbers in the AS_PATH attribute, making it easier to trace.

It's important to note that while confederations essentially create sub-ASs, all the confederations within an AS appear as a single AS to external ASs.

Confederation related BGP commands include the following:

config router bgp

set confederation-identifier <peerid_integer>

end

BGP conditional advertisements

Normally, routes are propagated regardless of the existence of a different path. The BGP conditional advertisement feature allows a route not to be advertised, based on the existence or non-existence of other routes. With this feature, a child table under bgp.neighbor is introduced. Any route matched by one of the route-maps specified in the table will be advertised to the peer, based on the corresponding route-map condition.

You can enable and disable conditional advertisements using the CLI.

To configure BGP conditional advertisements - CLI:

config router bgp

set as 3

config neighbor

edit "10.10.10.10"

set remote-as 3

config conditional-advertise

edit "route-map-to-match-sending"

set condition-routemap "route-map-to-match-condition"

set condition-type [exist | non-exist]

next

end

next

end

BGP neighbor groups

The BGP neighbor group feature allows a large number of neighbors to be configured automatically based on a range of neighbors' source addresses.

To configure BGP neighbor groups - CLI:

Start by adding a BGP neighbor group:

config router bgp

config neighbor-group

edit <neighbor-group-name>

set remote-as 100

...

(All options for BGP neighbor group are supported except password.)

end

Then add a BGP neighbor range:

config router bgp

config neighbor-range

edit 1

set prefix 192.168.1.0/24

set max-neighbor-num 100

set neighbor-group <neighbor-group-name>

next

end

Network Layer Reachability Information

Network Layer Reachability Information (NLRI) is unique to BGP-4. It's sent as part of the update messages sent between BGP routers and contains information necessary to supernet, or aggregate route, information. The NLRI includes the length and prefix that, when combined, are the address of the aggregated routes referred to.

There is only one NLRI entry per BGP update message.

BGP attributes

Each route in a BGP network has a set of attributes associated with it. These attributes define the route and are modified, as required, along the route.

BGP can work well with mostly default settings, but if you're going to change settings you need to understand the roles of each attribute and how they affect those settings.

The BGP attributes include:

Attribute	Description
AS_PATH	A list of ASs a route has passed through. For more information, see AS_PATH.
MULTI_EXIT_DESC (MED)	Which router to use to exit an AS with more than one external connection. For more information, see MULTI_EXIT_DESC.
COMMUNITY	Used to apply attributes to a group of routes. For more information, see COMMUNITY.
NEXT_HOP	Where the IP packets should be forwarded to, like a gateway in static routing. For more information, see NEXT_HOP.
ATOMIC_AGGREGATE	Used when routes have been summarized to tell downstream routers not to de-aggregate the route. For more information, see ATOMIC_AGGREGATE.
ORIGIN	Used to determine if the route is from the local AS or not. For more information, see ORIGIN.
LOCAL_PREF	Used only within an AS to select the best route to a location (like MED).

Inbound policies on FortiGate devices can change the NEXT-HOP,LOCAL-PREF, MED and AS-PATH attributes of an internal BGP (iBGP) route for its local route selection purposes. However, outbound policies on the device can't affect these attributes.

AS_PATH

AS_PATH is the BGP attribute that keeps track of each AS that a route advertisement has passed through. AS_PATH is used by confederations and by exterior BGP (EBGP) to help prevent routing loops. A router knows there is a loop if it receives an AS_PATH with that router's AS in it. The diagram below shows the route between Router A and Router B. The AS_PATH from A to B would read 701,702,703 for each AS that the route passes through.

As of the beginning of 2010, the industry upgraded from 2-byte to 4-byte AS_PATHs. This upgrade was due to the imminent exhaustion of 2-byte AS_PATH numbers. FortiOS supports 4-byte AS_PATHs in its BGP implementation.

AS_PATH of 701,702, 703 between routers A and B

The BGP commands related to AS_PATH include the following:

config router bgp

set bestpath-as-path-ignore {enable | disable}

end

MULTI_EXIT_DESC

BGP AS systems can have one or more routers that connect them to other ASs. For ASs with more than one connecting router, the Multi-Exit Discriminator (MED) lists which router is best to use when leaving the AS. The MED is based on attributes, such as delay. It's a recommendation only, as some networks may have different priorities.

BGP updates advertise the best path to a destination network. When a FortiGate receives a BGP update, the FortiGate examines the MED attribute of potential routes to determine the best path to a destination network before recording the path in the local FortiGate routing table.

FortiGate devices have the option to treat any routes without an MED attribute as the worst possible routing choice. This can be useful because a lack of MED information is a lack of routing information, which can be suspicious as a possible hacking attempt or an attack on the network. At best, it signifies an unreliable route to select.

The BGP commands related to MED include the following:

config router bgp

set always-compare-med {enable | disable}

set bestpath-med-confed {enable | disable}

set bestpath-med-missing-as-worst {enable | disable}

set deterministic-med {enable | disable}

config neighbor

set attribute-unchanged [as-path] [med] [next-hop]

end

end

COMMUNITY

A community is a group of routes that have the same routing policies applied to them. This saves time and resources. A community is defined by the COMMUNITY attribute of a BGP route.

A FortiGate can set the COMMUNITY attribute of a route to assign the route to predefined paths (see RFC 1997). The FortiGate can examine the COMMUNITY attribute of learned routes to perform local filtering and/or redistribution.

The BGP commands related to COMMUNITY include the following:

config router bgp

set send-community {both | disable | extended | standard}

end

NEXT_HOP

The NEXT_HOP attribute says what IP address the packets should be forwarded to next. Each time the route is advertised, this value is updated. The NEXT_HOP attribute is much like a gateway in static routing.

FortiGate devices allow you to to change the advertising of the FortiGate device’s IP address (instead of the neighbor’s IP address) in the NEXT_HOP information that is sent to IBGP peers. This is changed with the config neighbor, set next-hop-self command.

The BGP commands related to NEXT_HOP include the following:

config router bgp

config neighbor

set attribute-unchanged [as-path] [med] [next-hop]

set next-hop-self {enable | disable}

end

end

ATOMIC_AGGREGATE

The ATOMIC_AGGREGATE attribute is used when routes have been summarized. It indicates which AS and which router summarize the routes. It also tells downstream routers not to de-aggregate the route. Summarized routes are routes with similar information that have been combined, or aggregated, into one route that's easier to send in updates for. When it reaches its destination, the summarized routes are split back up into the individual routes.

The FortiGate doesn't specifically set this attribute in the BGP router command, but it's used in the route map command.

The CLI commands related to ATOMIC_AGGREGATE include the following:

config router route-map

edit <route_map_name>

config rule

edit <route_map_rule_id>

set set-aggregator-as <id_integer>

set set-aggregator-ip <address_ipv4>

set set-atomic-aggregate {enable | disable}

end

end

end

ORIGIN

The ORIGIN attribute records where the route came from. The options can be IBGP, EBGP, or incomplete. This information is important because internal routes (IBGP) are, by default, higher priority than external routes (EBGP). However, incomplete ORIGINs are the lowest priority of the three.

The CLI commands related to ORIGIN include the following:

config router route-map

edit <route_map_name>

set comments <string>

config rule

edit <route_map_rule_id>

set match-origin {egp | igp | incomplete | none}

end

end

end

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.

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. Exterior BGP (EBGP) involves packets crossing multiple autonomous systems (ASs) and interior BGP (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 ASs.

These two modes are important because some features of BGP are used only for one of EBGP or IBGP. For example, confederations are used in EBGP and RRs are used only in IBGP. Also, routes learned from IBGP have priority over routes learned from EBGP.

FortiGate devices 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} and set ebgp-multihop-ttl <seconds_integer>

BGP path determination: which route to use

Firstly, recall that the number of available or supported routes isn't set by the configuration but depends on the available memory on the FortiGate. 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 don't 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 FortiGate receives BGP updates or when the FortiGate 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's 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's reachable, the AS_PATH is checked for loops. After that, routes are installed based on the following decision process:

• If there's only one route to a location, it's installed.
• If there are multiple routes to the same location, use the most preferred route from Level 1.
• If there's 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's 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. For more information, see BGP.

The ATOMIC_AGGREGATE attribute informs routers that the route has been aggregated and shouldn't 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

config aggregate-address6

edit <aggr_addr_id>

set as-set {enable | disable}

set prefix6 <address_ipv6mask>

set summary-only {enable | disable}

end

Configuring BGP graceful restart process on timer

You can configure the BGP graceful restart process to stop only when the restart timer expires, using the following CLI commands:

config router bgp

set graceful-end-on-timer enable

Configuring option to bring down BGP neighbor when the link is down

You can configure an option to bring down BGP neighbors when the outgoing interface is down, using the following CLI commands:

config router bgp

config neighbor

edit <ip_address>

set linkdown-failover enable

Configuring option to keep routes for a period after the BGP neighbor is down

You can configure an option to keep routes for a period after the BGP neighbor is down. If you enable this option for a BGP neighbor, the route learned from the neighbor is kept for the configured graceful-stalepath-time after the neighbor is down because of hold timer expiration or TCP connection failure.

To configure this option, use the following CLI commands:

config router bgp

config neighbor

edit <ip_address>

set stale-route enable

BGP local-AS support

A FortiGate supports BGP local-AS. Local-AS allows you to configure a BGP speaker to have a real local-AS and a secondary local-AS for a specific neighbor, so its local-AS number appears different to different neighbors.

You can configure a BGP speaker to have a real local-AS and a secondary local-AS for a specific neighbor, so the local-AS number appears different to neighbor B and neighbor A.

To configure BGP local-AS for BGP peers - CLI:

config router bgp

config neighbor

edit “neighbor” / edit <ip_address>

…

set local-as 300 (?) / set local-as <integer>

set local-as-no-prepend {enable | disable}

set local-as-replace-as {enable | disable}

end

CLI option	Description
<ip_address>	The IP/IPv6 address of neighbor
<local-as <integer>>	The local-AS number
local-as-no-prepend { enable | disable}	Set this to enable if you do not want to prepent local-AS to incoming updates.
local-as-replace-as { enable | disable}	Set this to enable to replace a real AS with local-AS in outgoing updates.