Child pages
  • BGP Route Servers

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fixed typo in DINX-RS (thanks willem!)

There are two BGP separate route servers on each peering LAN.  It is recommended to always peer with both BGP Route Servers at a location, as sessions to both servers ensure that there is no disruption to the advertisement of your prefixes should it be necessary to performance maintenance on a Route Server.  The Route Servers do not peer with each other by design, so peering with only one server is an unnecessary risk for your network! 


Note
titleBi-lateral peering is considered best practice !

While the BGP Route Server service is made available as a convenience, it is strongly recommended that, in addition to any sessions you plan to establish with the BGP Route Servers, you still maintain direct bi-lateral peering sessions with peers that you feel are important to your network! BGP Route Servers should be used to pickup quick/easy/additional peers only, and not as a replacement for your discrete peering policy!

In particular there are many peers that advertise only a subset of their prefixes to the BGP Route Server. Always aim for a bilateral session !


routeserver2
INXASNHostnameTypeIPv4IPv6
JINX37700routeserver1.jinx.net.zaBIRD196.22360.1496.12001:43f8:1f0::1
routeserver2.jinx.net.zaBIRD196.22360.1496.22001:43f8:1f0::2
CINX37701routeserver1.cinx.net.zaBIRD196.223.22.12001:43f8:1f1::1
routeserver2.cinx.net.zaBIRD196.223.22.22001:43f8:1f1::2
DINX37699routeserver1.dinx.net.zaBIRD196.223.30.12001:43f8:1f2::1
routeserver1.dinx.net.zaBIRD196.223.30.22001:43f8:1f2::2

Remember that the BGP-RS service at all the INXes do not include the BGP-RS ASN in BGP update messages, as the RS is not actually a transit network.  

Warning
titleBGP next-as
Ensure that if you do plan on peering with the BGP Route Servers, you
NMBINX

37735

routeserver1.nmbinx.net.zaBIRD196.60.120.12001:43f8:690::1
routeserver2.nmbinx.net.zaBIRD196.60.120.22001:43f8:690::2


First ASN Check

Remember that the BGP-RS service at all the INXes do not include the BGP-RS ASN in BGP update messages, as the RS is not actually a transit network.  Ensure that if you do plan on peering with the BGP Route Servers, you understand that the BGP-RS does not attach its ASN to outbound BGP messages.

Please implement the IOS "no bgp enforce-next-as" (or IOS-XR "enforce-first-as disable"), or appropriate equivalent, for your platform.

Filtering policy and process

INX has always believed in filtering and we filter all client sessions to the BGP-RS service.  We encourage peers to keep their IRR objects accurate to help us to autogenerate these filters.  

  • Filters are built based on RPKI and IRRDB registered objects.  
  • We search the AfriNIC, RADB and RIPE registries (in that order).  
  • We permit only exact match filters for both IPv4 and IPv6.
  • RPKI invalids are dropped.
  • Some prefixes are automatically filtered by the route servers (eg. bogons and martians).  
  • We do not accept BGP announcements from private ASNs, or with private ASNs
Tip
titleMax-prefix
We recommend that you set the BGP max-prefix to the BGP-RS to 100,000 prefixes for IPv4 and 50,000 prefixes for IPv6

Filtering Frequency

Filter generation happens every 4h at 4h40, 8h40, 12h40, and continues.  If you need a filter update done in an emergency, please call, or email us, using the details on the INX support page.

BGP Communities for policy control

A simple set of BGP communities are made available for rudimentary policy control.  These will be expanded on over time, as the BGP Route Server service is enhanced. We provide both extended and large community (RFC 8092) support.  Note that if you intend to effect policy to 32bit ASNs you'll need to make use of the BGP-LC communities.

Info
titleRemember to use the correct ASN
Note: The communities example below applies to peers using the JINX route servers. The appropriate ASN for each INX, should be substituted when using the BGP route servers, at other INXes.
CommunityActionExplanation0:peer-asndeny to peer-asnblock announcement of prefix to peer-as0:37700block allblock announcement of prefix to all peers37700:peer-asnallow to peer-asnannounce prefix to specific peer-as (in conjunction with block all)37700:37700allow allannounce prefix to all peers (implicit default)

We honour the well-known no-export and no-advertise communities as if they were sent to us as a regular peer.  If you would specifically like us to propagate these, then please tag as below: 

37700:65281add no-exportadds the well known no-export community to all routes sent to peers37700:65282add no-advertiseadds the well known no-advertise community to all routes sent to peers

BGP Large Community Support for policy control

CommunityActionExplanation37700:
  • in the path.


INX's Route Server filtering policy is below:

  • Drop small prefixes – longer than /24 for ipv4 and longer than /48 for ipv6.
  • Drop all well-known martians and bogons.
  • Ensure that there is at least 1 ASN and less than 64 ASNs in the AS path.
  • Ensure that the peer AS is the same as the first AS in the AS path.
  • Drop any prefix where the next-hop IP address is not the same as the peer IP address. This prevents prefix hijacking.
  • Drop any prefix with a transit network ASN in the AS path.
  • Ensure that origin AS is in set of ASNs from the client’s IRRDB AS-SET.
  • If the prefix is evaluated as RPKI valid, accept.
  • If the prefix is evaluated as RPKI invalid, drop.
  • If the prefix is evaluated as RPKI unknown, revert to standard IRRDB prefix filtering.


Tip
titleMax-prefix
We recommend that you set the BGP max-prefix to the BGP-RS to 150,000 prefixes for IPv4 and 100,000 prefixes for IPv6

Filtering Frequency

Filter generation happens every 4h starting at 0h45.  If you need a filter update done in an emergency, please call, or email us, using the details on the INX support page.

BGP Communities for policy control

A simple set of BGP communities are made available for rudimentary policy control.  These will be expanded on over time, as the BGP Route Server service is enhanced. We provide both extended and large community (RFC 8092) support.  Note that if you intend to effect policy to 32bit ASNs you'll need to make use of the BGP-LC communities.  As a general rule, you should implement large community (LC) filtering if your device supports this.  Do not mix both types!


Info
titleRemember to use the correct ASN
Note: The communities example below applies to peers using the JINX route servers. The appropriate ASN for each INX, should be substituted when using the BGP route servers, at other INXes.


CommunityActionExplanation
0:peer-asndeny to peer-asnblock announcement of prefix to peer-
asn
as
0:37700
:0:0
block allblock announcement of prefix to all peers
37700
:1
:peer-asnallow to peer-
as
asnannounce prefix to specific peer-as (in conjunction with block all)
37700:
1:0
37700allow allannounce prefix to all peers (implicit default)

Individual network filtering

Tip
titleAS-Path Stripping

The BGP route servers do not add their own ASN in the advertised path, so if you're planning on constructing a filter list to filter the BGP Route servers, do not use the BGP route servers ASN in the path!

We do not yet publish a route object for the route-servers.  We will add that in the future, so, for now, please reach out to the Ops team to see how to do this most efficiently.

Communities returned for filtered routes

If your prefix is filtered by the BGP-RS, we'll return one of the BGP communities below, that should help aid in the debugging process.

Code Block
languagebash
titleFiltered community List


PREFIX_LEN_TOO_LONG = ( routeserverasn, 1101, 1 ) PREFIX_LEN_TOO_SHORT = ( routeserverasn, 1101, 2 ) BOGON = ( routeserverasn, 1101, 3 ) BOGON_ASN = ( routeserverasn, 1101, 4 ) AS_PATH_TOO_LONG = ( routeserverasn, 1101, 5 ) AS_PATH_TOO_SHORT

We honour the well-known no-export and no-advertise communities as if they were sent to us as a regular peer.  If you would specifically like us to propagate these, then please tag as below: 


37700:65281add no-exportadds the well known no-export community to all routes sent to peers
37700:65282add no-advertiseadds the well known no-advertise community to all routes sent to peers

BGP Large Community Support for policy control

CommunityActionExplanation
37700:0:peer-asndeny to peer-asnblock announcement of prefix to peer-asn
37700:0:0block allblock announcement of prefix to all peers
37700:1:peer-asnallow to peer-asannounce prefix to specific peer-as (in conjunction with block all)
37700:1:0allow allannounce prefix to all peers (implicit default)


We also support path prepending using the following policy: 

CommunityExplanation
37700:101:peer-asnPrepend to peer AS once
37700:102:peer-asnPrepend to peer AS twice
37700:103:peer-asnPrepend to peer AS three times


Communities returned for filtered routes

If your prefix is filtered by the BGP-RS, we'll return one of the BGP communities below, that should help aid in the debugging process.

Code Block
languagebash
titleFiltered community List
PREFIX_LEN_TOO_LONG      = ( routeserverasn, 1101, 61  )
FIRSTPREFIX_ASLEN_NOTTOO_PEER_ASSHORT     = ( routeserverasn, 1101, 72  )
NEXT_HOP_NOT_PEER_IPBOGON       = ( routeserverasn, 1101, 8  )
IRRDB_PREFIX_FILTERED       = ( routeserverasn, 1101, 93  )
IRRDB_ORIGIN_AS_FILTERED = ( routeserverasn, 1101, 10 )
PREFIX_NOT_IN_ORIGIN_ASBOGON_ASN                = ( routeserverasn, 1101, 4 11 )
RPKI_UNKNOWN  AS_PATH_TOO_LONG           = ( routeserverasn, 1101, 125  )
RPKI_INVALIDAS_PATH_TOO_SHORT        = ( routeserverasn, 1101, 6  )
FIRST_AS_NOT_PEER_AS     = ( routeserverasn, 1101, 7 13 )
TRANSIT_FREE_ASN    NEXT_HOP_NOT_PEER_IP     = ( routeserverasn, 1101, 8 14 )
TOOIRRDB_MANYPREFIX_COMMUNITIESFILTERED     = ( routeserverasn, 1101, 15 )

Prefixes auto-filtered by the Route Servers

For the overall safety and security of our participants, we actively filter the following prefixes at the Route Servers.  That is, advertisements from peers, containing the following networks, will be dropped, and not onward announced.

Code Block
languagebash
titleIPv4 prefixes filtered by the BGP-RS (RFC6890)
        martians = [
9  )
IRRDB_ORIGIN_AS_FILTERED = ( routeserverasn, 1101, 10 )
PREFIX_NOT_IN_ORIGIN_AS  = ( routeserverasn, 1101, 11 )
RPKI_UNKNOWN             = (  10.0.0.0/8+,
				100.64.0.0/10+,
routeserverasn, 1101, 12 )
RPKI_INVALID             = (  169.254.0.0/16+,
  routeserverasn, 1101, 13 )
TRANSIT_FREE_ASN         = ( routeserverasn, 1101,  172.16.0.0/12+,
14 )
TOO_MANY_COMMUNITIES     = (          192.0.0.0/24+,
                192.0.2.0/24+,
      routeserverasn, 1101, 15 )

Prefixes auto-filtered by the Route Servers

For the overall safety and security of our participants, we actively filter the following prefixes at the Route Servers.  That is, advertisements from peers, containing the following networks, will be dropped, and not onward announced.

Code Block
languagebash
titleIPv4 prefixes filtered by the BGP-RS (RFC6890)
        martians  192.168.0.0/16+,= [
                19810.180.0.0/158+,
      				100.64.0.0/10+,
                198169.51254.1000.0/2416+,
                203172.16.0.113.0/2412+,
                224192.0.0.0/424+,
                240192.0.02.0/424+,
                0192.0168.0.0/32-16+,
                0198.018.0.0/0{25,32},15+,
                0198.051.0100.0/0{0,7}24+,
        ];
Code Block
languagebash
titleIPv6 prefixes filtered by the BGP-RS
        martians = [203.0.113.0/24+,
                ::/0,224.0.0.0/4+,
                240.0.0.0/4+,
   # Default (can be advertised as a route in BGP to peers if desired) 0.0.0.0/32-,
                ::/96,0.0.0.0/0{25,32},
                  # IPv4-compatible IPv6 address - deprecated by RFC42910.0.0.0/0{0,7}
        ];


Code Block
languagebash
titleIPv6 prefixes filtered by the BGP-RS
        martians = [
                ::/1280,                   # Unspecified addressDefault (can be advertised as a route in BGP to peers if desired)
                ::1/12896,                  # Local host loopback addressIPv4-compatible IPv6 address - deprecated by RFC4291
                ::ffff:0.0.0.0/96+/128,     # IPv4-mapped addresses            # Unspecified address
                ::224.0.0.0/100+1/128,                # CompatibleLocal addresshost (IPv4loopback format)address
                ::ffff:1270.0.0.0/10496+,       # Compatible address (IPv4 format)IPv4-mapped addresses
                ::0224.0.0.0/104100+,         # Compatible address (IPv4 format)
                ::255127.0.0.0/104+,       # Compatible address (IPv4 format)
                0000::/80.0.0.0/104+,              # PoolCompatible used for unspecified, loopback and embedded IPv4 addressesaddress (IPv4 format)
                0200::/7255.0.0.0/104+,       # Compatible address     # OSI NSAP-mapped prefix set (RFC4548) - deprecated by RFC4048(IPv4 format)
                3ffe0000::/168+,              # Pool used Formerfor 6bone, now decommissionedunspecified, loopback and embedded IPv4 addresses
                20010200:db8::/327+,         # Reserved by IANA for special purposes and documentation   # OSI NSAP-mapped prefix set (RFC4548) - deprecated by RFC4048
                20023ffe:e000::/2016+,             # InvalidFormer 6to46bone, packets (IPv4 multicast)now decommissioned
                20022001:7f00db8::/2432+,         # InvalidReserved 6to4 packets (IPv4 loopback)by IANA for special purposes and documentation
                2002:0000e000::/2420+,        # Invalid 6to4 packets (IPv4 defaultmulticast)
                2002:ff007f00::/24+,        # Invalid 6to4 packets (IPv4 loopback)
                2002:0a000000::/24+,        # Invalid 6to4 packets (IPv4 private 10.0.0.0/8 networkdefault)
                2002:ac10ff00::/2824+,        # Invalid 6to4 packets
 (IPv4 private 172.16.0.0/12 network)
                2002:c0a80a00::/3224+,        # Invalid 6to4 packets (IPv4 private 19210.1680.0.0/168 network)
                fc002002:ac10::/728+,              # UnicastInvalid Unique6to4 Local Addressespackets (ULA)IPv4 - RFC 4193private 172.16.0.0/12 network)
                fe802002:c0a8::/1032+,        # Invalid 6to4 packets (IPv4 # Link-local Unicastprivate 192.168.0.0/16 network)
                fec0::/10+,             # Site-local Unicast - deprecated by RFC 3879 (replaced by ULA)
                ff00::/8+,              # Multicast
                ::/0{49,128}            # Filter small prefixes
        ];    fc00::/7+,              # Unicast Unique Local Addresses (ULA) - RFC 4193
                fe80::/10+,             # Link-local Unicast
                fec0::/10+,             # Site-local Unicast - deprecated by RFC 3879 (replaced by ULA)
                ff00::/8+,              # Multicast
                ::/0{49,128}            # Filter small prefixes
        ];


ASNs filtered by the Route Servers (Tier-1 networks/peer-locking)

We filter a regular set of networks that are known to be transit-free (ie. we do not expect a peer to send us a prefix with one of these ASNs in the path).  

Code Block
languagebash
titleIPv6 prefixes filtered by the BGP-RS
       TRANSIT_FREE_ASNS = [ 174, 701, 1299, 2914, 3257, 3320, 3356, 3491, 5511, 6453, 6461, 6762, 6830, 7018 ];


Filtering of the Route Servers (ingress to a peer) 


Tip
titleAS-Path Stripping

The BGP route servers do not add their own ASN in the advertised path, so if you're planning on constructing a filter list to filter the BGP Route servers, do not use the BGP route servers ASN in the path!


We publish IRR record to show networks that peer with the BGP-RS service.  Peers are are so inclined, may use this to create their own filters that they can then elect to use to filter the BGP-RS in question.  These are available separately for each INX as AS-SETs for: 

  • CINX:   AFRINIC::AS-CINX-RS
  • DINX:   AFRINIC::AS-DINX-RS
  • JINX:   AFRINIC::AS-JINX-RS
  • NMBINX:  AFRINIC::AS-NMBINX-RS

This is also published at PeeringDB

Table of Contents