On this page
Key points
- Document both directionsFiltered delivery and the return path must satisfy the chosen routing and protection model.
- Use the delivered MTUEncapsulation and backup paths can require different values.
- Prove forwarding and recoveryAn established routing session alone does not prove useful traffic reaches the service.
Write the interface contract before activation
A handoff is the boundary where one team delivers traffic and another becomes responsible for it. Record the public tunnel endpoints or physical interface, inner addressing, VLAN where applicable, address families, routing peers, authorized prefixes and MTU. Keep the normal path, protected path and return path on the same diagram so that neither team assumes the other owns a missing step.
Name the owners of the interface, BGP policy, filtering rules and destination service. Agree on the change window, the evidence each side can provide and a recovery contact. The delivery record should be precise enough to distinguish a failed outer tunnel path, an incorrect inner route and an application that is not responding.
| Item | Record explicitly | Check at acceptance |
|---|---|---|
| Encapsulation or physical access | Actual endpoint, protocol, interface or VLAN and address family. | The selected path exists and is reachable through the intended underlay. |
| Inner routing | Local and peer addresses, ASN, permitted announcements and received routes. | Expected prefixes and return routes are usable, not merely configured. |
| Packet size | Delivered MTU for each path and the expected discovery behavior. | Both small and larger legitimate exchanges succeed. |
| Recovery | Preferred path, backup policy, convergence criteria and rollback owner. | Traffic uses a working path after the agreed failure and returns as intended. |
Treat MTU as a property of the complete path
Encapsulation consumes part of the outer path’s packet budget. In a simple example, a 1,500-byte outer IPv4 path with a 20-byte outer IPv4 header and a basic 4-byte GRE header leaves 1,476 bytes for the inner packet. GRE options, another tunnel layer or a lower underlay MTU can change the result. This calculation is not a universal value to copy into every GRE interface.
Use the MTU stated in the actual delivery record for each tunnel. A primary and backup path can require different settings; a delivered value of 1,452 on one path must not be replaced with 1,476 merely because another path uses it. Verify which packet layer an interface or packet capture reports before interpreting a size.
Path MTU discovery and transport behavior also matter. A small ping succeeding does not establish that larger TCP or UDP exchanges will work. Likewise, TCP MSS adjustment only addresses TCP segment sizing; it does not repair every UDP or encapsulation problem. Preserve the control messages needed by the chosen discovery mechanism under the agreed security policy.
Exercise real small and large exchanges
Choose tests that match the service. Check connection establishment and a useful application action, then a larger transfer or representative datagram exchange. Repeat in the directions and address families covered by delivery. Record the sizes, observation points, timeout behavior and counters rather than relying on a single “reachable” result.
TCP throughput can be affected by round-trip time, loss, receiver limits and other transport behavior as well as the available link. The goal is to identify a problem, not to attribute every slow transfer to filtering. Use the application baseline and the transport measurements together, and keep resource-saturating load tests in an authorized isolated environment.
Distinguish BGP state from usable forwarding
A BGP session can be Established while the required routes are absent, rejected by policy or less preferred than another route. Verify what each peer sends and receives, the accepted prefixes, selected next hops and the resulting forwarding entries. Where a customer requires a default route, establish explicitly whether it is delivered through BGP or configured by another agreed method.
Test the return direction too. A stale static route or an incompatible stateful path can make the backup look broken even when its BGP session is healthy. Also check route specificity: a less-specific backup cannot replace traffic still attracted by a more-specific route that remains installed elsewhere. Investigate the actual route selection before changing preferences.
Define the failure you intend the backup to cover
Keep an agreed standby tunnel and routing session enabled when the design expects them to provide automatic recovery. Normal traffic preference and backup eligibility are separate questions. Both ends need compatible policy, and the existence of a backup session does not by itself document the preference applied to received routes.
Exercise the agreed failure scenario with the teams responsible for production: session loss, tunnel path loss and router loss are not identical. Two tunnels on one router do not demonstrate router redundancy. Record forwarding loss, application behavior, route selection and restoration; do not promise a lossless transition from a test that only showed reachability.
Correlate both ends and the recovery period
Use a common observation window and name every counter’s direction. Compare the sender, tunnel or handoff interface, receiving interface, filter and destination application. Record when routing changed and when useful service resumed. A packet observed leaving one component does not prove arrival at the next, so retain enough evidence to locate the gap.
After restoring the preferred path, check that the intended route becomes selected, the backup remains available and established applications behave as required. Verify monitoring as well: the collector may have recovered at a different time from forwarding. Keep the final configuration and acceptance results with the delivery record.
A compact delivery and acceptance record
These are acceptance tasks, not permission to interrupt a live service without coordination. Keep intrusive tests separate from routine checks and define the stop conditions beforehand. The useful result is a reproducible record of the actual handoff, not a generic claim that the network is fully validated.
Identify the service
Record the interfaces, owners, authorized prefixes and versioned configuration.
Verify normal forwarding
Check received routes, selected next hops, both directions and application success.
Verify packet sizing
Use each path’s delivered MTU and representative small and large exchanges.
Record failure and restoration
Capture the agreed failure, convergence observations, remaining limits and rollback outcome.
Handoff questions
Can I use one GRE MTU for every tunnel?
No. Use the delivered value for each complete path. Additional encapsulation or a different underlay can change the available inner MTU.
Does an Established BGP session prove the backup works?
No. Check accepted and selected routes, forwarding, the return direction and application behavior under the agreed failure scenario.
What should the final acceptance report contain?
The actual configuration and owners, normal-service results, packet-size checks, observed failure and recovery behavior, and explicit untested conditions.
