Summary
- AS24989 was visible in RIPE RIS on 18 July 2026 with thirteen IPv4 prefixes and one IPv6 prefix, a compact routing surface that cannot be treated as an inventory of Equinix’s German data centres, cross-connects or metro paths.
- Equinix publicly presents German facilities in Frankfurt, Düsseldorf, Hamburg and Munich, but its current pages disagree on site counts and leave important capacity fields unavailable, so portfolio size is not proof of independent power, transport or recovery domains.
- A customer seeking real resilience must verify the legal contracting party, A- and B-side port placement, building and campus separation, carrier routes, exchange dependencies, power and cooling chains, and the tested failover behaviour of every service layered above the fibre.
The cross-connect is where a global promise becomes local
Picture a technician standing between two rows of cabinets in a German carrier hotel. One end of a yellow fibre jumper terminates on a customer panel. The other reaches an Equinix-managed panel, a carrier cage, an internet-exchange switch or a metro transport device. The commercial description may say that the customer is connected to a global platform. The operational fact is narrower: light must pass through clean connectors, the correct patching record, powered optics, working line cards and a path that has not been cut or misconfigured.
That distinction matters because a cross-connect is both extremely simple and deeply consequential. It is a short physical circuit, often entirely inside one building, but it may be the first link in a route to a cloud on-ramp, a transit provider, a private peer or another Equinix site. A service can therefore have a global name while its first failure domain is a single panel, tray, meet-me room or power feed. The customer does not receive geographic diversity merely because the far endpoint belongs to a worldwide company.
The local contracting and operating boundary is visible in Equinix’s German legal notice, which identifies Equinix (Germany) GmbH at Rebstöcker Straße 33 in Frankfurt and gives the Frankfurt commercial-register number HRB 91407. That page establishes a legal entity. It does not say that every German building, network service, route and recovery procedure is operated solely inside that entity, nor does it prove that two ordered connections avoid common group systems or contractors.
The physical nature of the service is clearer on individual site pages. Equinix’s FR5 page, for example, lists cross-connects, campus cross-connects, Fiber Connect, Metro Connect, internet access and internet exchange among available offerings. Those are distinct products with different paths. A cabinet-to-cabinet jumper inside FR5 is not the same asset as a campus circuit leaving the building, and neither is automatically the same network as an IP service advertised by AS24989.
The useful starting question is therefore not, “Is this in Equinix?” It is, “What exactly leaves my equipment, where does it terminate, who operates each segment, and which components are shared with my supposed backup?” The answer should identify two endpoints and the facilities between them, not just a brand and a service label. If the response stops at a logo, a metro name or an autonomous-system number, the most important part of the route remains unknown.
The German company, the group and the ASN are different boundaries
Equinix (Germany) GmbH is a German legal person within a much larger corporate group. AS24989 is an internet number registered through the RIPE system. An IBX site is a physical operating location. Equinix Fabric, Metro Connect, internet access, exchange ports and cross-connects are services. These layers can interact, but none is a synonym for the others.
The RIPE database entity for AS24989 names the autonomous system EQUINIX-CONNECT-GERMANY, describes it as “Equinix Germany” and adds the historically revealing note that it was previously only the Frankfurt data centre. It also refers to organisation ORG-IG20-RIPE and records many import and export policy statements. This establishes an administrative routing identity. It does not identify the racks from which every announcement originates, the fibre route used by each neighbour, or the legal entity responsible for every underlying circuit.
Public registries also preserve naming history imperfectly. The Euro-IX IXP Database entry for AS24989 labels the organisation “Equinix (Germany) Enterprise GmbH,” links onward to a PeeringDB subdomain and shows an update date in 2018. That is a useful clue that records can reflect a different entity name or an older organisational arrangement. It is not strong enough to override the current German legal notice or to prove present operational ownership. The prudent reading is that the ASN has an Equinix Germany lineage while public labels do not cleanly collapse into one legal and physical boundary.
This is more than corporate housekeeping. A customer may sign a colocation agreement with one entity, order a network service delivered by a group platform, buy transit whose BGP session terminates on shared infrastructure, and use a carrier whose route exits through a third party. During an incident, those distinctions determine who can authorize work, who can see alarms, who owns the failed optic, who supplies the post-incident explanation and which service commitment applies.
They also change the meaning of redundancy. Two circuits can be billed by different entities yet share the same duct. Two ports can be delivered in separate cabinets yet land on the same metro transport system. A German site and a group software service can fail independently, or a group control-plane problem can affect several physically healthy sites at once. Conversely, the loss of one building may leave the group platform available elsewhere while disconnecting the customer that has only one local attachment.
AS24989 is valuable because it lets an investigator inspect one visible routing surface associated with Germany. It should be treated as a window, not a wrapper. The company boundary answers questions about legal responsibility; the facility boundary answers questions about power, cooling and physical access; the ASN boundary answers questions about route origination and exchange with other networks. A credible resilience design has to reconcile all three.
What AS24989 actually announced on 18 July 2026
The most defensible description of AS24989 comes from current routing observations rather than from the scale of Equinix’s brand. RIPE NCC’s routing-status response for AS24989, observed on 18 July 2026, reported thirteen IPv4 prefixes covering 19,712 addresses and one IPv6 announcement equivalent to 65,536 /48 blocks. It showed the ASN to almost all reporting RIS peers at that collection point and counted six observed neighbours. These are measurements of BGP visibility, not a count of routers, customers, ports or facilities.
The accompanying announced-prefixes response listed the actual set: one IPv4 /18, one /23, eleven /24s and the IPv6 prefix 2a05:c700::/32 during the displayed two-week interval. Fourteen routed prefixes are a modest public footprint compared with the physical and commercial scale Equinix attributes to Germany. That mismatch is the point of the inquiry, not evidence that either dataset is wrong. Colocation buildings can host thousands of independently numbered customer networks that never originate through the facility operator’s local ASN.
The live summary at bgp.tools for AS24989 independently displays the EQUINIX-CONNECT-GERMANY name and a small observed peer set, while reproducing registry information that includes both transit-style imports and numerous customer-facing export statements. It helps show that AS24989 participates in a real service network. It still cannot reveal the capacity of a link, the location of a BGP speaker or whether two sessions share a chassis, room or fibre route.
Several cautions follow. First, a prefix count is not traffic volume. A /18 can carry little traffic, while a /24 serving a concentrated platform can be operationally important. Second, public route collectors see paths from selected vantage points. They do not expose private interconnections, layer-two exchange membership that does not originate these prefixes, customer cross-connects or traffic kept inside a private cloud connection. Third, neighbour counts depend on what collectors can observe and on the routing policies in use; they are not a full port inventory.
Fourth, the RIPE entity contains far more policy statements than the six neighbours visible in the current RIS summary. Registry policy can include historical, prospective or customer relationships that are not simultaneously visible as direct global neighbours. Observational data can also compress several commercial relationships behind one path. The difference is a reminder to separate declared policy from measured state.
The strongest conclusion is deliberately limited: AS24989 is globally visible, originates a specific and relatively compact set of address space, and is associated with an Equinix Germany routing service. It does not carry an embedded map of German IBX buildings. It does not prove that Frankfurt, Düsseldorf, Hamburg and Munich share or avoid a control plane. It does not show where customer traffic crosses from an exchange fabric into transit. Those questions require facility, port and route evidence.
Facility inventory is broader, and the public count is not internally tidy
Equinix’s Germany location page places its operations in four metros: Frankfurt, Düsseldorf, Hamburg and Munich. It says the company operates fifteen German data centres and offers about 1.1 million square feet, or approximately 103,000 square metres, of colocation capacity. On the same page, however, the displayed metro counts are ten for Frankfurt, one for Düsseldorf, one for Hamburg and four for Munich. Those numbers add to sixteen, not fifteen.
The metro pages introduce another discrepancy. The Frankfurt page says ten data centres but visibly links nine named locations: FR2, FR4, FR5, FR6, FR7, FR8, FR9x, FR11x and FR13. The Munich page says four but visibly links MU1, MU3 and MU4. Düsseldorf’s metro page links DU1, while Hamburg’s metro page links HH1.
Equinix’s separate colocation availability documentation lists DU1; Frankfurt FR2, FR4, FR5, FR6, FR7, FR8, FR9x and FR11x; HH1; and Munich MU1, MU3 and MU4. It omits FR13 even though FR13 has a live site page and has been open since 2023. The documentation also distinguishes full-time on-site operational coverage, non-24/7 coverage and locations where Smart Hands is unavailable. Coverage status is a service-support fact, not proof that a site is closed, but it demonstrates that facilities under one brand do not all present the same operating profile.
There are plausible explanations for the counting differences. A page may count phases, campuses, xScale buildings, recently opened capacity or locations not yet linked in the same way. A product table may lag a marketing page. A metro total may include a site that is grouped differently elsewhere. None of those explanations should be selected without further evidence. The correct response is to preserve the inconsistency rather than manufacture a reconciled total.
For customers, the exact count is less important than the consequence: “multiple German data centres” is not a usable recovery design. A Frankfurt campus can contain several buildings with short inter-site connections and shared regional dependencies. A Munich listing can include central-city and Aschheim locations. Hamburg and Düsseldorf can provide geographic separation from Frankfurt, but only if the ordered services truly terminate there and the transport between metros avoids common bottlenecks.
Portfolio maps are helpful for deciding where to ask for service. They are not route diagrams. A marker in two cities says nothing about conduit diversity, carrier ownership, optical regeneration, shared exchange systems or the customer’s actual BGP policy. Even the facility count needs qualification until Equinix identifies which sites and phases are included. Public evidence supports a broad German footprint; it does not support turning every displayed marker into an independent failure domain.
Frankfurt shows why buildings, campuses and routes must be separated
Frankfurt is the centre of Equinix’s German interconnection story, but its facilities are not interchangeable. The official pages place them at several addresses and describe different technical characteristics. That physical spread can support resilient design. It does not, by itself, prove a route-diverse service.
FR2 is listed at Kruppstraße 121–127 in 60388 Frankfurt. Its page reports 29,386 square metres of colocation space, N+1 UPS, generator and cooling arrangements, and generator autonomy of at least thirty hours at full load. FR5, at Kleyerstraße 90 in 60326 Frankfurt, reports 7,257 square metres, N+1 UPS, generator and cooling, and the same stated generator-autonomy threshold. These are substantial facility specifications, but the area is building space, not available electrical megawatts, contracted customer load or currently unoccupied capacity.
FR7, at Gutleutstraße 310, reports 6,889 square metres and N+1 UPS and cooling. Its generator field is more nuanced: one part of the site is shown as N while another is N+1. That detail alone is enough to reject blanket reasoning from a metro-level uptime phrase. A customer needs to know the room, power chain and product to which a redundancy statement applies.
The newer pages expose even larger gaps. FR8 at Lärchenstraße 141 identifies N+1 UPS and cooling but says its colocation-space figure cannot currently be displayed; its generator fields are also incomplete. FR9x and FR11x are presented as the two xScale facilities on the north-east campus. Their current pages withhold total sellable capacity. FR11x displays zero square metres in one field while simultaneously describing an operating hyperscale facility and withholding sellable capacity. Zero is therefore best treated as a page-data defect, not as physical evidence that the building has no usable space.
FR13, at Friesstraße 9, is a retail IBX addition on the same broad north-east campus. Its current page withholds most space and redundancy fields. The opening announcement for FR13 gives a firmer dated fact: Equinix opened the building in November 2023 after a stated investment of $104 million and said it delivered 1,125 cabinets. It also described the north-east campus as nine data centres, counting six FR2 phases, FR13 and the two xScale sites. This explains how “data centre” can mean a phase or building in one context and a marketed site code in another.
Equinix’s 2024 annual filing later listed FR13 phase II among significant construction projects. An opening capacity is therefore not the final capacity, while a construction plan is not operating capacity until commissioned, powered and available. Frankfurt offers real physical plurality, but the public record does not identify the route taken by a customer’s two circuits or prove that all phases avoid common substations, campus ducts, transport shelves or operating systems.
Düsseldorf, Hamburg and Munich widen geography, not certainty
The other German metros matter because they can move workloads and network attachments away from Frankfurt’s concentrated ecosystem. They also have their own local dependencies. Geographic distance improves resilience only when the service design actually uses it.
DU1 is the only location linked on Equinix’s Düsseldorf page. The metro description emphasizes peering, transit, cloud access, disaster recovery and business continuity. Those are useful service possibilities, but a customer must distinguish between placing equipment in Düsseldorf and reaching a Düsseldorf service remotely from Frankfurt. A remote connection can still begin in the failed Frankfurt building or ride the same metro aggregation layer as the primary.
HH1 is the linked Hamburg facility. Equinix describes Hamburg as a northern gateway with access to networks, cloud providers and subsea-cable routes. DE-CIX’s 2020 announcement about HH1 provides useful corroboration: it says HH1 became a DE-CIX enabled site offering the exchange operator’s interconnection services. That proves a service presence at the building at the time of the announcement. It does not disclose the fibre route from HH1 to other DE-CIX nodes, the number of physically separate entries, or whether a customer buys a local port rather than remote access.
Munich adds another important distinction. MU1 and MU3 are described at Seidlstraße, while MU4 is in Aschheim. Two site codes at one street address may offer equipment and room separation without providing the same geographic separation as an Aschheim deployment. Conversely, an Aschheim site can still share carriers, service platforms or regional power constraints with another Munich-area location. The customer must ask which kind of diversity the architecture is intended to deliver.
These metros also serve different demand centres. Frankfurt concentrates international interconnection, finance and cloud access. Düsseldorf sits in the Rhine-Ruhr industrial region. Hamburg supports northern enterprises, logistics and connectivity toward cable gateways. Munich serves automotive, engineering, media, finance and technology clusters. An outage can therefore have different local effects even when the same group operates the sites. A Hamburg cross-connect fault may isolate one customer with little impact on Frankfurt routing; a shared software failure could affect ordered services in all four metros while power remains stable.
No public page reviewed here supplies an exact Germany-wide optical route map. That absence should shape the language used about service area. Equinix has operating locations in four German metros and markets interconnection among a large ecosystem. It is not possible from those pages to claim that every facility pair has two independently owned, geographically separated fibre paths, or that AS24989 is present with identical equipment and policy at each location.
The recovery value of Düsseldorf, Hamburg or Munich therefore depends on deployment choices. Equipment, data replicas, DNS, routing sessions, credentials, management access and carriers must all be capable of operating from the secondary location. Otherwise the distant site is a spare room rather than a recovery system.
Capacity is space, power, cooling, ports and time—not one number
The Germany landing page’s approximately 103,000 square metres is a useful indication of portfolio scale. It is not a measure of immediately usable capacity. A square metre may be fitted or unfitted, powered or awaiting utility delivery, occupied or available, suitable for ordinary cabinets but not a high-density deployment, or located in a building that does not offer the customer’s required interconnection.
The same caution applies to cabinets. FR13’s 1,125-cabinet opening figure is dated and site-specific. It does not say how many cabinets were sold, reserved, energized or available on 18 July 2026. The annual filing’s reference to phase II indicates expansion potential, but planned construction must pass through utility connection, commissioning, customer fit-out and operational acceptance before it becomes usable production capacity. A facility can be open while a later phase remains unavailable.
Power is often the harder limit. A data hall with free floor area cannot accept a new deployment if contracted utility power, UPS modules, distribution equipment or cooling capacity is exhausted. High-density systems can also strand nominal space because their heat load exceeds what a row or room can remove. Equinix’s site pages describe N+1 arrangements at several Frankfurt facilities and advertise advanced or liquid cooling at some locations. They do not publish a complete site-by-site table of installed megawatts, lit megawatts, contracted load, remaining sellable load and failure-mode derating.
Renewable-energy statements describe procurement coverage, not electrical independence. Equinix’s sustainability quick-reference guide lists German sites and renewable-energy coverage for its reporting period. A certificate or guarantee of origin can support an environmental claim while the facility remains physically dependent on the regional grid, local substations, switchgear, UPS batteries and generators. It does not mean a data centre is fed by a dedicated renewable generator during an outage.
Certifications require similar precision. Equinix’s standards and compliance page shows the range of certifications associated with its facilities and tells customers to request copies through their customer contact. Certification can provide meaningful assurance about management systems and controls. It does not disclose a customer’s exact circuit route, prove that two power feeds lack a common upstream component, or guarantee that a particular failure will remain inside one room.
Usable capacity is also conditional during failure. If a hall loses one UPS module, the surviving system may carry the load but leave no redundancy for the next fault. If cooling operates at N+1 under normal conditions, extreme outdoor temperatures or maintenance can change the margin. Generator autonomy depends on fuel, replenishment, load and successful starting. A stated thirty-hour minimum at full load is stronger than a vague “backup power” phrase, but it is still a design or operating claim that should be tested against the applicable service documentation.
The public evidence supports substantial built space and ongoing investment. It does not support a single audited number for Germany-wide powered, lit, unsold and failure-tolerant capacity. Procurement decisions should therefore ask for capacity in the unit that constrains the intended workload: committed kilowatts, permissible rack density, cooling method, ports, cross-connect lead time and the capacity available after the first component fails.
Peering density depends on facilities, exchange systems and transport
Frankfurt’s value comes partly from the number of networks that can meet there. Equinix describes dense access to networks and clouds, while DE-CIX Frankfurt reports more than 1,000 connected networks, access in more than thirty data centres and route-server reach to a large share of entities. Those are exchange-wide figures. They should not be assigned to AS24989 or to every Equinix building.
The physical exchange fabric is distributed. DE-CIX’s route-server community documentation identifies edge devices at Equinix FR2, FR5 and FR7 among many sites. That is valuable location evidence: exchange equipment or an exchange edge exists at specific facilities. It also illustrates why a metro exchange cannot be reduced to one carrier hotel. Traffic may enter at one edge, cross an optical backbone and reach a peer attached elsewhere.
DE-CIX’s Apollon platform description says the Frankfurt system uses a mesh optical backbone, multiple supernodes and active core redundancy. It publishes platform-level capacity and equipment details. Those claims describe the exchange operator’s architecture, not the complete path from a customer cabinet to every peer. The customer-side cross-connect, patch panel, exchange access port and local facility power remain necessary. A resilient exchange core cannot repair a cut jumper between the customer and its first switch.
Private peering adds another layer. Two networks can connect directly without using a route server, or buy a service that reaches a remote exchange port through transport. Cloud connectivity can be delivered over Equinix Fabric without appearing as a public AS24989 route. Transit through Equinix Internet Access or Equinix Connect can have yet another BGP policy. The fact that all of these services are purchasable in a facility does not mean they share one data plane, but neither does separate product naming prove that they are physically independent.
Control-plane diversity must be tested separately from physical diversity. Two fibre paths can be physically separate while both sessions depend on the same route server, authentication system, provisioning service or customer router configuration. Two BGP sessions can use different peers while both fibres leave through the same duct. The safest design separates the failure domains deliberately: distinct customer devices, ports, meet-me rooms where available, facility entrances, carrier paths, exchange attachment points and routing policies.
AS24989 sits inside this environment as one visible routing service, not as the index of it. The fourteen originated prefixes say nothing about the thousands of other networks exchanging traffic in Equinix facilities under their own ASNs. Equally, a large exchange-wide traffic figure cannot be used to estimate traffic carried by AS24989. The two datasets answer different questions.
This is why peering density can increase both opportunity and concentration risk. A customer gains short paths to many counterparties, but a faulty configuration, exchange edge, facility power event or metro transport problem can affect several valuable connections at once. The remedy is not to avoid dense hubs. It is to know which dependencies are common and place recovery paths outside them.
Five failure paths expose five different customer impacts
A serious assessment should test at least five classes of failure, because each one crosses the legal, physical and routing layers differently.
The first is a cross-connect fault. A contaminated connector, incorrect patch, failed optic or damaged jumper can take down one service while the building, AS24989 and the wider exchange remain healthy. The directly attached customer is affected; other tenants may see nothing. Recovery may be as simple as moving to a pre-installed secondary port, but only if that port follows a separate path and has been configured in advance.
The second is a facility power or cooling event. A site can lose utility power and continue on UPS and generator systems, but a failed distribution component or cooling chain may still affect a room or row. Customers with both “diverse” circuits terminating in the same cabinet or power domain may lose both. Other Equinix sites can remain operational, and AS24989 may remain globally visible from elsewhere, masking a severe local impact in route-collector summaries.
The third is shared metro transport failure. Two endpoints in different Frankfurt buildings may depend on the same street duct, carrier ring, optical shelf or campus handoff. The buildings can have independent generators while the circuits fail together. Public facility pages do not disclose enough route geometry to rule this out. Only carrier route records, entrance details and a written diversity commitment can settle the question.
The fourth is a control-plane incident. Route leaks, filtering errors, a software defect, an authentication problem or an incorrect provisioning change can withdraw or misdirect routes while fibres remain lit. A control-plane issue can affect several metros if they use a common service system. Conversely, AS24989 can suffer a routing change without disrupting private cross-connects that do not depend on it.
The fifth is a broader service dependency failure. Customer access to a portal, remote-hands process, cloud on-ramp or exchange service can be impaired even if the cabinet has power. Equinix’s incident and notification documentation says its Service Insight capability covers operational and outage-related status for network products and planned or unplanned IBX maintenance. The incident-details documentation describes affected locations, products, updates and the process for requesting a post-incident report. This shows that incident scope is tracked by both site and service, which is exactly the separation customers need.
The affected population changes with each failure. A cross-connect fault can isolate one organisation. A room-level power event can hit a cluster of cabinets. A facility outage can affect many tenants and exchange attachments. A metro fibre cut can impair services across several buildings. A shared routing or service-control error can cross geography. Internet users may experience latency or reachability changes, while private-cloud customers see application timeouts and operations teams lose management access.
None of these outcomes is established merely by the existence of AS24989. BGP visibility is useful during an incident, but it can understate failures in private services and overstate recovery if surviving announcements lead to overloaded or incomplete paths. Operators should combine route observation with optical alarms, port state, facility status, application health and customer reports.
Redundancy claims need a named scope and a failure condition
Equinix’s metro pages advertise very high guaranteed uptime, and several site pages list N+1 UPS, generator or cooling arrangements. These are meaningful statements when tied to a defined service and measurement period. They are not universal proof that every customer architecture survives every single failure.
“N+1” means there is one additional unit beyond the number required for the designed load, but the unit and boundary matter. It can describe UPS modules, generators, chillers or another component set. It does not automatically mean two utility substations, two independent fuel contracts, two building entrances or two metro routes. FR7’s differing generator notation by building area is a concrete example of why the scope must be read closely.
An uptime commitment is also not an engineering diagram. The commitment may apply to power availability, environmental conditions or a particular product; exclusions and remedies may be contractual. A customer can experience an application outage even when the measured facility service remains within its commitment. A route can flap, a peer can reject an announcement, or the customer can misconfigure failover without the building breaching an uptime promise.
Recovery claims should therefore be expressed as tests. If FR5 becomes unreachable, does traffic move to a router in another building without manual intervention? If the Frankfurt metro is isolated, can the service originate from Munich or Hamburg with the necessary data, credentials and upstream capacity? If a route server is unavailable, do bilateral sessions or transit paths maintain reachability? If the group provisioning layer is impaired, are already established private circuits still usable?
Physical diversity needs evidence at the level of address, room, meet-me room, building entry and carrier route. Logical diversity needs evidence at the level of ASN, BGP neighbour, route policy, exchange attachment and customer device. Operational diversity needs separate access methods, staff procedures, spares and escalation paths. Legal diversity, where required, needs clarity about the party that owes each obligation. Buying two order lines does not necessarily deliver two of each.
The current public record supports several positive conclusions. Equinix operates across multiple German metros. Frankfurt contains multiple addressed facilities and campuses. DE-CIX distributes exchange infrastructure across facilities, including several Equinix sites. Individual facility pages publish useful redundancy and generator-autonomy details. FR13 represents completed investment with further phased expansion reported later.
It also leaves important questions unanswered. No public evidence here proves the duct path between any selected pair of Equinix facilities. Site pages do not provide a complete current table of powered and available megawatts. The relationship between AS24989’s visible neighbours and every German service location is not disclosed. Facility-count inconsistencies prevent a clean, audited inventory from the marketing pages alone.
The right evidence grade is therefore mixed by layer: strong for the existence and current visibility of AS24989; strong for the existence of named facilities and four German metros; medium for portfolio-wide capacity because the aggregate is marketed while important component fields are missing; and weak for customer-specific route diversity until a provider supplies route and design documentation.
A customer can turn this ambiguity into a verifiable recovery design
The practical response is not scepticism for its own sake. It is a procurement and testing discipline that converts broad claims into named assets and observable behaviour.
Start with the service demarcation. Record the customer device, port, optic, panel, meet-me room, facility code and street address for each connection. Identify whether the next hop is an Equinix service, an exchange, a carrier or a cloud provider. For a cross-connect, document both endpoints. For a virtual connection, document the physical ports and transport that make the virtual service possible.
Then separate the paths. Ask whether A and B circuits use different customer routers, facility entrances, carrier systems and metro routes. If both use Equinix-operated transport, request the shared components and the failure cases the design is intended to survive. If two carriers are used, do not assume they own separate fibre; wholesale arrangements can put both services on one underlying route.
Map routing independently. Record every ASN, neighbour address, accepted prefix set, advertised prefix set and failover preference. AS24989 may be relevant to an internet-access service, but it should not be assigned to private peers or customer networks without evidence. Monitor the fourteen-prefix public surface as one indicator, not as the health signal for all Equinix Germany services.
Qualify capacity under stress. Obtain committed power, rack-density limits, cooling method and the capacity available after one module, feed or path fails. Ask whether the secondary site has enough compute, storage and network headroom to carry production rather than merely accept backups. Confirm cross-connect lead times and whether spare ports are installed, powered and configured.
Test the recovery sequence. Withdraw the primary BGP session in a controlled exercise. Disable one customer port. Simulate loss of management access. Confirm that DNS, authentication, monitoring and data replication continue from the secondary metro. Measure convergence, packet loss and application recovery, then compare the result with the business objective. A recovery plan that has never carried production traffic is still a hypothesis.
Finally, keep the boundaries visible during an incident. Facility status, optical state, exchange status, BGP observations and application health should appear separately. The survival of AS24989 announcements does not clear a local building, and a dark route collector graph does not prove that a private circuit is down. Escalation contacts should match the party that owns each failed component.
Equinix Germany’s scale is real in the sense that public pages show facilities across four metros, substantial Frankfurt space and continuing investment. AS24989’s fourteen prefixes are real in the sense that RIPE RIS observed them on the publication date. The analytical mistake would be to force these facts into a one-to-one map.
The cross-connect in the meet-me room is a better guide. It reminds us that every global service begins with local hardware and that every recovery claim must survive a named failure. When a customer can trace both primary and secondary paths from port to building, from building to metro, and from metro to routing policy, Equinix’s broad footprint becomes usable resilience. Until then, AS24989 is a narrow and informative window—not proof of the view beyond it.