We can't wait to see you all!

LINX Metro Resilience provides LINX members with a 60 per cent reduction on LON2 port and peering fees that mirror LON1, providing a second peering option to make their internet traffic more secure and resilient.

LON2 runs as the secondary LAN network for LINX, with its main network LON1 running at nearly 9.8Tbps at its peak.

The focus on resilience coincides with the incoming Cyber Security and Resilience Bill, designed to bolster the defences of the UK’s critical digital infrastructure following a wave of major cyber attacks and third-party outages.

Jennifer Holmes, CEO of the London Internet Exchange, said:

“The internet, and wider Critical National Infrastructure, cannot be reliant on a single point of failure. This is even more important with the Cyber Security and Resilience Bill on the horizon, placing stricter security requirements on organisations.”

“Metro Resilience ensures cost isn’t a blocker for organisations, providing affordable access to high security, low-latency peering through LON2, while removing single points of failure for LINX Members.”

In July, LINX members benefited from £41,000 in discounts from the Metro Resilience initiative, as new orders and port upgrades rose with networks adding resilience to their London infrastructure.

“As organisations prioritise network resilience and data security, we expect uptake for LON2 to steadily grow. As a member-owned organisation, we’re focused on giving back, and Metro Resilience is our way of doing that as demand grows,” Holmes added.

Early this year, LINX undertook a full network refresh of its LON2 infrastructure across all 17 of its sites, moving onto Nokia IXR hardware running SR-Linux. The refresh made LON2 fully 400GE capable and highly scalable to handle future traffic demands.

LON2 was launched in 2002 as a second peering LAN in London for LINX, built on different hardware and software to LON1 to prevent outages from impacting a single point of failure.

LINX expects traffic on LON2 to continue rising with orders and port upgrades increasing.

The London Internet Exchange (LINX), the member-owned internet exchange operator, is pleased to welcome Angani Ltd to their LINX Nairobi interconnection hub as they demonstrate the value of regional peering in Kenya.

LINX took their first steps into Africa with the launch of LINX Nairobi in 2023, where they provide an interconnected and resilient IXP, accessible from multiple data centre locations in Kenya’s capital. LINX Nairobi has over 55 members now live and peering including several unique networks including TikTok and Starlink. LINX Mombasa was then launched in 2025, a strategic gateway and key content hub for East Africa due to its proximity to major international subsea cable systems. Together, the two exchange points give networks greater choice, resilience and control over how their traffic moves within Kenya and across the wider region.

Angani Ltd is East Africa’s leading cloud services provider delivering locally hosted applications, infrastructure and digital services. Angani first connected to LINX Mombasa in 2025 and has since added LINX Nairobi to its network strategy this year, strengthening its ability to peer across key locations and support low-latency, reliable services for customers.

Patrick Mbogo Business Executive for Africa at LINX commented:

“This is exactly what we encourage our members to do. A 10GE port and 4Gbps of service at each global LINX location is included in the membership fee to really encourage regional peering to keep traffic as close to the end user as possible.” The IXPs overall presence in Kenya has seen remarkable growth in a short time. Over the past year, traffic combined across both of the LINX IXPs Kenya has increased twenty-fold, reaching a maximum peak of over 330Gbps. This significant uplift demonstrates the strong demand for high-quality interconnection services and the value LINX brings to the region.

Denson Ngumo from Angani explains their strategy for IXP presence in Kenya and the value they got from attending the first ever LINX member meeting in Nairobi in May of this year;

“As a local cloud provider, local peering is instrumental for us. 80% of our traffic is local and that is supported by us connecting to an IXP…”

“Connecting to LINX Nairobi was a matter of when and not if. Having already seen the number of peers our Mombasa POP got access to, peering at LINX Nairobi was a no-brainer. Being part of the LINX ecosystem allows us to give our customers access to cloud services at the lowest latency possible, access to international CDNs and overall network resiliency. We also appreciate LINX’s support of the ecosystem via their numerous events and capacity building sessions.”

By peering locally at LINX Nairobi and LINX Mombasa, networks can exchange traffic closer to the end user, reducing reliance on international transit routes and helping to deliver faster, more reliable digital experiences.

Where to find them

Look for the bell icon in the portal, it shows a preview of your latest notifications, and you can click through to any of them for the full detail.

Clearing and tidying your notifications

You can select several notifications at once and mark them all as read in one go, rather than clearing them one at a time. Notifications sent to you personally, such as an invitation to join a Private VLAN or Closed User Group, can also be deleted. Notifications sent to your whole organisation can't be deleted, but you can still mark them as read and they clear automatically when they expire.

What you'll be notified about

Right now that covers orders, updates as your order moves through processing, including if it needs attention from the LINX NOC, if it's complete, or if it's been rejected or delayed. Plus maintenance and outages, with reminders ahead of scheduled maintenance and updates as maintenance or an outage starts and finishes. We'll be adding more notification types over time.

Who sees what

Most notifications about your orders and services go to everyone with portal access in your organisation, not just whoever placed the order, so anyone on your team can pick up any follow up needed. A smaller number go to one specific person instead, because they need that person's approval, if your organisation's been invited to join another member's Private VLAN or Closed User Group, for instance, the invitation goes to the named contact responsible for approving it, not your whole team.

Managing your preferences

You can control this at whatever level suits you. You can switch all notifications on or off in one go, switch off a whole area such as maintenance or outages, or fine tune within an area. For maintenance and outages you can even go by how much impact is expected, so you might keep alerts for anything that could cause an outage while turning off reminders for changes with no impact on your service at all. Everything's switched on by default, and you can adjust any of it from your notification preferences in the portal.

How long notifications stick around

Order notifications stay for a week after they're created. Maintenance and outage notifications clear shortly after the event finishes, usually within a couple of hours of the end time, or within a day if no end time was recorded. That's the same whether you've read them or not. If a notification was sent to you personally, you can delete it before then if you'd rather not wait.

Need help?

If something doesn't look right, or you've got a question about a notification you've received, get in touch with LINX support as usual.

1. Where to find your stats in portal

Portal stats live in three places:

• Home page - two graphs are shown as soon as you log in: LINX Traffic Overview (traffic across all LINX LANs, plus Managed IXP and an Aggregate line) and [Your Organisation] Top 5 Port Services (your five highest-traffic ports). Both link through to a fuller analysis view

• My Services - select one or more of your own ports or logical services to see detailed stats for exactly what you run with us. This view has more metrics available than the home page

• Peers view (within My Services) - select a port service to see the peers connected to it, with traffic figures per peer, and a combined peering traffic graph

Which view you need depends on what you're trying to find out: the home page is a quick health check across LINX and your top ports, My Services is for looking at a specific port or service in detail, and Peers view is for understanding who you're exchanging traffic with on a given port.

2. Using the controls

Most of the graphs across portal stats share a common set of controls:

• Period - choose from Past hour, Past day, Past week, Past month, Past year, or set Custom dates

• Metric - switch what's being measured (Bitrate, Errors, Unicast/Multicast/Broadcast Packets, depending on the view, see Section 4 for what's available where)

• Time Zone - toggle between Local and UTC

• Legend - click an entry (an exchange, port, or peer) to show or hide it on the graph, use the search box above the legend to filter a long list down to what you're looking for

• Export - where available, CSV and PNG export buttons sit above the graph, letting you download the underlying data or a static image of the chart

3. What data you're looking at, and how fresh it is

Portal stats are drawn from a few different underlying sources depending on what you're looking at:

• SNMP based stats - bitrate, errors, and packet counts, polled at regular intervals from the network devices themselves. This is what powers the LINX Traffic Overview SNMP view, Top 5 Port Services, and the port/service-level stats in My Services

• Flow based stats - a separate traffic view (LINX Traffic Overview also has a Flow Traffic tab), built from flow data rather than SNMP polling

• Optics (light level) stats - received and transmitted power, collected via a different method and updated approximately every 10 minutes. Coming to My Services in a future release (see Section 7); if you've recently made a change to your port, please allow a few minutes before checking, as it won't reflect the change instantly

Not every graph on the page updates at the same speed. If you've just made a change and a stat hasn't updated yet, it's worth waiting a few minutes rather than assuming something's wrong. We know this isn't always obvious, so we're adding a "last updated" indicator to each stats area, so you can see exactly when the data you're looking at was last refreshed rather than having to guess. This is expected to be live by the end of the year.

For SNMP based graphs, the level of averaging also depends on the date range you select: ranges under a month show 5-minute averages, ranges up to two months show hourly averages, and anything longer shows daily averages. Peak traffic values are always calculated from 5-minute samples regardless of the range selected.

4. Metrics available at each level

Different views expose different metrics:

• LINX Traffic Overview (SNMP tab): Bitrate, Errors, Unicast Packets, Multicast Packets, Broadcast Packets

• LINX Traffic Overview (Flow tab): Bitrate, Packets. Flow data doesn't distinguish packet type, so this is a single combined count, unlike the SNMP tab, which breaks packets out by type

• My Services (your ports and logical services): Bitrate, Errors, Unicast Packets, Multicast Packets, Broadcast Packets

• Peers view: Bitrate (shown as combined in/out/total figures per peer)

5. Aggregate view

When viewing more than one port or peer at once, an Aggregate view toggle lets you switch between seeing each one plotted individually, or combined into a single summed line. This is available in both My Services and Peers view. Off (individual lines) is the default.

6. Port groups (LAGs) vs individual ports

If your port is part of a LAG (a group of ports bundled together), selecting the group in portal shows you a combined graph across all the ports in that group.

This means:

• A spike, error, or discard shown at the group level doesn't tell you which individual port within the group it came from

• If you need to isolate the source of an issue, select the individual port rather than the group

This behaviour is consistent across the ports we support, though the way it's presented may vary slightly depending on the underlying hardware vendor. We'll update this section if we identify vendor specific differences that affect how you should read the data.

7. Peers view

From My Services, selecting a port service and switching to Peers view shows you the peers connected on that port, along with average, current, and max traffic figures (in, out, and combined). Selecting one or more peers builds a combined peering traffic graph below, with the same period, metric, and time zone controls as elsewhere, plus CSV and PNG export.

This is useful for identifying which specific peer is contributing to traffic on a port, rather than just seeing the port's totals.

8. Discards, what they do and don't tell you

Discards are currently only reliably understood on LON1. On our other LANs, discard figures should be treated with more caution, for two reasons:

• Background noise: on some LANs, the discard count can include ARP and IPv6 neighbour discovery (ND) packets that are uplifted to the switch CPU for processing where proxy ARP or ND is enabled, as well as routing protocol traffic. These aren't genuinely dropped packets, so a non-zero discard count doesn't necessarily mean traffic was lost.

• Hardware limitation: on ports using SR Linux (Broadcom) switching hardware, it's not currently possible to distinguish real discards from control plane discards. There's no fix available for this at present

What this means for you: discard data outside LON1 can still be useful. For example, as a general signal or for spotting anomalies and trends over time, but shouldn't be read as a precise count of dropped packets. If you're trying to diagnose a specific issue, we'd recommend treating a discard reading as a starting point for investigation rather than a definitive answer, particularly outside LON1.

9. Light levels (optics), availability and limitations

The Optics view will show received and transmitted power levels for your port over time. Where a port has multiple lanes assigned (for example, on a breakout configuration), each lane will be shown individually.

Availability: optics data is not currently available on edge core ports (locations: CAR1, JED1, MAN1, SCO1). If your port is one of these, you won't see optics data and this isn't a fault, it's a current limitation of that platform

Update frequency: optics data is collected roughly every 10 minutes, so there will be a short delay between a real world change and it showing up in portal

10. Why a stat might not be showing

If a graph or stat isn't showing what you expect, it's usually one of the following:

• Not collected for your hardware - some metrics (e.g. optics on certain edge core platforms, discards accuracy on SR Linux) aren't available due to a hardware or vendor limitation, not a fault

• Temporarily unavailable - occasionally the underlying data service is briefly unreachable. If you see a message saying data is temporarily unavailable, this should resolve on its own; try again shortly

• Not supported for this port type - some stats only apply to certain port or service types, and won't appear for others

If you're unsure which of these applies to what you're seeing, please contact the NOC and they can clarify.

LINX/Dammam IX maintains route servers at each peering LAN, allowing members to establish multilateral peerings with other participants on Dammam IX. By establishing a single peering with a route server, routes can be shared with a large number of LINX members without configuring separate peerings with each LINX member.

Current route server statistics can be found here: Route Server Graphs

Dammam IX route server list

All LINX route servers are using the BIRD distribution and are configured with ASN 213797

All route servers filter bogon address ranges.

Dammam IX route server list

Policy control is done by use of BGP Standard Communities and BGP Large Communities. Members may tag their routes with the following to control policy via the route server. The model is as follows:

* N/A ~ Cannot be used as RS ASN is 32bit

If none of the above communities is present, then the default behaviour is to advertise the prefix to all peers.

AS-Path prepending

Members can tag their prefixes with the following communities, causing the Dammam IX route server to prepend ASNs to the prefix when advertising it to either all or selected members.

The following communities will cause the Dammam IX route server to prepend ASNs to the prefix for all members peering on the route server.

* N/A ~ Cannot be used as RS ASN is 32bit

The following communities will cause the Dammam IX route server to prepend ASNs to the prefix for the member with ASN $peer on the route server.

If you want to prepend more than three ASNs, please contact support@linx.net

Prefix validation

LINX is validating prefixes at ingress on all route servers. The validation is based on RPKI and IRR Object presence.

For RPKI validation we build a ROA table from IRR trust anchors and for IRR Object presence we build a list of valid origin ASN and prefixes based on route objects. Refines/more specifics of valid route objects are rejected.

We are looking for a valid AS-SET in the members PeeringDB record. If no valid AS-SET is found, we use the members ASN only, unless the member has provided us other information.

The results of the validation is reflected in communities which are being added at ingress:

• 213797:1001:1 = Prefix is present in an AS's announced AS/AS-SET

• 213797:1001:6 = Prefix is not present in an AS's announced AS/AS-SET

• 213797:1001:2 = Prefix has valid Origin AS in AS-SET

• 213797:1001:5 = Prefix has no valid Origin AS in AS-SET

• 213797:1000:1 = Prefix is RPKI VALID

• 213797:1000:4 = Prefix is RPKI INVALID

• 213797:1000:2 = Prefix is RPKI UNKNOWN

The prefix validation will always occur, and members can check the communities being set to their prefixes, and as such see the result of the validation checks through the route server looking glass interface.

Prefixes will only be accepted on the following criteria where,

1. Prefixes tagged with communities 213797:1001:2 (valid Origin AS in AS-SET) & 213797:1000:1 (RPKI VALID) or

2. Prefixes tagged with communities 213797:1001:2 (valid Origin AS in AS-SET) & 213797:1001:1 (Prefix is present in an AS's announced AS/AS-SET) & 213797:1000:2 (RPKI UNKNOWN).

All other prefixes will be filtered at egress.

Any member who prefers to receive an unfiltered set of prefixes can request to opt-out of the filtering by contact our NOC at support@linx.net.

Vendor issues

Corrupt AS path & malformed AS-Path issues

Some members who use Cisco, Brocade and Huawei devices to peer with may encounter issues in establishing peering sessions and may see notifications of invalid or corrupt AS path and Malformed AS-path in their device logs. Something similar to:

Sep 1 08:40:40.498 UTC: %BGP-5-ADJCHANGE: neighbor 195.66.225.230 Up Sep 1 08:40:41.506 UTC: %BGP-5-ADJCHANGE: neighbor 195.66.225.230 Down BGP Notification sentSep 1 08:40:41.506 UTC: %BGP-3-NOTIFICATION: sent to neighbor 195.66.225.230 3/11 (invalid corrupt AS path) 11 bytes 40020802 033C3424 580097

This issue is caused where the peering device does not like to receive updates from the route-server where the first AS in the path is not the route-server AS.

To work around this please use one of the vendor specific commands in your router configuration.

Cisco/Quagga/Brocade/Arista

router bgp <ASN>
no bgp enforce-first-as

Huawei

bgp <ASN>
undo check-first-as

If members are having trouble peering with the route servers please contact support.

Improved bandwidth selection and ordering experience

Following feedback that the previous experience was difficult to use, we've completely redesigned the bandwidth selection and ordering flow:

• Delivery constraints are now presented upfront, reducing confusion and invalid selections

• Port selection now includes third party fabrics

• The experience is consistent whether you're ordering as a member or managing services as a reseller

Order summaries

Order summaries are now live. For any completed order that results in a billing change, including new orders, bandwidth changes, and location moves, you can download a standardised PDF directly from portal to support internal finance reconciliation.

BGP session visibility

You can now view the health of your BGP sessions directly in portal, without needing to contact the NOC or use Looking Glass. This includes:

• Session status and uptime

• Prefix counts

• Rejection reasons and session health indicators

Service health and maintenance visibility

You can now see which of your services are affected by scheduled or active maintenances and outages directly within My Services, without navigating away. This includes:

• Visual indicators at service level showing maintenance or outage status

• A summary banner showing how many of your services are affected, with the ability to filter to affected services only

• A detail view with event information for each affected service

Coming soon

• Portal notifications: proactive notifications for order lifecycle events, scheduled maintenances and outages, and access and role changes, delivered in-portal and via email

• Portal stats improvements: restoring missing metrics, surfacing optics data, and usability improvements across the stats views

This session is ideal for network engineers, operations teams, and anyone responsible for managing peering and other services at LINX.