When preparing a data center refresh or moving workloads onto new infrastructure, much of the testing naturally focuses on whether systems can reach each other and how quickly the network responds when something moves. Those checks are important, although they can leave a separate question unanswered, which is whether the system now using a particular network address is actually the one that should be using it.
In an EVPN network, information about an endpoint’s MAC address can be shared across the fabric so that traffic reaches the location where that address has been learned. If the original claim is wrong, the network can distribute that information consistently and still end up directing traffic to the wrong place, which makes it worth looking beyond successful connectivity when deciding whether a migration is ready to proceed.
Understanding where the ownership decision is made
An APNIC guest article by Broadcom technologist Sabina Anja looks at how a spoofed MAC address learned locally can propagate through EVPN Type-2 routes and redirect traffic within the fabric. The article discusses how route information can be considered alongside DHCP, authentication, IP address management and access-port records, although it is an architectural analysis rather than a measure of how frequently these incidents occur or a comparison of products.
For a delivery team, this raises the question of how to establish that an address appearing in a new location is the result of an approved change. Our recommendation is to work through that during design and acceptance, while the network, platform and security teams have an opportunity to agree on the evidence they will need and who is responsible for acting on it.
The available controls will depend on the implementation, including where address bindings can be enforced and which port, authentication, ARP or Neighbor Discovery inspection controls it supports. Their behavior needs to be demonstrated in the proposed environment, particularly where legitimate workload movement has to coexist with critical systems whose identities are expected to remain fixed.
Knowing what a legitimate change should look like
A workload migration, an infrastructure replacement and a recovery exercise may all involve changes that look different from the network’s perspective, even though each has been authorized. Before deciding what should trigger an alarm, the team needs to understand which identities are allowed to move, where they can move to and what change records or platform events should accompany the move.
This gives the person reviewing an event something to compare it against, rather than leaving them to decide whether an address change is acceptable with little information about what the platform team was doing at the time. Systems that should remain in a fixed location also need a clear replacement process, so that a legitimate recovery does not become difficult simply because the expected exception was never considered.
A move count on its own provides limited context, which is why we would want the design team to explain how its detection conditions fit the workloads being delivered and how it will investigate an exception without unnecessarily interrupting an approved migration.
Making the supporting records usable
The evidence needs to connect what the network has observed with the endpoint and location that are expected, including the MAC and IP information, previous and current locations, relevant times and the records used to assess whether the change is legitimate. This can be kept in a relatively small investigation record, provided that the teams agree which system is authoritative for each part of it.
There are practical limitations to work through here, since DHCP information will not cover every system with a static address, an inventory record may be out of date and authentication evidence may establish less than people assume about the addresses associated with a device. Those gaps need an owner before the environment is accepted, so that the engineer handling a cutover is not also trying to work out how an application identifier relates to an access port or who can confirm that the inventory is current.
Having records available is only useful if the people making the decision can access them and understand what they establish, which makes this as much a handover and responsibility issue as a question of which technical controls have been enabled.
Responding without creating a wider problem
When there is a suspected ownership conflict, the response needs to account for the risk of leaving an unauthorized attachment active as well as the possibility of interrupting a legitimate service. Isolating an individual endpoint may have a very different impact from shutting down an access port that supports several workloads, so the available response and its boundaries should be understood before the team has to use them.
The plan should identify the evidence required, who can authorize containment and how the service will be restored and checked afterward. If part of that response is automated, the acceptance testing should demonstrate what triggers it, which systems it affects and how recovery works, with a route for escalation when the evidence is incomplete.
Testing the decision before cutover
One proposed acceptance exercise would start with an approved move of a designated test workload, checking that service continues, the change can be understood from the records and no inappropriate containment occurs. A separate, controlled test of a conflicting identity claim in an isolated test environment would then check whether the relevant evidence reaches the decision-maker and whether the agreed response stays within its intended scope.
These are suggested test scenarios, rather than results from an Ahead engagement, and they need to be adapted to the controls and enforcement limits of the selected implementation. The outcome should include recovery verification and any unresolved exceptions with their owners, so that the exercise establishes more than whether an alert appeared.
Carrying the decisions into handover
At Ahead, our work across infrastructure architecture, design, implementation and cutover planning brings these decisions into the delivery process, where the technical design needs to be supported by evidence and clear responsibilities. For an EVPN refresh, making address ownership part of acceptance gives the people approving the change a clearer understanding of what an expected move looks like, how a conflicting claim will be assessed and who can authorize the response before those decisions have to be made in production.