• All Files

Home > Online Help

BGP background and concepts

The border gateway protocol 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 units support iBGP, and eBGP only for communities.

The following topics are included in this section:

• Background
• Parts and terminology of BGP
• How BGP works

Background

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 the more recent 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. In doing so, 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 are not explained here as they are common to other dynamic routing protocols as well. When determining your network topology, note that the number of available or supported routes is not set by the configuration but depends on your FortiGate’s available memory. For more information on parts of BGP that are not listed here, see Dynamic Routing Overview.

BGP and IPv6

FortiGate units support IPv6 over BGP using the same config router bgp 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 with config network6 or set allowas-in6. For more information about IPv6 BGP keywords, see the FortiGate 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

Roles of routers in BGP networks

Dynamic routing has a number of different roles routers can fill such as those covered in Dynamic Routing Overview. BGP has a number of custom roles that routers can fill. These include:

• Speaker routers
• Peer routers or neighbors
• Route reflectors (RR)

Speaker routers

Any router 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 are not speaker routers, are not 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 your FortiGate unit. Your FortiGate unit learns about all other routers through these peers.

You need to manually configure BGP peers on your FortiGate unit as neighbors. Otherwise these routers will not be seen as peers, but instead as simply other routers on the network that don’t support BGP. You can optionally use MD5 authentication to password protect BGP sessions with those neighbors. (see RFC 2385).

You can configure up to 1000 BGP neighbors on your FortiGate unit. You can clear all or some BGP neighbor connections (sessions) using the execute router clear bgp 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 command:

execute router clear bgp ip 10.10.10.1

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

execute router clear bgp as 650001

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

execute router clear bgp dampening 10.10.0.0/16

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

Router A and its 5 peer routers

As a minimum, when configuring BGP neighbors you must enter their IP address, and the AS number (remote-as). This is all the information the web-based manager interface 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 (RR)

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

In a BGP route reflector 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 route reflectors and border routers. Only the reflectors need to be configured, not the clients — the clients will find the closest reflector and communicate with it automatically. The reflectors communicate with each other as peers. FortiGate units can be configured as either reflectors or clients.

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

Smaller networks running BGP typically don’t require route reflectors (RR). However, RR is a useful feature for large companies, where their AS may include 100 routers or more. For example, for 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. From these numbers, its plain that updating this many sessions will quickly consume the limited bandwidth and processing resources of the routers involved.

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

Required sessions within an AS with and without route reflectors

The BGP commands related to route reflectors includes:

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 in that 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, requiring few changes. Any additional permanent changes can then be implemented over time as required. The figure 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 route reflectors perform similar functions — they both sub-divide large ASes for more efficient operation. They differ in that route reflector clusters can include routers that are not members of a cluster, where 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 is 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:

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 existence or non-existence of other routes. With this new feature, a child table under bgp.neighbor is introduced. Any route matched by one of the route-map specified in the table will be advertised to the peer based on the corresponding condition route-map.

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 Groups 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 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 (NLRI)

Network Layer Reachability Information (NLRI) is unique to BGP-4. It is 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 are going to change settings you need to understand the roles of each attribute and how they affect those settings.

The BGP attributes include:

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

Inbound policies on FortiGate units 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 unit cannot affect these attributes.

AS_PATH

AS_PATH is the BGP attribute that keeps track of each AS 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 routers AS in it. The figure 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 the route passes through.

As of the start 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:

config router bgp

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

end

MULTI_EXIT_DESC (MED)

BGP AS systems can have one or more routers that connect them to other ASes. For ASes 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 is a recommendation only, as some networks may have different priorities.

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

FortiGate units 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 — possibly a hacking attempt or an attack on the network. At best it signifies an unreliable route to select.

The BGP commands related to MED include:

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.

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

The BGP commands related to COMMUNITY include:

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 units allow you to to change the advertising of the FortiGate unit’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:

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 is easier to send in updates. When it reaches its destination, the summarized routes are split back up into the individual routes.

Your FortiGate unit doesn’t specifically set this attribute in the BGP router command, but it is used in the route map command.

The commands related to ATOMIC_AGGREGATE include:

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 commands related to ORIGIN include:

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, through the various states until they reach the established state. An error can cause the connection to be dropped and the state of the router to be 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, often you 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 (ASes) where 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 ASes.

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

FortiGate units have some commands specific to EBGP. These include:

• 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 (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 is not set by the configuration but depends on your FortiGate’s available memory. 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 enable 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 unit receives BGP updates, or when the FortiGate unit sends out BGP updates.

Three phases of 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 master 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 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

BGP4 allows classless routing, which uses netmasks as well as IP addresses. This classless routing enables the configuration of aggregate routes by stating the address bits the aggregated addresses have in common. For more information, see Dynamic Routing Overview.

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:

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