From Routed Attachments to a Stretched VLAN
The final scenario in the ITNOG10 Segment Routing workshop combines EVPN services with an SR-MPLS core. It reuses the lab topology from the earlier services-focused scenarios, but replaces two PE-to-host subnets with a stretched VLAN.
That change shifts the operational question. Engineers are no longer validating only separate routed attachments; they must also confirm that the Ethernet service is represented consistently at both provider edges and carried correctly across the underlying core.
At a high level, the architecture separates two concerns:
EVPN represents and distributes service information between the participating edge devices.
SR-MPLS provides transport across the core.
The stretched VLAN presents the Ethernet service at geographically or logically separated attachment points.
This separation is useful, but it creates multiple layers that must be examined together during deployment and troubleshooting.
What Engineers Need to Validate
A successful validation should correlate intended topology, stored configuration, and current operational state. Looking at only one layer can hide a mismatch elsewhere.
1. Physical and logical topology
Start by identifying the complete service path:
Host-facing attachment points
Provider-edge devices participating in the EVPN service
Core nodes carrying SR-MPLS transport
Links and interfaces connecting each layer
The VLAN extended between the edge locations
The topology view should distinguish the customer-facing Ethernet service from the transport path beneath it. This helps engineers determine whether a fault belongs to the access layer, the EVPN service, or the SR-MPLS core.
2. Configuration consistency
Configuration reviews should focus on whether both edges express the same intended service, while accounting for vendor-specific syntax. Useful checks include:
VLAN and interface assignments at each attachment point
EVPN-related service configuration on participating edge devices
Routing and MPLS configuration required by the core design
Neighboring relationships and device identifiers referenced by the service
Unexpected differences from the last known-good configuration
In a multi-vendor network, equivalent intent can appear very different in the command-line configuration. Validation therefore needs to compare both raw configuration and normalized service intent.
3. Operational state
A correct configuration does not guarantee a working service. Engineers should also inspect live state at every layer:
Host-facing interface and VLAN state
EVPN control-plane state on the edge devices
Reachability between participating nodes
MPLS transport state through the core
Forwarding information associated with the stretched Ethernet service
The objective is to follow the dependency chain from the attachment circuit to the service control plane and then through the core transport.
A Practical Multi-Vendor Validation Workflow
A repeatable workflow reduces the risk of treating each device as an isolated troubleshooting exercise.
Map the intended service. Record the participating hosts, attachment interfaces, VLAN, provider edges, and expected path across the core.
Capture current configurations. Preserve the relevant device configurations before making changes.
Compare both edge definitions. Confirm that the stretched service is represented consistently, even when vendors use different syntax.
Validate the core independently. Establish that SR-MPLS transport is operational before attributing a failure to EVPN.
Inspect EVPN state. Verify that the participating edges have the operational information expected for the service.
Test from the attachment points. Validate the service from the host-facing side rather than relying exclusively on core checks.
Correlate failures with change history. If the service previously worked, identify configuration changes on every device in its dependency path.
The key operational principle is correlation: topology, configuration, and live state should describe the same end-to-end service.
How ConnectMyAssets Helps
ConnectMyAssets provides an on-prem, vendor-agnostic way to manage the infrastructure supporting an EVPN service over an SR-MPLS core.
The Topology module helps map edge devices, core nodes, interfaces, and service dependencies across vendors.
Dynamic CMDB keeps asset and relationship information aligned with the managed environment.
Backup & History stores configuration versions, highlights changes, and provides one-click rollback when a deployment introduces an issue.
Automation & ZTP supports repeatable collection and validation workflows without requiring engineers to handle every platform manually.
The Compliance Engine can check device configurations against internal policies and frameworks such as NIS2, ISO 27001, PCI, CISA, and NIST.
AI Insights, running locally, can assist with analyzing infrastructure information while keeping operations on premises.
For a multi-vendor EVPN deployment, the practical benefit is a common operational record. Engineers can relate the service topology to configuration history and asset state instead of switching between disconnected device views.
Closing Perspective
EVPN over an SR-MPLS core demonstrates how service and transport layers can be combined while remaining operationally distinct. The stretched-VLAN scenario from the ITNOG10 workshop is also a useful reminder that end-to-end validation must cross those boundaries.
Engineers should verify the attachment layer, EVPN information, and SR-MPLS transport as parts of one service dependency chain. In multi-vendor environments, normalized topology, configuration history, and repeatable state collection are essential for making that validation manageable.
Source: ipSpace.net
