FAQ

When does collector maintenance happen?

RouteViews plans all maintenance during our Maintenance Window.

What is Telnet rate limiting?

We use Telnet Rate Limiting to help keep our collectors running healthily.

ℹ We hope this solution will help keep our MRT Archives more complete going forward.

What is RouteViews?

RouteViews at the University of Oregon started its first research infrastructure development in 1995; the project has continuously collected and archived daily snapshots of data about the global Internet routing table since 1997. 

With routing collectors located around the world today at key locations such as Amsterdam, London, Sydney, Singapore, São Paulo, Santiago, Nairobi, South Africa, plus Northern Virginia, Chicago, California and other U.S. locations, with more than 900 active peering sessions, the infrastructure has global coverage. 

Over 260 different organizations share routing information with RouteViews, including many of the largest ISPs in the world.

How can I join RouteViews?

RouteViews is not a member organisation, but participation is open to all network infrastructure operators who are using BGP, have their own AS Number, and are multi-homing with other providers on the Internet (either directly and/or at Internet Exchange Points). 

Of greatest interest to RouteViews are operators who carry a significant portion of the commercial Internet BGP table or the full Research and Education Network BGP table. This variety of views helps users of RouteViews see how connectivity and reachability is seen across the various infrastructures which make up the global Internet.

How do I contact RouteViews?

Please email us at help@routeviews.org where one of the team will respond to your query or request.

 

Who can log in to RouteViews?

Anyone is welcome to log in to RouteViews.

To find a collector to view, look at our location map at https://www.routeviews.org/routeviews/index.php/map/ and pick a collector you want to access.

For example, navigate to the Sydney collector; the hostname displayed is route-views.sydney. Apart from the hostname, the type of collector, its location, IP addresses, and historical data are all accessible from the pop up window.

To access the collector, use telnet to the full hostname. Make sure you include the routeviews.org domain name. For example:

% telnet route-views.sydney.routeviews.org
Trying 114.31.193.202...
Won't send login name and/or authentication information.
Connected to route-views.sydney.routeviews.org.
Escape character is '^]'.

Hello, this is Quagga (version 0.99.23.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

route-views.sydney.routeviews.org>
How do I peer with RouteViews?

The simple answer is: direct BGP peering with a collector at a common Internet Exchange (this is the preferred method), or via multi-hop peering. There are some nuances as to which routes we want filtered out of the peering (i.e. routes described in RFC 6890). There are specifics as to how to do this, but it varies depending on your operating system. For more information, contact us!

How can I see the routes I advertise to a collector?

There are a few different ways you can see which routes you are advertising to the collector you peer with:

1. Log into the appropriate collector and take a look, e.g.:

% telnet route-views3.routeviews.org
Trying 128.223.51.108...
Won't send login name and/or authentication information.
Connected to route-views3.routeviews.org.
Escape character is '^]'.

Hello, this is FRRouting (version 7.3-rv).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

route-views3> sh bgp ipv4 unicast neighbor  routes

2. MRT RIB and update dumps. We get RIB dumps every two (2) hours and updates every fifteen (15) minutes. You can find them at: https://archive.routeviews.org. There are several tools to view the data at archive.routeviews.org, namely those described at https://www.routeviews.org/routeviews/index.php/tools/. CAIDA’s BGPReader tool is especially useful. But, if you’re feeling adventurous the MRT file format is described in RFC 6396.

3. Live BMP data via Kafka

How do I find out which of my routes are seen by RouteViews?

As with the previous question, any of the three ways mentioned:

1. Log in to the appropriate collector and query by your AS Number. E.g.:

% telnet route-views.routeviews.org
Trying 2001:468:d01:33::80df:3367...
Won't send login name and/or authentication information.
Connected to route-views.routeviews.org.
Escape character is '^]'.

<snip>

route-views>show ip bgp regexp _<your ASN>$

2. MRT dump file at https://archive.routeviews.org 

3. Live BMP data via Kafka.

Where does RouteViews peer?

RouteViews usually peers directly at IXPs. However, sometimes circumstances dictate multi-hop peering. Direct peering is when our collector interfaces directly (usually over Layer-2) with a peer. Multi-hop relies on existing Internet infrastructure to establish BGP peering sessions. This allows our collector to be placed anywhere. Check out our map at https://www.routeviews.org/routeviews/index.php/map/ to see where our current collectors are!

How do I host a RouteViews collector?

Contact us at help@routeviews.org!

We prefer to host collectors at Internet Exchange Points where members have expressed an interest and willingness to peer with RouteViews to provide a view of their BGP table. IXPs have rich connectivity, and their members can help the whole Internet provide a better view of route availability in that location.

RouteViews is seeking partners who are willing to host collectors in Central America, the Middle East, Africa, Central Asia, South Asia and the Pacific.

Can you please remove me from your block/deny list?

We do not maintain or distribute any block lists or deny lists.

Is RouteViews data licensed?

Yes. We recently migrated to the Creative Commons v4 w/ Attribution license visible at  https://creativecommons.org/licenses/by/4.0/.

Who is using RouteViews data?

We don’t always know. Please tell us if you are! Email us at help@routeviews.org

Check out this page: https://www.routeviews.org/routeviews/index.php/papers/

It is useful for the RouteViews project to be able to demonstrate how valuable this data is to the community. If you find this service useful for your research or operations, please take a moment to share your research papers or success stories.

What is RPKI and how can I see it?

RPKI (Resource Public Key Infrastructure) is a hierarchical method of validating routes on the Internet. RPKI relies on trust anchors for validation and uses objects called ROAs (Route Origination Authorizations) to validate said routes. These ROAs consist of a timestamp, the originating AS (Autonomous System), the prefix, the maximum length of that prefix, and a date range for which the prefix is valid. For more information visit https://www.ripe.net/manage-ips-and-asns/resource-management/certification.

You can see the current RPKI data (called VRPs – Validated ROA Payload) on the collectors by logging into a collector as in the examples below.

For FRR based collectors:

route-views2.routeviews.org> sh rpki prefix-table
host: 184.171.101.187 port: 3323
host: 184.171.101.188 port: 3323
RPKI/RTR prefix table
Prefix                               	Prefix Length  Origin-AS
1.160.0.0                               	12 -  24     	3462
1.1.1.0                                 	24 -  24    	13335
<snip>
2a01:c000::                             	19 -  48     	5511
2003::                                  	19 -  19     	3320
Number of IPv4 Prefixes: 129160
Number of IPv6 Prefixes: 22036

On Cisco IOS-based collectors, you can see the IPv4 VRPs with:

route-views>show ip bgp rpki table
119227 BGP sovc network entries using 19076320 bytes of memory
129160 BGP sovc record entries using 4133120 bytes of memory

Network          	Maxlen  Origin-AS  Source  Neighbor
1.0.0.0/24       	24  	13335  	0   	184.171.101.187/3323
1.1.1.0/24       	24  	13335  	0   	184.171.101.187/3323
<snip>

To show IPv6 VRPs:

route-views>show bgp ipv6 unicast rpki table
20207 BGP sovc network entries using 3718088 bytes of memory
22036 BGP sovc record entries using 705152 bytes of memory

Network          	Maxlen  Origin-AS  Source  Neighbor
2001:200::/32    	32  	2500   	0   	184.171.101.187/3323
2001:200:136::/48	48  	9367   	0   	184.171.101.187/3323
<snip>

To find the validation information relating to any single prefix, on the FRR-based collectors, use:

route-views2.routeviews.org> show rpki prefix 1.160.0.0/12
Prefix                               	Prefix Length  Origin-AS
1.160.0.0                               	12 -  24     	3462

And on Cisco IOS-based collectors you can use the command line search to achieve the same thing:

route-views>show ip bgp rpki table | i ^1.160.0.0/12
1.160.0.0/12     	24  	3462   	0   	184.171.101.187/3323
Is it okay to log in to the collector and show all the routes it has?

It is possible to do this, but we discourage it as it negatively impacts services for all users. 

Each collector is receiving full IPv4 and IPv6 BGP tables from a large number of peers. Logging in and showing the entire BGP table at the command line consumes considerable resources on each device, slowing down the service for everyone else.

If you want to show the full BGP table on a collector, or require frequent dumps of the entire BGP table, we encourage you to use the MRT RIB and Update dumps mentioned earlier.

 

Why is access to the collector using telnet and not ssh?

Because we have nothing to hide! 

We are aware that telnet is obsolete now and no longer provided by default on major operating systems. However, RouteViews is publicly available for all to use for their research, operations and troubleshooting. Besides, we use Secure Shell for administrative access.

 

What should my BGP policy on my RouteViews peering look like?

We set up the RouteViews peerings at IXPs and to multi-hop collectors so that they accept all prefixes you send us; we do not send anything to you. 

In the simplest case, your router configuration should send us “everything you have”, and you should have an inbound prefix filter that denies everything. Here is an example for Cisco IOS:

router bgp 64511
 address-family ipv4
  neighbor <routeviews> remote-as 6447
  neighbor <routeviews> prefix-list deny-all in
  neighbor <routeviews> prefix-list permit-all out
!
ip prefix-list deny-all deny 0.0.0.0/0 le 32
ip prefix-list permit-all permit 0.0.0.0/0 le 32
!

However, it is more common for operators not to send (or expose) the internal subnets of their address blocks to us – these subnets are per customer or service assignments, and not announced to the global Internet. So a more typical policy example might be:

router bgp 64511
 address-family ipv4
  neighbor <routeviews> remote-as 6447
  neighbor <routeviews> prefix-list deny-all in
  neighbor <routeviews> route-map routeviews-feed out
!
ip prefix-list deny-all deny 0.0.0.0/0 le 32
!
ip community-list standard aggregates permit 64511:1000
ip community-list standard subnets    permit 64511:1001
ip community-list standard pi         permit 64511:1005
!
route-map routeviews-feed permit 5
 match community aggregate pi
!
route-map routeviews-feed deny 10
!

Where the IOS named community “aggregate” is set on the network operator’s aggregate prefixes, and the IOS named community “pi” is set on the operator’s customers’ own (provider independent) address space. (For more detailed BGP configuration information that this example is based on, please consult  the BGP Community presentations at https://learn.nsrc.org/bgp.)

Am I able to run a traceroute from a collector?

You can run a traceroute from a collector, but remember that this is a collector of BGP routes, rather than a full router itself. The best path you will see in the BGP table is due to the best path selection process run across all the BGP paths it sees. Yet the FIB entry (where packets get sent) will be to the external physical interface of the collector, and the traceroute will show you the result from the host of the collector itself (rather than the best path you might see in the BGP table).

Here is an example, showing the BGP table entry for 1.1.1.1, versus what the FIB is actually doing:

route-views>sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 603920099
Paths: (28 available, best #23, table default)
<snip>
  3356 13335, (aggregated by 13335 108.162.243.1)
	4.68.4.46 from 4.68.4.46 (4.69.184.201)
  	Origin IGP, metric 0, localpref 100, valid, external, best
  	Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2012 65003:4134 65003:4837
  	path 7F57C4B2EA48 RPKI State valid
  	rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
<snip>

route-views>sh ip cef 1.1.1.1
1.1.1.0/24
  nexthop 128.223.51.1 TenGigabitEthernet0/0/0

route-views>trace 1.1.1.1
Type escape sequence to abort.
Tracing the route to one.one.one.one (1.1.1.1)
VRF info: (vrf in name/id, vrf out name/id)
  1 vl-51-gw.uoregon.edu (128.223.51.1) [AS 3582] 0 msec 0 msec 0 msec
  2 vl-51-gw.uoregon.edu (128.223.51.1) [AS 3582] 0 msec 1 msec 0 msec
  3 10.252.20.5 [AS 3257] 1 msec 0 msec 1 msec
  4 10.252.9.249 [AS 3257] 1 msec 0 msec 1 msec
  5 10.252.9.246 [AS 3257] 0 msec 1 msec 0 msec
  6 eugn-pe2-gw.nero.net (207.98.68.226) [AS 3701] 1 msec
<snip>
How do I use RouteViews to troubleshoot connectivity problems?

There are many ways to use RouteViews for troubleshooting connectivity issues. The common uses by network operators include:

  • Check BGP table entries for prefixes and their subnets – useful for finding what is being filtered, and often where it is being filtered, or not being filtered.
  • Check BGP table entries to assess aggregation – useful to find inadvertent subnet leaks
  • Check the variety of paths from the origin network to the collector – useful for troubleshooting reachability issues when multihoming/traffic engineering
  • Traceroutes from the collector back to the origin network (note, this relies on the collectors host location transit, and is not indicative of the paths the collector knows about)
  • Checking validation state of routes
  • Checking for mis-origination of routes (hijacks, “fat-fingers” etc)

For tougher problems, e.g. routes being visible in only some parts of the Internet, you can check collectors in different parts of the world to identify reachability problems being caused by providers incorrectly filtering prefixes.

What is BMP and why is it useful?

BMP (BGP Monitoring Protocol) is a protocol that allows realtime updates about all routes that a collector knows about. It is useful in network analysis and troubleshooting (see our FAQ about troubleshooting). For more information, check out https://tools.ietf.org/html/rfc7854.

What is Kafka?

Kafka is a distributed event streaming platform that uses the publish-subscribe model. In the context of RouteViews, we use Kafka to publish realtime BMP messages that you can access via bgpstream.

For more information, check out https://kafka.apache.org/

How do I access real-time RouteViews data?

First you should evaluate what kind of data you want to access.

For example, to access RouteViews BMP messages:

$ bgpreader -p routeviews-stream -R <collector name> -j <ASN>

For more information about bgpreader and its capabilities, check out https://bgpstream.caida.org/docs/tools/bgpreader

We have several examples in our public git repository: https://github.com/routeviews/tutorials

If you have any questions, don’t hesitate to contact us at help@routeviews.org