GoBGP is an open source tool developed in Go language and running on Linux systems that provides control plane functionality for the BGP protocol. Compared to Quagga/FRRouting, GoBGP has better performance and shorter convergence time, and can be used for larger networks, such as acting as an IXP router. GoBGP can be configured via the gRPC API using multiple languages such as Python, C++, and of course the CLI. goBGP also supports OpenConfig, and its YANG model conforms to draft-ietf-idr-bgp-model-03. Because GoBGP can easily interfere with routing manually and is more involved, it is a good tool for experimentation. In this paper, we present the main features and practices of gobgp.
Installation and Composition
Installation of GoBGP is very simple, just download the tar.gz file from https://github.com/osrg/gobgp/releases and unzip it. The one selected here is v2.27.0.
- daemon for Gobgp, complete implementation of BGP protocol
- Can interact with gobgpd via the gRPC API
- You can also configure bgp through configuration files
- Full-featured CLI
- You can view BGP-related information and configure BGP
- Configuration file: supports multiple formats toml/yaml/json, etc.
- Full-featured CLI
- Multiprotocol Support
- Labeled IPv4/IPv6
- Labeled IPv4/IPv6
- Flowspec IPv4/IPv6/L2
- Flexible Policy
- Graceful Restart
- Both restarting/helper speak role
- Route Reflector
- Route Server
- MRT Dumping
- RPKI Validation
- FIB manipulation
- gRPC API
- Standard configuration format
Compared with Quagga/FRRouting, GoBGP has better performance and shorter convergence time, and can be applied to larger networks, such as acting as an IXP router. For more performance tests on BGP, see Comparing Open Source BGP stacks with internet routes.
Integration with Quagga/Zebra, etc
GoBGP supports only one routing protocol, BGP, but it can be integrated with Zebra to work with Quagga/FRR by way of an API to support multiple routing protocols.
GoBGP can be integrated into the Quagga/Zebra system.
We can start
gobgpd as a bgp server to establish a BGP connection with the switch.
Here is the network topology diagram
For example, for
Check the peer information via gobgp, here the
Establ of the State means the connection has been established, if the State is
Active then you need to check if the switch configuration is correct.
adjacent rib-in and rib-out.
You can declare the route with the following command.
To ensure connectivity between iBGP peers, full connectivity relationships between IBGP peers are required . The Route Reflection mode is a mature alternative to the Full Mesh mode, which decreases dramatically as the cluster size grows, allowing a BGP Speaker (i.e., Route Reflector) to broadcast learned routing information to other BGP Peers, greatly reducing the number of BGP Peer This greatly reduces the number of BGP Peer connections.
For gobgpd, the BGP Server can be supported as a Route Reflector by modifying the configuration file by adding the
RouteReflector.RouteReflectorConfig configuration as follows.
- Node 172.25.0.7 as an RR node to establish a bgp peer with switch
- Node 172.25.0.6 as RR client node, establish bgp peer with RR node
- Node 172.25.0.8 as RR client node, establish bgp peer with RR node
There are some scenarios in the existing network, In order to achieve network traffic interoperability, it is usually necessary to perform full connectivity through eBGP . Full connectivity between border devices is more demanding in terms of cost consumption and device performance, and is not conducive to network topology and device expansion. Route Server is similar to IBGP full connectivity using route reflector , which is a device (or multiple devices) used to perform routing services, and its main function is to propagate routes to individual clients (border devices), and the routes published to clients do not modify path attributes such as AS_PATH, Nexthop, MED, etc., thus reducing the border router full connectivity consumption.
As shown in the figure below, an IX (Internet eXchange) contains multiple independent SPs (service providers) that want to interoperate traffic. Each SP has a border router connected to the common switching network. Each SP has its own AS number, and the BGP Router addresses range from 10.0.0.1 to 10.0.0.8.
In this case, the 8 BGP Peers are required to establish a full connection. Like iBGP, this full mesh connection is more demanding in terms of cost consumption and device performance, and is not conducive to the expansion of network topology and number of devices.
BGP Route Server can simplify SP connectivity as follows.
The following figure shows the transparent route propagation implemented by route server.
For more information about route server, see Route Server.
Route Server is also supported for GoBGP.
Policy is a way to control how a BGP route is inserted into a RIB or broadcast to a BGP Peer, and is divided into two parts
Action. When the Policy is configured and the Condition condition is triggered, an Action action is performed to modify the route.
- Condition includes
neighbor(source/destination of the route) and
- Action includes
MED/aspath/community manipulation, etc.
Policy model includes
Import Policy and
Import policy is invoked before best path calculation and pushing routes to RIB.
Export policy is invoked after that.
You can view the policy with the following command.
Route Server Policy Model
For the Route Server model, Import and Export policies are specific to a Peer: Import and Export policies are specific to a Peer.
The Import policy defines what routes will be imported into the master RIB.
The Export policy defines what routes will be exported from the master RIB.
A Policy contains multiple Statements, each with its own Condtions and Actions.
- aspath length
- extended community
- rpki validation result
- route type (internal/external/local)
- large community
- afi-safi in
- accept or reject
- add/replace/remove community or remove all communities
- add/subtract or replace MED value
- set next-hop (specific address/own local address/don’t modify)
- set local-pref
- prepend AS number in the AS_PATH attribute
You can view the Policy configuration with the following command.
Policy configuration is a bit more complicated, the following are the steps to configure it, which can be found here.
- define defined-sets
- define prefix-sets
- define neighbor-sets
- define bgp-defined-sets
- define community-sets
- define ext-community-sets
- define as-path-setList
- define large-community-sets
- define policy-definitions
- attach policies to global rib (or neighbor local rib when neighbor is route-server-client).
GoBGP supports the BGP Monitoring Protocol (RFC 7854) for real-time monitoring of the operational status of BGP sessions, including the establishment and closure of peer relationships, routing information, etc.
In a BGP network, when multiple peers change frequently, if the peers are configured statically, it is necessary to add or remove peers frequently at the local end, which is a great maintenance workload. In this case, you can configure BGP dynamic peer function to make BGP listen for BGP connection requests from specified network segments and dynamically establish BGP peers, and add these peers to the same peer group. This reduces the workload of network maintenance by eliminating the need to add or remove BGP peers at the local end when peer changes occur.
Switches generally support the configuration of Dynamic Neighbors, for example, here is the method of configuring Dynamic Neighbors for Huawei switches, and Dynamic Neighbors are also supported for gobgp.
As shown below, there are two main parts to configure.
- Create a peer group and describe the basic information of the peer group.
- Configure the peer group to listen on the
There are a lot of other features on GitHub about MRT/BMP/EVPN, so I won’t go over them here, but you can check the documentation if you need to.
Referring to the documentation provided by the gobgp library, we can implement a simple go bgp server as shown below.
As you can see, the sample code is relatively simple and mainly uses the following APIs.
api.Peer structure can be configured in more detail so that the joined BGP Peer is acting as an RR client.
Here is a list of several common BMP messages.