open menu

Internet Exchange Fabric Documentation

Port Security

For the purposes of ensuring layer 2 stability, the following policies are hardware enforced.

Source MAC address locking

All frames forwarded to the public internet exchange fabric must have the same source MAC address. To ensure this is complied with, there is an access control list that will drop any traffic, both ingress and egress, that does not match your configured MAC address.


To update the source MAC Address assigned to your port, simply log in to the portal and change the mac address for the desired port. This will automatically push the change to your port and have you ready to pass more bits in no time.


All Frames forwarded to the public internet exchange fabric must have one of the following ethertypes:

  • 0x0800 IPv4
  • 0x0806 ARP
  • 0x86dd IPv6

Broadcast Storm Control

Broadcast traffic received on any port on the public internet exchange fabric is limited to no more than 33713 Kbps, any broadcast traffic over this limit will be dropped.

Reverse DNS

All reverse dns is automatically generated and assigned, and represents participant information
|       |       |     +--- pop
|       |       +--------- switch
|       +----------------- port
+------------------------- ASN


We operate an AS112 server. This system provides anycast reverse DNS lookup for several prefixes, namely:


Because these IP addresses are widely used for private networking, many end-user systems are configured to perform reverse DNS lookups for these address ranges. DNS lookups for these ranges should always be null-answered quickly, in order to make sure that DNS retransmits don't occur (thereby overloading local DNS resolvers), and to prevent end-user systems from hanging due to DNS lookups.

Use of this service is available via a BGP session to all users at no charge.


A BGP session will be automatically configured for you if you select the checkbox on the signup form, or visit the portal at anytime to enable / disable your session.

Route Servers

We offer a pair of highly available route servers. Each route server runs at a diverse location as a virtual machine on a cluster of physical servers connected via a private 10G mesh. In the highly unlikely event that there is a failure in reachability to a single one, it's designed so that its counterpart will continue to provide BGP connectivity.

Incoming BGP Community Actions

    0:$ASN    Prevent announcement of a prefix to $ASN
33713:$ASN    Announce a route to $ASN
    0:33713   Prevent announcement of a prefix to all peers
33713:33713   Announce a route to all peers

33713:666     Blackhole destination prefix across only public internet exchange
33713:999     Blackhole source prefix across only public internet exchange

We also honor RFC7999

65535:666     Blackhole destination prefix across only public internet exchange

IRRdb filtering

We automatically provide IRRdb filtering at the route servers, if for some reason you are unable to function with this in place, we suggest you setup private sessions. You may also contact operations to arrange static filtering.

Realtime Blackholing

Traffic is matched to destination MAC address, so customer blackholes will not interfere with any other traffic.

Blocking is done per customer, for customers with multiple ports, any destination MAC address will match.

You may activate the blackholing with BGP Communities . You do not need to peer with anyone on the route server, just need to establish sessions.

Under normal conditions, adding blackhole routes take place immediately, however actions are rate limited globally and processed serially, so at times they may take up to a minute or two to take effect. Removing blackhole communities may take a bit longer since they have to be synchronized across all route servers.

Traffic Policing

Traffic policing allows customers to setup prefix lists and policers on ingress traffic via a RESTful API.

Currently in a closed beta, contact us if interested.

BCP 214 / RFC 8327 BGP Session Culling Compliance

United IX is compliant with BCP 214 / RFC 8327, specifically using section 3.2 for "Involuntary BGP Session Teardown."

Before doing maintenance on any switch, we will filter port 179 and wait up to 5m until traffic has dropped significantly in order to reduce the amount of traffic loss. We of course always give 7+ days notice for standard maintenance as well.