Peering Policy

Peers must comply with the following policies

  • A publicly routable ASN
  • Publicly routable address space
  • ASN record completed in PeeringDB
  • 24x7 NOC contact capable of resolving BGP routing issues
  • Ability to do the BGP between peers (and ideally the route servers, but optional)
  • Peer contact information must be provided to help enable a response in the event of any issues that may impact the IX or other Peers
  • Re-advertising the IX peering prefixes is bad and not permitted

Allowed Traffic Types

Ethernet types:
  • 0x800 – IPv4
  • 0x806 – ARP
  • 0x86DD – IPv6
Mac Security

Layer 2 MAC filtering is implemented at EdgeIX to help prevent unauthorised traffic from entering the exchange, each peering port/bundle is restricted to a single MAC address.

No Proxy ARP

Unicast only (except for broadcast ARP and Neighbour Discovery/IPv6 Things)

The following protocols are fine:

  • ARP
  • IPv6 ND

Please assume all others are a no-no

Community based prefix filtering

The EdgeIX route server system also provides well known communities to allow members to control the distribution of their prefixes. These communities are defined as follows:

Community Description
0:peer-as Prevent announcement of a prefix to a peer
24224:peer-as Announce a route to a certain peer
0:24224 Prevent announcement of a prefix to all peers
24224:24224 Announce a route to all peers

So, for example, to instruct the route server to distribute a particular prefix only to AS64111 and AS64222, the prefix should be tagged with communities: 0:24224, 24224:64111 and 24224:64222.

Alternatively, to announce a prefix to all EdgeIX members, excluding AS64333, the prefix should be tagged with community 0:64333.