Border Gateway Protocol (BGP)
This section describes Border Gateway Protocol (BGP). The following topics are included in this section:
BGP background and concepts
Troubleshooting BGP
Dual-homed BGP example
Redistributing and blocking routes in BGP
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 on page 284.
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 on page 284. 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.
Hi Mike,
if i configure the following on fortigate1:
config router bgp
set as 65000
set router-id 10.2.2.254
config neighbor
edit “10.2.2.253”
set next-hop-self enable
set remote-as 65000
set send-community6 disable
next
config redistribute “static”
set status enable
end
fortigate2 should get the default route 0.0.0.0 0.0.0.0 from fortigate1 as it is static ?
how can i redistribute the default route(fortigate1) to fortigate2 ?
thanks
regards
There is a really good KB article that explains how to do this. You can find it here
If you want to redistribute static routes you would enable the following
config router bgp
config redistribute static
set status enable
end
end
An example of the config would be like this
config router prefix-list
edit “only_dflt”
config rule
edit 1
set prefix 0.0.0.0 0.0.0.0
unset ge
unset le
next
end
next
end
config router route-map
edit “only_default_route”
config rule
edit 1
set match-ip-address “only_dflt”
next
end
next
end
config router bgp
set as 2
config neighbor
edit 10.142.0.110
set remote-as 1
set route-map-in “only_default_route”
next
end
set router-id 10.142.0.205
end
Let me know if this helped answer your question!
Thanks!
Hi,
thanks for the link and example, got it working!
Regards
Awesome to hear Piccolo!
config router bgp
set as 65041
set router-id 162.53.156.138
config neighbor
edit “10.104.55.1”
set ebgp-enforce-multihop enable
set soft-reconfiguration enable
set remote-as 64699
set send-community6 disable
next
edit “10.104.55.2”
set ebgp-enforce-multihop enable
set soft-reconfiguration enable
set remote-as 64699
set send-community6 disable
next
i am trying to accomplish above but i can see only one neighbour is establish and other is in ACTIVE state…
So you see both neighbors but only one is active?