NSW CGNAT Issue Postmortem: 5 May 2026

On Tuesday 5 May 2026 at approximately 07:50 AEST, customers using CGNAT in NSW lost connectivity.

The issue affected one of our NSW traffic paths. Some traffic continued to pass, but at a much lower level than expected.

The root cause was identified and isolated at 09:39 AEST, with service restored shortly after. Final customer communications were sent at 09:57 AEST.

We know interruptions like this are frustrating, especially when they affect basic connectivity. This post explains what happened, why it happened, and what we are doing to prevent it happening again.

What happened

Our engineers observed that traffic on one of our NSW BNGs had dropped unexpectedly. A second BNG serving NSW was operating normally, which helped us narrow the issue to a specific traffic path rather than a wider network outage.

Initial checks did not show a software or hardware fault on the router. Reloading the affected router did not resolve the issue.

Working with our aggregation partner, we reviewed MAC address learning across the NNI and subscriber-facing services. This showed that one of Neptune's router MAC addresses was being learned from the subscriber side of the network, where it should not have appeared.

In simple terms, traffic for part of our network was being learned in the wrong direction.

Why it happened

Ethernet networks use MAC address learning to determine where traffic should be sent.

A MAC address that belongs to Neptune's router should only be learned from Neptune's side of the network. In this case, that MAC was also being seen from a subscriber-facing service.

This can happen if a downstream service is misconfigured, looping traffic, or otherwise reflecting frames back into the aggregation network.

Because the same MAC address was being seen from the wrong direction, the network could make incorrect forwarding decisions. This caused traffic on the affected CGNAT path to drop completely.

How we fixed it

Once the offending subscriber-facing service was identified, our aggregation partner shut down that service path.

Traffic returned immediately after this was isolated at 09:39 AEST.

Customers using the affected CGNAT path in NSW then began reconnecting normally.

What we're doing next

We are working with our aggregation partner to ensure Neptune router MAC addresses are filtered from subscriber-facing services.

This prevents Neptune-side MAC addresses from being learned from the customer side of the network, reducing the chance of this type of forwarding issue happening again.

We are also reviewing the same filtering across other state handoff points to make sure the configuration is consistent.

Closing

This issue was caused by an unexpected MAC learning condition on a subscriber-facing service. Once identified, the affected path was isolated and traffic returned to normal.

If you were affected, thanks for your patience while we worked through it.