Member Portal
Categories

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

100Gbps Port coming soon so SA-IX

Order your 100Gbps port on SA-IX now!

Great news, Adelaide! After months in the pipeline, 100Gbps ports ane now available across all SA-IX Points of Presence, delivering the high capacity your users demand.

More capacity. More content.
Our latest upgrade will support the surge in traffic from major content sources like Steam, Netflix, Google, and more – keeping your users connected and content flowing smoothly.

There’s never been a better time to level up.

Order your port via the IAA Member Portal now:

Order now!

IAA invoices now delivered via the Member Portal

You might have noticed something a little different – and in some cases some quirks – with your invoices this month. From 1 May 2025, IAA invoices began being sent directly from the IAA Member Portal as part of our ongoing plans to make our Portal the single source of truth for services and more streamlined overall.

Unfortunately, we set a higher default for the invoice settings and in many cases additional account holders received copies of invoices. We’ve now corrected that, so only your billing contacts will receive them in future. We appreciate your patience as we get the new system up and running.

We’ve addressed the issues behind the scenes, and things should be back on track for next month’s billing cycle. To be clear, our bank details and payment methods remain the same as usual.

If you have any questions or need a copy of your invoice, feel free to get in touch at accounts@internet.asn.au.

Sign up to IAA's mailing list

Complete this form to receive all our latest news, events and updates.