We use the following standards to connect to any of our peering points (Duplex SMF):

• 10Gbps
  10GBaseLR – 1310nm – 10km
• 40Gbps
  40GBaseLR4 – 1310nm – 10km
• 100Gbps
  100GBaseLR4 – 1310nm – 10km

For those networks without the requirement to go straight to 100Gbps, we offer Link Aggregation (LAG) to enable gradual increases in bandwidth. LAG cost is calculated by the number of ports times the port price.

Permitted Ethernet types:

• 0x800 – IPv4
• 0x806 – ARP
• 0x86DD – IPv6

Unicast Only

Frames forwarded on the IX shall be Unicast only. Forwarding traffic to a Multicast or Broadcast MAC destination address is prohibited, except for the following:

• Broadcast ARP Packets
• Multicast ICMPv6 Neighbour Discovery packets (this does not include Route Solicitation or Advertisement packets).

Link local traffic

Link-local traffic shall not be forwarded to the IX Peering VLAN(s). Link-Local protocols include but are not limited to:

• ICMP redirects
• IEEE 802 Spanning Tree
• BOOTP/DHCP
• ICMPv6 Router Advertisements
• UDLD
• PIM
• Interior routing protocol broadcasts (e.g. OSPF, ISIS, IGRP, EIGRP)
• L2 Keepalives
• Vendor proprietary protocols:
  • Discovery protocols: CDP, EDP, FDP, MNDP
  • VLAN/trunking protocols: VTP, DTP

The following link-local protocols are exceptions and are allowed:

• ARP
• ICMPv6 Network Discovery

The following are NOT permitted:

X  Proxy ARP. Use of Proxy ARP on the router’s interface to the IX is strictly prohibited.

X  IP Directed Broadcasts. IP Directed Broadcasts are strictly prohibited.

Port MAC Limit

We request only one (1) layer 3 MAC per port on any of our Peering Points. This means frames forwarded to an individual IX port shall have the same MAC Address. Additional MAC(s) for maintenance/migration purposes are allowed.

Port Rate limits

We rate limit Broadcast, Unknown Unicast and Multicast (BUM) traffic to 500 packets per second on all IX ports.

Routing

We would appreciate it if you practice good network hygiene on your side, to protect your network and the internet community generally.

This means creating RoA’s for your prefixes, signing your routes (we use RPKI and drop invalids), implementing BCP38 on your network broadly and URPF on your ports into the IX.

If you need assistance with RPKI, check out APNIC’s RPKI pages or contact us.

We utilise the Routing Daemon BIRD. There are two route servers per state.

By default, the IX peering AS (7606) is removed from all sessions. However, if you would like us to include this, please advise us when you sign up for a service.

To define your peering session policy we require an AS-Set provided to us to that includes your ASN as well as any other ASNs you are announcing, this is supplied at your peering order submission.

Configuration changes to the Route Servers across all IX’s are on a set schedule, this means any changes to your AS-Set resource will only reflect on our side following these daily updates (Sydney local time):

• Route Server 1 at 9am
• Route Server 2 at 2pm

We have also made available communities that are universal across all peering points. These communities allow peers to set specific policies for their sessions.

For a list of communities, please review the Policy Control and the CDN Policy Control or contact us.

Policy control is achieved by the use of BGP Communities.

IX peers may tag their routes using the following to control policy via the route server. Please ensure you follow the instructions below to correctly set it up.

You may verify the communities are received by selecting your prefix via our looking glass at https://lg.ix.asn.au (5min refresh timer)

For Extended Communities, prepend “rt:” to the community of choice, for example:

For Large Communities, prepend “7606:” to the community of choice, for example:

We utilise an auxiliary network, AS10084, that peers at exchanges to provide a path for Content Delivery Networks (CDNs). CDNs provide hardware residing in our points of presence for a high speed, low latency direct path to all peers helping bring content as close as possible!

To control access to these content services, we aim to ensure all content is opt-in by default; however, some may require explicit opt-in.  Please review the below to control your visibility from AS10084’s perspective.

VLL services are terminated as native (untagged) traffic, or as a VLAN of your choice, except where other services are delivered on the same port.

For example, a typical service port may have peering as untagged and a VLL to another peer as tagged (up to 4096 per port).

Your existing peering port speed binds the speed available for your VLL service.

You may use up to 100% of your additional ports per IX assigned to VLL service(s).

We highly recommend you apply bandwidth shaping profiles to your VLL services at the speed of the service you have to ensure our policers do not impact them.

As a general rule, we apply a policing profile of the service speed as CIR + 10% EBS and drop any traffic exceeding.

We apply bandwidth policers to all virtual leased line services to ensure we manage growth appropriately and maintain the stability of the IX fabric.