BGP configuration

There are a list of necessary elements to know when forging a BGP configuration.

Basic elements for configuration

When forging a BGP configuration, the local AS number, and the remote AS number, as well as the remote IP address have to be known in order to establish peering.

An AS is an administrative set of routers, depending on an administrative authority. There are public or assigned ASes, and private ASes. An ASes is identified by a number called ASN.

The public ASNs are any registered ASN values that are not private. These ASNs are assigned by a RIR. The private ASNs are made up of 2 ranges that can be used for local administration. These numbers are 64512 through 65535, and 4200000000 through 4294967294.

BGP has been extended to exchange routing information not only for IPv4 routing tables, also other routing information like IPv6, or for other purpose: flowspec, or L3VPN or L2VPN. The address-family command allows us to identify the network protocol. It is made up of a pair of arguments AFI, SAFI. For instance, by default, IPv4, unicast is enabled and stands for the routing information of IPv4.

Here below is an example on how to configure a sample BGP configuration with both IPv4 and IPv6 address-family set:

vrf main
   routing
      bgp
         router-id 10.125.0.1
         as 65501
         neighbor 10.125.0.3
            remote-as 65502
            address-family ipv6
               ..
            ..
         commit

The same configuration can be made using this NETCONF XML configuration:

vsr running config# show config xml absolute vrf main routing bgp
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <routing xmlns="urn:6wind:vrouter/routing">
      <bgp xmlns="urn:6wind:vrouter/bgp">
        <router-id>10.125.0.1</router-id>
        <as>65501</as>
        <neighbor>
          <neighbor-address>10.125.0.3</neighbor-address>
          <address-family>
            <ipv6-unicast>
            </ipv6-unicast>
          </address-family>
          <remote-as>65502</remote-as>
        </neighbor>
      </bgp>
    </routing>
  </vrf>
</config>

Configuring various address-family means that there are subtle differences between each address-family, that permit benefiting from each specificity.

For instance, IPv6, unicast address-family provides 2 IPv6 next-hops : the local one and the global one.

Also, IPv4, vpn is the L3VPN combination for MPLS tunnels. While the routing information exchanged deals with inner IPv4 information, the MPLS VPN SAFI implies that the overlay will be based with MPLS. The nexthop information will stand for underlay tunnel end point information. Here, the nexthop may be either IPv4 or IPv6, independently of the inner IPv4 prefix. The nexthop will also contain the MPLS label identifier.

Note

You can also disable BGP, either by suppressing the configuration:

vrf main
    del routing bgp
    ..

Alternatively, if you don’t want to lose the configuration, and disabling BGP configuration, you can use following command:

vrf main
    routing bgp
        enabled false

This method can be used if the user wants to force peering with remote BGP speakers. Consecutively changing the state of BGP will force the peering. Here, below illustration indicates how the session for 10.125.0.3 is flushed.

flush bgp vrf main ipv4 unicast neighbor 10.125.0.3

Note that this command can also selectively flush different parts of the routing tables, like ADJ-RIB-IN by issuing the soft in prefix at the end of the command. An other possibility is to disable the whole BGP instance.

vrf main
    routing bgp enabled false
    commit
    routing bgp enabled true
    commit

Basic BGP configuration

../../../../_images/first-config.svg

BGP configuration illustration with 3 BGP peerings

The above diagram depicts 3 devices, each one has a BGP instance that peers with each other. The 3 devices configuration is like below:

rt1

routing bgp
    router-id 10.1.1.1
    as 65500
    neighbor 10.1.1.2 remote-as 65510
    neighbor 10.1.1.3 remote-as 65520
    address-family ipv4-unicast redistribute connected
    ..
    ..
interface
    physical eth1_0
       ipv4 address 192.168.1.0/24
       ..
    ..
    physical eth0_0
       ipv4 address 10.1.1.1/28
       ..
    ..

rt2

routing bgp
    router-id 10.1.1.2
    as 65510
    neighbor 10.1.1.1 remote-as 65500
    neighbor 10.1.1.3 remote-as 65520
    address-family ipv4-unicast redistribute connected
    ..
    ..
interface
    physical eth1_0
       ipv4 address 192.168.2.0/24
       ..
    ..
    physical eth0_0
       ipv4 address 10.1.1.2/28
       ..
    ..

rt3

routing bgp
    router-id 10.1.1.3
    as 65520
    neighbor 10.1.1.1 remote-as 65500
    neighbor 10.1.1.2 remote-as 65510
    address-family ipv4-unicast redistribute connected
    ..
    ..
interface
    physical eth1_0
       ipv4 address 192.168.3.0/24
       ..
    ..
    physical eth0_0
       ipv4 address 10.1.1.3/28
       ..
    ..

After having executed the three configurations, the status of the BGP connections can be obtained. The peerings between the devices can be visualised with the following command:

rt1> show bgp summary

IPv4 Unicast Summary:
BGP router identifier 10.1.1.1, local AS number 65500 vrf-id 0
BGP table version 5
RIB entries 9, using 1368 bytes of memory
Peers 2, using 41 KiB of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/P
fxRcd
10.1.1.2        4      65510      17      17        0    0    0 00:09:08      4
10.1.1.3        4      65520      17      17        0    0    0 00:09:11      4

Total number of neighbors 2

The output of the state column must be blank in case the BGP connection is established, otherwise it reflects the state of the BGP connection. The different BGP session states are studied later in the section. Following command gives detailed BGP information about a given neighbor:

rt1> show bgp neighbor 10.1.1.2
BGP neighbor is 10.1.1.2, remote AS 65510, local AS 65500, external link
Hostname: rt1
  BGP version 4, remote router ID 10.1.1.2
  BGP state = Established, up for 00:14:00
  Last read 00:01:00, Last write 00:01:00
  Hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    AddPath:
      IPv4 Unicast: RX advertised IPv4 Unicast and received
    Route refresh: advertised and received(old & new)
    Address Family IPv4 Unicast: advertised and received
    Hostname Capability: advertised (name: rt1,domain name: n/a)
          received (name: rt2,domain name: n/a)
    Graceful Restart Capabilty: advertised and received
      Remote Restart timer is 120 seconds
      Address families by peer:
        none
    Graceful restart informations:
      End-of-RIB send: IPv4 Unicast
      End-of-RIB received: IPv4 Unicast
    Message statistics:
      Inq depth is 0
      Outq depth is 0
                           Sent       Rcvd
      Opens                   1          1
      Notifications:          0          0
      Updates:                6          6
      Keepalives:            14         14
      Route Refresh:          0          0
      Capability:             0          0
      Total:                 21         21

It is also possible to dump the list of BGP entries that rt1 learnt from the other peers, by using following command on configuration mode:

rt1> show bgp ipv4 unicast neighbors
 BGP table version is 5, local router ID is 10.1.1.1, vrf id 0
 Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
                i internal, r RIB-failure, S Stale, R Removed
 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
 Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
 *  10.0.2.0/24      10.1.1.2                 0             0 65510 ?
 *                   10.1.1.3                 0             0 65520 ?
 *>                  0.0.0.0                  0         32768 ?
 *  10.1.1.0/28      10.1.1.2                 0             0 65510 ?
 *                   10.1.1.3                 0             0 65520 ?
 *>                  0.0.0.0                  0         32768 ?
 *> 192.168.1.0      0.0.0.0                  0         32768 ?
 *  192.168.2.0      10.1.1.2                               0 65520 65510 ?
 *>                  10.1.1.2                 0             0 65510 ?
 *  192.168.3.0      10.1.1.3                               0 65510 65520 ?
 *>                  10.1.1.3                 0             0 65520 ?

 Displayed  5 routes and 11 total paths

Peer-groups

Scaling BGP deployments may be useful, when one deploys multiple instances of BGP. Instead of configuring each peer one by one, it is possible to configure peer groups.

A peer group is defined by a name, and is being applied the same configuration as the one applied to a single peer IP, except for the IP addressing of that peer.

You can use a peer group configuration so as to define some peers with outgoing peering, with the inherited configuration coming from the peer-group. You can also use a peer group to permit incoming peering connections, like a server would do. Below configuration illustrates the usage of a peer group named group:

routing bgp
   listen
      neighbor-range 10.135.0.0/24 neighbor-group group
      ..
   as 65502
   neighbor-group group
      address-family
         ipv6-unicast
            ..
         ..
      remote-as 65501
      update-source 10.135.0.2
      ..
   neighbor 10.145.0.2
      neighbor-group group
         ..
       ..

By default, the BGP instance will create up to 100 maximum peering connections. This is a configuration limit that can be modified to increase the maximum number of peering connections to support:

routing bgp
   listen limit 5000
   ..

With that extra configuration, incoming BGP connections that match its settings will be able to be peered up to that new limit. It is also possible to limit the number of accepted incoming connections by establishing a range of potential IP addresses, like the above example illustrates.

Note

When configuring and handling a huge number of peering connections, for example with values above 5000, you may experience some timeout issues on the BGP connections. This is due to the increased time of processing the incoming BGP packets. This time can be reduced by increasing the number of BGP packets to be processed by I/O cycle. When a huge number of peering connections is used, it is recommended to use the following configuration command:

routing bgp
   packet-rw-quantum read 64
   packet-rw-quantum write 200
   ..

As you can see, the packet-rw-quantum write value has been increased accordingly. It is recommended to keep that value above packet-rw-quantum read value, if you do not want to experience memory exhaustion due to accumulation of buffers in BGP process.

Note

With such big number of sessions, it may be wishable for the server to detect the failure of remote endpoint as quick as possible. One possibility consists in enabling tcp-keepalive parameter. tcp-keepalive packets need to be replied at remote TCP endpoints with ack packet. After a defined consecutive number of probes where ack is not seen, TCP session is considered as down. Below configuration detects a failure of 3 probes send each 2 seconds.

routing bgp
   tcp-keepalive idle 2 keepalive 2 probes 3
   ..

Route-Reflector

Route reflector is used in iBGP networks, where the number of BGP peers becomes too important. Instead of using a full mesh peering, a 1-N peering topology is used. A single ( or two, in case backup is needed) BGP instance acts as route reflector server, and receives/replies BGP updates from/to route reflector clients accordingly. This permits scaling some setups. Creating a route reflector server consists in defining an IBGP peering session, either via peer-group or by defining directly a peer. The option route-reflector-client must be set to true.

as 65501
neighbor-group group
   address-family
      ipv4-unicast
         route-reflector-client true
         ..
      ..
   remote-as 65501
neighbor 1.1.1.1
   address-family
      ipv4-unicast
         route-reflector-client true
         ..
      ..
   remote-as 65501
   ..

There is no need to add extra-configuration to the iBGP clients.

Multipath

BGP multipath permits to create ECMP routes, so that traffic can be load-shared on all the available routing entries. By default, BGP know how to handle up to 8 ECMP route entries. It is possible to reduce per the number of maximum-paths per address-family, and for both iBGP or eBGP sessions. Here is a configuration example, on how to disable multipath for IPv4, unicast BGP:

router-id 10.125.0.1
address-family
   ipv4-unicast
      maximum-path
         ebgp 1
         ibgp 1
         ..
      ..
   ..
as 65501

The multipath is criteria are strict by default. That means that even if as-path attribute that goes along with the prefixes differs, then the load-sharing will fail. There are some mitigations methods that permit relax the load sharing. For instance, the as-path attribute list can be completely ignored with following command, thus permitting to do load sharing across paths that do not share at all same path-list.

bestpath
   as-path
      ignore true
      ..
   ..

It is also possible to find an intermediary point, by taking into account only prefixes that share different path list, but same as-path list count.

bestpath
   as-path
      multipath-relax as-set
      ..
   ..

BGP supports advertisements of multiple paths. This is an extra identifier that is encoded in the NLRI of the packet. It contains a separate identifier. For instance, it permits to transmit 2 ECMP entries that will be differentiated by that identifier. To enable encoding of the prefix with the add-path option, use the following configuration command:

neighbor 10.125.0.3
   remote-as 65502
   address-family
      ipv4-unicast
         addpath
            tx-all-paths true
            ..
         ..
      ..
   ..