Network Traffic Engineering: Optimising Paths, Performance and Capacity
Network traffic engineering is the practice of analysing, influencing and controlling how traffic moves through a network to meet defined performance, capacity, availability and policy objectives. Rather than relying exclusively on the paths selected by conventional routing, engineers can introduce additional controls to make better use of available network resources.
A routing table may identify a valid path to a destination, but that path is not necessarily the best choice for every traffic flow. A heavily utilised link, increasing latency, packet loss or an application with strict service requirements can make an alternative path more appropriate. Traffic engineering provides the methods to understand these conditions and influence forwarding decisions where the network design permits.
How can we move the right traffic across the right path, at the right time, while respecting routing policy, available capacity, resilience and security requirements?
Measure the network
Monitor bandwidth utilisation, latency, jitter, packet loss and link health to identify congestion, performance changes and unused capacity.
Control traffic behaviour
Apply routing metrics, QoS policies, load balancing or explicit paths to influence how different traffic classes use network resources.
Choose suitable paths
Use the capabilities of technologies such as OSPF, IS-IS, BGP, MPLS Traffic Engineering and SDN to meet defined forwarding objectives.
Validate the outcome
Confirm that the selected path improves the intended metric without creating new bottlenecks or undermining redundancy and policy.
These techniques operate at different layers and solve different problems. QoS manages the treatment of traffic; routing protocols determine reachability and route preference; MPLS Traffic Engineering can establish constrained label-switched paths; and SDN can provide centralised visibility and programmable forwarding. Effective designs combine these capabilities where they add measurable value.
Network Traffic Engineering: Optimising Paths, Performance and Capacity
Network traffic engineering is the practice of measuring network behaviour and influencing how traffic uses available paths, links and services. It helps network engineers address congestion, make better use of capacity, improve application performance and design for failure.
From QoS and routing policy to MPLS traffic engineering, SDN, cloud networking and resilient WANs, this guide explores the mechanisms that shape traffic flow—and the important differences between selecting a route, managing a queue and measuring real application performance.
Traffic Measurement, Congestion and Quality of Service
Effective traffic engineering starts with evidence. Before changing routing policies, adjusting link costs or introducing explicit paths, engineers need to understand how traffic behaves, where congestion develops and which applications are affected. Measurement provides the foundation for making informed decisions rather than simply moving traffic from one link to another.
A network can have complete reachability and still deliver poor application performance. Routing protocols may select valid paths while a critical interface is saturated, queues are filling, packets are being discarded or delay-sensitive traffic is competing with large data transfers. Traffic engineering connects operational measurements with decisions about capacity, forwarding and traffic treatment.
1.1 The measurements that matter
No single metric explains every performance problem. Engineers combine interface statistics, active probes, flow records, queue counters and application telemetry to establish a more complete picture of network behaviour.
A link may show acceptable average utilisation while users experience intermittent delay or loss. Correlate interface counters with end-to-end measurements, queue statistics and application symptoms before deciding where to intervene.
1.2 How congestion develops
Congestion occurs when traffic demands exceed the capacity available at a particular point, either temporarily or for a sustained period. Packets may accumulate in queues, increasing delay. When buffers fill, packets are dropped. Transport protocols may then retransmit data or reduce their sending rate, potentially reducing useful throughput further.
Congestion is not always caused by insufficient total network capacity. Traffic may be unevenly distributed, a preferred route may become overloaded, or several high-volume flows may converge on the same interface. A redundant path can remain underused even while another path is congested.
| Observed symptom | Possible explanation | Useful investigation |
|---|---|---|
| High utilisation over time | Demand is approaching or exceeding available capacity. | Review interface rates, traffic trends and capacity forecasts. |
| Latency rises during busy periods | Packets may be waiting in queues along the path. | Compare latency with utilisation and queue statistics. |
| Loss on a particular interface | Queue drops, physical errors, policing or another forwarding issue. | Inspect drop counters, error counters and policy statistics. |
| One path is busy while another is idle | Routing policy or flow-hashing behaviour may limit distribution. | Check route selection, ECMP eligibility and per-flow traffic patterns. |
1.3 Quality of Service: managing competing traffic
Quality of Service (QoS) provides mechanisms for classifying traffic and applying different forwarding treatments. It does not create additional bandwidth. Instead, it helps determine how available resources are shared when traffic competes for them.
A typical QoS design classifies packets into traffic classes, marks them where appropriate, and applies queuing, scheduling, shaping or policing policies at relevant points in the network. The design must be consistent across the intended path if the required treatment is to be maintained end to end.
Several mechanisms are frequently used together, but they serve different purposes:
- Classification and marking: identify traffic and communicate its intended treatment, commonly using fields such as DSCP.
- Queuing and scheduling: control how packets from different classes share an interface during contention.
- Traffic shaping: smooths or buffers traffic to enforce a configured transmission rate over time.
- Policing: checks traffic against a rate or burst profile and may drop or remark packets that exceed it.
- Admission and capacity control: helps prevent the network from accepting more traffic than the intended service can support.
For example, a voice class may receive low-latency treatment while bulk file transfers use remaining capacity. The voice queue still needs appropriate rate limits and capacity planning: an incorrectly configured priority queue can starve other traffic, and QoS cannot overcome a sustained shortage of physical bandwidth.
1.4 From monitoring to traffic engineering
Measurement and QoS are closely related to traffic engineering, but they are not the same thing. QoS primarily controls how packets are treated at forwarding points. Traffic engineering can go further by influencing which paths traffic uses, how demand is distributed across the topology, and whether additional capacity or protection paths are required.
If monitoring identifies a congested link, the appropriate response depends on the cause. Engineers might tune routing metrics, adjust traffic distribution, use policy-based routing, establish an MPLS Traffic Engineering path, or apply SDN-based control. If the problem is a physical fault or a queue configuration error, changing the route alone may not solve it.
Reliable traffic engineering follows a measurement-led cycle: observe performance, identify the bottleneck, choose an intervention that matches the problem, and verify the result. These measurements become the evidence base for the routing and path-selection techniques explored in the next section.
Traffic Measurement & QoS Workbench
Change offered traffic, available capacity and queueing policy. Run the simulation to compare a simplified traffic-engineering outcome.
1. Traffic and capacity
2. Select a QoS policy
Simulation results
Within capacityRouting-Based Traffic Engineering: OSPF, IS-IS, BGP and ECMP
Routing-based traffic engineering uses the control plane to influence where packets travel through a network. Rather than treating the routing table as a fixed result, engineers examine path costs, available alternatives, traffic distribution and routing policy to determine whether traffic is using the topology effectively.
Traditional routing protocols are designed primarily to establish reachability and select routes according to their defined decision processes. Traffic engineering builds on those mechanisms by adjusting metrics, using multiple eligible paths, applying routing policy or introducing tools that make path selection more deliberate.
A routing protocol may select a path because it has the lowest configured cost or wins a policy decision. That does not automatically mean the path has the lowest real-time latency, the most spare bandwidth or the least packet loss.
2.1 Interior routing: OSPF and IS-IS
Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) are link-state routing protocols commonly used within an autonomous system. Routers distribute topology information, calculate paths and install eligible routes according to the protocol's rules and the configured metrics.
OSPF calculates shortest paths using configured interface costs. Engineers can tune costs to influence path preference, provided the change is consistent with the wider design and does not create unintended traffic shifts.
IS-IS distributes link-state information and calculates routes using metrics. It is widely used in service-provider and large routed networks, including as an underlay for MPLS and Segment Routing designs.
Metric tuning is useful, but it is not a complete traffic-engineering system by itself. Changing a link cost can redirect many prefixes at once, potentially moving congestion elsewhere. The effect should be assessed across the topology, not just on the router where the change is made.
2.2 Equal-Cost Multipath: using multiple eligible routes
Equal-Cost Multipath (ECMP) allows a router to install multiple next hops for a destination when the routing system considers those paths equal under the applicable selection rules. Forwarding hardware or software then distributes traffic across the eligible next hops, often using a hash based on flow attributes.
ECMP can improve link utilisation and provide path redundancy, but it does not guarantee an even split of bytes or packets. A small number of large flows, unequal link capacities, hash collisions or different traffic patterns can leave one path busier than another. A change in the next-hop set may also remap flows, depending on the implementation.
Verify the actual distribution with per-interface counters or flow telemetry. Seeing two next hops in a routing table confirms multipath eligibility; it does not prove that traffic is balanced evenly across both links.
2.3 BGP traffic engineering: influence inter-domain traffic
Border Gateway Protocol (BGP) exchanges reachability information between autonomous systems and can also support routing policy within a network. BGP traffic engineering generally involves influencing which routes are selected or how traffic enters and leaves a network, rather than directly measuring every path's live performance.
| Technique | Typical purpose | Key limitation |
|---|---|---|
| Local preference | Influence outbound route selection within an AS. | Applies to the local routing policy domain; it does not directly command remote networks. |
| AS-path prepending | Make an advertised route appear less attractive to some remote networks. | Remote networks apply their own policies, so the result is not guaranteed. |
| Selective prefix advertisement | Influence which destinations are reachable through particular upstreams. | Requires careful prefix, policy and reachability planning. |
| Communities | Signal policy requests to a provider or other BGP neighbour. | The receiving network determines which communities it supports and honours. |
BGP policy can influence traffic direction, but it should not be confused with a mechanism that automatically picks the lowest-latency path. Even when two providers offer different performance, the resulting route depends on BGP attributes, import and export policies, route availability and the decisions of other networks.
2.4 Policy-Based Routing: steer traffic by policy
Policy-Based Routing (PBR) allows forwarding decisions to be influenced by criteria beyond the destination-based routing lookup alone. Depending on the platform, a policy may match source addresses, protocol, ports, ingress interface or other packet attributes and then select a configured next hop or forwarding action.
- Application-aware separation: send a defined class of traffic through a designated gateway or service path.
- WAN selection: steer selected traffic toward a preferred circuit, subject to the platform's policy and tracking capabilities.
- Service insertion: direct matching traffic through a firewall, inspection device or other network service.
- Operational safeguards: account for unavailable next hops, asymmetric routing, return-path requirements and policy interactions.
PBR is powerful because it can provide fine-grained control, but overly broad rules can bypass intended routing behaviour or create asymmetric paths. Policies should be narrowly scoped, observable and tested against failure conditions.
2.5 Performance-based optimisation and PfR
Some network designs add a monitoring and policy layer that evaluates WAN-path performance and influences how traffic is distributed. Cisco Performance Routing (PfR), also known in later product generations as part of the Intelligent WAN family, is one example of this approach. Depending on platform and configuration, such systems can use traffic classes, reachability, delay, loss or utilisation-related information to guide path selection.
The key idea is to connect measurements to a controlled routing decision. Instead of assuming that a statically preferred path is always suitable, the system can evaluate whether traffic meets defined performance objectives and apply an allowed alternative when policy conditions are met.
| Approach | Primary control | Best understood as |
|---|---|---|
| OSPF / IS-IS metric tuning | Interior path cost | Influencing shortest-path calculations. |
| ECMP | Multiple equal-cost next hops | Sharing eligible flows across paths. |
| BGP policy | Route preference and advertisement | Influencing route selection and traffic direction. |
| PBR | Packet-matching rules | Steering selected traffic using policy. |
| Performance-based WAN control | Measured conditions plus policy | Adapting path choice to defined objectives where supported. |
2.6 A practical routing-engineering workflow
Routing changes should be treated as controlled engineering interventions. Establish a baseline, define the desired outcome and check how the change affects both the intended traffic and other traffic sharing the same infrastructure.
- Identify the affected prefixes, applications, ingress points and egress links.
- Determine whether the problem is route selection, flow distribution, congestion, QoS treatment or a physical fault.
- Select the narrowest suitable mechanism: metric tuning, ECMP, BGP policy, PBR or a performance-aware control system.
- Check convergence, redundancy, route-policy interactions and possible asymmetric forwarding.
- Measure the outcome and retain a rollback plan if performance or reachability degrades.
Routing-based traffic engineering offers several levels of control, from adjusting link-state metrics to distributing flows with ECMP, influencing BGP route policy and steering selected packets with PBR. The correct choice depends on what needs to be controlled. When traffic requires a deliberately constrained path rather than ordinary route preference, MPLS Traffic Engineering introduces another set of tools.
Routing-Based Traffic Engineering Lab
Explore how routing metrics, BGP policy, equal-cost paths and traffic classification can influence packet forwarding.
1. Configure the routing scenario
2. Selected forwarding path
Illustrative network: R1 forwards traffic towards destination R4 over one of two paths.
MPLS Traffic Engineering: RSVP-TE, Explicit Paths and Fast Reroute
Multiprotocol Label Switching (MPLS) Traffic Engineering gives network operators greater control over how selected traffic crosses a routed core. Instead of relying exclusively on each router's ordinary shortest-path forwarding decision, an engineered path can be established to follow a planned route and, where supported, meet configured resource constraints.
This is particularly useful in service-provider networks, enterprise WANs and large IP backbones where several links may be available between the same endpoints. A shortest path can be perfectly valid yet concentrate traffic on a small number of links, leaving other capacity underused. Traffic engineering provides tools for controlling that distribution.
An IGP such as OSPF or IS-IS supplies topology and reachability information. MPLS Traffic Engineering can use that information, together with engineering constraints and signalling, to establish a specific label-switched path through the network.
3.1 Understanding the MPLS forwarding model
In an MPLS network, packets are forwarded using labels attached to packets or frames. A Label Edge Router (LER) commonly classifies incoming traffic and pushes an MPLS label at the ingress edge. Intermediate Label Switch Routers (LSRs) forward traffic by swapping labels. At or near the egress, the label is removed and the packet continues toward its destination.
The ingress router identifies the traffic or forwarding equivalence class and applies the appropriate label stack for the selected forwarding path.
Core routers use label-forwarding entries to send traffic toward the next hop without requiring a full IP route lookup for every transit packet.
The egress side processes the label stack and forwards the traffic toward its destination according to the service design.
Routing and label-distribution mechanisms provide the information needed to build the forwarding entries used by the data plane.
MPLS forwarding alone does not guarantee that traffic follows an optimised path. Conventional MPLS label-switched paths may follow the IGP's shortest-path calculations. MPLS Traffic Engineering adds mechanisms for selecting and signalling paths that may differ from that default.
3.2 What is an MPLS Traffic Engineering tunnel?
An MPLS-TE tunnel represents a logical forwarding path from an ingress router toward an egress router. The tunnel can be associated with a planned route, resource requirements and protection behaviour. Traffic is then mapped onto the tunnel using the routing and forwarding mechanisms supported by the implementation.
The physical topology remains unchanged. What changes is the selected route through that topology and the forwarding state used to carry the traffic. Multiple tunnels can be engineered for different destinations, traffic classes or operational requirements.
3.3 RSVP-TE and constrained path selection
Resource Reservation Protocol Traffic Engineering (RSVP-TE) is a signalling mechanism historically used to establish MPLS traffic-engineered label-switched paths. The ingress router determines a candidate path using available topology and constraint information, then uses RSVP signalling to request establishment along that path.
Intermediate routers participate in signalling and maintain the required path state. Depending on the configuration and network capabilities, a path may include explicit hops, bandwidth requirements, administrative constraints and protection preferences.
| Engineering input | What it helps control | Design consideration |
|---|---|---|
| Explicit route | Constrains the path to specified hops or route segments. | Explicit hops must remain reachable and compatible with the intended design. |
| Bandwidth requirement | Requests that the path satisfy supported reservation constraints. | Reservations depend on configured link attributes and admission-control state; they do not create physical capacity. |
| Administrative constraints | Include or exclude links based on configured attributes. | Link attributes must be maintained accurately and consistently. |
| Path optimisation | Select a feasible candidate according to the configured objective. | A path that is optimal under configured metrics may not be optimal for every real-time application metric. |
RSVP-TE can reserve resources according to the network's configured reservation model. This is different from simply assigning a high QoS priority to packets. A reservation does not automatically guarantee application performance under every failure or congestion condition, and its effectiveness depends on correct capacity planning and operational configuration.
3.4 Why engineered paths can improve utilisation
Imagine a core network with two possible routes between an ingress and an egress router. The IGP's preferred route crosses a heavily used link, while an alternative route has spare capacity but more hops. A traffic-engineered tunnel can be configured to use the alternative when the path satisfies the intended constraints.
The objective is not always to choose the path with the fewest hops. Depending on the service, the objective might be to avoid a constrained link, satisfy a bandwidth requirement, keep traffic away from a particular administrative domain or provide a path that is independent of the primary route.
A longer route can sometimes provide better capacity distribution or resilience. However, additional hops can also add delay and operational complexity. Compare the candidate paths against the actual engineering objectives instead of assuming that either the shortest or longest path is inherently better.
3.5 Fast Reroute: protecting traffic against failure
Traffic engineering also addresses what happens when a link or router fails. Without a pre-established protection mechanism, traffic may depend on routing convergence before it can use a new path. Fast Reroute (FRR) mechanisms can provide a locally available backup forwarding action intended to protect traffic while broader recovery takes place.
- Link protection: aims to keep traffic moving when a particular link fails, using an eligible alternate path.
- Node protection: aims to protect against failure of a downstream router where a suitable bypass is available.
- Backup path design: requires an alternate that is genuinely independent of the protected resource where possible.
- Post-failure capacity: the backup must be able to carry the redirected load without creating a new unacceptable bottleneck.
Protection is not the same as eliminating failure. A backup may be unavailable, share a common risk with the primary path or become congested when traffic shifts. Engineers should test failure scenarios and verify both the switchover behaviour and the resulting forwarding path.
3.6 MPLS-TE in modern network design
RSVP-TE remains important in many established networks, but it is not the only approach to traffic-engineered paths. Segment Routing can encode a path using a sequence of segments and may reduce the need to maintain per-tunnel signalling state at every transit router, depending on the architecture. The best choice depends on existing infrastructure, operational skills, interoperability and service requirements.
Whichever technology is used, the engineering process remains similar: define the objective, understand the topology, calculate a feasible path, install forwarding state, monitor performance and plan for failures. Traffic engineering is effective when the control-plane design is supported by accurate telemetry and disciplined operational practice.
MPLS Traffic Engineering extends ordinary routing by allowing selected traffic to use engineered label-switched paths. RSVP-TE can signal explicit or constrained paths and support reservation and protection mechanisms. The next section moves from distributed routing and signalling toward SDN and OpenFlow, where a controller can coordinate forwarding decisions across multiple devices.
MPLS Traffic Engineering Workbench
Build a constrained path, inspect illustrative MPLS labels, and test what happens when a link fails with or without a pre-planned Fast Reroute backup.
1. Configure the LSP
2. Inspect the selected path
SDN, OpenFlow and Centralised Traffic Engineering
Software-Defined Networking (SDN) introduces a programmable approach to network control. Rather than relying exclusively on independent configuration and distributed routing decisions at each device, an SDN architecture can give a controller a broader view of network topology, policy and observed conditions. The controller can use that view to calculate forwarding decisions and coordinate changes across supported devices.
This is valuable for traffic engineering because congestion and inefficient path selection are often network-wide problems. A link may look attractive from the perspective of one router while using it could overload a shared resource elsewhere. A controller with sufficiently current topology and telemetry can evaluate a wider set of alternatives before deploying a policy.
A controller-based design may use OpenFlow, NETCONF, gNMI, APIs or vendor-specific interfaces, depending on the devices and architecture. OpenFlow is one protocol associated with SDN; not every SDN system uses it.
4.1 The main components of an SDN design
Applications describe the intended policy, such as prioritising a traffic class, selecting a path or avoiding a constrained link.
The controller evaluates available topology, policy, device capabilities and telemetry to calculate an appropriate forwarding strategy.
Switches and routers apply supported forwarding rules or configuration changes to implement the selected behaviour.
Counters, events and measurements help the system assess whether the policy is working and whether another action is required.
4.2 How OpenFlow can influence forwarding
OpenFlow defines a protocol through which a controller can communicate with compatible forwarding devices. In an OpenFlow-capable switch, flow tables contain entries that match packet fields and specify actions, such as forwarding a packet to a port, modifying supported fields or sending selected traffic to the controller.
The controller can install, modify or remove flow entries according to its application logic and the capabilities of the switch. This enables explicit control over matching traffic, although the exact match fields, actions, table pipeline and hardware support depend on the OpenFlow version and implementation.
A controller does not magically gain control over every device in the network. Devices must expose a compatible interface, the controller must understand their capabilities, and the design must account for existing forwarding state and other control-plane systems.
4.3 Centralised path selection using network metrics
A traffic-engineering controller can score candidate paths against defined objectives. For example, a policy might reject paths that fail a bandwidth requirement, penalise paths with high observed delay, avoid links with excessive loss, and prefer a suitable path with more available capacity.
A simplified illustrative scoring model could combine normalised measurements:
Path score = (latency weight × latency score) + (loss weight × loss score) + (jitter weight × jitter score) + (utilisation weight × utilisation score).
In this example, lower scores are preferred. Real systems must define normalisation, units, thresholds, missing-data handling and hard constraints carefully.
This model is a conceptual example, not a standard OpenFlow algorithm. A production controller may use graph algorithms, constraint-based path computation, optimisation solvers or simpler policy rules. Measurements can also be stale or noisy, so a robust system avoids changing paths in response to every small fluctuation.
4.4 Example: selecting a path through a diamond topology
Consider a source router connected to two intermediate routers, both of which can reach the same destination. One candidate path has lower latency but is approaching its capacity limit. The other has slightly higher latency but more spare bandwidth. A controller can evaluate both against the application's policy and select a path that meets the required performance and capacity objectives.
| Candidate path | Observed condition | Possible policy result |
|---|---|---|
| Path A | Low latency, but high utilisation. | Prefer it for delay-sensitive traffic only if capacity constraints remain satisfied. |
| Path B | Moderate latency, more spare capacity. | Prefer it for a high-volume flow if it meets the application's delay limit. |
| Backup path | Available alternative with acceptable failure-domain separation. | Retain as a recovery option if the primary path becomes unavailable. |
The right answer depends on the service objective. A video-conferencing flow may be sensitive to delay and jitter, while a large replication flow may place greater emphasis on sustained throughput. The controller should evaluate traffic against explicit requirements rather than applying one universal ranking to every application.
4.5 Centralised control versus distributed routing
Centralised and distributed control are not mutually exclusive. Many networks use a distributed IGP or BGP for basic reachability while a controller provides additional policy, automation or traffic-engineering decisions. This combination can preserve the strengths of established routing while introducing more coordinated control.
| Consideration | Distributed routing | Controller-based control |
|---|---|---|
| Decision scope | Routers make decisions using their protocol state and configured policies. | A controller can evaluate a broader topology view, subject to the data it receives. |
| Convergence and updates | Protocols exchange updates and recalculate routes as network state changes. | Changes depend on controller logic, telemetry, device interfaces and deployment behaviour. |
| Programmability | Typically configured through routing policies and device features. | Can support policy automation and coordinated changes through software. |
| Failure considerations | Distributed protocols can continue operating according to their local state and design. | Requires controller availability, secure communication and a strategy for stale or lost control connectivity. |
| Operational complexity | Familiar protocols, but potentially many separate device configurations. | Centralised automation can simplify operations, but introduces software, integration and policy-validation requirements. |
4.6 Stability, security and safe deployment
A centralised view can improve coordination, but poorly designed control loops can cause traffic to oscillate between paths. If several flows are moved at once, the new path may become congested, triggering another round of changes. Telemetry delay can make the controller react to conditions that no longer exist.
- Use guardrails: define capacity limits, acceptable performance ranges and policy constraints before deploying changes.
- Reduce oscillation: use thresholds, hold-down periods or hysteresis where appropriate to avoid unnecessary path changes.
- Validate first: test controller decisions and device compatibility in a lab or limited deployment.
- Secure the control channel: restrict access, authenticate components and protect controller APIs and management interfaces.
- Plan for controller failure: define what devices should do when controller connectivity is lost or policy information becomes stale.
- Keep a rollback path: record previous configuration and provide a tested recovery procedure.
A controller may calculate an excellent theoretical path, but success depends on whether the forwarding devices can implement it, whether the route remains available, and whether measured application performance improves after deployment.
4.7 Where SDN fits in the traffic-engineering toolkit
SDN is most useful when policy and forwarding decisions benefit from coordination across devices or when repetitive changes can be automated safely. It can complement IGP metrics, BGP policy, ECMP, MPLS-TE and QoS rather than replacing every existing mechanism.
The practical goal is to connect network-wide intent with measurable outcomes. A controller should understand what the network is trying to achieve, choose a feasible action, deploy that action through supported interfaces, and verify that the result matches the objective.
SDN enables programmable, coordinated traffic control, while OpenFlow is one possible interface for managing forwarding rules on compatible devices. Centralised visibility can support more deliberate path selection, but dependable traffic engineering still requires accurate telemetry, stable control logic, secure interfaces and a tested failure strategy. The next section examines how these principles apply to cloud networking, load balancing and Kubernetes.
SDN Controller & Traffic Engineering Lab
Compare distributed shortest-path routing with controller-selected paths. Change link utilisation, simulate a failure, and inspect the illustrative forwarding decision.
1. Configure the network
2. View the forwarding decision
Cloud, Kubernetes and Application Traffic Engineering
Traffic engineering extends beyond traditional routers and WAN circuits. In cloud and container environments, performance depends on how virtual networks route packets, how load balancers distribute requests, how applications are deployed across regions, and which services are permitted to communicate. These mechanisms operate at different layers, but they all influence the path or destination that traffic takes.
A useful design begins by distinguishing network routing from request distribution and security policy. A virtual network route determines where packets are forwarded next. A load balancer chooses a backend or service endpoint for a connection or request. A Kubernetes NetworkPolicy defines permitted communication between selected workloads, subject to the network plugin's implementation. These controls complement one another rather than replacing one another.
Routing answers, “Where should packets go next?” Load balancing answers, “Which eligible backend should handle this traffic?” Network policy answers, “Which communications are allowed?” Confusing these responsibilities can lead to ineffective optimisation or security gaps.
5.1 Cloud virtual networks and route selection
Cloud platforms provide virtual networking constructs such as virtual private clouds, subnets, route tables, gateways, peering connections and private connectivity services. Together, these determine how traffic moves between workloads, services and external networks.
In Google Cloud, for example, Virtual Private Cloud (VPC) routes participate in forwarding decisions within the supported network environment. Route destinations, next-hop types, route priority and other platform-specific rules affect which route is selected. VPC peering can provide private connectivity between eligible networks, but it does not automatically make every route transitive across a chain of peerings.
Routes associate destination ranges with next hops. Engineers should check route priority, destination specificity, reachability and the supported next-hop type.
Peering, VPNs, dedicated connectivity and gateways provide different connectivity models, each with its own routing and reachability constraints.
Flow logs, route inspection, health information and application telemetry help identify where traffic is delayed, dropped or sent along an unexpected path.
Regional capacity, service quotas, network limits and workload placement can constrain the available options even when a route exists.
Cloud routing is not identical to physical-router routing. Providers implement their own control planes and forwarding rules, and some behaviour is managed by the platform rather than exposed as a customer-configurable protocol. Engineers should use the provider's documented route-selection and connectivity model when diagnosing a cloud traffic path.
5.2 Load balancing: distributing connections and requests
Load balancing distributes eligible traffic across a set of backend services or endpoints. Depending on the product, a load balancer may operate at Layer 4, making decisions using transport-layer information, or at Layer 7, where HTTP attributes and application-level information can influence routing.
Backend selection may consider health checks, configured balancing policies, locality, connection persistence, capacity or other product-specific criteria. The exact behaviour varies by load balancer type, so engineers should not assume that every service chooses the backend with the lowest live latency.
| Mechanism | Primary responsibility | Example use |
|---|---|---|
| Network routing | Forwards packets toward a destination or next hop. | Reach a workload subnet through a valid virtual route. |
| Layer 4 load balancing | Distributes transport connections or flows. | Spread TCP or UDP traffic across eligible backends. |
| Layer 7 load balancing | Routes application requests using supported application attributes. | Send requests to different services based on host or URL rules. |
| Health checks | Determine whether a backend is eligible to receive traffic. | Stop sending new traffic to an unhealthy service endpoint. |
5.3 Cross-region traffic engineering
Applications deployed in multiple regions can improve availability and serve users from geographically distributed locations. However, distributing traffic across regions introduces decisions about latency, regional capacity, data locality, cost, service dependencies and disaster recovery.
Global or cross-region load balancing can direct traffic to eligible backends in different locations according to the service's supported selection model. A well-designed policy considers backend health and regional availability while avoiding a configuration in which one region becomes overloaded during a surge or a regional failure.
- Latency and proximity: consider where users are located and how application response time varies by region.
- Regional capacity: ensure each region can support its expected demand and any planned failover load.
- Health and readiness: verify that the service can safely receive requests before sending traffic to it.
- Data dependencies: account for replication delay, state consistency and services that are available in only one region.
- Cost and egress: evaluate the financial impact of cross-region traffic and data transfer.
- Failure testing: verify how traffic is redistributed when a region or backend pool becomes unavailable.
A second region is not a complete resilience strategy if it cannot handle the workload displaced by a failure. Test realistic traffic volumes and dependencies, not just whether a health check causes traffic to move.
5.4 Kubernetes networking and NetworkPolicy
Kubernetes introduces additional networking layers because applications run in pods that can be created, moved, scaled or replaced dynamically. Services provide stable ways to reach groups of pods, while ingress controllers, gateways or service meshes can provide further traffic-management capabilities depending on the cluster architecture.
Kubernetes NetworkPolicy is primarily a traffic-permission mechanism. It specifies which connections are allowed to or from selected pods, based on supported selectors and rules. It does not, by itself, choose the lowest-latency route, distribute traffic evenly between pods or guarantee that a particular path will be used. Enforcement requires a network implementation that supports NetworkPolicy.
A Kubernetes Service provides a stable abstraction for reaching a group of eligible endpoints, while the cluster's data plane handles traffic forwarding.
Supported ingress or gateway implementations can route application traffic toward services using their configured rules and capabilities.
Policy rules can limit communication between workloads and other permitted peers, reducing unnecessary network exposure.
Application metrics, service-level indicators, flow data and cluster events help distinguish network problems from application or resource bottlenecks.
5.5 Application-aware traffic steering
Application-aware steering makes forwarding or backend decisions using information about the service, request or traffic class. Depending on the architecture, this may be implemented by an application load balancer, API gateway, service mesh, SDN controller or a policy-aware WAN platform.
Consider a service that has both a current application version and a legacy version. A request can be directed according to a validated application-version header, authenticated identity, hostname or route rule. Such decisions should be made at the appropriate application-aware layer rather than assuming that ordinary IP routing understands application identity.
| Steering input | Possible decision | Safeguard |
|---|---|---|
| Host or URL path | Send a request to a matching application service. | Validate routing rules and avoid exposing unintended endpoints. |
| Authenticated identity | Apply access or service-routing policy for an authorised user or client. | Verify identity tokens and enforce authorisation server-side. |
| Application version | Direct eligible requests to a new or legacy service. | Validate the version value and do not trust a client-supplied header on its own. |
| Backend health | Remove unhealthy endpoints from new traffic selection. | Use meaningful health checks and test recovery behaviour. |
Headers such as X-App-Version are ordinary request metadata, not proof of identity or permission. A client may be able to alter them. If a decision affects access or sensitive operations, validate the request against trusted authentication and authorisation information, and enforce the rule at a trusted gateway or service boundary.
5.6 Combining the controls into one design
Consider an application deployed across two cloud regions, with several Kubernetes services behind regional load balancers. The network route table provides connectivity between the relevant components. Regional load balancers select healthy backends. Kubernetes Services provide stable access to pods, while NetworkPolicy restricts permitted workload communication. Application-level rules may then steer requests based on service paths or validated identity.
If users experience slow responses, engineers should investigate each layer independently before changing the design. The problem might be a route issue, overloaded backend, unhealthy pod, cross-region dependency, restrictive network policy or slow application query. A change at the wrong layer can hide the symptom without correcting its cause.
- Trace the request path from the client through the load balancer, network and application service.
- Check route selection and connectivity between the relevant networks and subnets.
- Review backend health, endpoint availability and regional utilisation.
- Verify that NetworkPolicy permits the required communication without granting unnecessary access.
- Correlate network measurements with application latency, errors and resource metrics.
- Test scaling, backend loss and regional failover under representative demand.
Cloud and application traffic engineering combines several distinct controls: virtual routes determine packet forwarding, load balancers distribute connections or requests, Kubernetes networking connects workloads, and NetworkPolicy restricts permitted communication. The strongest designs coordinate these layers while measuring the actual outcome. The next section moves back toward WAN engineering, including DMVPN, NHRP and IPv6 path behaviour.
Cloud & Kubernetes Traffic Engineering Lab
Choose a traffic-steering layer, vary application demand, and simulate an unhealthy backend. See how cloud routing, load balancing and Kubernetes service selection solve different problems.
1. Configure traffic delivery
2. Inspect the delivery path
WAN Traffic Engineering: DMVPN, NHRP and IPv6
Wide Area Network (WAN) traffic engineering must account for more than the route selected by a routing protocol. Enterprise WANs often combine hub-and-spoke connectivity, encrypted tunnels, multiple transport circuits and remote branches with different bandwidth and latency characteristics. The engineering challenge is to direct traffic appropriately, make efficient use of available paths and preserve connectivity when links or tunnels fail.
Dynamic Multipoint VPN (DMVPN), the Next Hop Resolution Protocol (NHRP), routing policy and IPv6 neighbour and router-discovery mechanisms solve different problems within this environment. Understanding their roles helps engineers distinguish tunnel establishment and address resolution from route selection and traffic optimisation.
DMVPN provides a framework for dynamic multipoint tunnel connectivity. NHRP helps spokes discover the tunnel endpoint information needed for direct communication. Routing protocols determine network reachability, while routing policy and supported path-selection features influence which available route traffic uses.
6.1 DMVPN: flexible hub-and-spoke connectivity
DMVPN is a Cisco networking architecture commonly built from multipoint GRE (mGRE), NHRP and IPsec. It enables a hub-and-spoke VPN design in which remote sites can use a shared multipoint tunnel interface rather than requiring a separately configured static GRE tunnel for every possible spoke-to-spoke connection.
mGRE supports multiple tunnel destinations through a multipoint interface, allowing the architecture to scale more flexibly than a collection of individually configured point-to-point GRE tunnels.
NHRP allows a spoke to register its tunnel information with a hub and discover the mapping needed to communicate directly with another spoke when the design supports it.
IPsec can provide confidentiality, integrity and peer authentication according to the configured security policy and negotiated parameters.
A supported routing protocol can advertise branch prefixes and provide the route information needed to send traffic through the overlay.
6.2 DMVPN phases and direct spoke-to-spoke traffic
DMVPN designs are commonly described in phases. The phase influences how routing information and next-hop behaviour interact with NHRP and whether direct spoke-to-spoke forwarding can be established.
| DMVPN phase | Typical behaviour | Traffic-engineering consideration |
|---|---|---|
| Phase 1 | Spoke-to-spoke traffic typically traverses the hub. | Simple centralised forwarding, but the hub can become a bandwidth or latency bottleneck. |
| Phase 2 | Direct spoke-to-spoke tunnels can be established, with routing and next-hop requirements that preserve the remote spoke as the next hop. | Can reduce hub transit, but route summarisation and next-hop handling require careful design. |
| Phase 3 | NHRP redirect and shortcut mechanisms can help spokes discover and establish direct paths while allowing more scalable hub-oriented routing designs. | Can improve direct-path efficiency, but depends on compatible configuration and correct operation of the redirect and shortcut process. |
Exact configuration requirements vary by platform and software version. The phase label alone does not guarantee a particular path: verify the installed route, next-hop resolution, NHRP state and actual forwarding behaviour.
6.3 How NHRP shortcuts change the traffic path
In a hub-and-spoke overlay, the hub may initially provide reachability between two spokes. When a spoke sends traffic toward a remote branch, the hub can identify an opportunity for direct communication and send an NHRP redirect in a supported Phase 3 design. The source spoke can then use NHRP to resolve the remote spoke's tunnel endpoint and establish a shortcut path.
A shortcut can reduce unnecessary hub transit and may improve latency or relieve hub capacity. However, a direct tunnel is not automatically the fastest or most resilient path. The underlay Internet or private WAN path between spokes may have different delay, loss and capacity characteristics, and the tunnel still depends on valid routing and security state.
If a DMVPN application performs poorly, inspect both the logical overlay route and the physical or provider path carrying the tunnel. Tunnel state alone does not prove that the underlying transport is healthy or that the selected route meets the application's needs.
6.4 Routing policy across multiple WAN paths
Many enterprise WANs have more than one available transport, such as broadband Internet, private WAN connectivity or cellular backup. Routing metrics and policy can influence which path is preferred, while platform-specific tracking or performance-based WAN features may respond to reachability or measured conditions.
- Primary and backup paths: define a preferred route and verify that an alternate becomes usable when the primary fails.
- Traffic separation: use supported routing policy or PBR to direct selected traffic through an appropriate WAN service.
- Dynamic tunnel selection: consider which peers and tunnel endpoints remain reachable after an underlay change.
- Capacity and cost: account for circuit bandwidth, data-transfer costs and the demand expected during failover.
- Asymmetric forwarding: check whether outbound and return traffic follow compatible paths, particularly when stateful firewalls or NAT are involved.
Basic route preference does not inherently measure real-time latency or loss. Where a design requires application-specific performance objectives, use an appropriate performance-monitoring and path-selection capability rather than assuming that a lower routing metric always identifies the best-performing circuit.
6.5 IPv6 Router Advertisements and path preference
IPv6 introduces its own mechanisms for discovering routers and learning default-router information. Hosts can receive Router Advertisements (RAs) through Neighbor Discovery, with information such as router preference helping a host distinguish between advertised default routers when the relevant conditions and implementations support that behaviour.
Router preference is not a general-purpose traffic-engineering metric. It does not directly measure bandwidth, application latency or packet loss. It helps influence a host's choice among eligible default routers, while broader IPv6 route selection also depends on the destination, routing table and other applicable rules.
| IPv6 mechanism | Purpose | What it does not guarantee |
|---|---|---|
| Router Advertisement | Advertises router and network information to IPv6 hosts. | Does not automatically identify the lowest-latency upstream path. |
| Default-router preference | Helps distinguish advertised default routers according to supported preference rules. | Does not guarantee that the preferred router has more capacity or better performance. |
| IPv6 routing protocol | Provides routes and reachability within the relevant routing domain. | Does not automatically optimise every application flow using real-time metrics. |
| Policy and monitoring | Can guide path choice based on defined operational objectives. | Cannot compensate for missing telemetry, incorrect policy or unavailable connectivity. |
6.6 WAN failure handling and validation
A resilient WAN design must be tested under failure, not just during normal operation. A tunnel can remain configured while its underlying path has degraded, and a routing change can restore reachability without restoring acceptable application performance.
- Confirm that the expected routes are installed and that next hops resolve correctly.
- Inspect tunnel state, NHRP mappings and shortcut behaviour where applicable.
- Measure delay, jitter, loss and throughput over the actual traffic path.
- Simulate loss of a circuit, hub or remote endpoint and verify recovery behaviour.
- Check firewall, NAT and security-association behaviour when traffic moves between paths.
- Confirm that backup capacity is sufficient for the traffic redirected during failure.
- Review IPv6 Router Advertisements and default-router behaviour separately from IPv4 routing.
WAN traffic engineering combines routing policy, tunnel architecture, endpoint discovery and failure planning. DMVPN and NHRP can support dynamic branch connectivity and direct spoke-to-spoke paths, while IPv6 Router Advertisements influence host-side router discovery. None of these mechanisms alone guarantees optimal performance: validate the installed routes, tunnel state, underlying transport and measured application outcomes. The next section brings these principles together in an interactive traffic-engineering lab.
WAN Traffic Engineering Workbench
Explore DMVPN phases, NHRP shortcut behaviour, WAN link failures, and IPv6 default-router preference in one illustrative topology.
1. Configure the WAN
2. Inspect the WAN path
Interactive Traffic Engineering Lab: Compare Paths, Manage Congestion and Protect Resilience
Traffic engineering turns network measurement into a forwarding decision. In this simplified lab, you will compare two paths across a small WAN, inspect latency and utilisation, and see how a failed link can change the preferred route.
The topology and metrics are illustrative, not live measurements. They represent a network in which a traffic engineer must balance delay, link utilisation and resilience rather than choosing a route based on hop count alone.
Choose a routing strategy, adjust the demand placed on the network and simulate a link failure. Observe how the selected path changes, then consider whether the lowest-latency path is also the best operational choice.
The lower path offers a lower estimated latency in this example. The selected strategy also considers utilisation when comparing candidate routes.
7.1 Understand the simulated network
The WAN uses four routers and two end-to-end candidate paths. The upper route passes through B, while the lower route passes through C. Each link has a baseline latency and utilisation value. The simulation distributes the additional offered load across the links of the selected path and estimates a congestion-related delay penalty as utilisation rises.
| Candidate path | Baseline latency | Initial peak utilisation | Engineering consideration |
|---|---|---|---|
| A–B–D | 75 ms | 70% | Higher baseline delay and less headroom on its most utilised link. |
| A–C–D | 28 ms | 55% | Lower baseline delay and more headroom in the initial example. |
7.2 Experiment with the routing strategy
- Lowest estimated latency: selects the available path with the lowest modelled delay, including the simulation's congestion penalty.
- Balanced latency and utilisation: scores candidate paths using both estimated delay and peak link utilisation.
- Prefer lower utilisation: favours the route with more remaining headroom, while still considering estimated delay.
- Manual selection: lets you choose a path directly and compare it with the automatic strategies.
These are teaching strategies, not exact implementations of OSPF, IS-IS, BGP, RSVP-TE or a commercial SD-WAN controller. Real networks use protocol-specific metrics, policies and constraints. A routing protocol does not automatically use live latency and utilisation simply because those measurements are available elsewhere.
7.3 Simulate congestion and link failure
Increase the offered load to see how the selected route's modelled utilisation and delay change. Then select Simulate upper-link failure. The upper route becomes unavailable, and the automatic strategies must use the remaining path. If the manually selected route is no longer available, the lab reports that condition rather than silently claiming that the manual choice succeeded.
A path that looks attractive under normal conditions may lose its advantage when demand increases or a link fails. Traffic engineering should consider performance, capacity, policy and resilience together, and should be validated with actual telemetry and failure testing before being deployed.
7.4 Engineering review checklist
- Are latency, loss and utilisation measured on the same traffic path and over a suitable time window?
- Does the selected route have sufficient capacity for expected demand and failover traffic?
- Are primary and backup paths genuinely independent, or do they share a circuit, provider or physical conduit?
- Can routing policy and security controls accommodate a path change?
- Does the recovery process restore acceptable application performance, not merely basic reachability?
- Are the path-selection decisions observable, explainable and reversible?
Traffic engineering is a continuous process of measurement, path selection, validation and adjustment. Use the lab to explore trade-offs, then apply the same reasoning to routing policy, MPLS traffic engineering, SDN controllers and WAN designs. In production, base decisions on trustworthy telemetry, documented objectives and repeatable tests—not on an illustrative score alone.
Traffic Engineering Scenario Challenge
Can you deliver the traffic without overloading a link? Choose a strategy, change demand and capacity, then introduce a failure to test the outcome.
Maximise delivered traffic, avoid exceeding available path capacity, and maintain a usable route after a failure. The best strategy depends on the demand and network conditions.
Run the scenario to evaluate the selected strategy against available path capacity.
Path choice is only one part of traffic engineering. Capacity, demand, failures and policy all influence the result.
Educational model only. Delay values are illustrative; this lab does not implement live routing, QoS queues, BGP, RSVP-TE or a production traffic controller.
Network Traffic Engineering: Key Takeaways
Network traffic engineering is the practice of directing, distributing and managing traffic to make effective use of network resources. It connects routing policy, link capacity, Quality of Service (QoS), traffic measurement and application requirements to improve performance, resilience and operational control.
The central challenge is not simply to find a path between two endpoints. Engineers must understand how traffic behaves under normal conditions, where congestion develops, what happens when links fail, and whether the chosen policy can deliver the required service.
What you should understand
Traffic, congestion and QoS
Use throughput, utilisation, loss, latency and jitter to understand network conditions. QoS controls how traffic is classified, queued and treated; it does not automatically select a different route.
Routing-based engineering
OSPF and IS-IS metrics, BGP policy, ECMP, policy-based routing and performance-aware routing mechanisms influence how traffic reaches its destination. Each operates within its own capabilities and constraints.
MPLS Traffic Engineering
Explicit paths, bandwidth constraints, RSVP-TE and fast reroute can provide more deliberate path control and protection than ordinary shortest-path forwarding alone.
SDN and centralised decisions
Software-defined networking can use controller policies and network telemetry to coordinate forwarding decisions. OpenFlow is one possible southbound protocol, not a synonym for SDN itself.
Cloud and application traffic
Cloud routing, load balancing, Kubernetes service selection and application-aware steering solve different problems. Good designs make their boundaries and health-check behaviour explicit.
WANs, DMVPN and IPv6
WAN path selection, NHRP-supported shortcuts, failover design and IPv6 router preferences must be evaluated against actual topology, platform behaviour and operational requirements.
A practical workflow for engineers
- Establish a baseline. Measure offered load, throughput, link utilisation, loss and latency.
- Identify the constraint. Determine whether the problem is congestion, path selection, capacity, QoS treatment or application behaviour.
- Choose the appropriate mechanism. Apply routing policy, constrained path engineering, load distribution, QoS or application-level controls where suitable.
- Test failure conditions. Simulate link loss, reduced capacity and traffic surges; verify that alternate paths can carry the required demand.
- Validate the outcome. Compare the result against measurable service objectives and confirm that the change has not created a new bottleneck.
Put the concepts into practice
Use the interactive Traffic Engineering Lab in this article to experiment with traffic demand, path capacity, routing strategies and link failures. Observe how the selected policy affects delivered traffic and where a capacity shortfall occurs.
Treat the lab as a learning model rather than a prediction of live network behaviour. Real deployments require platform-specific configuration, reliable telemetry, testing and operational safeguards.
