Border Gateway Protocol (BGP)

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.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Ask your questions in the comments below!!! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

4 thoughts on “Border Gateway Protocol (BGP)

  1. 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!

Leave a Reply

Name *
Email *
Website