I’ve been doing some testing recently with different software based routers, and wanted to give them a test under real world conditions. The current full IPv4 table is larger than 900,000 routes and to get an idea of how well they handle it, I needed to be able to simulate getting a full transit feed in the lab environment.
This is far from a new topic, and I’m sure there’s many ways to approach this issue, I just happened to need to work on this recently, and this is the method I ended up settling on.
First, we need a source for all these routes. They don’t necessarily have to be real, we could just make fake routes for 1.1.1.1/32, 1.1.1.2/32, 1.1.1.3/32, and so on till we got to 900,000(ish) total, but in some cases this can be an unrealistic test as systems will merge routes into contiguous blocks of larger prefixes and internally reduce the size of the routing table. To replicate how reductions would happen in the real world, we need the real world routes.
Fortunately, RIPE maintains a number of servers that regularly save a copy of all the routes received, from a variety of locations around the world, and provide that for download. I looked at their list of servers, and selected RRC18 as it has a single full table, which matches what I’m aiming to emulate. You could of course select another server that gets multiple copies of the full table from different peers if that data better fits your test environment. Then you just download the latest dump from your selected server, in my case: https://data.ris.ripe.net/rrc18/latest-bview.gz
I originally thought the easiest use of the data might be to use some bash and awk one-liner to parse the output of the file with bgpdump, and generate a text file with commands to add them as static routes to a VyOS instance, and I’d BGP peer that to the test lab. However, loading the routes to VyOS choked on the massive quantity. The first route addition commands went quickly, eventually slowing to a crawl as ever more routes were added. Eventually I gave up after leaving it trying to process the static route creations for several hours.
I tried tweaking my bash and awk to output a config file for FRR under linux that contained all the static routes, but FRR choked, using more than 64GB of memory and being killed when the system ran out of RAM.
An acquaintance pointed me to gobgpd, which will work on the dump from RIPE directly, and is a very simple daemon to test with BGP. Turns out it works pretty well.
You’ll want to:
- install via your distro’s package manager of choice, “apt-get install gobgpd” or equivalent.
- Create gobgpd.conf (example below)
- Start gobgpd with “sudo -E gobgpd -f gobgpd.conf &”
- Load the route dump into the daemon with “gobgp mrt inject global latest-bview”
Here’s a very quick config example for you. This config should be pretty self documenting in terms of the local AS and router-id, and the neighbor configuration. The policy is there to overwrite the next-hop data from the dump, as their next-hop data obviously won’t work for us here.
[global.config]
as = 65500
router-id = "192.168.1.1"
[[neighbors]]
[neighbors.config]
neighbor-address = "192.168.1.2"
peer-as = 65501
[[policy-definitions]]
name = "policy1"
[[policy-definitions.statements]]
name = "statement1"
[policy-definitions.statements.actions.bgp-actions]
set-next-hop = "192.168.1.1"
[global.apply-policy.config]
export-policy-list = ["policy1"]
default-import-policy = "accept-route"
default-export-policy = "accept-route"And once it’s running, we can check on the BGP state on our peer, in this case a VyOS test VM.
nigel@vyos01:~$ show bgp summary
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.1.2, local AS number 65501 vrf-id 0
BGP table version 916895
RIB entries 1679949, using 308 MiB of memory
Peers 1, using 725 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.1.1 4 65500 945727 15503 0 0 0 00:05:24 916835 0 N/A
Total number of neighbors 1Now we’ve got a full table of 916,835 routes, with real data, in our lab environment for testing.