The purpose of this article is to facilitate analysis of raw BGP data collected by various public monitors. From time to time, one might need to look at the raw aggregated BGP data in order to convince oneself that there's not something wrong, or that data collected by ThousandEyes is in fact correct. (It almost always is, but proof helps.)
Working with Quagga BGP RIB files
First, it's important to understand how our BGP data collection works, and where the data comes from.
- Public monitors shown in ThousandEyes consume data aggregated by the University of Oregon's RouteViews project (www.routeviews.org). We download routes collected by various collectors maintained by the RouteViews project, process the data and display it for use.
- Private monitors peer directly with a ThousandEyes-maintained route collector and provide updates in real time. Data from private monitors is not presently available for inspection/analysis.
The RouteViews project makes full routing information base (RIB) dumps of data available every 2 hours (UTC time), and provides updates every 15 minutes. These files are compressed in .bz2 format. Data for each monitor we display can be found on the RouteViews site, in the location shown by the table at the bottom of this page.
To review raw BGP data, you'll need an application to parse the data. For this, we use bgpdump, which provides human-readable data from the raw BGP information.
Installing and using BGPdump
Note: This is simply a compiled version of RIPE bgpdump, The project is maintained by RIPE NCC and the Internet Research community. The project source is available at https://bitbucket.org/ripencc/bgpdump/wiki/Home.
To install and run bgpdump, follow these instructions:
- Download the file, and extract the contents
- move the bgpdump file to /usr/local/bin/ (which puts it in the path for your user)
- chmod +x it, to make it executable
- test it, by running bgpdump. The following information should be displayed
$ bgpdump 2014-08-12 17:13:17 [info] logging to syslog bgpdump version 126.96.36.199 Usage: bgpdump [-m|-M] [-t dump|-t change] [-O <output-file>] <input-file> bgpdump translates binary MRT files (possibly compressed) into readable output Output mode: -H multi-line, human-readable (the default) -m one-line per entry with unix timestamps -M one-line per entry with human readable timestamps (there are other differences between -m and -M) Common options: -O <file> output to <file> instead of STDOUT -s log to syslog (the default) -v log to STDERR Options for -m and -M modes: -t dump timestamps for RIB dumps reflect the time of the dump (the default) -t change timestamps for RIB dumps reflect the last route modification Special options: -T run unit tests and exit
Next, download a RIB file from the appropriate collector. Use the table at the bottom of this page to determine which collector to use. Data is stored in a year.month structure, with RIBS containing the full downloads made available every two hours (UTC), and UPDATES containing the updates captured by the collectors (every 15 minutes). Beneath the RIBS|UPDATES folders, you will find a folder for each day of the month, and files saved using the convention [rib|updates].yyyyMMdd.hhmm.bz2. File sizes vary based on the number of monitors advertising routes to each specific collector, and by number of routes collected by each monitor.
Running bgpdump without -m will output a lot of data and includes column explanations to help better understand the data. Given the form of the output and content of one of the files, it makes running prefix-based searches on the data difficult - thus without the -m or -M option, bgpdump tends to be less useful than you'd like. Below, see an example of a single entry from a RIB file.
$ bgpdump rib.20140801.0000.bz2 2014-08-07 13:47:13 [info] logging to syslog TIME: 08/01/14 00:00:00 TYPE: TABLE_DUMP_V2/IPV4_UNICAST PREFIX: 188.8.131.52/24 SEQUENCE: 0 FROM: 184.108.40.206 AS2914 ORIGINATED: 07/30/14 08:41:55 ORIGIN: IGP ASPATH: 2914 15169 NEXT_HOP: 220.127.116.11 MULTI_EXIT_DISC: 96 COMMUNITY: 2914:420 2914:1001 2914:2000 2914:3000 65504:15169
Running with the -m option will output as shown below:
$ bgpdump -m rib.20140801.0000.bz2 2014-08-07 13:49:42 [info] logging to syslog TABLE_DUMP2|1406851200|B|18.104.22.168|5056|22.214.171.124/24|5056 6461 15169|IGP|126.96.36.199|0|0||NAG|| TABLE_DUMP2|1406851200|B|188.8.131.52|1668|184.108.40.206/24|1668 15169|IGP|220.127.116.11|0|0||NAG|| TABLE_DUMP2|1406851200|B|18.104.22.168|701|22.214.171.124/24|701 6453 15169|IGP|126.96.36.199|0|0||NAG|| TABLE_DUMP2|1406851200|B|188.8.131.52|293|184.108.40.206/24|293 15169|IGP|220.127.116.11|0|0||NAG|| TABLE_DUMP2|1406851200|B|18.104.22.168|3257|22.214.171.124/24|3257 15169|IGP|126.96.36.199|0|10|3257:8012 3257:30016 3257:50001 3257:54900 3257:54901|NAG||
bgpdump -m outputs data in the following column order:
- BGP Protocol
- timestamp (in epoch format)
- W/A/B (withdrawal/announcement/routing table)
- Peer IP (address of the monitor)
- Peer ASN (ASN of the monitor)
- Origin Protocol (typically always IGP)
- Next Hop
- Community strings
- Atomic Aggregator
A couple of use cases for using bgpdump to get necessary information:
- Determine all routes to a specific prefix ( bgpdump -m <file> | grep <prefix>)
$ bgpdump -m rib.20140801.0000.bz2 | grep 188.8.131.52/24 2014-08-07 13:51:36 [info] logging to syslog TABLE_DUMP2|1406851200|B|184.108.40.206|5056|220.127.116.11/24|5056 6461 15169|IGP|18.104.22.168|0|0||NAG|| TABLE_DUMP2|1406851200|B|22.214.171.124|2914|126.96.36.199/24|2914 15169|IGP|188.8.131.52|0|96|2914:420 2914:1001 2914:2000 2914:3000 65504:15169|NAG|| TABLE_DUMP2|1406851200|B|184.108.40.206|1668|220.127.116.11/24|1668 15169|IGP|18.104.22.168|0|0||NAG|| TABLE_DUMP2|1406851200|B|22.214.171.124|701|126.96.36.199/24|701 6453 15169|IGP|188.8.131.52|0|0||NAG||
- Determine all routes that use a specific AS Path (bgpdump -m <file> | grep "ASPath" )
$ bgpdump -m rib.20140801.0000.bz2 | grep "37100 15169" 2014-08-07 14:04:17 [info] logging to syslog TABLE_DUMP2|1406851200|B|184.108.40.206|37100|220.127.116.11/24|37100 15169|IGP|18.104.22.168|0|0|no-export|NAG|| TABLE_DUMP2|1406851200|B|22.214.171.124|37100|126.96.36.199/24|37100 15169|IGP|188.8.131.52|0|0|no-export|NAG|| TABLE_DUMP2|1406851202|B|184.108.40.206|37100|220.127.116.11/20|37100 15169 43515|IGP|18.104.22.168|0|0|no-export|NAG||
Note: ASPaths are shown in monitor>transit>origin format. When using AS Path as the filter, the results show all the updates having the filter as a part of the AS Path. In the example below, the Origin AS is 56203, but contains AS 577 in the AS Path string. To target a specific origin, grep for the origin with a trailing pipe character (ie, "577|")
$ bgpdump -m rib.20140801.0000.bz2 | grep "577" | more 2014-08-07 15:37:48 [info] logging to syslog TABLE_DUMP2|1406851200|B|22.214.171.124|6539|126.96.36.199/24|6539 577 6939 4826 38803 56203|IGP|188.8.131.52|0|0||NAG||
Checking BGP changes over a period of time
You can also run bgpdump on a group of files, using the bzcat -- just concatenate them using bzcat, and then pipe the output to bgpdump. This can be useful to find any updates related to a specific monitor, path or prefix over a period of time - but is predicated on having all the data available to use. Below shows two methods:
$ cat rib.20140801.0000.bz2 rib.20140801.0200.bz2 > result_concat.bz2 $ bgpdump -m result_concat.bz2 | grep <filter> or $ bzcat *.bz2 | bgpdump -m - | grep <filter>
When you want more specific information, you can actually telnet to the quagga collectors, and use a limited set of commands to interact with quagga to show you data. The most typical usage is the sh ip bgp <prefix>, which will show you the last update to the routing table for each monitor using that collector for a specific prefix. Visit http://archive.routeviews.org/, and click the login link for the appropriate collector (check the table below to find the appropriate collector for the monitor you’re interested in reviewing).
Working with Quagga collectors
$ telnet route-views2.routeviews.org Trying 184.108.40.206... Connected to route-views2.routeviews.org. Escape character is '^]'. Hello, this is Quagga (version 0.99.21). Copyright 1996-2005 Kunihiro Ishiguro, et al.
route-views2.routeviews.org> sh ip bgp 220.127.116.11/24 BGP routing table entry for 18.104.22.168/24 Paths: (33 available, best #19, table Default-IP-Routing-Table) Not advertised to any peer 37100 15169 22.214.171.124 from 126.96.36.199 (188.8.131.52) Origin IGP, localpref 100, valid, external Community: no-export Last update: Wed Aug 6 22:42:49 2014 2914 15169 184.108.40.206 from 220.127.116.11 (18.104.22.168) Origin IGP, metric 96, localpref 100, valid, external Community: 2914:420 2914:1001 2914:2000 2914:3000 65504:15169 Last update: Tue Aug 5 09:58:21 2014 8492 15169 22.214.171.124 from 126.96.36.199 (188.8.131.52) Origin IGP, localpref 100, valid, external Community: 8492:1305 29076:223 29076:900 29076:51003 29076:53003 29076:60495 29076:64667 Last update: Sat Aug 2 07:45:53 2014
route-views2.routeviews.org> sh ip bgp summary BGP router identifier 184.108.40.206, local AS number 6447 RIB entries 961711, using 103 MiB of memory Peers 48, using 214 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 220.127.116.11 4 37100 8288960 80256 0 0 0 1d18h15m 502043 18.104.22.168 4 3356 18146786 180159 0 0 0 03w2d11h 496968 22.214.171.124 4 7018 29305714 54041 0 0 0 07w4d01h 499044 126.96.36.199 4 11537 2107157 357770 0 0 0 01w0d04h 14846 188.8.131.52 4 1668 26907309 357321 0 0 0 01w0d04h 498641 184.108.40.206 4 3549 16541627 180168 0 0 0 03w2d11h 499753 220.127.116.11 4 22652 10690189 180158 0 0 0 03w2d11h 501666 18.104.22.168 4 1299 21217943 180155 0 0 0 02w2d15h 495653 22.214.171.124 4 8492 40104466 357732 0 0 0 6d09h11m 508154 126.96.36.199 4 3257 16473759 180252 0 0 0 01w2d15h 499352 188.8.131.52 4 39756 0 0 0 0 0 never Connect 184.108.40.206 4 31500 0 0 0 0 0 never Active 220.127.116.11 4 11686 34598321 180171 0 0 0 03w2d11h 504967
route-views2.routeviews.org> sh ip bgp neighbors BGP neighbor is 18.104.22.168, remote AS 37100, local AS 6447, external link Description: SEACOM BGP version 4, remote router ID 22.214.171.124 BGP state = Established, up for 1d18h16m Last read 15:50:46, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: 4 Byte AS: advertised and received Route refresh: advertised and received(old & new) Address family IPv4 Unicast: advertised and received Address family IPv4 Multicast: advertised Message statistics: Inq depth is 0 Outq depth is 0 Sent Rcvd Opens: 8 6 Notifications: 4 1 Updates: 0 8216893 Keepalives: 80245 72125 Route Refresh: 0 4 Capability: 0 0 Total: 80257 8289029 Minimum time between advertisement runs is 30 seconds Update source is 126.96.36.199
Using BGPlay to work with RouteViews Data
You can also use bgplay on the RouteViews site to look at the last 10 days' worth of data. This can be useful when tracking changes that occur over a short period of time. Note that it only works based on the previous 10 days' worth of data.
Note: due to large data storage requirements, BGPlay only works with the trailing 10 days' of data
When BGPlay starts, a query window opens us where you can enter the prefix to monitor and the time interval in UTC. Press OK to open up an animation window as shown below. Below the figure, a numbered list corresponding to the callouts on the figure, explains each field in the image.
Let us break the picture into different parts for better understanding
- Indicates that the update shown is the 3rd update of the 399 updates within the specified time period.
- Signifies the router collector which received the BGP update.
- Path change indicates that the current BGP update contains new paths. Other possible BGP Update messages that can be seen are Route Announcement, Route Withdrawal and Route Re-Announcement.
- IP address of the peer from which the current BGP Update was collected.
- The date and time at which the current BGP Update was collected.
- Displays the change in the AS Path as contained by the new BGP Update message.
- Indicates the last clicked AS number and name.
- Vertical time axis.
- Each purple horizontal spike indicates a burst of BGP updates.
- Any purple horizontal spike touching this vertical line indicates 1 BGP update.
- Any purple horizontal spike touching this vertical line indicates 23 BGP updates.
- The starting date and time specified in the query.
- To scroll through the different BGP messages within the time period.
- To rearrange the AS graph to its starting layout.
- To start a new query.
|Collector||Monitor name||ASN||Monitor IP||BGP data location|
|rv/jinx||Johannesburg, South Africa||30844||188.8.131.52||http://routeviews.org/route-views.jinx/bgpdata|
|rv/oreg||Los Angeles, CA||2152||184.108.40.206||http://routeviews.org/bgpdata|
|rv/oreg||New York, NY-1||7018||220.127.116.11||http://routeviews.org/bgpdata|
|rv/isc||Palo Alto, CA-4||36351||18.104.22.168||http://routeviews.org/route-views.isc/bgpdata|
|rv/oreg||San Francisco, CA||3561||22.214.171.124||http://routeviews.org/bgpdata|
|rv/oreg||San Jose, CA-3||2914||126.96.36.199||http://routeviews.org/bgpdata|
|rv/route-views3||San Jose, CA-4||209||188.8.131.52||http://routeviews.org/route-views3/bgpdata|
|rv/route-views3||San Jose, CA-5||5650||184.108.40.206||http://routeviews.org/route-views3/bgpdata|
|rv/route-views6||New York, NY-6||7018||2001:1890:111d:1::63||http://routeviews.org/route-views6/bgpdata|
|rv/oreg||Palo Alto, CA-2||3549||220.127.116.11||http://routeviews.org/bgpdata|