Summary

  • On 4 April 2023, Virgin Media UK, identified by technical observers as AS5089, experienced two major disruptions that impaired reachability to its network and services from the wider Internet. [1][2]
  • Cloudflare observed traffic falling close to zero around 00:30 UTC, followed by unstable recovery. ThousandEyes described a first incident from roughly 00:30 to 07:00 UTC and a second from about 15:20 to 17:30 UTC. [1][2]
  • ThousandEyes attributed most observed traffic loss to the absence of viable BGP routes to the Virgin Media network. It also observed a different condition: some providers retained routes toward AS5089, but traffic was dropped at the Virgin Media edge. [2]
  • Those observations establish route and forwarding failure modes. They do not establish the initiating command, device, vendor, person, maintenance activity, cyberattack or other root cause.
  • The recurrence later the same day makes restoration evidence central. A route reappearing is not the same as stable service recovery, and an internal green status is not proof that diverse external networks can reach and traverse the edge.
  • Accountability follows practical control. Virgin Media controlled route origination, withdrawal, edge policy, internal forwarding, restoration sequencing, incident disclosure and customer remedy. Peers controlled their own path selection and evidence. Measurement providers supplied independent observations but could not reconstruct undisclosed internal state.
  • Current PeeringDB, RIPE-derived and routing records identify AS5089 and its interconnection context. They are not frozen copies of the network on 4 April 2023 and must not be used as incident telemetry. [6][7][8][9][10][11]
  • RFC 4271, RFC 7454, RFC 8212 and MANRS provide protocol and operational context. None proves which controls Virgin Media had deployed or that one control would have prevented the event. [12][13][14][15]
  • A credible accountability record should align three clocks: route availability, packet forwarding and customer-visible service. It should preserve exact observations, label inference, expose unknowns and document the evidence that only the operator could have produced.

The incident was two disruptions, not one vague day of downtime

Large network failures are often summarized as a start time, an end time and a customer count. That format is convenient, but it can erase the mechanism that determines responsibility. The Virgin Media disruption is better understood as two observed periods, several stages of unstable recovery, and at least two externally visible failure conditions.

Cloudflare's traffic view placed the first major collapse at around 00:30 UTC on 4 April. Traffic associated with Virgin Media fell close to zero. Service did not return through one clean transition. The graph and accompanying account described partial recovery, further drops and another later disruption. The importance of that record is not that Cloudflare could see every Virgin Media customer. It could not. Its value is that a large external network observed a sharp change in traffic involving the Virgin Media autonomous system. [1]

ThousandEyes described the first incident as running from approximately 00:30 to 07:00 UTC. It recorded BGP route withdrawals, loss of traffic and intermittent periods of recovery. The second incident began at about 15:20 UTC and resolved around 17:30 UTC. It shared similar external characteristics. That chronology supports the statement that reachability failed twice. It does not prove that the same internal component or change initiated both events. [2]

Contemporaneous reporting captured the customer-facing dimension. The Register reported widespread broadband disruption and an acknowledgement from Virgin Media that customers were experiencing problems. That evidence helps establish that the routing observations corresponded with service impact. It does not turn social reports or a company statement into a complete technical postmortem. [3]

The distinction between two disruptions matters because recovery occurred between them. An operator that reports service restoration after the first event is making an operational claim: the network is again reachable, forwarding correctly and stable enough to carry expected traffic. A later recurrence may reveal that the trigger was not removed, that recovery criteria were too narrow, or that a separate but related fault remained. The public record does not tell us which explanation is correct.

This article therefore does not combine every symptom into one invented sequence. It treats the observed periods as a bounded accountability case. The first question is what the outside world could see. The second is what only Virgin Media could know. The third is what evidence should connect those two views.

AS5089 is an operational boundary, not a branding detail

An autonomous system number identifies a network that presents a coherent routing policy to other networks. It does not describe every internal router, cable, access segment or commercial product. It does establish a useful boundary for interdomain accountability: other networks exchange reachability information with the autonomous system and forward traffic according to the resulting paths.

Technical sources identify Virgin Media UK with AS5089. Current PeeringDB data describes Virgin Media under that ASN and records an interconnection footprint, an AS-SET and public peering information. Current BGP and RIPE-derived tools also associate AS5089 with Virgin Media Limited and show announced network resources. Those records help bind the event to the correct network identity. [6][7][8][9][10][11]

They must be used carefully. A current PeeringDB page can change after an operator updates its record. Current prefixes may differ from those announced in April 2023. A present RPKI status says nothing by itself about a route's status during the disruption. A registry object records administrative and routing information; it does not prove that packets crossed an edge at a particular minute.

Registries and network directories are evidence records. They help identify resource holders, routing objects and contact paths. They are not declarations that make the running network healthy. Operational truth appears in the routes that peers actually receive and the packets that the network actually accepts and forwards.

The AS boundary also prevents responsibility from dissolving into the word "Internet." The Internet is a collection of independently operated networks. A remote content provider may have working servers. A transit provider may carry a path toward AS5089. A customer device may function locally. Yet if routes to the access network disappear, remote networks cannot deliver traffic. If routes remain but the operator edge drops packets, the visible path still does not produce service.

Virgin Media did not control every remote peer, resolver, application or customer device. It did control its own route origination, edge behavior, internal forwarding and recovery process. That is the practical control boundary on which a fair accountability analysis should begin.

Route withdrawal made reachability disappear

BGP allows autonomous systems to exchange information about which address prefixes they can reach and through what paths. RFC 4271 defines the protocol model. A route is not a guarantee that an application will work, but without a usable route, traffic generally has nowhere to go. [12]

ThousandEyes observed that most traffic loss during the April 4 incidents was associated with a lack of viable BGP routes to the Virgin Media network. When routes were withdrawn, other networks could no longer select those paths. Packets destined for addresses inside the affected prefixes would be dropped upstream or fail after repeated connection attempts. [2]

That is not merely an incidental technical symptom. Route origination is one of the main ways an access provider makes its network reachable from the global Internet. Withdrawal can be an intentional safety action, a consequence of session loss, a policy outcome, an automation effect or the result of another failure. The public sources do not establish which mechanism operated here.

The absence of root-cause detail does not make accountability impossible. It changes the questions. Which prefixes disappeared? Which peers received withdrawals first? Did all external paths disappear together or in groups? Did IPv4 and IPv6 behave the same way? Which monitoring systems detected the change? What internal health signal authorized readvertisement? Which acceptance test had to pass before customer-facing recovery was declared?

Those questions are evidence requests, not accusations. They map observable behavior to the records an operator should possess. A route server, edge router, automation controller or monitoring system can record changes with timestamps. Change management can record whether a deployment was in progress. External route collectors can show a partial outside view. No single record is complete, but together they can establish a defensible chronology.

The operational risk is larger than one protocol session. Access networks may advertise many prefixes across multiple edges. A failure that withdraws a wide set of routes can isolate services, customer address space, DNS infrastructure, management systems and support channels at once. The affected population then experiences different application errors, even though the shared failure is reachability.

Accountability therefore requires scope as well as timing. An operator should be able to say which address resources were affected, which edges changed state, which services depended on those resources and which paths remained available. A broad statement that "broadband was down" is not enough to distinguish a regional access failure from autonomous-system-wide isolation.

A visible route did not always produce working forwarding

The most important detail in the ThousandEyes account is that route withdrawal did not explain every observed failure. Some providers were reportedly still able to route traffic toward the Virgin Media network. In those cases, traffic was dropped at Virgin Media's edge. ThousandEyes described that pattern as suggesting systemic distress, likely involving the control plane. [2]

The word "suggesting" matters. An outside observer can see that a path remains and packets fail near a boundary. It cannot inspect the operator's internal control state. Edge drops could arise from several classes of condition: forwarding state may be missing, internal routes may be unavailable, interfaces may be impaired, policy may reject traffic, capacity may collapse or dependencies may fail. Selecting one mechanism without evidence would convert observation into fiction.

The bounded conclusion is still strong. Route presence and packet delivery had diverged. For those paths, the global routing system carried an apparent promise that AS5089 was reachable, while the operator edge did not deliver the corresponding service.

That divergence is a recurring network risk. Control-plane state can look valid while the data plane fails. A BGP session can remain established while a next hop is unusable. A prefix can remain in a routing table while packets are discarded. An internal dashboard can mark an edge as available because the process is alive even though end-to-end probes fail.

The accountability response is to require paired evidence. Route health asks whether expected prefixes are visible through expected peers. Forwarding health asks whether representative packets cross the edge and reach destinations. Application health asks whether real services complete transactions. An operator should not collapse those layers into one green indicator.

External probes are valuable because they test the service from outside the changed system. They should be diverse enough to avoid mistaking one peer's view for the whole Internet. Measurements should include providers that received withdrawals and providers that retained routes. They should cover relevant regions, address families and service classes.

The result should be a matrix, not a single uptime number. A route can be absent or present. A packet can fail before the edge, at the edge or after entry. An application can fail despite successful transport. That matrix helps responders decide whether to restore route advertisements, repair internal forwarding, shed load, isolate a failing edge or communicate a narrower scope.

Recovery has to be proved across three clocks

The April 4 recurrence makes the meaning of "recovered" central. Recovery is not one timestamp. It is an agreement among at least three clocks: routing, forwarding and customer-visible service.

The routing clock records when prefixes were withdrawn, readvertised and accepted by peers. It can include BGP update streams, route collector observations and looking-glass checks. Because BGP propagation is distributed, different observers may see changes at different times. A route's first reappearance does not prove global convergence.

The forwarding clock records whether traffic actually crossed the operator boundary and reached representative destinations. It includes packet loss, latency, path traces and active probes. It can lag route readvertisement if forwarding state is incomplete. It can also fail independently while routes remain visible.

The customer clock records when users lost service, when support channels acknowledged the issue, when status notices changed, when customers could complete real tasks and when compensation or complaint processes became available. It reflects commercial and social consequences, not just network state.

An accountable restoration should align these clocks. The operator should specify a stabilization interval during which route visibility remains consistent, forwarding probes succeed from diverse networks and customer-impact indicators return to expected ranges. If the first recovery was accepted before that interval elapsed, the record should explain why.

The public sources do not reveal Virgin Media's internal acceptance criteria. They do show that service improved and then a similar major disruption recurred. That is enough to ask whether restoration was defined as a transient return of traffic or as stable end-to-end reachability.

The answer should not be guessed. A post-incident record could provide it by publishing a bounded timeline: what was changed, what signals triggered recovery, what signals later deteriorated, whether the same components were involved and what additional validation was added. If security or commercial concerns prevent configuration disclosure, aggregated route and health evidence can still be published.

This approach avoids performative transparency. A long narrative without route and forwarding timestamps may sound candid while leaving the main claim untestable. A shorter record that aligns the three clocks can provide more accountability.

A second disruption turns rollback into an evidence problem

Recurrence after partial recovery presents responders with a difficult choice. They may believe they have removed the cause, or they may only have restored symptoms. The distinction determines whether the network should return to normal operation or remain in a guarded state.

A rollback is often treated as a binary event: the new state was removed, so the old state must be safe. Distributed networks are not that simple. Old configuration may return while sessions reconverge at different rates. Cached or generated state may persist. Internal dependencies may not recover together. A separate fault may have been exposed by the original event.

For that reason, rollback should be tied to observable invariants. Expected prefixes should be present. Unexpected withdrawals or path churn should stop. Edge forwarding should work from multiple external networks. Internal next hops should be valid. Capacity should support the returning load. Customer-visible error rates should remain stable for a defined interval.

RFC 7454 discusses operational and security practices around BGP. RFC 8212 advances an explicit default-reject posture for eBGP policy. MANRS describes filtering, coordination, validation and global validation practices. These sources are useful for defining control families. They do not establish that a specific Virgin Media control failed, nor do they prove that applying one recommendation would have prevented this outage. [13][14][15]

The lesson is narrower: route policy and recovery need explicit, testable conditions. An operator should know what routes a peer is permitted to advertise, what it will export, what internal reachability must exist before an aggregate is announced and which independent measurements can block or reverse a rollout.

For a nationwide access provider, canary design is especially important. A change can be limited to one edge, one region, one address family or one controlled prefix group before broader deployment. The canary should be observed from outside the administrative domain. If route or forwarding invariants fail, automation should stop expansion and preserve evidence.

None of this requires the article to claim that a change caused the April 4 incident. It sets a standard for any explanation. If the cause was a deployment, the operator should show the boundary and rollback. If it was a device or dependency failure, it should show why redundancy did not preserve route and forwarding service. If several conditions combined, it should show how detection and recovery were changed.

Interconnection turns private operations into shared risk

AS5089 does not operate in isolation. Its reachability depends on sessions and policies with other networks. PeeringDB's current record identifies interconnection facilities and exchange participation associated with Virgin Media. Those details are current context, not a reconstruction of the 2023 topology, but they demonstrate the number of operational boundaries involved in reaching a large access network. [7]

When a network withdraws routes, peers must process the updates and select alternatives if alternatives exist. When an edge accepts traffic but cannot forward it, peers may continue sending packets into a failing path until measurements or operator coordination reveal the problem. The incident therefore created evidence obligations on both sides of the interconnection.

Virgin Media controlled the accuracy and usability of the routes it originated and the forwarding behavior behind its edge. Peers controlled what they accepted, how they monitored the path and whether they could contact the operator. Measurement providers observed only the vantage points available to them.

This division of control should appear in incident coordination. A peer report should state which routes it received, which sessions remained up, where packets failed and when the behavior changed. The operator should acknowledge whether that view matches its own telemetry. Conflicting observations should be preserved rather than normalized into one timeline too early.

Contact data matters here. Registry and PeeringDB records can provide NOC or policy contacts. Their value is practical: can an affected network reach someone authorized to act? An address that exists but is not monitored is not an operational control. A contact path should be tested and maintained without turning the registry into a claim of governance over the operator.

Coordination also affects customer recovery. Content networks and enterprise customers with multiple providers may shift traffic away from a failing path. Residential customers usually cannot choose an alternate last-mile autonomous system during an incident. That asymmetry places more continuity responsibility on the access provider.

Customers should not be blamed for failing to engineer around an AS-wide access disruption they cannot control. Large peers should still test their own routing and escalation procedures, but their preparedness does not erase the operator's responsibility for accurate route and forwarding state.

Monitoring must be independent of the failing network

A failure that affects routing can also isolate the tools used to diagnose and communicate about it. Status systems, telemetry collectors, authentication services and support portals may share the same network path. If they do, the operator can lose both service and evidence at once.

Independent monitoring should therefore sit outside the production failure domain. External route collectors, active probes and third-party measurements can test what other networks see. Internal telemetry remains necessary because it explains device and policy state. Neither view is sufficient alone.

Cloudflare's account and ThousandEyes' analysis illustrate the value of external observation. They could detect traffic collapse, route withdrawal and edge failure without access to Virgin Media's internal systems. Their data, however, could not identify the initiating internal event. [1][2]

The operator should correlate external and internal evidence by time, prefix, edge and address family. Time sources must be reliable enough that responders can compare records. A five-minute clock error can distort the apparent order of route withdrawal, forwarding failure and operator action.

Monitoring also needs negative tests. It is not enough to confirm that a route exists. Probes should test destinations inside representative prefixes. It is not enough to confirm that an edge responds. Tests should verify that customer traffic can traverse it. It is not enough to confirm that a portal loads from inside the network. External clients should be able to reach it.

The design goal is not to produce a perfect global view. That is unrealistic. It is to make blind spots explicit and ensure that no single failure domain supplies all evidence used to declare recovery.

Public disclosure should preserve unknowns

Network postmortems often face competing pressures. Customers want an explanation. Engineers need time to verify. Security teams may restrict details. Legal teams may avoid statements that could create liability. The result can be language so broad that it offers no operational evidence.

A responsible disclosure can remain bounded without being empty. It can state the affected services and prefixes at an appropriate level, the observed failure mode, the period of route withdrawal, the period of edge forwarding failure, the restoration steps, the validation interval and the controls changed afterward.

It should distinguish observation from inference. "Routes to these prefix groups were withdrawn" is an observation. "A control-plane dependency was under distress" may be an inference. "A particular vendor process failed" requires direct evidence.

The public sources used here preserve that distinction. ThousandEyes said the edge behavior suggested systemic duress likely affecting the control plane. This article does not rewrite that statement as a confirmed control-plane root cause. [2]

Unknowns should remain visible: the initiating event, the internal decision owner, the exact device set, the complete customer scope, whether both disruptions shared one cause and the durable remediation are not established by the source set. Preserving them is a form of accuracy, not a weakness.

The accountability question is then whether the party with access to the missing evidence produced an adequate record. External analysts should not fill a disclosure gap with confident speculation. Operators should not use the impossibility of outside certainty as a reason to publish nothing.

Customer remedies are part of network accountability

Routing and forwarding evidence may appear remote from billing and customer support, but they determine whether customers can prove a qualifying loss of service. An access provider controls both the technical record and much of the initial remedy process.

Ofcom's automatic compensation framework is intended to provide money back for specified broadband and landline service failures without requiring customers to make a conventional claim. Virgin Media is listed as a participant. Virgin Media also publishes its own compensation guidance and information about planned work. [16][17][18]

Those pages are current. This article does not assume that every current amount, rule or eligibility condition applied unchanged in April 2023. Any use of the policy should state the date and should not assert that every customer affected by the routing event qualified automatically.

The accountability principle is broader than one payment. The operator should preserve enough service-state evidence to determine when a total loss began and ended, which products were affected and whether an exception applies. Customers should not have to reverse-engineer BGP to establish that their service failed.

Communication channels must also survive the incident. If a status page, support portal or phone service depends on the same failing network, customers may be unable to report the fault or see updates. Virgin Media's current planned-work page points customers toward alternative services during planned disruption. Unplanned incidents need an equally independent communication path. [17]

Remedy data can improve engineering accountability. The number and duration of validated service-loss records show impact in customer terms. Complaint patterns can reveal regional or product differences that aggregate traffic graphs hide. That information should feed the post-incident review without replacing technical evidence.

The right standard is traceability. A customer-facing outage period should be reconcilable with route and forwarding evidence, while exceptions should have a documented reason. That reduces disputes and discourages recovery declarations that are technically narrow but commercially premature.

Registry and routing-security evidence must stay in its proper role

An ASN, prefix registration, route object or RPKI authorization helps establish who is authorized to originate address space and how other networks can validate claims. These records matter to the accountability surface, but they do not guarantee availability.

Current tools show AS5089's network identity and announced resources. PeeringDB identifies the operator and interconnection context. RIPE-derived services expose registration and prefix information. BGP tools show present routing observations. [6][7][8][9][10][11]

The article must not use those current pages to claim what routes were present at every point in 2023. Historic incident analysis should rely on dated observations from Cloudflare and ThousandEyes. Current records are used to bind the entity and explain the control surface.

RPKI also has a bounded role. Route origin validation can help networks assess whether an origin ASN is authorized for a prefix. It does not prove that the authorized origin can forward packets, that its internal routes are healthy or that its edge will accept traffic. A route can be valid by origin and still lead to a blackhole.

That distinction aligns with the reality layer. Security metadata improves the quality of routing decisions. It does not replace running-code evidence. Accountability requires both accurate records and observed service.

The same caution applies to RFC 8212's default-reject approach and MANRS practices. They reduce classes of accidental route propagation and improve coordination. They are not universal explanations for a reachability collapse, and a general control cannot establish a retrospective diagnosis.

A practical evidence standard for access-network recovery

The Virgin Media incident suggests a concrete recovery record that other access networks can adopt. The record should be designed before an outage, because evidence assembled afterward is easily incomplete.

First, preserve route state. For each affected prefix group, record announcements, withdrawals, peer sessions, policy versions and timestamps. Include enough information to show which external paths disappeared and which remained. Do not publish customer-sensitive configuration, but retain it for internal and regulatory review.

Second, preserve forwarding state. Run probes from diverse external networks toward representative destinations. Record where traffic stopped, whether the edge accepted it and whether internal destinations responded. Separate IPv4 and IPv6. Separate residential, business, DNS and management dependencies where their paths differ.

Third, preserve change state. Record deployments, maintenance, automation decisions and rollback actions around the incident window. If no change caused the event, say so only after checking the record. If the cause remains unknown, preserve that status and the investigation boundary.

Fourth, define recovery criteria. Require route stability, forwarding success, application health and customer-impact improvement for a named interval. Avoid declaring full recovery from the first successful probe or first route readvertisement.

Fifth, test recurrence risk. Compare the restored state with the state before the incident. Identify dependencies that remained degraded. Continue heightened monitoring through at least one normal load cycle. If a second disruption occurs, preserve the differences rather than overwriting the first timeline.

Sixth, coordinate with peers. Provide a tested NOC path and a structured way for other networks to report route and forwarding observations. Acknowledge conflicting evidence. External reports may expose failures invisible from inside the operator.

Seventh, communicate in layers. Give customers a concise service statement and remedy path. Give technical stakeholders a bounded routing and forwarding chronology. Give regulators enough evidence to assess duration, scope and response.

Eighth, reconcile remedies. Link validated service-loss periods to compensation and complaint systems without requiring customers to understand the network mechanism. State policy dates and eligibility limits.

Ninth, review concentration. Identify support, status, authentication and telemetry systems that share the affected network. Move critical evidence and communication paths outside the failure domain where practical.

Tenth, publish durable remediation. A promise to improve monitoring is not sufficient. State what signal was added, what threshold changed, what rollout boundary was introduced, what recovery test became mandatory and how the control will be audited.

This framework does not assume that every outage can be prevented. It requires that the operator can identify the failure boundary, restore service safely and prove what changed.

Accountability should follow capability, not hindsight

An outage of a large access network affects millions of relationships among customers, services and other networks. That scale creates a temptation to assign unlimited responsibility to one operator or, conversely, to call the event an unavoidable Internet failure. Neither approach is precise.

Virgin Media should be accountable for the controls it possessed: route origination, edge forwarding, internal recovery, operational communication and customer remedy. It should not be held responsible for facts the public evidence does not establish, such as a named vendor fault or malicious act.

Peers should be accountable for their own route acceptance, monitoring and escalation. Content providers should be accountable for realistic dependency and communication design. Regulators should be accountable for remedy frameworks that can use technical evidence without placing impossible proof burdens on customers.

Measurement providers should state the limits of their vantage points. Their observations are valuable because they are independent, not because they are omniscient. Analysts and journalists should preserve those limits.

Customers have the least control over the autonomous-system boundary. Residential users generally cannot reroute around their provider. Their primary responsibility is to report impact and use available remedies, not to engineer a second access network.

Capability-based accountability avoids hindsight. It asks what each party could observe, decide, change and prove at the time. It also exposes missing evidence without inventing a cause.

Conclusion

The Virgin Media disruptions of 4 April 2023 were network-infrastructure events because route and forwarding state determined whether AS5089 existed as a usable path from the wider Internet. Most observed traffic loss accompanied a lack of viable BGP routes. Some routes remained, but traffic still failed at the operator edge. Service then returned and failed again later in the day. [1][2]

Those facts are enough to define an accountability standard even though the root cause remains undisclosed. Recovery must be proved across route availability, packet forwarding and customer-visible service. Registry data must identify the network without being mistaken for operational truth. External measurement must test operator claims without pretending to reveal internal state. Customer remedies must connect to the same evidence timeline.

The strongest post-incident record would not claim certainty that the sources cannot support. It would show what routes changed, what packets did, what customers experienced, what the operator changed and how stable recovery was verified. That is the difference between a network returning briefly and an operator demonstrating that the service was restored.

For future incidents, that proof should be assembled as operations proceed rather than reconstructed after public concern rises. Route updates, forwarding probes, customer-impact signals, change records and status notices should share a reconciled timeline. The operator should publish enough of that record to show the failure mode, the recovery test and the durable control change while protecting customer and security-sensitive details. A network that can produce this evidence is better positioned to learn from failure, coordinate with peers and deliver fair remedies.

A network that cannot produce it may restore packets, but it cannot demonstrate why the same conditions will not return.

Sources

  1. Cloudflare, "Cloudflare's view of the Virgin Media outage in the UK": https://blog.cloudflare.com/virgin-media-outage-april-4-2023/
  2. ThousandEyes, "Virgin Media UK Outage Analysis: April 4, 2023": https://www.thousandeyes.com/blog/virgin-media-uk-outage-analysis-april-4-2023
  3. The Register, "UK's Virgin Media suffers massive broadband outage": https://www.theregister.com/on-prem/2023/04/04/uks-virgin-media-suffers-massive-broadband-outage/1495714
  4. ThousandEyes, "The Top Internet Outages of 2023": https://www.thousandeyes.com/blog/top-internet-outages-2023
  5. Cloudflare, "Q2 2023 Internet disruption summary": https://blog.cloudflare.com/q2-2023-internet-disruption-summary/
  6. Cloudflare Radar, AS5089 traffic: https://radar.cloudflare.com/traffic/as5089
  7. PeeringDB, AS5089 Virgin Media: https://www.peeringdb.com/net?asn=5089
  8. bgp.tools, AS5089 Virgin Media Limited: https://bgp.tools/as/5089
  9. RIPEstat, AS5089 network information: https://stat.ripe.net/data/network-info/data.json?resource=AS5089
  10. RIPEstat, AS5089 announced prefixes: https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS5089
  11. RIPE Database, AS5089 query: https://apps.db.ripe.net/db-web-ui/query?searchtext=AS5089
  12. RFC 4271, "A Border Gateway Protocol 4 (BGP-4)": https://www.rfc-editor.org/rfc/rfc4271
  13. RFC 7454, "BGP Operations and Security": https://www.rfc-editor.org/rfc/rfc7454
  14. RFC 8212, "Default External BGP (EBGP) Route Propagation Behavior without Policies": https://www.rfc-editor.org/rfc/rfc8212
  15. MANRS, Network Operators Programme: https://manrs.org/netops/
  16. Ofcom, "Automatic compensation: What you need to know": https://www.ofcom.org.uk/phones-and-broadband/service-quality/automatic-compensation-need-know
  17. Virgin Media, "We're improving the network in your area": https://www.virginmedia.com/help/planned-work
  18. Virgin Media, "Automatic compensation": https://www.virginmedia.com/help/billing-and-payments/automatic-compensation