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¶
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
..
..
..
..