Global WAN Backbone Using FCR + IP-WAN

1 Summary

This Equinix Validated Design (EVD) validates a global WAN backbone built on Equinix Fabric, Fabric Cloud Router (FCR), and IP-WAN. In this EVD a THREE regional hub locations — Metro-A (Frankfurt) and Metro-B (Amsterdam) in the EMEA Region, and Metro-C (New York) in the AMER Region — are interconnected using Regional IP-WAN for intra-EMEA connectivity and Global IP-WAN for inter-regional connectivity.

Each regional hub hosts a Fabric Cloud Router (FCR) connected to a Network Edge Cisco 8000v router via a local Fabric Virtual Connection. Network Edge (NE) is used in this design as the regional access aggregation layer — connecting simulated on-premises data centres, remote branch offices, and colocation environments to the FCR backbone.

This EVD validates a cost-optimised, software-defined global WAN backbone using Fabric Cloud Router, Regional IP-WAN, and Global IP-WAN on Platform Equinix.

1.1 High-Level Architecture Diagram

1.2 Key Outcomes

This EVD validates the following:

• Strict prefix separation between Regional and Global IP-WAN is enforced using FCR egress route filter policies — the same prefix never appears on both IP-WAN paths simultaneously at any FCR.
• Intra-EMEA traffic (Metro-A / Frankfurt ↔ Metro-B / Amsterdam) stays on Regional IP-WAN using site-specific routes.
• Inter-regional traffic (EMEA ↔ Metro-C / New York) uses Global IP-WAN.
• Metro-C (New York) receives only summary routes from EMEA via Global IP-WAN — no site-specific EMEA prefixes are visible at Metro-C.
• When Regional IP-WAN is unavailable, EMEA traffic automatically falls back to Global IP-WAN via the summary route — no manual intervention required.
• Infrastructure peering ranges and lab loopback ranges are completely blocked from all IP-WAN connections by route filter policies.

2 Technology Stack & Scope

Technology Stack

Scope

3 Low Level Design

3.1 Why This Design: FCR + IP-WAN Over Alternatives

Why FCR + IP-WAN for this EVD.

• FCR provides managed BGP routing on Equinix Fabric — provisioned via portal or API, natively redundant, and requiring no vendor software licensing or specialised vendor engineering skills. The customer configures routing policy. Equinix operates the platform.
• IP-WAN provides Any-to-Any Layer 3 multipoint connectivity. When an FCR connects to IP-WAN via a Fabric Virtual Connection, BGP session establishment and route advertisement between FCRs is handled automatically by Equinix — eliminating the need for per-peer BGP configuration or carrier circuit management.
• Combined, FCR and IP-WAN provide a managed, scalable L3 backbone where the customer defines routing policy through BGP and route filter policies, and Equinix handles the underlying infrastructure. This separation keeps intra-regional traffic on the lower-cost Regional IP-WAN and reserves Global IP-WAN capacity for inter-regional traffic — enforced by the route filter policies validated in this EVD.
• In this design, Network Edge is used at the regional access aggregation layer. Customers can equally use physical L3 routing gear — such as a router or firewall — collocated in the Equinix IBX as an alternative to Network Edge, connected to the FCR via a Fabric Virtual Connection and physical Fabric ports.

Other Architectural Options on Platform Equinix:

Selecting the right architectural approach for a global WAN backbone on Platform Equinix depends on the specific use case and requirements. Each option has a valid for certain scenarios: MPLS Provides reliable managed L3 connectivity but involves long carrier lead times, limited on-demand flexibility. Equinix Fabric E-LAN (EP-LAN and EVP-LAN) Provides multipoint L2 connectivity where L2 adjacency is required but places the full L3 routing responsibility on the customer. Equinix Fabric E-Line (EPL and EVPL) Provides point-to-point L2 connectivity suited to specific site pairs. Network Edge with Device Link Groups (DLGs) provides L3 routing with full vendor platform control but requires vendor-specific skills and software license management.

3.2 Design Principle — Strict Prefix Separation

The fundamental rule of this design is:

• The same prefix will not be advertised over both Regional IP-WAN and Global IP-WAN simultaneously, preventing ECMP between the two IP-WAN paths and ensuring intra-regional traffic stays on Regional IP-WAN.

This is achieved by assigning non-overlapping address blocks to each metro and enforcing prefix scope through route filter policies:

• Site-specific prefixes — advertised over Regional IP-WAN only (EMEA FCRs)
• Summary route (aggregate) — advertised over Global IP-WAN only (all FCRs)
• Result: remote EMEA FCRs receive site-specific prefixes via Regional and the summary route via Global. The more-specific route always wins — intra-EMEA traffic stays on Regional IP-WAN.
• When Regional IP-WAN fails — site-specific prefixes are withdrawn, the summary route via Global activates automatically. Traffic fails over without manual intervention.

This rule applies uniformly to all FCRs in the design — every FCR advertises only the aggregate over Global IP-WAN, regardless of whether a Regional IP-WAN exists at that metro. This ensures the design scales consistently as new metros are added without requiring per-metro exceptions.

3.3 IP Addressing Plan

The IP addressing plan is a foundational design element — defined before any deployment begins. Four distinct address spaces are used, each with a single unambiguous purpose.

Service Prefixes

📝 Note —Metro-C (New York) is connected only to the Global IP-WAN. Consistent with the universal design rule, Metro-C advertises only the aggregate over Global IP-WAN — site-specific prefixes remain local to the metro. This ensures the design rule is uniform across all metros regardless of whether a Regional IP-WAN exists.

Infrastructure, Loopbacks, and BGP Peering Links

Loopback ranges 1.1.1.0/24, 2.2.2.0/24, and 3.3.3.0/24 are public IP ranges used for EVD simulation only. They may be replaced with customer-assigned private loopback addresses in production deployments.

3.4 Topology and BGP Design

BGP Session Summary

IP-WAN connections (Regional and Global) do not expose a directly configurable BGP peer session. Route advertisement between FCRs via IP-WAN is handled automatically and internally by Equinix. IP-WAN routes appear in FCR Active Routes with the next-hop translated to the IP-WAN fabric name and remote metro.

3.5 IP-WAN Redundancy and Bandwidth

FCR and IP-WAN inherit redundancy from the Equinix Fabric platform. This redundancy is designed for availability and resilience — not bandwidth aggregation. Each IP-WAN service operates at its provisioned speed regardless of the redundant path in the background.

• Regional IP-WAN: active and standby paths exist internally. Usable bandwidth equals the provisioned speed. The two paths do not combine to double throughput.
• Global IP-WAN: same model — active and standby paths, usable bandwidth equals provisioned speed.

Each IP-WAN service has four dedicated public IP subnets assigned from Equinix-owned ranges — one for the active path and one for the standby path, per service. These ranges are drawn from the same Equinix-owned pool used for Internet Exchange points but are dedicated exclusively to IP-WAN infrastructure — they are not used in the IX fabric and are not publicly reachable from the internet. These specific addresses observed during validation are documented in the companion Lab Validation Report — Global WAN Backbone: FCR + IP-WAN.

3.6 Route Filter Policy Design

Route filter policies on IP-WAN connections work as a whitelist — only explicitly permitted prefixes are advertised. All other prefixes are denied by default. In a multipoint IP-WAN topology, egress filters must be applied at the source FCR — this prevents unwanted prefixes from entering the IP-WAN fabric entirely, rather than blocking them at each individual receiving FCR.

All five policies follow the same universal rule: site-specific prefixes are permitted on Regional IP-WAN only, and the aggregate is permitted on Global IP-WAN only. Every FCR in the design advertises only the aggregate over Global IP-WAN — no exceptions. Infrastructure peering ranges and loopback ranges are implicitly denied on all connections.

3.7 Traffic Path Design

Note: Inter-regional traffic in both directions uses only aggregate routes over Global IP-WAN — this is the direct result of the universal filter policy rule applied consistently across all FCRs. The design is fully symmetric: no metro advertises site-specific prefixes over Global IP-WAN, and no FCR has visibility into the internal site-specific prefix details of a remote region.

3.8 Scalability and Ease of Expansion

The universal design rule — every FCR advertises only the aggregate over Global IP-WAN — is the foundation that makes this design scale cleanly. When a new metro is added, the engineer deploying it does not need to reason about whether that metro requires special treatment on the Global IP-WAN connection. The rule is the same for every metro, every region, every time. This eliminates a class of configuration errors that arise when designs have per-metro exceptions.

Adding a New Metro Hub:

• Extending the backbone to a new metro — for example, adding Singapore as an APAC hub — involves four steps: provision a new FCR instance in Singapore, connect it to the existing Global IP-WAN service via a single Fabric Virtual Connection, deploy a local Network Edge router and create a local VC, and apply an egress route filter policy on the new FCR's Global IP-WAN connection permitting only the new metro's aggregate. No changes are needed on existing FCRs — the multipoint IP-WAN automatically includes the new participant. The entire process can be completed in under an hour via the Equinix Fabric portal or API, without any carrier negotiations or change windows.

Adding a New Regional IP-WAN

• If a new region requires intra-regional connectivity between its own metro hubs — for example, two APAC metros — a Regional IP-WAN service is provisioned separately for that region following the same pattern as FCR-Regional-IPWAN-AB in EMEA. The Global IP-WAN continues to handle inter-regional traffic. Regional IP-WAN services are independent per region and require no changes to existing services in other regions.

Adding New Sites Within an Existing Metro

• Adding new simulated branch or colo sites within an existing metro requires no changes to the IP-WAN or FCR configuration. New site-specific prefixes within the existing metro address block are advertised by the NE router to the local FCR. The existing Regional IP-WAN egress filter policy is updated to permit the new prefixes. The Global IP-WAN aggregate automatically covers any new additions within the metro address block — no changes to Global IP-WAN filtering are needed.

API-Driven Automation

• Every provisioning and configuration action in this design — FCR deployment, VC creation, IP-WAN connection, route filter policy creation and attachment, BGP configuration — is available through the Equinix Fabric API. This means the entire backbone can be managed programmatically using Terraform, Ansible, or any API-capable automation toolchain. New hubs, new sites, and new route policies can be deployed through CI/CD pipelines without portal interaction, making the design well-suited to infrastructure-as-code operational models.

3.9 Prerequisites

• Active Equinix Fabric account with FCR, Regional IP-WAN, and Global IP-WAN services available in the target metros.
• FCR instances provisioned at all three metros with BGP sessions established to the local Network Edge router at each metro.
• Regional IP-WAN provisioned connecting the two EMEA metro FCRs.
• Global IP-WAN provisioned connecting all three FCR instances.
• Network Edge router deployed at each metro with a local VC connection to the FCR.
• IP addressing plan finalised and locked before deployment begins — the address block and prefix scope must be defined per metro before any BGP advertisement is configured.
• FCR route filter policies created and attached to each IP-WAN connection before end-to-end routing validation begins

3.10 Assumptions, Constraints & Dependencies

• The NE router originates the metro summary route via static route and BGP network statement — a clean and supported approach using standard BGP capabilities.
• FCR route filter policies use a whitelist model — only explicitly listed prefixes are permitted. Implicit deny applies to all others.
• In a multipoint IP-WAN, egress filters at the source FCR are the correct and only reliable control point. Ingress filters at the receiving FCR do not prevent prefix leakage to other IP-WAN participants and would require identical policy on every connected FCR to be effective.
• Metro-C has no Regional IP-WAN connection in this design. All Metro-C prefixes traverse Global IP-WAN only — this is intentional as Metro-C represents a different region with no intra-regional peers in this EVD.
• Loopback ranges used in this lab are public IP ranges — for lab simulation only. In production deployments, customers should use RFC 1918 private ranges for loopback addressing.
• A single Network Edge router is deployed per metro in this EVD for simplicity. This represents a single point of failure at the access layer. Production deployments should consider a redundant NE pair per metro.

4 Deployment & Implementation

Steps are listed in the recommended deployment order. Verify each step before proceeding to the next. Route filter policies must be applied before end-to-end validation begins.

Step 1 — Provision FCR Instances

• Provision FCR-A in Frankfurt via Equinix Fabric portal or API.
• Provision FCR-B in Amsterdam via Equinix Fabric portal or API.
• Provision FCR-C in New York via Equinix Fabric portal or API.
  • FCR is natively redundant — no additional HA configuration required at the platform level.

Step 2 — Provision IP-WAN Services

• Create FCR-Regional-IPWAN-AB: Regional IP-WAN service connecting FCR-A and FCR-B (EMEA only).
• Create FCR-Global-IPWAN-ABC: Global IP-WAN service connecting FCR-A, FCR-B, and FCR-C. ◦
  • Verify both IP-WAN services are provisioned and active before creating local VCs.

Step 3 — Deploy Network Edge Routers and Create Local VCs

• Deploy Router-A (Cisco C8kv) in Frankfurt. Create VC-A connecting FCR-A to Router-A.
• Deploy Router-B (Cisco C8kv) in Amsterdam. Create VC-B connecting FCR-B to Router-B.
• Deploy Router-C (Cisco C8kv) in New York. Create VC-C connecting FCR-C to Router-C.
  • Interface Gi3 is used on each C8kv as the FCR-facing interface.

Step 4 — Configure NE Routers

Apply the following configuration pattern on each router. Substitute metro-specific values per the IP addressing plan.

Step 5 — Verify BGP Sessions and Local Route Advertisement

• Confirm BGP session Established on each router: show ip bgp summary
• Confirm all locally originated prefixes are being advertised toward the FCR: show ip bgp neighbors <FCR-IP> advertised-routes
• Confirm FCR Active Routes shows all local prefixes from each router before applying filters.

At this stage, ECMP will be present — the same EMEA prefixes will appear via both Regional and Global IP-WAN. This is expected and will be resolved in Step 6.

Step 6 — Create and Apply Route Filter Policies

• Create Metro-A Regional egress policy: permit site-specific prefixes only. Attach as egress on the Metro-A Regional IP-WAN connection.
• Create Metro-A Global egress policy: permit Metro-A aggregate only. Attach as egress on the Metro-A Global IP-WAN connection.
• Create Metro-B Regional egress policy: permit site-specific prefixes only. Attach as egress on the Metro-B Regional IP-WAN connection.
• Create Metro-B Global egress policy: permit Metro-B aggregate only. Attach as egress on the Metro-B Global IP-WAN connection.
• Create Metro-C Global egress policy: permit Metro-C aggregate only. Attach as egress on the Metro-C Global IP-WAN connection.

All policies use the whitelist model — implicit deny applies to all prefixes not listed.

Step 7 — Verify Post-Policy FCR Active Routes

• Confirm Metro-A FCR: site-specific prefixes from Metro-B via Regional IP-WAN only; Metro-B and Metro-C aggregates via Global IP-WAN only. No duplicate prefixes on both paths.
• Confirm Metro-B FCR: site-specific prefixes from Metro-A via Regional IP-WAN only; Metro-A and Metro-C aggregates via Global IP-WAN only. No duplicate prefixes on both paths.
• Confirm Metro-C FCR: Metro-A and Metro-B aggregates only via Global IP-WAN. No site-specific EMEA prefixes visible at Metro-C.
• Confirm no infrastructure peering ranges or loopback ranges visible in any IP-WAN Active Routes.

5 Validation Summary

All tests were performed in the lab environment described in Section 3. Route filter policies were applied before validation began. Detailed test evidence — pre-filter and post-filter Active Routes tables, NE router BGP outputs, and traceroute screenshots — is provided in the companion “Detailed Test and Validation — Global WAN Backbone: FCR + IP-WAN” Detailed Test and Validation — Global WAN Backbone: FCR + IP-WAN

5.1 Test Summary

📝 Test 15 was performed by deleting VC-Regional-B — the Virtual Connection between FCR-B and the Regional IP-WAN service. This is the only mechanism available to simulate Regional IP-WAN failure from the customer side. VC-Regional-B was re-provisioned after the test and Active Routes returned to the baseline post-policy state.

5.5 Key Results

• FCR route filter policies successfully enforce strict prefix separation between Regional and Global IP-WAN. ECMP is completely eliminated across all three FCRs after policies are applied — confirmed by comparing pre-policy and post-policy Active Routes tables.
• Intra-EMEA traffic (Metro-A ↔ Metro-B) correctly uses Regional IP-WAN for all site-specific destinations — confirmed by traceroute showing Regional IP-WAN next-hop addresses in the 206.126.236.0/22 range.
• Inter-regional traffic (EMEA ↔ Metro-C) correctly uses Global IP-WAN — confirmed by traceroute showing Global IP-WAN next-hop addresses in the 142.215.8.0/22 range.
• The universal design rule is confirmed across all three FCRs: every FCR advertises only the aggregate over Global IP-WAN and only site-specific prefixes over Regional IP-WAN — with no exceptions. Metro-C follows the same rule despite having no Regional IP-WAN.
• Metro-C correctly receives only EMEA aggregates via Global IP-WAN — no site-specific EMEA prefixes are visible at Metro-C. Symmetrically, EMEA FCRs receive only the Metro-C aggregate via Global IP-WAN — no Metro-C site-specific prefixes are visible at EMEA FCRs.
• Two distinct Regional IP-WAN entry point addresses are observed: 206.126.237.1 (Metro-A entry) and 206.126.237.7 (Metro-B entry) — both within the 206.126.236.0/22 Regional IP-WAN active range. This reflects the per-metro entry point architecture of the Regional IP-WAN service.
• Infrastructure peering ranges and lab loopback ranges are completely absent from all IP-WAN Active Routes after filter policies are applied — confirmed in all three post-policy Active Routes tables.
• When Regional IP-WAN is unavailable, EMEA traffic automatically falls back to Global IP-WAN using the aggregate route — confirmed by traceroute showing hop 2 changing from 206.126.237.1 (Regional IP-WAN) to 142.215.9.1 (Global IP-WAN) after VC-Regional-B was deleted. The destination remained reachable throughout with no manual intervention.

6 Glossary

7 Appendix

A: References

• Equinix FCR Route Filter Policy documentation — Network Policies | Equinix Product Documentation
• Equinix FCR IP-WAN Create — Create an IP-WAN | Equinix Product Documentation
• Equinix FCR IP-WAN Connect — Connect to an IP-WAN | Equinix Product Documentation
• Equinix FCR BGP Configuration — Configuring BGP | Equinix Product Documentation
• Companion EVD: FCR Routing Behaviour — Local-First Design Intent and IP-WAN Failover (internal reference).
• Companion Document: Detailed Test and Validation — Global WAN Backbone: FCR + IP-WAN. Detailed Test and Validation — Global WAN Backbone: FCR + IP-WAN.
• Companion Document: FCR Routing Behaviour: Local-First Design Intent and IP-WAN Failover. FCR Routing Behaviour: Local-First Design Intent and IP-WAN Failover