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:
vsr running config# / vrf main routing bgp as 65501
vsr running config# / vrf main routing bgp router-id 10.125.0.1
vsr running config# / vrf main routing bgp neighbor 10.125.0.3 remote-as 65502
vsr running config# / vrf main routing bgp neighbor 10.125.0.3 address-family ipv6-unicast
The same configuration can be made using this NETCONF XML configuration:
vsr> show config nodefault 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">
<as>65501</as>
<router-id>10.125.0.1</router-id>
<neighbor>
<neighbor-address>10.125.0.3</neighbor-address>
<remote-as>65502</remote-as>
<address-family>
<ipv6-unicast/>
</address-family>
</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:
vsr running config# del / vrf main routing bgp
Alternatively, if you don’t want to lose the configuration, and disabling BGP configuration, you can use following command:
vsr running config# / 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.
vsr> 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.
vsr running config# / vrf main routing bgp enabled false
vsr running config# / vrf main routing bgp enabled true
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
rt1 running config# / vrf main routing bgp as 65500
rt1 running config# / vrf main routing bgp router-id 10.1.1.1
rt1 running config# / vrf main routing bgp ebgp-requires-policy false
rt1 running config# / vrf main routing bgp neighbor 10.1.1.2 remote-as 65510
rt1 running config# / vrf main routing bgp neighbor 10.1.1.3 remote-as 65520
rt1 running config# / vrf main routing bgp address-family ipv4-unicast redistribute connected
rt1 running config# / vrf main interface physical eth2 port pci-b0s5
rt1 running config# / vrf main interface physical eth2 ipv4 address 192.168.1.0/24
rt1 running config# / vrf main interface physical eth1 port pci-b0s4
rt1 running config# / vrf main interface physical eth1 ipv4 address 10.1.1.1/28
rt2
rt2 running config# / vrf main routing bgp as 65510
rt2 running config# / vrf main routing bgp router-id 10.1.1.2
rt2 running config# / vrf main routing bgp ebgp-requires-policy false
rt2 running config# / vrf main routing bgp neighbor 10.1.1.1 remote-as 65500
rt2 running config# / vrf main routing bgp neighbor 10.1.1.3 remote-as 65520
rt2 running config# / vrf main routing bgp address-family ipv4-unicast redistribute connected
rt2 running config# / vrf main interface physical eth2 port pci-b0s5
rt2 running config# / vrf main interface physical eth2 ipv4 address 192.168.2.0/24
rt2 running config# / vrf main interface physical eth1 port pci-b0s4
rt2 running config# / vrf main interface physical eth1 ipv4 address 10.1.1.2/28
rt3
rt3 running config# / vrf main routing bgp as 65520
rt3 running config# / vrf main routing bgp router-id 10.1.1.3
rt3 running config# / vrf main routing bgp ebgp-requires-policy false
rt3 running config# / vrf main routing bgp neighbor 10.1.1.1 remote-as 65500
rt3 running config# / vrf main routing bgp neighbor 10.1.1.2 remote-as 65510
rt3 running config# / vrf main routing bgp address-family ipv4-unicast redistribute connected
rt3 running config# / vrf main interface physical eth2 port pci-b0s5
rt3 running config# / vrf main interface physical eth2 ipv4 address 192.168.3.0/24
rt3 running config# / vrf main interface physical eth1 port pci-b0s4
rt3 running config# / vrf main interface physical eth1 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 (VRF default):
BGP router identifier 10.1.1.1, local AS number 65500 vrf-id 0
BGP table version 4
RIB entries 7, using 1288 bytes of memory
Peers 2, using 176 KiB of memory
Neighbor V AS LocalAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
10.1.1.2 4 65510 65500 7 7 0 0 0 00:00:33 3 4 N/A
10.1.1.3 4 65520 65500 7 7 0 0 0 00:00:29 3 4 N/A
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: rt2
BGP version 4, remote router ID 10.1.1.2, local router ID 10.1.1.1
BGP state = Established, up for 00:00:34
Last read 00:00:28, Last write 00:00:28
Hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
4 Byte AS: advertised and received
Extended Message: advertised and received
AddPath:
IPv4 Unicast: RX advertised IPv4 Unicast and received
Route refresh: advertised and received(old & new)
Enhanced Route Refresh: advertised and received
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 Capability: advertised and received
Remote Restart timer is 120 seconds
Address families by peer:
none
Graceful restart information:
End-of-RIB send: IPv4 Unicast
End-of-RIB received: IPv4 Unicast
Local GR Mode: Helper*
Remote GR Mode: Helper
R bit: True
Timers:
Configured Restart Time(sec): 120
Received Restart Time(sec): 120
IPv4 Unicast:
F bit: False
End-of-RIB sent: Yes
End-of-RIB sent after update: No
End-of-RIB received: Yes
Timers:
Configured Stale Path Time(sec): 360
Message statistics:
Inq depth is 0
Outq depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 5 5
Keepalives: 1 1
Route Refresh: 0 0
Capability: 0 0
Total: 7 7
Minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
Update group 1, subgroup 1
Packet Queue length 0
Community attribute sent to this neighbor(all)
3 accepted prefixes
Connections established 1; dropped 0
Last reset 00:00:39, No AFI/SAFI activated for peer
Local host: 10.1.1.1, Local port: 179
Foreign host: 10.1.1.2, Foreign port: 37292
Nexthop: 10.1.1.1
Nexthop global: fe80::dced:1ff:fe9f:a51d
Nexthop local: fe80::dced:1ff:fe9f:a51d
BGP connection: shared network
BGP Connect Retry Timer in Seconds: 120
Read thread: on Write thread: on FD used: 26
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
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Default local pref 100, local AS 65500
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
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* 10.1.1.0/28 10.1.1.3 0 0 65520 ?
* 10.1.1.2 0 0 65510 ?
*> 0.0.0.0 0 32768 ?
*> 192.168.1.0/24 0.0.0.0 0 32768 ?
* 192.168.2.0/24 10.1.1.2 0 65520 65510 ?
*> 10.1.1.2 0 0 65510 ?
* 192.168.3.0/24 10.1.1.3 0 65510 65520 ?
*> 10.1.1.3 0 0 65520 ?
Displayed 4 routes and 8 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:
vsr running config# / vrf main routing bgp as 65502
vsr running config# / vrf main routing bgp neighbor-group GROUP address-family ipv6-unicast
vsr running ipv6-unicast# / vrf main routing bgp neighbor-group GROUP remote-as 65501
vsr running ipv6-unicast# / vrf main routing bgp neighbor-group GROUP update-source 10.135.0.2
vsr running ipv6-unicast# / vrf main routing bgp neighbor 10.145.0.2 neighbor-group GROUP
vsr running ipv6-unicast# / vrf main routing bgp listen neighbor-range 10.135.0.0/24 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:
vsr running config# / vrf main 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:
vsr running config# / vrf main routing bgp packet-rw-quantum read 64
vsr running config# / vrf main routing bgp 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.
vsr running config# / vrf main 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.
vsr running config# / vrf main routing bgp as 65501
vsr running config# / vrf main routing bgp neighbor-group GROUP address-family ipv4-unicast route-reflector-client true
vsr running config# / vrf main routing bgp neighbor-group GROUP remote-as 65501
vsr running config# / vrf main routing bgp neighbor 1.1.1.1 address-family ipv4-unicast route-reflector-client true
vsr running config#! / vrf main routing bgp neighbor 1.1.1.1 remote-as 65501
There is no need to add extra-configuration to the iBGP clients.
Multipath¶
Overview¶
The BGP path selection process involves a series of criteria to determine the best path for a given prefix. Here is a summarized and ordered list of these criteria:
Highest Weight: Prefers the path with the highest weight.
Highest Local Preference: Routes with higher local preference are favored.
Originated Locally: Prefers routes originated by the local router.
Shortest AS-path: Chooses the route with the fewest AS hops.
Lowest Origin Code: Prefers iBGP origins over eBGP, and eBGP over Incomplete.
Lowest MED: Selects the path with the smallest MED, but only compares MED for routes from the same AS.
eBGP over iBGP: Prefers external BGP paths over internal.
Shortest IGP Path to BGP Next Hop: Chooses the nearest next hop according to IGP metrics.
Oldest Path for eBGP: Prefers the oldest path from external BGP peers for stability.
Lowest Router ID: Selects the path through the BGP router with the lowest router ID.
Minimum Cluster List Length: In route reflection, prefers the path with the shortest cluster list.
Lowest Neighbor Address: Finally, the path from the neighbor with the lowest IP address is chosen if all other criteria are equal.
Traditionally in BGP, the selection process chooses only one route to be installed into the RIB. This approach was not optimal as it utilized only one path at a time. BGP multipath is a feature that allows multiple paths to be selected simultaneously, enabling traffic to be distributed across these paths. The paths included in the multipath setup are not distinguished by preference based on the criteria from 1 (Weight) through 8 (Shortest IGP Path to BGP Next Hop). They must either have the same AS-path for iBGP paths or be received from the same AS for eBGP paths. This technique enhances bandwidth usage and provides redundancy by utilizing all eligible routes equally (using ECMP) or unequally (using UCMP). BGP multipath promotes load balancing and ensures network reliability by rerouting traffic if a path fails.
By default, BGP can handle up to 8 multiple paths for a given prefix and
install them into the RIB. The limit on the number of paths can be customized
for each address family and both iBGP and eBGP sessions. Setting the
maximum-path value to 1 effectively disables the multipath feature.
vsr running config# / vrf main routing bgp as 65501
vsr running config# / vrf main routing bgp router-id 10.125.0.1
vsr running config# / vrf main routing bgp address-family ipv4-unicast maximum-path ebgp 1
vsr running config# / vrf main routing bgp address-family ipv4-unicast maximum-path ibgp 1
Specific parameters can be used to relax the criteria for including paths in the
BGP multipath selection. For example, the command bestpath as-path
multipath-relax as-set relaxes the requirement for paths to have the same
AS-path list (for iBGP) or to originate from the same AS (for eBGP).
However, the condition of having the shortest AS-path is still enforced,
meaning the paths must have the same number of AS hops as the best path.
vsr running config# / vrf main routing bgp bestpath as-path multipath-relax as-set
Another command, bestpath as-path ignore true, goes further by removing the
requirement for paths to share an identical count of AS in the AS-path
(criteria 4 in the previously mentioned list). With this setting, the AS-path
is entirely excluded from the path comparison process:
vsr running config# / vrf main routing bgp bestpath as-path ignore true
Refers to command reference for more details.
BGP Add-Path¶
The BGP Additional Paths feature, commonly referred to as BGP Add-Path,
enhances the capabilities of BGP by allowing the advertisement of multiple
paths for the same prefix in a BGP session. By default, BGP installs
multiple paths to a prefix into the RIB but only advertises the best path
according to the above-mentioned criteria. The Add-Path feature,
however, enables the advertisement of additional paths using the commands
addpath tx-all-paths. For example, the command addpath tx-all-paths true
configures BGP to advertise all available paths.
vsr running config# / vrf main routing bgp as 65501
vsr running config# / vrf main routing bgp neighbor 10.125.0.3 remote-as 65502
vsr running config# / vrf main routing bgp neighbor 10.125.0.3 address-family ipv4-unicast addpath tx-all-paths true
Refers to command reference for more details.
Unequal Cost Multipath¶
BGP Unequal Cost Multipath (UCMP), is an extension to the BGP multipath feature that allows for load balancing traffic across multiple paths that have different bandwidth capacities. In standard networking practices, ECMP is typically used when paths have the same cost metric, meaning that the traffic can be distributed evenly among them. However, this is not optimal when the paths have different bandwidths or capacities.
BGP UCMP improves upon this by allowing routers to distribute traffic in proportion to the bandwidth of each available path. This means that a higher-capacity link can carry more traffic, which can improve overall network efficiency and utilization.
The implementation of UCMP involves:
Path Advertisement: Routers advertise paths along with their respective bandwidth capabilities using a special bandwidth extended-community.
Path Selection: When multiple paths to the same destination are available, the router can use the bandwidth information to decide how much traffic to send over each path.
BGP UCMP can be particularly useful in environments where there are significant differences in link bandwidths and where bandwidth optimization and efficient load balancing are critical.
Warning
The current UCMP implementation is based on the IETF standard draft “draft-ietf-idr-link-bandwidth-07”. As the standard has not yet been finalized, interoperability of the UCMP feature is only guaranteed between Virtual Service Router routers. Routers from other vendors might not recognize the bandwidth extended-community correctly and could default to applying ECMP instead.
Bandwidth advertisement¶
Bandwidth information can be advertised using the bandwidth extended-community,
which can be configured via a route-map. Either num-multipaths or a bandwidth
value can be set. Refers to
command reference
for details.
vsr running config# / routing route-map BANDWIDTH seq 10 policy permit
vsr running config# / routing route-map BANDWIDTH seq 10 set extcommunity bandwidth 100
The route-map is typically applied to the outbound configuration of a neighbor.
Path selection¶
By default, Virtual Service Router applies UCMP when all the paths for a given prefix include a bandwidth extended-community value. If this condition is not met, ECMP is performed instead. This behavior is customizable using the command.
vsr running config# / vrf main routing bgp bestpath extcommunity-bandwidth behavior ecmp-on-missing
The options are detailed in command reference .