BGP Community filtering

Provide a BGP community filtering mechanism to peers

Route server peers will be able to manipulate outbound routing policies via
an in-band mechanism using BGP communities, instead of relying on
import/import-via, export/export-via RPSL attributes. The downside
to this method is that peers won’t be able to control inbound policies. 

Currently we offer the following options:

  • Do not announce a prefix to a certain peer: 0:peer-as
  • Announce a prefix to a certain peer: 6777:peer-as
  • Do not announce a prefix to any peer: 0:6777
  • Announce a prefix to all peers: 6777:6777

We also offer customers the ability to filter outbound announcements by tagging them with the following predefined communities. Note that you have to use the appropriate route server AS number, based on the AMS-IX location you're peering in, with 6777 representing Amsterdam.Currently supported locations for this feature are Hong Kong (AS58560) and Amsterdam (AS6777). 

For destination peers employing a 32-bit ASN, you can use the route target extended BGP community as follows:

  • do not announce a prefix to a certain peer: RT:0:peer-as
  • announce a prefix to a certain peer: RT:6777:peer-as
  • do not announce a prefix to any peer: RT:0:6777
AS-Path prepending can be done via the Route Servers by tagging prefixes using the following communities:
  • using 6777:65501, to prepend the advertising peer customer AS once towards all other peers
  • using 6777:65502, to prepend the advertising peer customer AS twice towards all other peers
  • using 6777:65503, to prepend the advertising peer customer AS thrice towards all other peers

ADDITIONAL NOTES

  • IRRdb policies work only on the AS level, whereas BGP communities work on the prefix level.
  • IRRdb policies are parsed and applied hourly, whereas BGP communities are effective immediately, being in-band.
  • BGP communities can only influence outbound (customer edge router to route server) announcements, whereas IRRdb policies can be used to also influence inbound (route server to customer edge router) announcements, before reaching the customer edge router, thus potentially affecting the BGP decision process.
  • Path hiding should not be a problem, as we are  employing the BIRD “secondary” configuration option.
  • Note that validity of the IRRdb/RPKI based information provided is not guaranteed in any way.
    Please consider carefully whether your AMS-IX facing router should solely rely
    on information exchanged to and from the route servers.