Technical HOPUS

Routing

The HOPUS backbone is fully routed, traceroutes will show all the hops.

We honor the MED: if you are interconnected on several POPs, we will choose the route with the lowest MED. We advertise our routes with the MED set to our IGP cost to the BGP next-hop (IGP costs are set based on the latency between our POPs).

We accept and honor the BGP Graceful Shutdown community (RFC8326). When you advertise this community we adjust our LocalPref to 0, which will ensure that alternate paths are used if they exist. During scheduled maintenances we will always signal this community.

The following routes are filtered on HOPUS:

More specific than / 24 in IPv4 or / 48 in IPv6 (except RTBH)
AS_PATH length greater than 5
Bogon ASN : Private or reserved ASNs (Bogon ASN filtering)
Martian's networks (Bogon Reference)

Maximum-prefix limit : We do set maximum-prefix limit on all eBGP sessions. The recommended max-pref limit to be configured on your side is provided on our PeeringDB page.

RTBH/Blackholing

It is possible to trigger some actions with BGP communities (44530:0 or 65535:666 for RTBH, 44530:65281 to be re-announced with NO_EXPORT).

Prefixes advertised with an RTBH community must be accepted by IRR filtering but may have an invalid RPKI/ROA validation status (eg /32 IPv4 or /128 IPv6 RTBH advertisements are accepted).

Route Servers

The BGP session with the Route Server is optional, we have an RS by POP.

The RS learns the routes via its iBGP session with our PE router and advertises all the routes available on HOPUS without the AS44530 (HOPUS ASN) in the AS_PATH.

BGP is not reciprocal, therefore each HOPUS member must establish a session with its local RS if he does not want to see AS44530 (HOPUS ASN) in AS_PATH.

To establish the BGP session with the RS, you must activate the multihop on this session (2 hops) and preferably add a static route to the RS via the PE.

Cisco users must specify "no bgp enforce-first-as” (IOS and IOS-XE) or “bgp enforce-first-as disable” (IOS-XR) when setting their configuration with the RS (since RS do not add their ASN in the AS_PATH)

Strict IRR Filtering

We filter the BGP announcements received using the NTT's IRR database (rr.ntt.net with bgpq4) this aggregates data from other IRRs by checking their relevance (IRR Lockdown).

The list of accepted prefixes is updated on a daily basis on our equipment, this list is based on your AS-SET if you provided one (see members page).

You can check the list of accepted prefixes on our Looking Glass. By doing a "BGP summary" on your POP router, you will see the number (and the list, following the link) of PfxRcd and PfxAcc for your session.

Route Origin Validation RPKI/ROA

Routes with an invalid RPKI/ROA validation status are rejected.

European networks can create and modify their ROA via the page https://my.ripe.net/#/rpki, and follow theses detailed explanations.

It is possible to check the BGP announcements and the validity of the ROA on the website of the RIPE RPKI Validator or the RPKI Portal from Cloudflare. The "received-routes" link from PfxRcd column also shows validation status on our Looking Glass.

BGP communities

We use a number of BGP communities in order to mark the origin of the learned routes (POP, Country ...), any route that we receive from you with these communities will be refused.

It is possible to trigger some actions with BGP communities (44530:0 or 65535:666 for RTBH, 44530:65281 to be re-announced with NO_EXPORT). However, it is not possible to restrict announcements via BGP communities.

The complete list of communities can be viewed on our object AUT-NUM AS44530.