A research network that also carries the internet
Members get one connection for everything: traffic to other members, to research networks abroad, to the cloud and to the rest of the internet.
Janet and education networks
The UK research network, from campus to GÉANT
Janet connects UK universities, colleges and research institutes to each other and to the world. This page explains how it is built, how a campus connects and what the policies ask. It then covers eduroam, federated login, DDoS (distributed denial of service) protection, moving research data and GÉANT, and ends with a fault finder.
Overview
The UK's research and education network, from campus to the world
Janet is the UK's NREN (national research and education network), run by Jisc. It links universities, colleges and research institutes to each other, to research networks around the world and to the internet. It is one AS (autonomous system), and members join it at a regional PoP (point of presence). Choose a destination to see where a packet from a member campus goes.
Swipe sideways to see the whole diagram.
Traffic between two Janet members stays on Janet from end to end. It leaves my campus border, crosses the regional access network to the backbone, and leaves again at the other member's access PoP. It never touches the commercial internet, so the path is short and predictable.
Traffic to a research partner in Europe leaves Janet on its link to GÉANT, the pan European network that joins the national research networks together. GÉANT hands it to the partner's own national network, such as SURF in the Netherlands or DFN in Germany.
Traffic for the rest of the internet leaves at Janet's edge. Janet peers openly at internet exchange points such as LINX (London Internet Exchange) and IXLeeds, and buys transit to reach the networks it does not peer with directly.
Jisc connects Janet to cloud providers including AWS (Amazon Web Services), Microsoft and Google. For a member, a cloud region is one more destination reached over the same Janet connection, behind the same protection.
Janet at a glance
| Janet today | |
|---|---|
| Operator | Jisc, the UK's not for profit digital agency for education and research |
| Live since | 1 April 1984 |
| Autonomous system | AS786, with an open peering policy |
| Users | About 18 million, around five million of them students (Jisc) |
| Organisations | More than 900, including every UK university and further education college (Jisc) |
| Backbone | Core links of up to 800 Gbit/s, with a refresh planned to start at 1.6 Tbit/s |
| Capacity to other networks | About 5 Tbit/s in total (Jisc, 2025) |
| Link to GÉANT | 400 gigabit Ethernet, resilient (Jisc, 2026) |
| Traffic | About 6 petabytes a day (Jisc) |
| Direct peerings | More than 600 (Jisc) |
Figures from Jisc's own publications and talks, from about 2023 to April 2026. They change as the network grows, so I check the latest before I quote one.
Rules come with the connection
The connection policy, the acceptable use policy and the security policy bind every connected organisation, and through it, its partners and guests.
Services on top
eduroam roaming, DDoS (distributed denial of service) mitigation, a security response team, dedicated research paths and performance testing all run on the same network.
History
Forty years, five generations
Janet is older than the commercial internet in the UK. Each generation brought more capacity and a simpler design, and each one changed what a member campus needed at its border.
Swipe sideways to see the whole diagram.
Janet went live on 1 April 1984, linking about 50 university and research council sites at 9.6 kbit/s. It ran on X.25 with the Coloured Book protocols, developed by the UK academic community.
An IP pilot started in March 1991 and became an official service that November. IP traffic overtook X.25 within months, and the X.25 service closed in August 1997. From then on Janet was an IP network, like the internet it connects to.
The SuperJANET programmes rebuilt the backbone five times. Sites moved to 34 Mbit/s ATM (Asynchronous Transfer Mode) by late 1993. SuperJANET4 arrived in March 2001 and SuperJANET5 in October 2006, each one faster and more resilient than the last.
Migration to Janet6 began in July 2013, and it launched on 26 November 2013. Jisc then rebuilt access in most regions as resilient rings, using telephone exchanges, carrier neutral data centres and dark fibre, so new connections could be provisioned faster.
Core links run at up to 800 Gbit/s on Juniper MX routers over a Ciena optical layer. Jisc reported in April 2026 that it plans to replace the core routers and move to 400 and 800 gigabit interfaces, starting at 1.6 Tbit/s.
The history shows in practice. Janet is run by a not for profit body for its members, its policies are written for education and research, and the security policy makes each member responsible for its own network.
Architecture
Fibre, a core and regional rings, in five layers
Janet is built like a carrier network. An optical layer carries a small number of very fast core links. Regional access rings collect member connections at points of presence. At the edge, Janet meets GÉANT, the internet exchanges and the cloud providers. Step through the layers from the fibre up.
Swipe sideways to see the whole diagram.
Underneath everything is an optical layer. Ciena optical equipment carries many wavelengths on each fibre pair between points of presence, and lets Jisc add capacity in 100 or 400 gigabit steps on the same fibre.
Juniper MX2010 and MX960 routers form the IP core. A core link today is built from eight 100 gigabit Ethernet circuits, up to 800 Gbit/s in all. The core also carries the Layer 2 and Layer 3 VPNs (virtual private networks) Jisc offers across and beyond Janet.
From 2018 Jisc rebuilt access in most regions as resilient rings. The PoPs sit in telephone exchanges and carrier neutral data centres, joined by dark fibre and by Openreach Ethernet and optical services. A ring keeps each PoP connected if one fibre path is cut.
Each member site connects to a regional PoP, with a second link to another PoP where it needs resilience. The network is ready for jumbo frames of 9,000 bytes, which matters for research transfers if the campus path supports them too.
At the edge, Janet has a resilient 400 gigabit link to GÉANT, open peering at LINX and IXLeeds, commercial transit, and connections to the large cloud providers. In 2025 Jisc gave the total capacity to other networks as about 5 Tbit/s.
Where Janet meets other networks
| Where | Port speed | Type |
|---|---|---|
| LINX LON1, London | 400G | Public peering |
| LINX LON2, London | 100G | Public peering |
| LINX Manchester | 20G | Public peering |
| IXLeeds | 10G | Public peering |
| GÉANT | 400G, resilient | Research and education |
| Telehouse North and North Two, Equinix LD6, LD8 and MA1 | Various | Interconnection facilities |
From Janet's PeeringDB entry and Jisc's 2026 update. Janet's peering policy is open: no ratio, no contract and no minimum number of locations.
When a service is slow from a campus, I first find where its traffic leaves Janet: a peering, transit or GÉANT. Each one has a different owner and a different fix.
Connecting a campus
Two links, two PoPs, no single point of failure
A campus joins Janet through an access link to a regional PoP. For a site that cannot go offline, I design two links to two different PoPs, on different cable routes into the building. BGP (Border Gateway Protocol) and BFD (Bidirectional Forwarding Detection) move traffic on their own when something fails. Choose a failure to see what happens.
Swipe sideways to see the whole diagram.
In my design both links run BGP and BFD. The primary is preferred in both directions: a higher local preference for routes learned over it, and an agreed method for traffic coming in. How routing runs on the access links is agreed with Jisc for each connection.
The primary access link fails. If the interface goes down, the router reacts at once. If it stays up but stops passing traffic, BFD notices: at 300 ms intervals with a multiplier of 3, in under a second (typical). BGP withdraws the routes and both directions move to the backup.
Janet PoP 1 fails, or the ring breaks behind it. The link to it goes quiet, BFD and BGP react as before, and traffic moves to PoP 2. This is why I ask for the two links to land on different PoPs, with different cable routes into the building.
Border A fails. The campus core stops learning routes from it and sends everything to Border B. I run routed links with an IGP (interior gateway protocol) between the core and the borders, rather than a shared VLAN (virtual local area network), so failover does not wait for a first hop protocol.
The choices for a connection
| Choice | Options | How I decide |
|---|---|---|
| Resilience | One link; two links to one PoP; two links to two PoPs | From the cost of an outage. Teaching, research and student services usually justify two PoPs. |
| Routing | Static routes or BGP, as agreed with Jisc | BGP with BFD wherever there are two links, so failover is automatic in both directions. |
| Addressing | Jisc allocated space or provider independent space | The connection policy requires one of the two. Addresses on the access link are for the link and routing only, never for campus traffic. |
| IPv6 (Internet Protocol version 6) | Dual stack, or IPv4 only | Dual stack from the start. Research traffic is moving to IPv6 quickly: Jisc reports that LHCONE (the Large Hadron Collider Open Network Environment) traffic is almost all IPv6. |
| MTU (maximum transmission unit) | 1,500 bytes, or jumbo frames to 9,000 | Jumbo only on a research path I control end to end. Everywhere else stays at 1,500. |
| Guests and partners | eduroam, govroam, partner organisations, public access | Each has its own segment and policy. Public access must be tunnelled to an internet provider. |
A border router for link A in my design. Link B is the same, without the higher local preference. The real AS numbers, addresses and routing method come from Jisc for each connection.
! Illustrative IOS XE border router. Addresses and AS numbers are documentation values.
interface TenGigabitEthernet0/0/0
description Janet access link A
ip address 192.0.2.2 255.255.255.252
ipv6 address 2001:DB8:0:1::2/64
bfd interval 300 min_rx 300 multiplier 3
!
ip prefix-list OUR-PREFIXES seq 10 permit 198.51.100.0/24
!
route-map FROM-JANET-A permit 10
set local-preference 200
!
router bgp 64512
neighbor 192.0.2.1 remote-as 64496
neighbor 192.0.2.1 description Janet PoP 1
neighbor 192.0.2.1 fall-over bfd
address-family ipv4
network 198.51.100.0 mask 255.255.255.0
neighbor 192.0.2.1 activate
neighbor 192.0.2.1 prefix-list OUR-PREFIXES out
neighbor 192.0.2.1 route-map FROM-JANET-A in
Policies
The rules that come with the connection
A Janet connection comes with three policies. They decide who may use it, what for, and what each member must do about security. They shape the design as much as any technical requirement, because the connected organisation answers for everyone behind its connection. Choose a type of user to see how each one reaches Janet.
Swipe sideways to see the whole diagram.
A connected organisation joins Janet directly, with Jisc's permission. The policy has three eligibility categories. The first is bodies whose main purpose is state regulated education or research, such as universities, colleges and UKRI (UK Research and Innovation) institutes. The others are bodies selling services to others on Janet, and other bodies whose use fits the policy.
A partner organisation uses Janet through a connected organisation's own IP connection. Schools, museums, charities and government bodies are examples. The connected organisation checks the partner is eligible, supports it itself, makes sure it follows the acceptable use and security policies, and accounts for its bandwidth.
Guests of a connected or partner organisation use Janet through the eduroam or govroam roaming services, or through direct guest access for purposes linked to the host's mission. Public access is different: it must be authenticated, tunnelled to a public internet provider and kept apart from other Janet traffic.
A partner may not pass access on to anyone else. The connected organisation must prevent onward connections, review civic engagement partners every year, and end access when a partner no longer qualifies. Jisc can suspend or withdraw access for persistent breaches that are not resolved.
The three policies
| Policy | Reference | What it asks of a member |
|---|---|---|
| Janet Network Connection Policy | MF-POL-053, issue 2.2, reviewed July 2025 | Who may connect, how partners and guests use a connection, addressing, no onward access, and fair use of bandwidth. |
| Janet Acceptable Use Policy | MF-POL-006 | What Janet may be used for. It binds everyone who uses the network, including partners and guests. |
| Janet Security Policy | MF-POL-007, issue 5.1, reviewed June 2025 | Secure networks and devices, named security contacts confirmed every quarter, an annual security self assessment, and serious incidents reported to Jisc. |
Titles and issue numbers as published by Jisc in 2025. I read the current issues before any design that depends on them.
What Jisc can do
Monitor and scan
Jisc may monitor use where it suspects a breach, and may scan members after a critical vulnerability alert or actionable threat intelligence, reporting what it finds to the security contacts.
Apply controls
It may apply temporary or long term technical controls, such as restricting high risk inbound protocols, to protect Janet and its members.
Disconnect in an emergency
If an organisation cannot or will not cooperate with a serious incident, Jisc can start an emergency disconnection. A tested contact list is the best way never to get there.
How I design to the policies
- Security contacts that answer. A shared mailbox, a named role and an emergency phone number, checked every quarter, as the security policy asks.
- Notice before testing. At least one working day's notice to Jisc before a penetration test or a scan of Janet from outside it.
- Partners on their own segment. Each partner organisation in its own VRF (virtual routing and forwarding instance) or VLAN, with its own firewall policy and bandwidth reporting.
- Public Wi-Fi off Janet. Any public access service tunnelled to a commercial provider, so it never appears as Janet traffic.
- Addresses used as allocated. Campus traffic sourced only from Jisc allocated or provider independent space, never from the access link addresses.
eduroam
One login, any participating campus
eduroam lets a student or member of staff connect at any participating campus with their own home login. It joins 802.1X on the Wi-Fi to a hierarchy of RADIUS (Remote Authentication Dial In User Service) proxies, which route each login by the realm after the @ sign. EAP (Extensible Authentication Protocol) carries the login, and TLS (Transport Layer Security) keeps the password between the device and its home. Each campus runs an ORPS (organisational RADIUS proxy server), Jisc runs the NRPS (national RADIUS proxy servers), and the ETLR (European top level RADIUS servers) join the countries. Step through a visitor's login.
Swipe sideways to see the whole diagram.
The laptop sees the SSID (service set identifier) eduroam and starts 802.1X. The access point asks who it is, and the laptop answers with its outer identity over EAPOL (EAP over local area networks). A well configured laptop sends [email protected], so only the realm is visible.
The access point, or its controller, puts the EAP message inside a RADIUS
Access-Requestand sends it to the campus RADIUS server. It adds the laptop's MAC (media access control) address asCalling-Station-Id, so every later log line can be tied to a device.The visited server, an ORPS (organisational RADIUS proxy server), sees that example.ac.uk is not one of its own realms. It adds an
Operator-Namenaming the visited site and forwards the request to Jisc's NRPS (national RADIUS proxy servers). A local realm would never go there.The national proxy knows which servers are registered for example.ac.uk and forwards the request to them. Every proxy on the way only reads the realm. None of them can see the password, and none of them need to.
With PEAP (Protected EAP) or TTLS (Tunnelled Transport Layer Security), the laptop builds a TLS tunnel to the home server and checks its certificate. The real username and password travel inside it, over several
Access-Challengeround trips. Only the home organisation sees them.The home server sends
Access-Acceptwith encryption keys back down the chain. The access point and the laptop use them for the four way handshake, and the laptop joins the visitor network and asks DHCP (Dynamic Host Configuration Protocol) for an address.For example.nl, the national proxy sends the request to the European top level RADIUS servers (ETLR). They pass it to the Dutch national proxy, which sends it to the home server in the Netherlands. The steps on campus are the same.
Try it: follow a login across eduroam
Type an outer identity as a laptop would send it, and choose where the visitor is. The tool routes it the way the RADIUS hierarchy does, hop by hop, and flags the mistakes I see most.
- Laptop to access point. 802.1X with the outer identity [email protected].
- Access point to visited RADIUS.
Access-Requestwith the laptop's MAC address. - Visited RADIUS to Jisc national proxy. example.ac.uk is not local, so it goes up.
- National proxy to example.ac.uk RADIUS. A UK realm, registered with Jisc.
- Home RADIUS. Checks the password inside the TLS tunnel and answers.
Routes home. A UK realm goes from the visited campus to Jisc's national proxy and straight to the home servers. The outer identity hides the username.
What each part must do
| Part | What the eduroam(UK) technical specification asks |
|---|---|
| Visited network | Broadcast the SSID eduroam in lower case. Use WPA2 (Wi-Fi Protected Access 2) Enterprise with AES (Advanced Encryption Standard), never TKIP (Temporal Key Integrity Protocol). Keep visitors off other services, do not intercept their TLS, log each visitor's IP address against its MAC address, and publish an information page with coverage and any filtering. |
| ORPS | At least one, with a second recommended. Send realms that are not local to the NRPS, never local ones. Listen on UDP (User Datagram Protocol) port 1812. RadSec, RADIUS over TLS, uses TCP (Transmission Control Protocol) port 2083 with certificates from GÉANT's eduPKI. Add Operator-Name, and keep logs with UTC (Coordinated Universal Time) timestamps. |
| Home organisation | Use an EAP method that returns keys, with PEAP, TTLS or EAP-TLS recommended. Usernames take the form identity@realm, where the realm is a DNS (Domain Name System) domain the organisation runs. Log every authentication, and keep a test account in the Jisc support portal. |
Summarised from the eduroam(UK) Technical Specification 1.4. Version 1.5 took effect on 2 October 2023, so I check the current text before a design or an audit.
Both roles
A site can be a visited service, a home service or both. I always design for both: staff and students roam as much as visitors arrive.
Certificates and onboarding
Most home failures are devices that do not check the server certificate, or that break when it changes. I onboard devices with a profile tool such as eduroam CAT (Configuration Assistant Tool) or geteduroam, and plan certificate renewals.
govroam
govroam is Jisc's public sector version, launched in 2017 and built on the same technology. Staff of councils, health and blue light services log in with their own employer's account at any govroam site.
How 802.1X and RADIUS work on a single campus is on my wireless page.
Identity
Log in at home, use services anywhere
eduroam handles network access. For websites, such as publishers' journals and research platforms, UK education uses federated login with SAML (Security Assertion Markup Language). The university remains the only place a password is checked. Step through a researcher opening a journal article.
Swipe sideways to see the whole diagram.
A researcher opens an article on a publisher's site. The publisher is a SAML service provider, and it needs to know whether this person belongs to an organisation that subscribes.
The publisher sends the browser to a discovery page, and the researcher picks their university from the list. The publisher now knows which identity provider to ask, without learning anything about the person.
The browser carries a SAML authentication request to the university's IdP (identity provider). The researcher never types their password on the publisher's site.
The researcher signs in with their own university account, with MFA (multi factor authentication) if the university requires it. The university's own access rules apply here, as they would for email.
The IdP signs an assertion and the browser posts it to the publisher. It carries only the attributes agreed, such as
eduPersonScopedAffiliation(for example [email protected]) and a pseudonymous identifier, not a name.The publisher checks the signature against the federation's signed metadata and grants access. The UK Access Management Federation, run by Jisc, publishes that metadata, so a publisher trusts every member university without a separate agreement with each one.
eduroam and federated login side by side
| eduroam | Federated web login | |
|---|---|---|
| What it gives | Network access on Wi-Fi or a wired port | Access to a website or application |
| Protocols | 802.1X, EAP and RADIUS | SAML, through the browser |
| How it finds home | The realm after the @ sign | The user picks their organisation |
| What the visited side learns | The realm, a device address and, optionally, a pseudonymous identity | Only the attributes released, such as affiliation |
| Run in the UK by | Jisc, as eduroam(UK) | Jisc, as the UK Access Management Federation |
Both rest on the same idea: the home organisation checks the password, and everyone else trusts its answer. That keeps a researcher to one account wherever they go.
Security
Protection in the network, and a team behind it
Every member is responsible for its own network, but some threats can only be handled upstream. A DDoS attack fills the access link before any campus firewall sees it. Janet detects and scrubs attacks in the network, and Jisc's security team supports members during incidents. Step through an attack on a campus.
Swipe sideways to see the whole diagram.
Real users reach the campus web servers, DNS and VPN (virtual private network) through Janet's edge, on the direct path.
A botnet sends far more traffic than the campus link can carry. The link fills, so real users fail too, even though the servers are fine. A campus firewall cannot help, because the damage happens before traffic reaches it.
Janet watches traffic for unexpected patterns. A flood towards one address raises an alert. With Foundation DDoS mitigation this is automatic for every Janet connected organisation.
Traffic for the address under attack is sent through Jisc's mitigation scrubbing centre instead of straight to the campus. Only that address moves. Everything else stays on its normal path.
The scrubbing centre drops attack traffic using carefully chosen criteria and forwards the legitimate traffic on to the campus. Users keep a working service while the attack goes on.
When the attack stops, the address returns to the direct path. I review it with Jisc: which services were targeted, how long detection took, and whether always on protection is worth it for the most critical ones.
DDoS protection on Janet
| Service | Who has it | What it adds |
|---|---|---|
| Foundation DDoS mitigation | Every Janet connected organisation, automatically | Detection and scrubbing for the Janet connection. Support from 08:00 to 18:00 on weekdays, with on call cover in the evenings, at weekends and on bank holidays. |
| Foundation Plus | Optional | A response at any hour, every day, for the whole Janet connection. |
| Critical Services Protection | Optional, charged | Protection for chosen services at any hour, with profiles for web, SIP (Session Initiation Protocol), DNS, VPN and ADFS (Active Directory Federation Services). Choose "Instant", always on, or "Fast", which starts on an alert. |
As described on Jisc's service pages in 2026. Names and terms change, so I confirm them with Jisc before a design relies on them.
The response team
Jisc's CSIRT (computer security incident response team) warns members, helps with incidents and can act on Janet itself. The security policy expects members to report serious incidents even when they need no help.
Routing security
Jisc was enabling RPKI (Resource Public Key Infrastructure) on Janet in 2025. I make sure every prefix a member announces has a correct ROA (route origin authorisation), so validation never drops it. More on the security page.
Plan for the bad day
A runbook names who calls Jisc, which addresses host critical services, and how to move a service behind always on protection. The time to find the contract number is before the attack.
Research data
Moving terabytes, not just browsing
Research traffic is different from everyday traffic. A few huge flows run for hours between known sites, and a small loss or a small buffer can turn a 100 gigabit path into a 1 gigabit transfer. TCP only speeds up as fast as acknowledgements return, so distance matters too. The usual answer is a Science DMZ (demilitarised zone): a DTN (data transfer node) at the border, filtered by ACLs (access control lists) rather than the campus firewall. Choose a design to see how the data travels.
Swipe sideways to see the whole diagram.
A large transfer from a partner lab passes through the campus firewall to a server deep inside the campus. Firewalls built for thousands of short flows can drop packets from a few huge ones. Over a long path, even a little loss cuts TCP throughput sharply, as the calculator below shows.
In a Science DMZ (demilitarised zone), a DTN (data transfer node) sits on its own segment at the border. The router filters it with ACLs (access control lists) for the partner addresses and ports in use, so the big flows skip the firewall. A perfSONAR node beside it tests the path all the time.
Where a project needs dedicated capacity, Jisc's Netpath service gives a point to point virtual private connection across Janet and beyond. Netpath classic shares an existing Janet port. Netpath plus uses dedicated ports and reserved bandwidth, in the UK and abroad.
Try it: why a big transfer is slow
Set the data size, the path speed, the round trip time, the TCP buffer and any packet loss. The tool finds what limits one TCP stream: the path, the buffer or the loss. Figures are indicative. The loss limit uses the classic Mathis model, and modern TCP behaves a little better.
- Bandwidth delay product
- 31.3 MB in flight to fill the path
- Limit from the TCP buffer
- 5.1 Gbit/s
- Limit from packet loss
- none, no loss set
- Best rate for one stream
- 5.1 Gbit/s
- Time to move the data
- 4 hours 20 minutes
The buffer is the limit. A 16 MB buffer cannot keep 31.3 MB in flight, so one stream reaches about 5.1 Gbit/s on a 10 Gbit/s path. I raise the buffer to at least the bandwidth delay product, or run parallel streams.
Tools for research data
| Tool or service | What it is for |
|---|---|
| perfSONAR | Open source test points that run scheduled throughput, loss and latency tests between sites, and keep the history. Jisc runs a 10G server at its Slough data centre and a 100G server at its London Telehouse North Two PoP. |
| DTN (data transfer node) | A server tuned for big transfers, with fast storage, large TCP buffers and tools such as Globus. Jisc has a 100G DTN in London for members to test against. |
| iperf3 | A quick memory to memory throughput test, to separate network limits from disk limits. |
| Netpath | Point to point virtual private connections across Janet and beyond, as classic or plus. |
| Jumbo frames | Janet is ready for 9,000 byte frames. They help long transfers only if the whole path, including the campus, supports them. |
In 2026 Jisc and GÉANT reported tests between servers in London, Paris and Amsterdam reaching close to 400 Gbit/s, at 20 to 30 ms of latency.
GÉANT
From Janet to GÉANT, and on to the world
Janet is one of many national research and education networks. GÉANT joins the European ones together and links them to other regions. Large science projects such as the LHC (Large Hadron Collider) also run their own networks across them. LHCOPN (LHC Optical Private Network) links CERN to the national Tier 1 centres, such as RAL (Rutherford Appleton Laboratory) in the UK.
Swipe sideways to see the whole diagram.
Purple packets travel from Janet through GÉANT to other national networks, and replies come back. Orange packets show LHC data between CERN and RAL, the UK's Tier 1 centre, on its own optical private network.
Janet's place in the global research network
| Link or service | What I know about it |
|---|---|
| Janet to GÉANT | One resilient 400 gigabit Ethernet link, which replaced four 100 gigabit links (Jisc, 2026). |
| RAL, the UK LHC Tier 1 | A resilient 400 gigabit connection, plus a 200 gigabit LHCOPN link that fails over to LHCONE. |
| Large university research sites | Several large GridPP (the UK particle physics grid) sites have 100 gigabit connections, and the largest expect to need 400 gigabit within a few years. |
| IPv6 | LHCONE traffic is almost all IPv6, so research sites need it working end to end. |
| Precise time | A PTP (Precision Time Protocol) feed from the NPL (National Physical Laboratory) reaches two Janet PoPs and feeds two of Jisc's NTP (Network Time Protocol) servers. |
From Jisc's network update to the GridPP community in April 2026.
For a campus, GÉANT is invisible most of the time: it is simply where European research traffic goes. It matters when a project needs a dedicated path to a partner abroad, or when a slow transfer has to be traced across several networks, each with its own operations team.
Design
How I would design a Janet connected campus
These are the rules I would bring to a campus on Janet. They follow from the policies, from what fails in practice and from what research traffic needs.
- Two links, two PoPs, two routes in. For any site that cannot go offline, with BFD and BGP so failover needs nobody awake. I test it twice a year, in a change window, by pulling the primary.
- Addresses and ROAs together. Campus space from Jisc or provider independent space, IPv6 dual stack from day one, and a correct ROA for every prefix announced.
- One segment per kind of user. Campus, research DMZ, eduroam visitors, govroam, partners and any public Wi-Fi each get their own VRF or VLAN and their own policy.
- eduroam as a service, not an SSID. Two ORPS, RadSec where it helps, certificate renewals planned a year ahead, onboarding that checks the server certificate, and logs kept as the specification asks.
- A research path that is measured. A Science DMZ for big transfers, perfSONAR at the border and beside the transfer nodes, and jumbo frames only where the whole path supports them.
- Security contacts and runbooks. Named contacts confirmed every quarter, a DDoS runbook, and always on protection for the services that cannot fail, such as the VPN and authentication.
- Time from a known source. Routers, RADIUS servers and logs set from Jisc's NTP servers, so timestamps line up when Jisc CSIRT asks about an incident.
Trade offs I weigh
| Decision | Option A | Option B | What tips it |
|---|---|---|---|
| Research transfers | Through the campus firewall | Science DMZ with ACLs | Flow sizes and distances. Above a few gigabits over long paths, the DMZ. |
| Visitor network | Shared with campus guests | eduroam on its own VLAN | The specification wants visitors kept apart from other services, so its own VLAN. |
| Dedicated research link | Shared Janet IP | Netpath plus | Whether the project needs reserved capacity or protocols other than IP. |
| DDoS protection | Foundation only | Critical Services Protection | How long the VPN, website and login services can be down before it hurts. |
Troubleshooting
Finding a fault hop by hop
Faults on a Janet connected campus fall into a few groups: eduroam logins, slow research transfers, failover that does not happen, routes that do not propagate and attacks. Choose a symptom to see where it usually sits and what I run first.
Swipe sideways to see the whole diagram.
Visitors cannot join eduroam here. The ORPS sends requests the national proxy will not answer: its address is not registered in the eduroam support portal, a firewall blocks UDP 1812 or TCP 2083 towards Jisc, or the shared secret is wrong. I check the portal entry, the firewall logs and the RADIUS debug output, then test again.
My users fail at other campuses but work at home. The outer identity has no realm or the wrong one, or devices reject a renewed server certificate. I test with eapol_test using the same outer identity, check that the home server answers Status-Server, and push new onboarding profiles before a certificate changes.
Transfers to a partner abroad crawl. Loss at a firewall, TCP buffers smaller than the bandwidth delay product, or a path MTU black hole. I compare perfSONAR results on both sides of my border, raise buffers on the transfer nodes, check that ICMP (Internet Control Message Protocol) for path MTU discovery is allowed, and move the flow into the Science DMZ.
The primary link was lost and nothing failed over. The backup session was down for weeks without an alarm, its filters do not match the primary's, or there was no BFD so a silent failure kept the old session up. I alarm on every session, keep the two configurations generated from one template, and test failover on a schedule.
One network cannot reach my new prefix. It is not announced, it is filtered upstream because it was not agreed, or its ROA names the wrong origin AS or a maximum length that is too short, so validating networks drop it. I check what I advertise, the ROA, and a public route view such as RIPEstat.
The link is full of traffic I did not ask for. A DDoS attack, usually against one address. I call the Jisc service desk at once with the target address, confirm the mitigation, and afterwards decide whether that service needs always on protection.
IPv6 works on campus but not to the world. No IPv6 BGP session or default route at the border, a missing route for the campus prefix, or a firewall dropping the ICMPv6 that IPv6 needs to work. I check the session, the routes and the firewall policy in that order.
The tools I reach for
| Question | Command or tool | What it tells me |
|---|---|---|
| Does my RADIUS server see the request? | radiusd -X (FreeRADIUS debug), or the NPS (Network Policy Server) event log | Every request, which realm it matched, where it was proxied and why it was rejected |
| Can a login work end to end? | eapol_test -c ttls.conf -a 127.0.0.1 -s testing123 | A full EAP login with a test account, without a laptop or an access point |
| Is the path clean? | pscheduler task throughput --dest ps.example.ac.uk | A perfSONAR throughput test, with history to compare against |
| Is it the network or the disk? | iperf3 -c dtn.example.org -P 4 -t 30 | Memory to memory throughput and retransmits |
| Where does the path break? | mtr -rwbzc 100 www.jisc.ac.uk, traceroute6 | Loss and latency per hop, and which networks the path crosses |
| Is my routing right? | show bgp ipv4 unicast summary, RIPEstat | Session state locally, and what the rest of the internet sees |
I change one thing at a time and repeat the same test after each change. For eduroam, the RADIUS logs on each side usually settle where a login failed within minutes. My general method is on the troubleshooting page.
Engagement
How I would run a campus network change on Janet, from first meeting to steady state
Janet work usually arrives as a border refresh, a move to resilient connections, an eduroam overhaul or a research group that needs to move far more data. I would follow the same path I use for any network change: agree what must keep working, measure what is there, design to Janet's policies, prove it, then hand it over with Jisc's contacts and services built in.
Swipe sideways to see the whole diagram.
I start by agreeing what must keep working through the change: teaching, exams, research transfers, student halls and visitors. I record who decides in a RACI (responsible, accountable, consulted, informed) chart, and bring in the Jisc account manager early, because connection changes have lead times.
I turn the outcome into functional and non functional requirements: how fast a failure must be survived, how much capacity research groups need and when, which users roam, and which duties the Janet policies place on the organisation. Each number has an owner who signs it off.
Before designing anything I measure: link use, the routes announced and their ROAs, eduroam success and failure rates by realm, and the largest research flows with their partners and distances. Flow records and perfSONAR tests show where transfers really slow down.
The high level design sets the connection, the segments for campus, research, visitors and partners, and the security services. The low level design covers routing, addressing, RADIUS, firewall rules and monitoring, with a test plan agreed in advance, including failover and eduroam roaming tests.
I prove the design before it carries real users: pull each link and router, roam test accounts in both directions, and record throughput baselines with perfSONAR. Cutovers run in agreed windows outside teaching and exam periods, each with a rollback, coordinated with Jisc.
Before handover, every BGP session, link and RADIUS server is in monitoring with alarms. Security contacts are registered with Jisc and checked, and support teams get runbooks for eduroam failures, slow transfers, failover and DDoS attacks. Hypercare ends when the agreed criteria are met.
RADIUS certificates, router software and Janet's policies all change, and research demand keeps growing. I keep a renewal calendar, review capacity each year with research groups and Jisc, check each new policy issue or eduroam specification, and patch on a schedule.
Functional requirements
What it must do.
- Connect the campus to Janet with enough capacity for teaching, research and residences at the busiest times.
- Survive the loss of any single link, router or PoP without manual action.
- Offer eduroam as both a home and a visited service, and govroam where public sector partners need it.
- Give partner organisations and any public access their own segments, as the connection policy requires.
- Carry large research transfers on a measured path that does not depend on the campus firewall.
- Report link, routing, eduroam and security events to the operations teams and to Jisc where the policy requires.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Resilience
- No single point of failure between the campus core and the Janet backbone for critical sites.
- Failover
- Traffic moved to the backup within about a second of a silent link failure (typical, with BFD).
- Capacity
- Busy hour use below about 70% of each access link, so bursts and failover fit (typical).
- Research throughput
- A single tuned transfer reaching most of the path speed to agreed partners, proven with perfSONAR.
- eduroam
- Logins complete in a few seconds, with logs kept with UTC timestamps for the period the specification sets.
- Security
- Named contacts answering within the hours agreed with Jisc, and incidents reported as the security policy asks.
- Routing hygiene
- Every announced prefix has a matching ROA, and nothing outside the agreed space is announced.
- Change
- No planned changes in teaching or exam periods unless agreed, and every change with a tested rollback.
Numbers are typical starting points. Each organisation agrees its own with its users and with Jisc.
Who I talk to
- IT leadership and the security lead, who own the risk
- Research computing teams and principal investigators with large data
- Student services and estates, for residences and new buildings
- Public sector partners using the connection, and their contacts
- Jisc account manager and engineers, for connection options and lead times
How I find out
- Link use and busy hours from the border routers and flow records
- An audit of announced prefixes, ROAs and addressing against the policy
- eduroam success and failure rates by realm, from the RADIUS logs
- perfSONAR and iperf3 tests to the main research partners
- A walk of the building entries and cable routes for both links
Discovery tools
| Tool or source | What it tells me |
|---|---|
| NetFlow or IPFIX (IP Flow Information Export) at the border | Top talkers, research flows and busy hours |
| perfSONAR and iperf3 | Throughput, loss and latency to partners, with history |
| RIPEstat and an RPKI validator such as Routinator | What the world sees of the campus prefixes, and whether each ROA is valid |
| RADIUS logs and the eduroam support portal | Login success by realm, and the site's registration details |
| Wireshark at the border | MTU, TCP windows and retransmits on slow transfers |
| Ekahau or Hamina survey data | Where eduroam coverage and capacity fall short |
Most faults turn out to be an eduroam configuration, a route or a slow path, so I separate those three early.
My approach
- Scope. Which users, sites, partners or services, which direction, and since when? What changed on campus, at Jisc or at the far end?
- Locate. Is the fault on campus, at the border, on Janet or at the far end? A test from the border usually splits it in two.
- Logs. RADIUS logs on both sides for eduroam, BGP state and route views for reachability, perfSONAR history for slow transfers.
- Compare. Compare with a working case: another realm, another partner, another prefix or the same test last month.
- Escalate. Open a call with the Jisc service desk with the evidence, or with the far end's network team through their NREN.
- Fix and prove. Change one thing through change control, repeat the same test and record the cause for problem management.
Faults I see most
- Visitors rejected because the ORPS is not registered or is blocked
- Home users failing away after a server certificate change
- Slow research transfers through a firewall or with small TCP buffers
- Backup links that had silently failed before they were needed
- New prefixes dropped for a missing or wrong ROA
- IPv6 broken by filtered ICMPv6 at the border
Layer by layer
| Layer | What I check |
|---|---|
| 1 · Physical | Optics, light levels and errors on the access links, and the cable routes into each building. |
| 2 · Data link | VLANs for visitors and partners, and MTU mismatches on research paths with jumbo frames. |
| 3 · Network | BGP sessions and routes, ROAs, IPv6 and path MTU discovery, using show bgp and traceroute6. |
| 4 · Transport | TCP windows, retransmits and buffer sizes on transfer nodes, with iperf3 and captures. |
| 5 to 7 · Application | RADIUS and EAP for eduroam, SAML for federated login, and the transfer tools such as Globus. |
My general method, with worked faults, is on the troubleshooting page.
A Janet connection is shared responsibility. I agree who does what on campus, and how the campus works with Jisc.
Service model
Who owns each part: service desk, network operations centre (NOC), security operations and research computing, and when each calls Jisc.
Monitoring
Link use, BGP sessions, RADIUS server health and eduroam failure rates, with alarms tuned during hypercare, the period of extra support after go live.
Security contacts
Named contacts, a shared mailbox and an emergency phone number registered with Jisc and checked every quarter.
Runbooks
Step by step guides for eduroam failures, slow transfers, failover and DDoS attacks, each starting with the evidence Jisc will ask for.
Change
Every routing, RADIUS and firewall change goes through change control, with Jisc involved where a change touches the connection.
Reviews
A regular service review with Jisc covering incidents, capacity, DDoS events and upcoming changes.
A campus connection changes with research demand, policy and technology. I plan its upkeep from the start.
- Capacity. A yearly review with research groups and Jisc, because a new instrument or project can multiply demand.
- Certificates. RADIUS server certificates renewed on a calendar, with new onboarding profiles sent out before each change.
- Policies. Each new issue of the connection, acceptable use and security policies, and of the eduroam specification, checked against the design.
- Software. Router, firewall and RADIUS software patched on a schedule, and tested before it reaches the border.
- Addressing. IPv6 growth, ROAs kept in step with announcements, and old space returned when it is no longer used.
- Services. Changes in Jisc services, such as new DDoS options or Netpath, reviewed for what they offer the campus.
Projects
Related work behind this page
None of these projects was a Janet connection. They are the projects closest to it, and they use the same skills: public sector networks, provider addressing and routing security, network access control with RADIUS, and the rooms that education networks serve.
Public sector network modernisation Related
Public sector network modernisation on Meraki, Nexus, FortiGate and Check Point, leading 7 engineers and third party suppliers. Public bodies such as councils can use Janet as partner organisations, and govroam was built for their staff.
Provider addresses, AS numbers and ROAs Related
Managed provider IP space and AS numbers with the RIPE NCC (Réseaux IP Européens Network Coordination Centre), including RPKI ROAs. This was for a Tier 3 data centre serving over 300 customer sites on Cisco ACI (Application Centric Infrastructure) and Nexus.
A secured internet edge Related
Secured the consolidated internet edge with RPKI based BGP origin validation, and cleaned up internet registry records across the merged address space.
Routing security at the peering edge Related
Defined routing security policy for the peering and transit edge: RPKI and ROA origin validation and RIPE NCC resource governance. The same checks apply to every prefix a campus announces to Janet.
Network access control Related
Cisco ISE (Identity Services Engine) for network access control, with Windows Server 2012 R2 running Active Directory, DNS, DHCP and TACACS (Terminal Access Controller Access Control System) for device logins. RADIUS and policy are the same building blocks eduroam uses. See the topology.
Education spaces Related
I have completed Kramer's Education Spaces and Solutions Designer course, on audio visual design for teaching rooms, which depend on the campus network underneath.
Backed by CCNP (Cisco Certified Network Professional) Enterprise and the CCIE (Cisco Certified Internetwork Expert) Security and Routing and Switching written exams. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.