Route Server Filters at IXPs and 4-byte ASNs

Job Snijders job.snijders at hibernianetworks.com
Sat Jan 25 14:26:23 UTC 2014


Dear Sebastian,

On Sat, Jan 25, 2014 at 02:56:16PM +0100, Sebastian Spies wrote:

> So here's the thing: IXPs usually implement N:M filtering based on
> standard community strings. As standard BGP communities support only 4
> bytes, this only works for IXPs with 2-byte ASNs and peers with 2-byte
> ASNs.

There are various directions in which a workable solution may for IXP
Operators:

    - Use a mapping table: 32 bit values to 16 bit values. Every
      participant with a 4-byte ASN is represented with 2-bytes, there
      are pro's and con's to this approach.

    - Use an out-of-band mechanism which allows IXP participants to
      signal the desired routing policy to the Route Server. (VIX.at
      offers a web-interface where people can click and point to which
      ASNs they want to export or not).

Another approach would be to signal the desired routing policy through
RPSL. I've been working on some extensions which would allow an IXP
participant to publish what the Route Server should do on their behalf,
in this example 6777 is a Route Server and AS4247483647 is an IXP
participant with a 4-byte ASN:

    import-via: AS6777 from AS4247483647 accept AS4247483647
    export-via: AS6777 to AS4247483647 announce AS-ATRATO

    (read more here: http://tools.ietf.org/html/draft-snijders-rpsl-via )

Support for these extensions will be available in the next release of
the RIPE Whois Database. After that IXP Operators can consider
implementing support for RPSL-via. 

All of the above approaches have disadvantages:

    - Mapping tables add complexity
    - Most Out-of-band methods would differ from each other
    - RPSL-via is has yet to be implemented in the wild

> Extended communities to the rescue? 

Nope. Not as it stands today.

> I have been asking some IXP operators, about their practice and their
> reply was "4-byte ASNs are supported by our RS". What's your experience?

Most of them are lying through their teeth. :-)

Kind regards,

Job
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 873 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140125/02a163a7/attachment.sig>


More information about the NANOG mailing list