Technical resources
Welcome to IAA’s Technical Resources Hub, your repository for detailed guidelines for peering configuration, port security, route policies, and CDN access. These standards help ensure stable, efficient, and secure interconnections across IAA’s national exchange fabric. Use this resource to configure your IX port, fine-tune your routing preferences, and manage your CDN visibility. If you are instead looking for documentation on how to use the portal, please head to the IAA Member Portal.
Peering service
Please review the below technical information to configure your IX port appropriately for the exchange’s Peering service; this information also applies to Extended Reach Peering.
Peers must adhere to the following rules: by doing so, you’ll help foster a healthy environment for all across the exchange!
Note: You may be wondering where the old communities are. They remain active and will continue to be supported into the future. On 15 July 2025, we updated our communities to accommodate the expansion of our caching offering, introducing a new range of communities for each exchange. If you require the details of the old communities please contact support@internet.asn.au, otherwise we do recommend you use these new communities.
Connection information
Connection information
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.
Traffic rules
Traffic rules
The following link-local protocols are exceptions and are allowed:
- 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
- L2 Keepalives
- Interior routing protocol broadcasts (e.g. OSPF, ISIS, IGRP, EIGRP)
- Vendor proprietary protocols:
-
- Discovery protocols: CDP, EDP, FDP, MNDP
- VLAN/trunking protocols: VTP, DTP
- Vendor proprietary protocols:
- ARP
- ICMPv6 Network Discovery
The following are NOT permitted:
- Proxy ARP. Use of Proxy ARP on the router’s interface to the IX is strictly prohibited.
- IP Directed Broadcasts. IP Directed Broadcasts are strictly prohibited.
Port & routing security
Port routing security
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 ingress rate limit Broadcast, Unknown Unicast and Multicast (BUM) traffic to 500 packets per second on all IX ports.
Prefix Lengths
In accordance with RFC 7454 (section 6.1.3) guidelines and to align with the generally accepted prefix lengths by BGP providers on the internet, we impose the following limits:
- IPv4 max length = /24
- IPv6 max length = /48
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.
Route servers
Route servers
There are two route servers per state which utilise the routing daemon BIRD to reflect routes received from peers to others that forms the multi-lateral peering environment.
By nature of reflecting routes, the IX peering ASN (7606) is removed from all sessions so please ensure your router is configured to expect this (no bgp enforce-first-as).
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. Please refer to the APNIC guide for the AS-Set object type on how to create this resource.
Configuration changes to the Route Servers across all IXes are deployed via two methods.
Method 1: Automated provisioning From the Member Portal, any new peering order or modification will instantly deploy to the route server and reflect the progress back to the user.
Method 2: Set Schedule The route servers also have a set schedule to redeploy configuration daily at the following times (Sydney local):
- Route Server 1 at 8am
- Route Server 2 at 1pm
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 them on the following sections and if you require assistance contact us.
BGP Communities
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.
| 0:<peer-as> | Do not advertise to <peer-as> |
| 7606:<peer-as> | Advertise to |
| 0:7606 | Do not advertise to any peer |
| 7606:7606 | Advertise to all peers |
| 1:<peer-as> | Prepend once to <peer-as> |
| 2: <peer-as> | Prepend twice to <peer-as> |
| 3:<peer-as> | Prepend thrice to <peer-as> |
For Extended Communities, prepend “rt:” to the community of choice, for example:
| rt:0:<peer-as> | Do not advertise to specified peer |
For Large Communities, prepend “7606:” to the community of choice, for example:
| 7606:0:<peer-as> | Do not advertise to specified peer |
CDN Communities
CDN Communities
We utilise an auxiliary network, AS10084, that peers at exchanges to provide a path for Content Delivery Networks (CDNs) caches.
Content providers supply us with their hardware which resides 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 served to you by default when peering with the route servers; however, some may require explicit opt-in. Please review the below to control your visibility from AS10084’s perspective.
All exchanges
| Opt-out | Opt-in | Notes | |
| ALL CDNs | 10084:4901 | 10084:4902 | For Opt-In please review each IX notes as some require extra steps |
NSW-IX
| Opt-out | Opt-in | Notes | |
| Netflix (OCA) | 10084:4603 | 10084:4604 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| ALL CDNs | 10084:4601 | 10084:4602 |
QLD-IX
| Opt-out | Opt-in | Notes | |
| Apple (AEC) | 10084:4711 | 10084:4712 | Opt-in required |
| Meta (MNA) | N/A | N/A | Bi-lat required to Meta (AS32934). Submit Peering Requests at: https://www.meta.com/peering |
| Microsoft (MCC) | 10084:4703 | 10084:4704 | Default Opt-in |
| Netflix (OCA) | 10084:4707 | 10084:4708 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| Steam (STM) | 10084:4709 | 10084:4710 | Default Opt-in |
| ALL CDNs | 10084:4701 | 10084:4702 |
SA-IX
| Opt-out | Opt-in | Notes | |
| Google (GGC) | 10084:4203 | 10084:4204 | Default Opt-in |
| Microsoft (MCC) | 10084:4205 | 10084:4206 | Default Opt-in |
| Netflix (OCA) | 10084:4207 | 10084:4208 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| Steam (STM) | 10084:4209 | 10084:4210 | Default Opt-in |
| ALL CDNs | 10084:4201 | 10084:4202 |
VIC-IX
| Opt-out | Opt-in | Notes | |
| Google (GGC) | 10084:4403 | 10084:4404 | Default Opt-in |
| Netflix (OCA) | 10084:4409 | 10084:4410 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| Microsoft (MCC) | 10084:4405 | 10084:4406 | Default Opt-in |
| Steam (STM) | 10084:4411 | 10084:4412 | Default Opt-in |
| ALL CDNs | 10084:4401 | 10084:4402 |
WA-IX
| Opt-out | Opt-in | Notes | |
| Netflix (OCA) | 10084:4007 | 10084:4008 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| Meta (MNA) | N/A | N/A | Bi-lat required to Meta (AS32934). Submit Peering Requests at: https://www.meta.com/peering |
| Microsoft (MCC) | 10084:4005 | 10084:4006 | Default Opt-in |
| Steam (STM) | 10084:4009 | 10084:4010 | Default Opt-in |
| ALL CDNs | 10084:4001 | 10084:4002 |
Note: You may be wondering where the old communities are. They remain active and will continue to be supported into the future. On 15 July 2025, we updated our communities to accommodate the expansion of our caching offering, introducing a new range of communities for each exchange. If you require the details of the old communities please contact support@internet.asn.au, otherwise we do recommend you use these new communities.
Connection information
We use the following standards to connect to any of our peering points (Duplex SMF):
-
10 Gbps
10GBase-LR – 1310nm – 10km -
40 Gbps
40GBase-LR4 – 1310nm – 10km -
100 Gbps
100GBase-LR1 – 1310nm – 10km (Preferred)
100GBase-LR4 – 1310nm – 10km -
400 Gbps
400GBase-LR4 – 1310nm – 10km
We offer Link Aggregation (LAG) to enable gradual increases in bandwidth. LAG cost is calculated by the number of ports times the port price.
Traffic rules
The following link-local protocols are exceptions and are allowed:
- 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
- L2 Keepalives
- Interior routing protocol broadcasts (e.g. OSPF, ISIS, IGRP, EIGRP)
- Vendor proprietary protocols:
-
- Discovery protocols: CDP, EDP, FDP, MNDP
- VLAN/trunking protocols: VTP, DTP
- Vendor proprietary protocols:
- ARP
- ICMPv6 Network Discovery
The following are NOT permitted:
- Proxy ARP. Use of Proxy ARP on the router’s interface to the IX is strictly prohibited.
- IP Directed Broadcasts. IP Directed Broadcasts are strictly prohibited.
Port routing security
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 ingress rate limit Broadcast, Unknown Unicast and Multicast (BUM) traffic to 500 packets per second on all IX ports.
Prefix Lengths
In accordance with RFC 7454 (section 6.1.3) guidelines and to align with the generally accepted prefix lengths by BGP providers on the internet, we impose the following limits:
- IPv4 max length = /24
- IPv6 max length = /48
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.
Route servers
There are two route servers per state which utilise the routing daemon BIRD to reflect routes received from peers to others that forms the multi-lateral peering environment.
By nature of reflecting routes, the IX peering ASN (7606) is removed from all sessions so please ensure your router is configured to expect this (no bgp enforce-first-as).
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. Please refer to the APNIC guide for the AS-Set object type on how to create this resource.
Configuration changes to the Route Servers across all IXes are deployed via two methods.
Method 1: Automated provisioning From the Member Portal, any new peering order or modification will instantly deploy to the route server and reflect the progress back to the user.
Method 2: Set Schedule The route servers also have a set schedule to redeploy configuration daily at the following times (Sydney local):
- Route Server 1 at 8am
- Route Server 2 at 1pm
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 them on the following sections and if you require assistance contact us.
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.
For Standard Communities:
| 0:<peer-as> | Do not advertise to <peer-as> |
| 7606:<peer-as> | Advertise to |
| 0:7606 | Do not advertise to any peer |
| 7606:7606 | Advertise to all peers |
| 1:<peer-as> | Prepend once to <peer-as> |
| 2: <peer-as> | Prepend twice to <peer-as> |
| 3:<peer-as> | Prepend thrice to <peer-as> |
For Extended Communities, prepend “rt:” to the community of choice, for example:
| rt:0:<peer-as> | Do not advertise to specified peer |
For Large Communities, prepend “7606:” to the community of choice, for example:
| 7606:0:<peer-as> | Do not advertise to specified peer |
CDN Communities
We utilise an auxiliary network, AS10084, that peers at exchanges to provide a path for Content Delivery Networks (CDNs) caches.
Content providers supply us with their hardware which resides 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 served to you by default when peering with the route servers; however, some may require explicit opt-in. Please review the below to control your visibility from AS10084’s perspective.
All exchanges
| Opt-out | Opt-in | Notes | |
| ALL CDNs | 10084:4901 | 10084:4902 | For Opt-In please review each IX notes as some require extra steps |
NSW-IX
| Opt-out | Opt-in | Notes | |
| Netflix (OCA) | 10084:4603 | 10084:4604 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| ALL CDNs | 10084:4601 | 10084:4602 |
QLD-IX
| Opt-out | Opt-in | Notes | |
| Apple (AEC) | 10084:4711 | 10084:4712 | Opt-in required |
| Meta (MNA) | N/A | N/A | Bi-lat required to Meta (AS32934). Submit Peering Requests at: https://www.meta.com/peering |
| Microsoft (MCC) | 10084:4703 | 10084:4704 | Default Opt-in |
| Netflix (OCA) | 10084:4707 | 10084:4708 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| Steam (STM) | 10084:4709 | 10084:4710 | Default Opt-in |
| ALL CDNs | 10084:4701 | 10084:4702 |
SA-IX
| Opt-out | Opt-in | Notes | |
| Google (GGC) | 10084:4203 | 10084:4204 | Default Opt-in |
| Microsoft (MCC) | 10084:4205 | 10084:4206 | Default Opt-in |
| Netflix (OCA) | 10084:4207 | 10084:4208 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| Steam (STM) | 10084:4209 | 10084:4210 | Default Opt-in |
| ALL CDNs | 10084:4201 | 10084:4202 |
VIC-IX
| Opt-out | Opt-in | Notes | |
| Google (GGC) | 10084:4403 | 10084:4404 | Default Opt-in |
| Netflix (OCA) | 10084:4409 | 10084:4410 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| Microsoft (MCC) | 10084:4405 | 10084:4406 | Default Opt-in |
| Steam (STM) | 10084:4411 | 10084:4412 | Default Opt-in |
| ALL CDNs | 10084:4401 | 10084:4402 |
WA-IX
| Opt-out | Opt-in | Notes | |
| Netflix (OCA) | 10084:4007 | 10084:4008 | Opt-in required AND your AS-Set added to RADB::AS10084:AS-CONTENT. Please email us your AS-Set to peering@internet.asn.au |
| Meta (MNA) | N/A | N/A | Bi-lat required to Meta (AS32934). Submit Peering Requests at: https://www.meta.com/peering |
| Microsoft (MCC) | 10084:4005 | 10084:4006 | Default Opt-in |
| Steam (STM) | 10084:4009 | 10084:4010 | Default Opt-in |
| ALL CDNs | 10084:4001 | 10084:4002 |
Note: You may be wondering where the old communities are. They remain active and will continue to be supported into the future. On 15 July 2025, we updated our communities to accommodate the expansion of our caching offering, introducing a new range of communities for each exchange. If you require the details of the old communities please contact support@internet.asn.au, otherwise we do recommend you use these new communities.
Virtual Leased Line
Please review the following to ensure your virtual leased line services are configured appropriately. These services use MPLS-based Virtual Private Wire Service (VPWS), also known as a pseudowire or “martini-style” circuit which emulate a point-to-point Layer 2 connection over an MPLS network.
Port configuration
Port configuration
For your reference, our VLL ports are configured as follows:
| Configuration | |
| MAC layer | IEEE 802.3-2002 |
| UNI MTU | 9100 bytes |
| VLAN Ethertype | 0x8100 |
| CoS level | Standard |
| Unicast frame delivery | Deliver unconditionally |
| Multicast frame delivery | Deliver unconditionally |
| Broadcast frame delivery | Deliver unconditionally |
Layer 2 control tunnelling
Layer 2 control tunnelling
Our VLL ports are configured to discard or tunnel frames with the following protocols:
| Protocol | Action |
| STP, RSTP, MSTP | Tunnel |
| Pause | Discard |
| LCAP | Discard |
| Link OAM | Discard |
| 802.1x | Discard |
| E-LMI | Tunnel |
| LLDP | Tunnel |
| GARP | Tunnel |
VLAN tagging
VLAN tagging
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).
Connection speed
Connection speed
Individual VLL services are limited to a maximum of 10 Gbps and you may use up to 100% of your port capacity for VLL services. If you require a VLL larger than 10 Gbps, please contact us.
| Port speed | Available VLL speed |
| 10/40/100/400 Gbps | Up to 10 Gbps |
Speed policing
Speed policing
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.
| VLL speed | CIR | EBS | Violation action |
| 50 Mbps | 50 Mbps | 55 Mbps | DROP |
| 100 Mbps | 100 Mbps | 110 Mbps | DROP |
| 500 Mbps | 500 Mbps | 550 Mbps | DROP |
| 1 Gbps | 1000 Mbps | 1100 Mbps | DROP |
We apply bandwidth policers to all virtual leased line services to ensure we manage growth appropriately and maintain the stability of the IX fabric.
BFD timers
BFD timers
To avoid unnecessary link instability (flapping), we strongly recommend configuring your BFD (Bidirectional Forwarding Detection) timers to match ours.
Current BFD Timers:
- Multiplier: 3
- TX/RX Interval: 1000ms
If your BFD timers are more aggressive (i.e., set to detect issues in less than 3x 1000ms), even brief upstream flaps could cause your links to experience unnecessary and excessive instability.
Port configuration
For your reference, our VLL ports are configured as follows:
| Configuration | |
| MAC layer | IEEE 802.3-2002 |
| UNI MTU | 9100 bytes |
| VLAN Ethertype | 0x8100 |
| CoS level | Standard |
| Unicast frame delivery | Deliver unconditionally |
| Multicast frame delivery | Deliver unconditionally |
| Broadcast frame delivery | Deliver unconditionally |
Layer 2 control tunnelling
Our VLL ports are configured to discard or tunnel frames with the following protocols:
| Protocol | Action |
| STP, RSTP, MSTP | Tunnel |
| Pause | Discard |
| LCAP | Discard |
| Link OAM | Discard |
| 802.1x | Discard |
| E-LMI | Tunnel |
| LLDP | Tunnel |
| GARP | Tunnel |
VLAN tagging
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).
Connection speed
Individual VLL services are limited to a maximum of 10 Gbps and you may use up to 100% of your port capacity for VLL services. If you require a VLL larger than 10 Gbps, please contact us.
| Port speed | Available VLL speed |
| 10/40/100/400 Gbps | Up to 10 Gbps |
Speed policing
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.
| VLL speed | CIR | EBS | Violation action |
| 50 Mbps | 50 Mbps | 55 Mbps | DROP |
| 100 Mbps | 100 Mbps | 110 Mbps | DROP |
| 500 Mbps | 500 Mbps | 550 Mbps | DROP |
| 1 Gbps | 1000 Mbps | 1100 Mbps | DROP |
We apply bandwidth policers to all virtual leased line services to ensure we manage growth appropriately and maintain the stability of the IX fabric.
BFD timers
To avoid unnecessary link instability (flapping), we strongly recommend configuring your BFD (Bidirectional Forwarding Detection) timers to match ours.
Current BFD Timers:
- Multiplier: 3
- TX/RX Interval: 1000ms
If your BFD timers are more aggressive (i.e., set to detect issues in less than 3x 1000ms), even brief upstream flaps could cause your links to experience unnecessary and excessive instability.