Case Studies/UK ISP — Layer 3 Growth Architecture
UK ISP · Network Architecture

UK ISP Growth Plan — Layer 3 Architecture & Private ASN Distribution

A UK Internet Service Provider with Juniper MX core routing, IX and LONAP peering, and an ambitious growth plan — blocked by a flat Layer 2 access architecture that could not scale. We redesigned the routing hierarchy from the access layer up, without touching the core peering relationships that the business depended on.

BGPeBGPPrivate ASNLayer 3Juniper MXIX PeeringLONAPOSPFRoute RedistributionISP Architecture

L3

Distributed routing architecture

Private ASNs at access, public ASN at core

IX

Peering integrity maintained

LONAP and IX peering untouched at core

Access layer scalability

VLAN ceiling eliminated with Layer 3 routing

100%

Growth plan unblocked

Architecture ready to scale with the business

The Challenge

A strong core. An access layer that couldn't keep up.

The ISP had built a solid core network — a Juniper MX series router carrying the public ASN, with active BGP peering at a UK Internet Exchange and LONAP (London Network Access Point) for direct traffic exchange with other networks. Tier 2 eBGP upstreams provided full internet routing tables. At the core, the architecture was sound.

The problem was at the edge. The access layer ran on ageing Cisco 2960C and 3750C switches — capable hardware for their era, but fundamentally Layer 2 platforms. Customer segmentation relied on VLANs. There was no Layer 3 routing at the access or distribution layer. Every packet, regardless of destination, was forwarded back to the Juniper MX core before a routing decision could be made.

This architecture has a ceiling, and the ISP was approaching it. The VLAN model doesn't scale beyond a certain point — 4,096 VLANs is the hard limit, and operational complexity grows long before that number is reached. Spanning tree across the access layer added instability risk. And every growth plan — more customers, more locations, more services — was constrained by an access layer that had no path forward.

📡

Strong core, weak edge

The Juniper MX with IX and LONAP peering gave the ISP excellent upstream connectivity — but the access layer had no routing capability. Every decision, including local traffic between customers on the same exchange, had to traverse back to the core.

🔢

VLAN scalability ceiling

The flat Layer 2 access architecture relied on VLANs for customer segmentation. With a maximum of 4,096 VLANs and spanning tree running across the access layer, the model was already showing limits. Any meaningful growth plan would hit the ceiling.

🌐

Inefficient traffic paths

Without Layer 3 at the access layer, traffic between customers on the same physical infrastructure was routed all the way to the Juniper MX core and back. This added unnecessary latency, consumed core capacity, and created a single choke point for all forwarding.

🔒

Poor customer isolation

Layer 2 VLAN-based isolation has known weaknesses at scale — VLAN hopping risks, broadcast domain size, and the operational overhead of managing per-customer VLANs across ageing 2960C and 3750C hardware that had no Layer 3 routing capability beyond basic SVIs.

📈

Growth plan blocked

The ISP had a clear commercial growth plan — more customers, more locations, more capacity. The existing architecture could not support it. Adding customers meant adding VLANs to an already strained Layer 2 domain with no path to scale.

Legacy access hardware

The Cisco 2960C and 3750C access switches were end-of-life platforms with limited Layer 3 capability. They were functional but represented a technical ceiling — any growth architecture had to account for their constraints or plan for their replacement.

The Solution

Layer 3 at the edge. Private ASNs distributed into the public routing table.

The solution was a fundamental shift in where routing decisions are made — moving intelligence from the core outward to the access layer, while keeping the public ASN and peering relationships at the core completely clean.

01

Private ASNs at the Access Layer

Private ASNs (from the RFC 6996 reserved range) were allocated to access and distribution domains across the ISP's network. This allowed BGP to run at the edge — enabling proper route summarisation, traffic engineering, and customer isolation at the layer closest to the customer — without exposing internal topology to the public internet.

02

Redistribution into the Public ASN

Routes from the private ASN domains were redistributed into the ISP's public BGP ASN at the Juniper MX core. Strict prefix filters and route policy were applied to ensure only correctly summarised, authorised prefixes were carried into the public routing table — and from there, advertised cleanly to IX and LONAP peers and tier 2 upstreams.

03

Core Peering Fully Protected

The IX and LONAP BGP sessions on the Juniper MX were untouched throughout the transition. All changes were made below the core peering layer — the access layer redistribution policy was designed so that internal routing changes could never propagate into the public peering sessions as route leaks or unexpected prefix advertisements.

04

Traffic Now Routes at the Edge

With Layer 3 at the access layer, routing decisions for local and regional traffic happen at the edge — not at the Juniper MX core. Traffic between customers on the same access domain no longer traverses the core, reducing latency, freeing core capacity, and eliminating the central choke point that was limiting growth.

05

VLAN Ceiling Eliminated

The Layer 3 access architecture replaced the flat VLAN model. Customer segmentation moved from VLAN-based isolation to Layer 3 routing domains — removing the 4,096 VLAN ceiling, eliminating spanning tree risk across the access layer, and providing a model that scales cleanly as new customers and locations are added.

06

Scalable Growth Architecture

New access domains can be added under the private ASN model without requiring changes to the Juniper MX core, the public ASN configuration, or the peering relationships. The ISP can now grow its customer base and geographic footprint by extending the access layer architecture — not by rebuilding it.

Delivery Phases

Assessment to live architecture

01 — Network Assessment

Reviewed the existing Juniper MX core configuration, BGP peering relationships at the Internet Exchange and LONAP, and the full access layer topology. Documented the VLAN structure, spanning tree domains, and identified where the Layer 2 model was creating hard growth limits.

02 — Architecture Design

Designed a hierarchical routing architecture introducing private ASNs at the access and distribution layer. Defined the redistribution policy to carry internal routes into the public ASN at the core — ensuring the Juniper MX and existing peering relationships remained stable throughout the transition.

03 — Private ASN Deployment

Implemented private BGP ASNs across the access layer, enabling Layer 3 routing decisions to be made at the edge rather than forcing all traffic back to the Juniper MX core. Each access domain received its own routing scope, with summarised prefixes propagated upward rather than individual host routes.

04 — Redistribution into Public ASN

Configured redistribution policy to carry access layer routes into the public ASN at the core. BGP route filtering and prefix policies were applied to ensure only correctly summarised, authorised prefixes were advertised to IX and LONAP peers — protecting the ISP's peering relationships from internal routing changes.

05 — Validation & Peering Verification

Full end-to-end validation of routing paths, BGP session stability at the Internet Exchange and LONAP, and customer traffic forwarding across the new Layer 3 access domains. Peering routes verified clean with no route leaks or unintended prefix advertisement.

06 — Documentation & Growth Roadmap

Delivered full documentation of the new routing architecture, private ASN allocation register, redistribution policy, and BGP prefix filter configurations. Produced a growth roadmap defining how new access domains can be added under the architecture without requiring core changes.

The Outcome

A growth plan with an architecture to match it.

The ISP now operates a proper hierarchical routing architecture — private ASNs at the access layer, summarised routes distributed into the public ASN at the Juniper MX core, and clean BGP peering relationships at the IX and LONAP that are isolated from internal routing changes.

Traffic that previously traversed the core for every routing decision now resolves at the edge. The VLAN ceiling that was blocking growth has been replaced by a Layer 3 model that scales without architectural limits. New customers and new access locations can be added by extending the private ASN model — not by rebuilding the network around it.

The growth plan is no longer blocked by the network. The architecture now leads it.

In their words

"We knew the core was solid — the Juniper MX and our IX peering were working well. What we couldn't see was how to get the access layer to a point where it could support the growth we were planning. Frodingham understood the problem immediately and delivered an architecture that didn't touch what was working while completely fixing what wasn't."

UK Internet Service Provider

ISP Growth Plan · Juniper MX · IX & LONAP Peering · United Kingdom

Is your network architecture limiting your growth?

Talk to us about how we can design a routing architecture that scales with your business.

All Case StudiesStart a Conversation