At London Internet Exchange (LINX), our members are at the heart of everything we do.
As a mutual, member-owned Internet Exchange Point (IXP), we are more than just a platform for peering. We are a community of networks working together to build a stronger, more resilient Internet. That means listening to our members, encouraging constructive feedback, and continuously improving our services based on the experiences and insights they share.
Recently, a member raised concerns about two technical issues affecting traffic at our London Internet Exchange Point (LON1). The discussions that followed led to further investigation by our engineering team, collaboration with vendors, and ultimately service improvements that benefited the wider ecosystem.
Issue One: Unknown Unicast Traffic and Flood Filtering
The first issue related to a small amount of traffic being dropped because of the way unknown unicast traffic was being handled on our switching infrastructure.
Like most Internet Exchange Points, LINX operates flood protection mechanisms designed to protect members from receiving excessive unwanted traffic. On our LON1 platform, a flood filter was configured at switch level to police broadcast, multicast and unknown unicast traffic. This helps reduce unnecessary traffic and improve security across the exchange.
However, during investigations, it became clear that some member networks had configurations that resulted in routers re-forwarding traffic. As the traffic they received was a unicast packet not intended for them, their router should have simply dropped that packet, but instead it created additional flooding behaviour and resulting in traffic being blackholed.
After reviewing the situation, conducting extensive testing, and assessing the potential impacts, we applied a filter that discarded unknown unicast completely, rather than rate limiting it.
The results were positive. We observed no negative impact on the exchange, and the change resolved the issue for the affected members.
Importantly, we also contacted the members involved to explain the findings and encourage them to review their own configurations. While having unknown unicast enabled is not necessarily incorrect, this case highlighted the potential risks associated with certain network configurations and provided valuable learning for everyone involved.
Issue Two: Stale MAC Addresses and Neighbour Discovery Behaviour
Further analysis revealed that traffic behaviour observed by some members was not related to unknown unicast filtering. Instead, the issue was linked to IXP switch behaviour involving proxy Neighbour Discovery (ND) functionality.
In this scenario, a member device was sending neighbour solicitation messages to an outdated MAC address. Rather than discarding these requests, the switch was responding in a way that effectively kept the stale MAC address entry alive. As a result, outdated information remained present for longer than expected.
The issue was triggered following a mac address change, and certain members would retain the old mac entry. It was difficult to identify as our PE routers had the correct mac-ip bindings, but were proxy replying to NS request members, who were sending to the stale mac address, which kept their incorrect v6 neighbour entry alive.
Once we understood what was happening, we took steps to disable proxy ARP and related functionality on the affected vendor switches, preventing the local switch from maintaining those stale entries.
We have worked closely with the vendor throughout this process to help improve their product, which benefits both their wider customer base as well as the small number of LINX members who were impacted.
The Outcome
Both issues were isolated to our London platform and affected a small number of our members. As far as we are aware, both have now been resolved.
Why Shared Learning Matters
Wherever we can, we share the lessons and improvements that come out of our work. As a member-driven organisation, we believe knowledge is most valuable when it’s passed on rather than kept in-house. The challenges we face are rarely unique to us, and the solutions we develop, both on our own and with our vendors, can save others time, effort and cost.
< Go Back
