What “BGP-Free” Actually Means
The idea of a BGP-free core has existed for decades. In this architecture, the routers at the network edge—PE routers in MPLS terminology—exchange and retain BGP routes. The core, made up of P routers, does not carry those BGP routes.
That distinction changes how traffic crosses the network. A core router cannot rely on a customer IP address to make its forwarding decision. Instead, an edge router must know how to reach the relevant BGP next hop through an encapsulation mechanism that makes the original IP packet opaque to the core.
SRv6 is the encapsulation context examined by the source article. The key architectural objective remains straightforward:
Keep customer routing knowledge at the edge while giving the core enough information to transport encapsulated traffic between edge routers.
“BGP-free” therefore describes the core’s relationship with BGP routes. It should not be interpreted as an absence of routing, topology knowledge, or operational state inside the core.
Why the Model Can Simplify a Multi-Vendor Core
A design based on clear P and PE roles can reduce the amount of customer-routing information that core devices must hold. It also gives operators a useful vendor-neutral boundary: edge routers manage BGP reachability, while core routers transport traffic that has been made opaque through encapsulation.
For a multi-vendor environment, that boundary is more useful when expressed as design invariants rather than as one vendor’s command syntax:
BGP routes remain on the intended edge routers.
Every required BGP next hop is reachable through the encapsulation design.
Core forwarding does not depend on inspecting customer IP addresses.
The same behavior is preserved across normal and failure paths.
This approach does not eliminate interoperability work. It makes the expected outcome clearer, allowing each implementation to be assessed against the same architecture.
Validate the Topology First
Configuration review alone cannot establish whether a BGP-free core will operate as intended. Operators first need an accurate topology showing which devices are edges, which belong to the core, and how traffic can move between them.
Validation should cover:
The explicit classification of every router as an edge or core node.
The paths connecting all edge routers that exchange BGP reachability.
Alternate paths that may be used after a link or node failure.
Any unexpected device that would require customer-route knowledge to forward traffic.
Differences between the documented design and the deployed links or roles.
The failure topology matters as much as the steady-state topology. A primary path might preserve the BGP-free boundary while an alternate path unintentionally crosses a device with a different role or configuration.
Check Routing and Encapsulation Policies
The next step is to verify that policy matches the architecture. The central question is not simply whether BGP sessions are established, but whether BGP information is confined to the intended edge layer.
Operators should check that:
BGP routes are exchanged only by the routers designated to perform the edge function.
Route policies produce the intended next-hop relationships.
Each edge router can resolve the required BGP next hops through the chosen encapsulation mechanism.
Policy changes do not introduce customer-route dependencies into the core.
Equivalent intent is implemented across the different vendor platforms.
In a multi-vendor network, compare outcomes rather than assuming similarly named features produce identical behavior. The desired state should be documented independently from device-specific configuration.
Prove the Forwarding State
A correct-looking control-plane configuration is not sufficient. Operators must verify the resulting forwarding behavior.
Useful checks include:
Confirming that ingress edge routers apply the expected encapsulation.
Tracing traffic across the intended core path.
Verifying that core routers forward without using the customer IP address.
Confirming that the correct egress edge router receives and processes the traffic.
Repeating the checks during representative link and node failures.
Comparing observed forwarding paths with the approved topology.
These tests should include more than basic reachability. They should demonstrate that the architectural separation between edge routing and core transport remains intact as conditions change.
How ConnectMyAssets Helps
ConnectMyAssets provides an on-prem, vendor-agnostic operational layer for documenting and controlling the infrastructure around this design.
Dynamic CMDB and Topology record P and PE roles, device relationships, and physical or logical paths, helping teams compare the intended architecture with the deployed network.
Backup & History preserves configuration versions and supports one-click rollback when an edge policy or core configuration change produces an unwanted result.
Compliance Engine can assess configurations against approved design rules, including the separation of edge and core responsibilities and the organization’s NIS2, ISO 27001, PCI, CISA, or NIST controls.
Automation supports consistent, reviewed changes across multiple vendors instead of relying on unrelated manual procedures for each platform.
Credential Vault and SSH Bastion provide controlled access when collecting configuration and operational evidence from routers.
Per-asset CVE Tracking and End-of-Life Tracking help operators include software exposure and platform lifecycle in decisions about devices carrying critical edge or core roles.
AI Insights, running locally, can assist with reviewing infrastructure information without moving that operational data to a cloud service.
ConnectMyAssets does not replace packet-level testing or protocol validation. It helps ensure that topology, configuration history, compliance evidence, asset risk, and change execution remain connected to the same documented design.
Source: ipSpace.net
