Member Portal
Categories

Looking ahead: what’s coming in 2026 for our network

As we head into 2026, our technical roadmap is focused on scale, automation, and delivering stronger performance and value for our Members across all exchanges. Here’s a snapshot of what’s underway:

Service automation
Over the past few months, we’ve been building towards our goal of full-service automation across ports, peering, and VLL services. Our plan is to enable faster provisioning and improved self-service capability through the IAA Member Portal. We’re targeting an early 2026 release, and when it’s ready we’ll be making some noise!

AS10084: new routers coming online
As our content network continues to grow, so too does the demand for larger capacity ports. We will be upgrading content routers at each exchange to 32x100Gbps platforms, with 400Gbps uplinks towards the exchange fabric, strengthening our capacity for growth.

VIC-IX 400Gbps deployment
With new hardware on the way, we will be upgrading VIC-IX to be fully 400Gbps capable across all sites. This is a key step in supporting ongoing growth in traffic volumes and high-capacity Member requirements.

VIC-IX NEXTDC M2 deployment
IAA is looking to expand our coverage on the VIC-IX. With more and more organisations setting up operations in Melbourne due to subsea cable connections, we see a lot of growth here still to come.

IAA Member Portal improvements are now live!

We’ve rolled out a set of practical improvements to the IAA Member Portal, designed to give Members greater control, faster service changes, and better visibility over their connectivity.

Change request rollbacks

Members can now roll back changes made to their services directly within the Portal.

While requests are still actioned by our network team, this feature provides an extra layer of confidence when making changes and is an important step toward fully automated provisioning.

Faster peering activation

The Portal is now integrated directly with our route servers for peering services.

When ordering a new peering service, a Member’s BGP session details are deployed on demand, meaning new peering can be active as soon as the service is provisioned, rather than waiting up to 24 hours as before.

Updates to existing peering services (such as AS-SETs and prefix limits) are also applied immediately.

Smarter cross connect reminders

When Members upgrade or cancel ports, the Portal will now issue reminders to cancel old cross connects with their data centre provider.

There are mutual benefits here as Members can ensure they aren’t paying data centres for cross connects they aren’t using any more, and we can make more efficient use of our data centre cabling.

IAA’s end-of-year embargo 2026

As we head towards the close of the year, we’d like to take this opportunity to give notice of our holiday shut-down period.

To ensure any new services, moves or changes are processed before the end of the year, please submit them by COB Friday, 12 December 2025.

Any requests received after this date will be actioned after our end-of-year embargo, which runs from COB Friday, 19 December 2025, to Sunday, 4 January 2026. During this period, our team will only be available to assist with urgent support issues.

For further information or queries regarding the network embargo period, please get in touch at support@internet.asn.au.

Wishing you a happy and restful holiday season from the whole IAA Team!

When a malformed BGP update made things interesting

On 8 October, we received alerts of IPv6 peers flapping toward several route servers across both IAA and NZIX. Investigation revealed that peers were receiving a malformed BGP update, isolated to our route server BGP daemon software (Bird v2.0.7). The issue stemmed from Bird propagating an attribute it didn’t support, and it wasn’t just us. Other exchanges including JINX, DINX, CINX, THINX, MegaIXs, LONAP, GetaFIX, PIT-IX, and later EdgeIX were affected too.

The culprit? The way RFC 7606 handles unknown attributes (ironic right?), is to set the transitive bit on a BGP attribute if it’s unknown. Our friends at BGP Tools provided an excellent breakdown of how this can occur:

“If a BGP implementation does not understand an attribute, and the transitive bit is set, it will copy it to another router.“

Source: Benjojo’s Blog – BGP Path Attributes and Grave Error Handling

The issue was initially filtered upstream by the offending peer, which stopped the immediate problem. However, since we remained vulnerable to a recurrence, we rolled out the latest Bird code to our lab environment. Compatibility testing with our route server config generator (arouteserver) showed no issues, so we scheduled maintenance windows with provisions to escalate to emergency maintenance if the fault reappeared.

Upgrades went live on Route Server 2 for IAA on 20 October and NZIX on 23 October. And sure enough, on the same day the issue re-emerged across exchanges, prompting an emergency upgrade of Route Server 1. We’re now running Bird 2.17.2, which includes support for RFC 9234, allowing it to drop a malformed Only-to-Customer (OTC) attribute instead of propagating it.

It’s difficult to confirm whether the problem originated from Bird taking a 4-byte field and malforming it to 1024 bytes.  On-the-wire data suggests it remained a 4-byte update, but for stability’s sake, IAA will review alternative BGP software stacks for route servers to reduce any single-point dependency on the Bird BGP stack.

Adventuring at BSides Canberra 2025

In late September, IAA’s trusty Development Team, Kyle and Cam, embarked on a quest to Canberra for the biggest BSides yet. We’re told it was a packed few days of talks, workshops, and a strong focus on AI and machine learning in security.

One of the most talked-about sessions was Bitsquatting .gov.au Domains by Matthew Belvedere, which explored how random bit-flip errors in DNS traffic (sometimes caused by cosmic rays) can redirect requests to attacker-controlled servers. It definitely got people thinking.

Our Dev Team do love to flip the script. This year’s theme was Dungeons & Dragons, and their CTF team, Illithids Against Adventurers, placed an impressive 42nd out of 395 registered teams, further proving brains beat brawn (this round at least).

With so much happening and so little time to see it all, it seems BSides Canberra 2025 was as intense and inspiring as ever and the team came back buzzing with ideas.

IAA was pleased to sponsor this year’s conference, once again.

IAA Member Portal update

It’s been a quiet quarter on the Portal front, but there are still a few changes worth noting.

  • Member Resources has had a facelift, and you’ll now find more IAA reports and resources conveniently located within.
  • Peering Service Provisioning has been improved with automatic IP address allocation, making setup smoother and faster.

Most of the other updates since August have been behind the scenes, small tweaks and internal improvements to keep things running smoothly.

Check out the refreshed Member Resources section in the Portal and see what’s new.

Learn more!

Microsoft Connected Caches are going live!

We’re expanding our CDN offering! Next Tuesday, 12 August 2025, Microsoft Connected Caches (MCC) are going live on our exchanges in Adelaide, Brisbane, Melbourne, and Perth via AS10084.

This will bring Microsoft content such as OS updates, games, applications, and static assets even closer to your users. MCC delivers content not available via AS8075.

During our testing in a single exchange we saw cache traffic egress over 20-40Gbps, so we expect members to see notable traffic spikes during Microsoft’s weekly release schedule each Wednesday (AU time)

MCC is by default opt-in, so we recommend checking your port sizing to avoid congestion. If you need time out to upgrade, opt-out BGP communities are available – see our CDN policy control communities page for details.

Questions? Reach out to us at peering@internet.asn.au.

QV1 - reign over

QV1 is gone

WA-IX’s first ever PoP in QV1 is no more. IAA has left the building. In March this year, our longest-running Point of Presence and the birthplace of the commercial internet in WA, was decommissioned.

Closing a legacy site is never easy, and QV1 didn’t go quietly. The final tidy-up was a mammoth task and a true archaeological dig through decades of networking relics and general detritus.

In the deepest recesses we found layer upon layer of history and horror. There were coiled-up cables dating back decades, disused gear long since replaced, and a truly shocking quantity of general tech junk. Old scrap, torn packaging, a Krone block, empty Krone logbooks, and even a GBIC to Ethernet module that sparked a wave of nostalgia. There were also the less savoury finds. A half empty tuna can. A long-forgotten yoghurt tub. We didn’t check the expiry dates. We didn’t want to know. Somewhere in there may still be an AUI adapter from a Cisco 2511 (and the lost treasure of the Sierra Madre), but we chose to stop digging.

Thanks to a solid team effort, the site is now restored to its former condition. Perhaps even better. 

As we shared earlier in the year, QV1’s age and constraints meant it could no longer keep up with the standards we set for our infrastructure. While it will always be part of our history, we need to evolve to meet the expectations of Members and the demands of modern networks.

Thanks to everyone who contributed to the clean-up, the decommissioning, and the memories.

As one of the team put it:
“I’ve been looking forward to this day since the first argument about whether we should keep it. That was at least two UPS and one air con upgrade ago.”

QV1, you were something. But your reign is over.

Share your memories of QV1 with us:

Click here

Question from the desk

Image of confused math lady meme with caption Wait... an IXP is really just a switch?

The truth about IXPs: No routing, just switching

⚡️Network Engineers & Internet Peering Enthusiasts, let's talk about something fundamental yet often misunderstood!⚡️

When we talk about the power and efficiency of the Internet, we often highlight Internet Exchange Points (IXPs) as critical interconnection hubs. And they absolutely are! However, it’s crucial to remember that a typical Internet Exchange fabric is a pure Layer 2 construct.

What does that mean in practical terms?

An IXP does NOT perform any routing for or on behalf of its peering participants.

Think of it this way:

It’s a giant, shared Ethernet switch. Your router connects to it, and its sole purpose is to forward Ethernet frames between connected participants’ routers based on MAC addresses.

Each participant is responsible for their own routing decisions. The IXP itself only influences which routes you learn from their route servers, or advertise via their route servers, based on things like attached control communities and RPKI ROA validity. This doesn’t include so-called “bi-lateral” BGP sessions with peering partners directly across the exchange, which are entirely free of IXP influence!

No IP forwarding tables, no MPLS labels, no routing protocols running within the IXP’s core fabric for participant traffic. Most IXP’s operational networks will have their own underlay routing, but that’s distinct from the participant traffic plane.

Why is this understanding critical?

– Troubleshooting: If you’re experiencing routing issues with a peer at an IXP, your focus should be on your BGP configuration, your router’s health, and the peer’s BGP configuration – not on the IXP “routing” your traffic incorrectly.

– Architecture: IXP peering is decentralised by nature. You’re effectively building direct relationships with others, not relying on a central router.

– Security: An IXP isn’t inspecting or manipulating your IP packets beyond some basic ingress filtering of “nuisance” traffic, to ensure the health of the exchange. Ultimately, the exchange simply provides physical and data link layer connectivity between networks.

– Performance: The beauty of Layer 2 is its speed and simplicity. It allows direct, low-latency communication between networks, which is exactly what IXPs want to give peers!

Next time you connect to an IXP, remember you’re essentially plugging into a massive switchboard designed for efficient, direct peer-to-peer conversations, not a traffic cop directing everyone’s data.

Written by: Matthew Kobayashi | IAA Peering Engineer