Global R&E Routing Report
Technical Background
There are two mailing lists which this project uses to distribute analysis data.
While we have a representative selection of Regional and National Research & Education Networks involved with this project, we are always happy to accept new feeds. More feeds increases the diversity and helps with our goal of improving the routing infrastructure for the global R&E network community.
To join the project, potential hosts need to be able to offer a BGP feed, using EBGP multihop, of IPv4 R&E prefixes (over an IPv4 peering) and IPv6 R&E prefixes (over an IPv6 peering).
The NSRC collector has these details:
Please contact philip at
nsrc dot org if you
would like to join the project and offer a BGP feed.
The NSRC collector is a Linux appliance running Free Range Routing, better known as FRR. FRR has its origin in Quagga, and is now a highly capable suite of routing protocols including, of course, BGP, IS-IS, and OSPF. We always endeavour to use the latest release version of FRR (currently at 10.1) to ensure we have the latest features and capabilities.
Each participant in the project sets up an EBGP Multihop from
one of their routers, sending the NSRC collector their view of
the global R&E table. The collector is configured so that
each feed exists in its own view. This means that to display the
routes received from one participant in the project, we simply
run the command sh bgp ipv4 view NAME for IPv4,
and sh bgp ipv6 view NAME for IPv6.
The FRR collector has no FIB - the entries learned from each neighbour are only stored in the BGP table for that neighbour.
Once the BGP table has been dumped from the collector, the
analysis programme is run over the raw dump. This involves
converting the Cisco IOS style output (FRR has a wide
option) into a consistent format readable by the analysis
programme, before running the programme itself. The analysis
is stored in several files, which are then published on this site under
the the participants own page, as well as being compressed and
archived for posterity (and future reference).
While the focus is on IPv4 at the moment, the IPv6 table is also dumped from the collector - a future activity will see the same analysis being applied to it too.
Right now the IPv6 report summaries the number of entries in the IPv6 table, the total number of ASNs present, and the total number of origin ASNs. The IPv6 report also pulls out the count of the IPv6 subnet sizes.
As part of this project, NSRC has deployed three of the most popular validators: Routinator, FORT, RPKI-client/StayRTR.
For the purposes of the research here, FRR prioritises the Routinator validator. This validator provides a continuously updated feed of the current VRPS (validated ROA payloads), basically the address space that has had its ROAs signed.
This means that a daily record of the RPKI invalids for IPv4 and IPv6 can be collected from each participant. This is helpful in tracking the global deployment of Route Origin Authorisation (using RPKI) and Route Origin Validation (ROV - the dropping invalid prefixes).
The invalids are gathered from the BGP feed from the collector
simply by greping for the lines with the I in
them. FRR also has a feature whereby the Invalids can be displayed
simply by running show bgp view view
addr-family rpki invalid, but that is not used here
as the BGP dump has already been collected from the collector.
Participants who have implemented ROV will show no output in the RPKI Invalid dump - the more who implement ROV, the better it is for the Internet as a whole.
The reason for deploying the 3 main validators is to monitor differences in their behaviour. There shouldn't be a difference, because the Internet standards are well defined.
FRR follows RFC8210 in prioritising the validators configured. It only displays the VRPs received from the highest priority active validator. So there isn't a straightforward way to find out what each validator is producing by way of VRPs. So the project also runs a virtual router which is also configured to talk with each validator - and download the VRP table from each of them. These differences are captured once per day.
Two of the five Regional Internet Registries have published an AS0 TAL for the unassigned address resources they hold. These TALs are added to the validators hosted by NSRC, and the output published listing the prefixes includes these.
To find out the number of VRPs in the absence of the two AS0 TALs,
NSRC has access to a Cisco C1100 router which also is configured
to speak to four validators. The simple IOS-XE command sh ip
bgp rpki servers | i Prefixes will pick out the number of
validated prefixes the router has received from each validator.
This section covers configuration examples for popular routing platforms. Right now there are FRR, JunOS, and IOS-XR. Suggestions and contributions for other routing platforms are always most welcome.
The following shows the FRR configuration needed to set up an EBGP multihop session with the NSRC Collector:
router bgp 64511
bgp router-id 192.0.2.254
bgp log-neighbor-changes
no bgp default ipv4-unicast
timers bgp 15 45
neighbor 128.223.157.40 remote-as 65534
neighbor 128.223.157.40 description NSRC Collector
neighbor 128.223.157.40 ebgp-multihop 255
neighbor 2607:8400:2880:4::80df:9d28 remote-as 65534
neighbor 2607:8400:2880:4::80df:9d28 description NSRC Collector
neighbor 2607:8400:2880:4::80df:9d28 ebgp-multihop 255
!
address-family ipv4 unicast
neighbor 128.223.157.40 activate
neighbor 128.223.157.40 prefix-list DENY-ALL in
neighbor 128.223.157.40 route-map RNE-out out
exit-address-family
!
address-family ipv6 unicast
neighbor 2607:8400:2880:4::80df:9d28 activate
neighbor 2607:8400:2880:4::80df:9d28 DENY-ALLv6 in
neighbor 2607:8400:2880:4::80df:9d28 RNE-out out
exit-address-family
!
ip prefix-list DENY-ALL seq 5 deny 0.0.0.0/0 le 32
!
ipv6 prefix-list DENY-ALLv6 seq 5 deny ::/0 le 128
!
route-map RNE-out permit 10
description Match R&E networks
match community rne
!
route-map RNE-out deny 20
description Deny everything else
!
Note that this configuration snippet assumes that the BGP
community rne has already been set elsewhere in
the operator's network infrastructure.
Operators using routing equipment with a CLI similar to that of FRR (eg Cisco's IOS and IOS-XE) should have no difficulty in adapting the above configuration snippet for their own requirements.
The following shows the JunOS configuration needed to set up an EBGP multihop session with the NSRC Collector:
top edit policy-options
set policy-statement DENY-ALL term END then reject
set policy-statement ANNOUNCE-RNE term RNE from family inet
set policy-statement ANNOUNCE-RNE term RNE from protocol bgp
set policy-statement ANNOUNCE-RNE term RNE from community RNE
set policy-statement ANNOUNCE-RNE term RNE from route-type external
set policy-statement ANNOUNCE-RNE term RNE then accept
set policy-statement ANNOUNCE-RNE term END then reject
set policy-statement ANNOUNCE-RNEv6 term RNE from family inet6
set policy-statement ANNOUNCE-RNEv6 term RNE from protocol bgp
set policy-statement ANNOUNCE-RNEv6 term RNE from community RNE
set policy-statement ANNOUNCE-RNEv6 term RNE from route-type external
set policy-statement ANNOUNCE-RNEv6 term RNE then accept
set policy-statement ANNOUNCE-RNEv6 term END then reject
top edit protocols bgp
set group NSRC-View type external
set group NSRC-View local-address LOCAL_ADDRESS
set group NSRC-View import DENY-ALL
set group NSRC-View family inet unicast
set group NSRC-View export ANNOUNCE-RNE
set group NSRC-View neighbor 128.223.157.40 description "NSRC Collector"
set group NSRC-View neighbor 128.223.157.40 multihop ttl 255
set group NSRC-View neighbor 128.223.157.40 peer-as 65534
set group NSRC-Viewv6 type external
set group NSRC-Viewv6 local-address LOCAL_V6_ADDRESS
set group NSRC-Viewv6 import DENY-ALL
set group NSRC-Viewv6 family inet6 unicast
set group NSRC-Viewv6 export ANNOUNCE-RNEv6
set group NSRC-Viewv6 neighbor 2607:8400:2880:4::80df:9d28 description "NSRC Collector"
set group NSRC-Viewv6 neighbor 2607:8400:2880:4::80df:9d28 multihop ttl 255
set group NSRC-Viewv6 neighbor 2607:8400:2880:4::80df:9d28 peer-as 65534
Note that this configuration snippet assumes that the BGP
community RNE has already been set
elsewhere in the operator's network infrastructure. Also,
LOCAL_ADDRESS and LOCAL_V6_ADDRESS
are the router's local address, whether this is chosen as a
Loopback (normal) or a physical interface.
Operators using Juniper equipment in their network should be able to adapt this for their own needs.
The following shows the IOS-XR configuration needed to set up an EBGP multihop session with the NSRC Collector, courtesy of Erdemnet in Mongolia:
route-policy deny-all
drop
end-policy
!
route-policy RNE-out
if community matches-any rne then
pass
else
drop
endif
end-policy
!
router bgp 64511
timers bgp 15 45
bgp router-id 192.0.2.254
bgp log neighbor changes detail
!
neighbor 128.223.157.40
remote-as 65534
ebgp-multihop 255
description NSRC Collector
address-family ipv4 unicast
route-policy deny-all in
route-policy RNE-out out
!
!
neighbor 2607:8400:2880:4::80df:9d28
remote-as 65534
ebgp-multihop 255
description NSRC Collector
address-family ipv6 unicast
route-policy deny-all in
route-policy RNE-out out
!
!
Note that this configuration snippet assumes that the BGP
community rne has already been set elsewhere in
the operator's network infrastructure.
Operators using Cisco IOS-XR based routers should have no difficulty in adapting the above configuration snippet for their own requirements.