Overview

BGP (Border Gateway Protocol) is available on the Route10 through the Dynamic Routing interface. It is ideal for networks that need precise routing control—such as multi-WAN environments or routing between multiple sites. The multi-WAN use cases all require ISP cooperation. Note that Route10 does not have enough RAM to handle the full 1+ million route public internet routing table, so multi-WAN cases need to be default-only, or a limited subset of routes, not full internet routing tables. 

This article explains how BGP works on Route10, how to access the FRR shell, and when BGP is useful.

Accessing BGP on Route10

Navigate to:

Settings → Networks → Routes → Dynamic Routing

This opens a live FRRouting terminal in the UI.

Example:

Supported protocols in this interface:

• BGP
• OSPF / OSPFv3 (see this article)
   

How BGP Works

BGP is a policy-based routing protocol. Unlike OSPF, it does not discover networks automatically; instead, you explicitly control:

• Which networks Route10 advertises
• Which routes it accepts
• WAN preference (primary, backup, etc.)
• Path selection between sites
• Traffic behavior across AS boundaries
   

When BGP Makes Sense on Route10

Common BGP use cases:

• Multi-WAN deployments needing granular control
• Primary/backup WAN behavior
• Multi-site routing using iBGP or VPN tunnels
• Integrations with enterprise routing environments
• Scenarios requiring predictable path selection

BGP is not required for simple single-router networks.
 

Example BGP Topology

The below diagram illustrates the environment depicted in configuration below. A link between the two Route10s, and each with its own set of VLANs within their own /20 supernet. 

Configuring BGP on Route10

All BGP configuration uses FRR syntax. The following shows an example of using BGP to exchange routes across a VPN where one end has multiple /24s within 10.2.0.0/20 and the other end has multiple /24s within 10.8.0.0/20. 

Summary Route

BGP will only advertise routes that are explicitly in the routing table. For this case, because we’re summarizing multiple /24s into a single /20 for each end, we need a /20 blackhole route for BGP to be able to advertise the /20. The individual /24 networks are more specific matches than the /20, so will be preferred, hence the blackhole route has no functional impact beyond enabling BGP to advertise a single route.
 

Browse to Settings, Networks, Routes, and click +. 

Prefix List and Route Map Configuration

Next we need to define prefix lists and route maps in the FRR shell, which tell BGP what routes to advertise and what routes to accept. The following example is from the side where 10.8.0.0/20 is local, and 10.2.0.0/20 is remote.

configure
ip prefix-list BGP-EXPORT seq 10 permit 10.8.0.0/20
ip prefix-list BGP-IN seq 10 permit 10.2.0.0/20
route-map BGP-IN-MAP permit 10
  match ip address prefix-list BGP-IN
exit
route-map BGP-EXPORT-MAP permit 10
  match ip address prefix-list BGP-EXPORT
exit

BGP Configuration

Now onto configuring BGP itself. Here the remote BGP router’s IP is 10.2.5.1. Using private Autonomous System (AS) number 65000 on this side, and 65001 on the remote.

router bgp 65000
 neighbor 10.2.5.1 remote-as 65001
 address-family ipv4 unicast
  network 10.8.0.0/20
  neighbor 10.2.5.1 route-map BGP-IN-MAP in
  neighbor 10.2.5.1 route-map BGP-EXPORT-MAP out
end

The peer side gets the same configuration, just changing the neighbor IP and flipping subnets in the prefix lists.

Checking BGP Status

The first thing to check post-configuration is the status of the new BGP neighbor. The following is a truncated version of show ip bgp neighbors showing the most important part, “BGP state”. You want to see Established for the state. If the state is anything other than Established, then there is a configuration problem, or lack of network connectivity in general to the neighbor.

# show ip bgp neighbors 10.2.5.1 
BGP neighbor is 10.2.5.1, remote AS 65001, local AS 65000, external link
  Local Role: undefined
  Remote Role: undefined
Hostname: alta-r2
  BGP version 4, remote router ID 198.51.100.20, local router ID 192.0.2.67
  BGP state = Established, up for 00:14:01

After verifying established state, you can confirm routing details. First, verify what each side is advertising to its neighbor.

# show ip bgp neighbors 10.2.5.1 advertised-routes 
BGP table version is 2, local router ID is 192.0.2.67, vrf id 0
Default local pref 100, local AS 65000
Status codes:  s suppressed, d damped, h history, u unsorted, * 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.8.0.0/20      0.0.0.0                  0         32768 i

That confirms 10.8.0.0/20 is being advertised to 10.2.5.1.

Next, verify which routes are being received from the neighbor.

# show ip bgp neighbors 10.2.5.1 routes
BGP table version is 2, local router ID is 192.0.2.67, vrf id 0
Default local pref 100, local AS 65000
Status codes:  s suppressed, d damped, h history, u unsorted, * 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.2.0.0/20      10.2.5.1                 0             0 65001 i

And finally, check the routing table to confirm the route has been installed as expected. 

# show ip route bgp
Codes: K - kernel route, C - connected, L - local, S - static,
       O - OSPF, B - BGP, T - Table, v - VNC, V - VNC-Direct,
       t - Table-Direct,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure


IPv4 unicast VRF default:
B>* 10.2.0.0/20 [20/0] via 10.2.5.1, ipcb1qVK, weight 1, 00:19:57

That confirms the 10.2.0.0/20 route is in the routing table. The “B>*” at the beginning of that line tells you it was received by BGP (B), is the selected route (>), and is installed as the FIB route (*). That’s exactly what you want to see. 
 

Important:

Route10 does not validate or sanitize BGP commands.

The FRR shell behaves exactly like FRR on standard Linux systems.

Related FRRouting Documentation

General Setup
https://docs.frrouting.org/en/latest/setup.html

BGP (Border Gateway Protocol)
https://docs.frrouting.org/en/latest/bgp.html

Configuration Persistence

FRR configuration gets saved to the controller when the user exits the FRR terminal. To ensure that your settings are preserved through reboots and reconfigurations, be sure you exit the terminal and say Yes when prompted.

Support Scope

Support can assist with:

• Verifying BGP process status
• Checking neighbor states
• Viewing advertised/received routes

Support cannot assist with:

• AS-path manipulation
• Communities or route maps
• Complex multi-WAN BGP engineering
• Custom FRR scripting or automation