OpenFlow Protocol

September 24, 2015

by Matt Conran Blog

OpenFlow Protocol

The world of networking has witnessed remarkable advancements, and one of the key contributors to this progress is the OpenFlow protocol. In this blog post, we will dive into the depths of OpenFlow, exploring its principles, benefits, and impact on the networking landscape.

OpenFlow, at its core, is a communication protocol that enables the separation of network control and forwarding plane. By doing so, it empowers network administrators with a centralized control plane and facilitates programmable network management. This flexibility opens up a realm of possibilities for network optimization, innovation, and enhanced performance.

To grasp the essence of OpenFlow, it's essential to familiarize ourselves with its key principles. Firstly, OpenFlow operates on a flow-based model, treating packets as individual entities rather than traditional IP and MAC addresses. Secondly, it enables the dynamic modification of network behavior through a centralized controller, providing unprecedented control and adaptability. Lastly, OpenFlow fosters interoperability by ensuring compatibility across various networking devices from different vendors.

The adoption of OpenFlow brings forth a plethora of benefits. Firstly, it allows network administrators to exert fine-grained control over traffic flows, enabling them to optimize network performance and reduce latency. Secondly, OpenFlow facilitates network virtualization, empowering organizations to create isolated virtual networks without the need for physical infrastructure. Additionally, OpenFlow promotes innovation and fosters rapid experimentation by providing an open platform for application developers to create and deploy new network services.

OpenFlow and SDN are often mentioned in the same breath, as they go hand in hand. SDN is a paradigm that leverages OpenFlow to enable programmability, flexibility, and automation in network management. By decoupling the control and data planes, SDN architectures simplify network management, facilitate network orchestration, and enable the creation of dynamic, agile networks.

The OpenFlow protocol has revolutionized the networking landscape, empowering organizations with unprecedented control, flexibility, and performance optimization. As we sail into the future, OpenFlow will continue to be a key enabler of innovation, driving the evolution of networking technologies and shaping the digital world we inhabit.

Matt Conran

Highlights: OpenFlow Protocol

Understanding OpenFlow Protocol

– The OpenFlow protocol is a communication standard allowing centralized control of network switches and routers. It separates the control plane from the data plane, enabling network administrators to have a holistic view of the network and make dynamic changes. Using a software-defined approach, OpenFlow opens up a realm of network management and optimization possibilities.

– OpenFlow boasts several essential features that make it a powerful tool in network management. These include flow-based forwarding, fine-grained control, and network programmability. Flow-based forwarding allows for traffic routing based on specific criteria, such as source or destination IP addresses.

– Fine-grained control enables administrators to set detailed rules and policies, ensuring optimal network performance. Network programmability allows for the customization and automation of network configurations, simplifying complex tasks.

Key Point: Flow-Based Forwarding

## Understanding the Basics of Flow-Based Forwarding

Flow-based forwarding is a method of routing network traffic based on predefined flows, which are essentially sequences of packets sharing the same attributes. Unlike traditional packet-based forwarding, which handles each packet independently, flow-based systems recognize and process flows as a single entity. This unified approach allows for more cohesive and efficient traffic management, as it can prioritize, route, and control data flows based on real-time requirements and policies.

## The Role of OpenFlow in Flow-Based Forwarding

OpenFlow is a pivotal protocol that enables flow-based forwarding by providing a standardized interface for programming network switches. It allows network administrators to define flows and enforce policies directly on the hardware, effectively separating the data plane from the control plane.

This separation empowers networks to be more adaptive and programmable, offering unprecedented levels of control over traffic behavior. OpenFlow’s ability to dynamically adjust to network conditions makes it an invaluable tool for implementing flow-based strategies across various applications.

Key OpenFlow Benefits

1: The adoption of the OpenFlow protocol brings numerous benefits to network environments. Firstly, it enhances network visibility and monitoring, enabling administrators to promptly identify and address potential bottlenecks or security threats.

2: Secondly, OpenFlow facilitates network flexibility and scalability, as changes can be easily implemented through centralized control. Moreover, the protocol promotes innovation by allowing new applications and services that leverage its programmability.

3: OpenFlow has significantly impacted network architecture, prompting a shift towards software-defined networking (SDN). SDN architectures provide a more agile and adaptable network infrastructure, enabling organizations to respond quickly to changing business requirements.

4: With OpenFlow as the backbone, SDN allows for the abstraction of network functions, making networks more programmable, scalable, and cost-effective.

Key OpenFlow Features

1. Centralized Control: OpenFlow Protocol provides a centralized control mechanism by decoupling the control plane from the devices. This allows network administrators to manage and configure network resources dynamically, making adapting to changing network demands easier.

2. Programmability: OpenFlow Protocol enables network administrators to program the behavior of network devices according to specific requirements. This programmability allows for greater flexibility and customization, making implementing new network policies and services easier.

3. Network Virtualization: OpenFlow Protocol supports virtualization, allowing multiple virtual networks to coexist on a single physical infrastructure. This capability enhances resource utilization and enables the creation of isolated network environments, enhancing security and scalability.

4. Traffic Engineering: With OpenFlow Protocol, network administrators have fine-grained control over traffic flows. This enables efficient load balancing, prioritization, and congestion management, ensuring optimal performance and resource utilization.

5. Software-Defined Networking (SDN): OpenFlow is a foundational element of Software-Defined Networking (SDN) architectures. SDN leverages the power of OpenFlow to decouple network control from hardware, enabling dynamic network management, automation, and scalability.

6. Traffic Engineering and Quality of Service (QoS): OpenFlow’s fine-grained control over network traffic enables advanced traffic engineering techniques. Network administrators can then prioritize specific types of traffic, allocate bandwidth efficiently, and ensure optimal Quality of Service (QoS) for critical applications.

OpenFlow Use Cases

1. Software-Defined Networking (SDN): OpenFlow Protocol is a key component of SDN, a network architecture separating the control and data planes. SDN leverages OpenFlow Protocol to provide a more flexible, programmable, and scalable network infrastructure.

2. Data Center Networking: OpenFlow Protocol offers significant advantages in data center environments, where dynamic workload placement and resource allocation are crucial. Using OpenFlow-enabled switches and controllers, data center operators can achieve greater agility, scalability, and efficiency.

3. Campus and Enterprise Networks: OpenFlow Protocol can simplify network management in large campus and enterprise environments. It allows network administrators to centrally manage and control network policies, improving network security, traffic engineering, and troubleshooting capabilities.

SDN: A History Guide

Martin Casado, a general partner at Andreessen Horowitz, would handle all the changes in the network industry. Previously, Casado worked for VMware as a fellow, senior vice president, and general manager. In addition to his direct contributions (like OpenFlow and Nicira), he has opened large network incumbents to the need to change network operations, agility, and manageability.

The Software-Defined Networking movement began with OpenFlow, whether for good or bad. During his Ph.D. at Stanford University, Casado worked on OpenFlow under Nick McKeown. Decoupling a network device’s control and data planes from the OpenFlow protocol is possible. A network device’s control plane consists of its brain, while its data plane consists of hardware that forwards packets or application-specific integrated circuits (ASICs).

Alternatively, OpenFlow can be run in a hybrid mode. It can be deployed on a specific port, virtual local area network (VLAN), or a regular packet-forwarding pipeline. Since there is no match in the OpenFlow table, packet forwarding is equivalent to policy-based routing (PBR).

OpenFlow provides granularity in determining forwarding paths (matching fields in packets) because its tables support more than destination addresses. PBR provides granularity by considering the source address when selecting the next routing hop.

In a similar way to OpenFlow, it allows network administrators to forward traffic based on non-traditional attributes, such as packet source addresses. Despite taking quite some time for network vendors to offer comparable performance for PBR-forwarded traffic, the final result was still very vendor-specific.

OpenFlow allowed us to make traffic-forwarding decisions at the same granularity as before but without vendor bias. Thus, network infrastructure capabilities could be enhanced without waiting for the following hardware version.

Example Technology: Policy-Based Routing

**The Mechanics of Policy-Based Routing**

At its core, policy-based routing enables network operators to define custom routes based on a variety of criteria such as source IP address, application type, or even specific user requirements. This flexibility is particularly valuable in scenarios where network administrators need to manage traffic efficiently across multiple paths. By creating and applying access control lists (ACLs), administrators can dictate how and where traffic should flow, optimizing network performance and ensuring compliance with organizational policies.

**Benefits of Implementing PBR**

One of the primary advantages of policy-based routing is its ability to enhance the quality of service (QoS) across a network. By prioritizing certain types of traffic—such as VoIP or video conferencing—PBR can reduce latency and improve overall communication quality. Additionally, PBR can aid in load balancing by distributing traffic evenly across available links, preventing bottlenecks and ensuring that no single path becomes overwhelmed.

**Challenges and Considerations**

While the benefits of PBR are substantial, implementing it is not without challenges. Network administrators must carefully design and test their routing policies to avoid unintended consequences, such as routing loops or security vulnerabilities. Furthermore, the complexity of managing numerous policies can increase administrative overhead. Therefore, it’s crucial for organizations to invest in training and tools that simplify the management of PBR configurations.

Real-World Applications of OpenFlow

So, what is OpenFlow? OpenFlow is an open-source communications protocol that enables remote control of network devices from a centralized controller. It is most commonly used in software-defined networking (SDN) architectures, allowing networks to be configured and managed from a single point. OpenFlow enables network administrators to programmatically control traffic flow across their networks, allowing them to respond quickly to changing traffic patterns and optimize network performance.

**The Creation of Virtual Networks**

OpenFlow will also help it create virtual networks on top of existing physical networks, allowing for more efficient and flexible network management. As a result, OpenFlow is an essential tool for building and managing modern, agile networks that can quickly and easily adapt to changing network conditions. The following post discusses OpenFlow, the operations of the OpenFlow protocol, and the OpenFlow hardware components you can use to build an OpenFlow network.

You may find the following helpful post for pre-information:

OpenFlow Protocol

OpenFlow history

OpenFlow started in the labs as an academic experiment. They wanted to test concepts about new protocols and forwarding mechanisms on real hardware but failed with current architectures. The challenges of changing forwarding entries in physical switches limited the project to emulations. Emulations are a type of simulation and can’t mimic an entire production network.

The requirement to test on actual hardware (not emulations) leads to separating device planes (control, data, and management plane) and introducing the OpenFlow protocol and new OpenFlow hardware components.

Highlighting SDN

Standard network technologies, consisting of switches, routers, and firewalls, have existed since the inception of networking. Data at each layer is called different things, and forwarding has stayed the same since inception. Frames and packets have been forwarded and routed using a similar approach, resulting in limited efficiency and a high maintenance cost.

Consequently, there was a need to evolve the techniques and improve network operations, which led to the inception of SDN. SDN, often considered a revolutionary new idea in networking, pledges to dramatically simplify network control and management and enable innovation through network programmability.

software defined networking — Diagram: Software Defined Networking (SDN). Source is Opennetworking

A key point: The OpenFlow Protocol versions

OpenFlow has gone through several versions, namely versions 1.0 to 1.4. OpenFlow 1.0 was the initial version of the Open Network Foundation (ONF). Most vendors initially implemented version 1.0, which has many restrictions and scalability concerns. Version 1.0 was limited and proved the ONF rushed to the market without having a complete product.

Not many vendors implemented versions 1.1 or 1.2 and waited for version 1.3, allowing per-flow meter and Provider Backbone Bridging (PBB) support. Everyone thinks OpenFlow is “open,” but it is controlled by a closed group of around 150 member organizations, forming the ONF. The ONF specifies all the OpenFlow standards, and work is hidden until published as a standard.

OpenFlow Protocol: Separation of Planes

An OpenFlow network has several hardware components that enable three independent pieces: the data plane, control plane, and management plane.

A: – The data plane

The data plane switches Protocol Data Units (PDU) from incoming ports to destination ports. It uses a forwarding table. For example, a Layer 2 forwarding table could list MAC addresses and outgoing ports. A Layer 3 forwarding table contains IP prefixes with next hops and outgoing ports. The data plane is not responsible for creating the controls necessary to forward. Instead, someone else has the job of “filling in” the data plane, which is the control plane’s function.

B: – The control plane

The control plane is responsible for giving the data plane the required information to enable it to forward. It is considered the “intelligence” of the network as it makes the decisions about PDU forwarding. Control plane protocols are not limited to routing protocols; they’re more than just BGP and OSPF. Every single protocol that runs between adjacent devices is usually a control plane. Examples include line card protocols such as BFD, STP, and LACP.

These protocols do not directly interface with the forwarding table; for example, BFD detects failures but doesn’t remove anything from the forwarding table. Instead, it informs other higher-level control plane protocols of the problem and leaves them to change the forwarding behavior.

C: – The management plane

On the other hand, protocols like OSPF and ISIS directly influence the forwarding table. Finally, the management plane provides operational access and monitoring. It permits you or “something else” to configure the device.

Diagram: Switch functions. Source is Bradhedlund

The Idea of OpenFlow Protocol

OpenFlow is not revolutionary new; similar ideas have been around for the last twenty years. RFC 1925 by R. Callon presents what is known as “The Twelve Network Truths.” Section 2.11 states, “Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.” Solutions to old problems are easily dressed up in new clothes, but the problems stay the same.

Example: Use case of vendors and OpenFlow hardware.

The scalability of a central control plane will always pose challenges. We had this with the SDH/SONET and Frame Relay days. NEC and Big Switch networks tried to centralize, eventually moving as much as possible to local devices or limiting the dynamic nature and number of supported protocols.

For example, NEC permits only static port channels, and if you opt for Layer 3 IP forwarding, the only control protocol they support is ARP. Juniper implemented a scalable model with MP-BGP, retaining low-level control plane protocols on local switches. Putting all the routine easy jobs on the local switch makes the architecture more scalable.

Cisco DFA or ACI uses the same architecture. It’s also hard to do fast feedback looks and fast convergence with a centralized control plane. OpenFlow and centralized control plane-centric SDN architectures do not solve this. You may, however, see OpenFlow combined with the Open vSwitch. Consider the Open vSwitch, also known as OVS, and the OVS bridge as the virtual switch in the data path.

A key point: Open vSwitch

The Open vSwitch is an open-source multi-layered switch that allows hypervisors to virtualize the networking layer. It is designed to enable network automation through programmatic extension. The OVS bridge supports standard management interfaces and protocols such as NetFlow, LACP, and 802.1ag). This caters to many virtual machines running on one or more physical nodes. The virtual machines connect to virtual ports on virtual bridges (inside the virtualized network layer.)

OVS bridge — Diagram: OVS Bridge: Source OpenvSwitch.

A key point: OpenFlow and Open Networking

Today, with many prominent vendors, we need an open interface to the forwarding plane. Many refer to this as monolithic, closed, and mainframe-like networking devices. On the other hand, a protocol such as OpenFlow. OpenFlow allows direct access to and manipulation of the forwarding plane of the network device. We can now move network control out of proprietary network switches and into open-source and locally managed control software. We were driving a new world of open networking.

OpenFlow protocol and decoupling

The idea of OpenFlow is straightforward. Let’s decouple the control and management plane from the switching hardware. Split the three-plane model where the dumb hardware is in one box, and the brains are in the other. The intelligence has to have a mechanism to push the forwarding entries, which could be MAC, ACL, IP prefix, or NAT rules to the local switches. The protocol used to push these entries is OpenFlow.

OpenFlow is viewed as a protocol with several instruction sets and an architecture. But it is nothing more than a Forwarding ( TCAM ) download protocol. It cannot change the switch hardware functionality. If something is supported in OpenFlow but not in the hardware, OpenFlow cannot do anything for you.

Just because OpenFlow versions allow specific matching doesn’t mean that the hardware can match those fields. For example, Juniper uses OpenFlow 1.3, which permits IPv6 handling, but its hardware does not permit matching on IPv6 addresses.

Flow table and OpenFlow forwarding model

The flow table in a switch is not the same as the Forwarding Information Base (FIB). The FIB is a simple set of instructions supporting destination-based switching. The OpenFlow table is slightly more complicated and represents a sequential set of instructions matching multiple fields. It supports flow-based switching.

OpenFlow 1.0 – Single Table Model: OpenFlow hardware with low-cost switches

The initial OpenFlow forwarding model was simple. They based the model of OpenFlow on low-cost switches that use TCAM. Most low-cost switches have only one table that serves all of the forwarding needs of that switch. As a result, the model for the OpenFlow forwarding model was a straightforward table. First, a packet is received on an interface; we extract metadata (like incoming interface) and other header fields from the packet.

Then, the fields in the packet are matched in the OpenFlow table. Every entry in a table has a protocol field, and the match with the highest priority is the winner. Every line in the table should have a different priority; the highest-priority match determines the forwarding behavior.

If you have simple MAC address forwarding, i.e., building a simple bridge. All entries are already distinct. So, there is no overlap, and you don’t need to use the priority field.

Once there is a match, the packet’s action is carried out. The action could be to send to an interface, drop, or send to the controller. The default behavior of OpenFlow 1.0 would send any unmatched packets to the controller. This punting was later removed as it exposed the controller to DoS attacks. An attacker could figure out what is not in the table and send packets to that destination, completely overloading the controller.

The original OpenFlow specifications could be sent to the interface or the controller. Still, they figured out they may need to modify the packet, such as changing the TTL, setting a field, and pushing/pop tags. They realized version 1.0 was broken, and you must do more than one action on every specific packet. Multiple actions must be associated with each flow entry. This was later addressed in subsequent OpenFlow versions.

OpenFlow ports

OpenFlow has the concept of ports. Ports on an OpenFlow switch serve the same input/output purposes as any switch. From the perspective of ingress and egress traffic flows, it is no different from any other switch. For example, the ingress port for one flow might be the output port for another flow.

OpenFlow defines several standard ports, such as physical, logical, and reserved. Physical ports correspond directly to the hardware. Logical ports do not directly correspond to hardware, such as MPLS LSP, tunnel, and null interfaces.

Reserved ports are used for internal packet processing and OpenFlow hybrid switch deployments. Reserved ports are either required or optional. Required ports include ALL, CONTROLLER, TABLE, IN_PORT, and ANY. In comparison, the Optional ports include LOCAL, NORMAL, and FLOOD.

TCAM download protocol

OpenFlow is simply a TCAM download protocol. OpenFlow cannot do this if you want to create a tunnel between two endpoints. It does not create interfaces for you. Other protocols, such as OF-CONFIG, use NETCONF for this job. It is a YANG-based data model. OpenFlow protocol is used between the controller and the switch, while OF-CONFIG is used between a configuration point and the switch. A port can be added, changed, or removed in the switch configuration with OF-CONFIG, not OpenFlow.

Port changes (state) do not automatically change the direction of the flow entry. For example, a flow entry will still point to that interface if a port goes down and subsequent packets are dropped. All port changes must first be communicated to the controller so it can make changes to the necessary forwarding by downloading instructions with OpenFlow to the switches.

A variety of OpenFlow messages are used for switch-to-controller and controller-to-switch communication. We will address these in the OpenFlow Series 2 post.

OpenFlow Classifiers

OpenFlow is modeled like a TCAM, supporting several matching mechanisms. You can use any combination of packet header fields to match a packet. Possibilities to match on MAC address (OF 1.0), with wildcards (OF 1.1), VLAN and MPLS tag (OF 1.1), PBB headers (OF 1.3), IPv4 address with wild cards, ARP fields, DSCP bits. Not many vendors implement ARP field matching due to hardware restrictions. Much current hardware does not let you look deep into ARP fields. IPv6 address (OF 1.2) and IPv6 extension headers (OF1.3), Layer 4 protocol, TCP, and UDP port numbers are also supported.

Once a specific flow entry matches a packet, you can specify the number of actions. Options include output to the port type: NORMAL port for traditional processing, LOCAL PORT for the local control plane, and CONTROLLER port for sending to the controller.

In addition, you may set the OUTPUT QUEUE ID, PUSH/POP VLAN, MPLS, or PBB tags. You can even do a header rewrite, which means OpenFlow can be used to implement NAT. However, be careful with this, as you only have a limited number of flow entries on the switches. Finally, some actions might be in software, which is too slow.

OpenFlow Groups

Finally, there is an exciting mechanism where a packet can be processed through what is known as a GROUP. With OpenFlow 1.1+, the OpenFlow forwarding model included the functionality of GROUPS. Groups enhance the previous OpenFlow forwarding model. However, enhanced forwarding mechanisms like ECMP Load Balancing cannot be completed in OpenFlow 1.0. For this reason, the ONF implemented OUTPUT GROUPS.

A Group is a set of buckets, and a Bucket is a set of actions. For example, an action could be output to port, set VLAN tag, or push/pop MPLS tag. Groups can contain several buckets; bucket 1 could be sent to port 1, and bucket 2 to port 2, but it could also add a tag.

This adds granularity to OpenFlow forwarding and enables additional forwarding methods. For example, sending to all buckets in a group could be used for selective multicast, or sending to one bucket in a group could be used for load balancing across LAG or ECMP.

Final Points: OpenFlow Protocol

OpenFlow Protocol represents a significant advancement in network management, offering a more flexible, programmable, and efficient approach. Decoupling the control and forwarding plane enables centralized control, programmability, and network virtualization. With its wide range of benefits and use cases, OpenFlow Protocol is poised to revolutionize network management and pave the way for future innovations in networking technologies.

As organizations face ever-increasing network challenges, embracing OpenFlow Protocol can provide a competitive edge and drive efficiency in network operations.

Summary: OpenFlow Protocol

The introduction of the OpenFlow protocol has witnessed a remarkable revolution in the world of networking. In this blog post, we will delve into its intricacies and explore how it has transformed the way networks are managed and controlled.

Understanding OpenFlow

At its core, OpenFlow is a communication protocol that enables the separation of control and data planes in network devices. Unlike traditional networking approaches, where switches and routers make forwarding decisions, OpenFlow centralizes the control plane, allowing for dynamic and programmable network management.

The Key Components of OpenFlow

To grasp the power of OpenFlow, it is essential to understand its key components. These include the OpenFlow switch, which processes packets based on instructions from a centralized controller, and the controller, which has a comprehensive view of the network topology and makes intelligent decisions on forwarding packets.

Benefits and Advantages

OpenFlow brings forth a myriad of benefits to networking environments. Firstly, it promotes flexibility and programmability, allowing network administrators to tailor the behavior of their networks to meet specific requirements. Furthermore, it simplifies network management, as policies and configurations can be implemented centrally. Additionally, OpenFlow enables network virtualization, enhancing scalability and resource utilization.

Real-World Applications

The adoption of OpenFlow has paved the way for innovative networking solutions. Software-defined networking (SDN) is one application where OpenFlow is critical. SDN allows for dynamic network control and management, making implementing complex policies and responding to changing network conditions easier.

In conclusion, the OpenFlow protocol has brought a paradigm shift in the networking world. Its ability to separate control and data planes, along with its flexibility and programmability, has transformed how networks are designed, managed, and controlled. As technology continues to evolve, OpenFlow and its applications, such as SDN, will undoubtedly play a pivotal role in shaping the future of networking.

Network Traffic Engineering

September 11, 2015

by Matt Conran Blog

Network Insight · Engineering Guide

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.

The central engineering question

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.

Topics explored in this guide

Congestion Management QoS and Bandwidth OSPF and IS-IS BGP Traffic Engineering MPLS RSVP-TE SDN and OpenFlow Cloud Networking WAN Optimisation

Network Insight · Traffic Engineering Guide

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 Routing & ECMP MPLS & SDN Cloud Networking WAN Resilience Interactive Lab

Section 01 · Observe Before Optimising

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.

Bandwidth utilisation Shows how much of a link's available capacity is being consumed. Sustained high utilisation can indicate a bottleneck.

Latency Measures how long traffic takes to travel between measurement points. High delay can affect interactive applications.

Jitter Describes variation in packet delay. It matters particularly to real-time voice, video and other timing-sensitive traffic.

Packet loss Identifies packets that fail to reach the observation point. Congestion is one possible cause, but not the only one.

Queue behaviour Queue depth, drops and scheduling statistics help reveal contention at network interfaces.

Flow distribution Shows which conversations, applications or traffic classes consume capacity and how flows are distributed across paths.

Engineering principle: measure the path, not just the interface

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.

Classify Identify traffic using defined rules.

Mark Apply an agreed traffic-class marking.

Queue and schedule Allocate transmission opportunities.

Verify Measure drops, delay and outcomes.

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.

Section takeaway

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.

Interactive lab · 01

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

Offered traffic 120 Mbps

Total traffic arriving at the link.

Link capacity 100 Mbps

Maximum modelled service rate.

Critical traffic share 30%

Traffic marked as critical for this illustrative model.

2. Select a QoS policy

Queueing / traffic policy

FIFO serves packets in arrival order. It does not prioritise critical traffic.

Ready. Adjust the inputs, then run the simulation.

Simulation results

Within capacity

Link utilisation

120%

Delivered throughput

100 Mbps

Modelled delay

— ms

Estimated loss / excess

16.7%

Offered load vs link capacity 120 / 100 Mbps

Offered traffic exceeds the configured link capacity.

1. ClassifyIdentify critical traffic

2. QueueApply selected policy

3. ScheduleAllocate service capacity

4. ForwardDeliver within capacity

The offered load exceeds link capacity. QoS can influence which traffic is served first, but it cannot create additional bandwidth.

Educational model only. Delay and loss are illustrative estimates, not measurements or predictions for a real network. Actual QoS behaviour depends on the device, queue configuration, traffic mix and congestion-management implementation.

Section 02 · Influence the Route

Routing-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.

Important distinction: a valid route is not necessarily the best-performing path

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 Cost-based path selection

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 Scalable link-state routing

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.

Traffic arrives Packets belong to different flows.

ECMP next hops Several eligible routes are installed.

Flow hashing Flows are assigned to available paths.

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.

Engineering consideration

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.

Section takeaway

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.

Interactive lab · 02

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

Routing strategy

Traffic class

PBR can steer selected traffic using configured match rules. Other traffic may follow the normal routing table.

Link condition

Ready to simulate.

2. Selected forwarding path

Illustrative network: R1 forwards traffic towards destination R4 over one of two paths.

Selected path Available alternative Unavailable link

Chosen path

R1–R2–R4

Path cost

Active paths

The upper path has the lower illustrative metric, so the metric-based strategy selects it.

Learning model, not a router emulator. The example metrics and BGP policy preferences are illustrative. Real BGP best-path selection follows implementation-specific rules and configured attributes; BGP does not inherently select the lowest-latency route from live performance measurements. ECMP requires eligible equal-cost routes and compatible forwarding configuration.

Section 03 · Engineer the Path

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.

Core concept: reachability and path engineering are different tasks

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.

Ingress Classify and label

The ingress router identifies the traffic or forwarding equivalence class and applies the appropriate label stack for the selected forwarding path.

Core Switch labels

Core routers use label-forwarding entries to send traffic toward the next hop without requiring a full IP route lookup for every transit packet.

Egress Remove or process labels

The egress side processes the label stack and forwards the traffic toward its destination according to the service design.

Control plane Establish forwarding state

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.

Define Specify endpoints and path constraints.

Signal Request path establishment and resources.

Forward Carry traffic over the established LSP.

Monitor Check path health and resource usage.

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.

Do not confuse path length with path quality

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.

Section takeaway

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.

Interactive lab · 03

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

Path selection strategy

Requested bandwidth40 Mbps

Each link advertises an illustrative available bandwidth value.

Failure scenario

Enable pre-planned Fast Reroute (FRR) backup

FRR can switch traffic to a pre-established local repair path when the protected failure is detected and the backup is usable.

Ready to simulate.

2. Inspect the selected path

Active LSPFRR repair pathFailed link

Selected route

R1–R2–R4

Path cost

Bandwidth fit

Pass

Illustrative label at R1Push 16001

Transit actionSwap 16002

Egress actionPop label

The explicit LSP follows R1–R2–R4. Label operations and path feasibility are illustrative.

Educational model only. Label values are fictional examples, not live router state. The simulation approximates path constraints using link bandwidth and illustrative costs. RSVP-TE signalling, admission control, label distribution, CSPF, failure detection and FRR behaviour depend on the real network's configuration and platform.

Section 04 · Centralised Control

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.

SDN is an architecture, not a single protocol

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

Application layer Express the objective

Applications describe the intended policy, such as prioritising a traffic class, selecting a path or avoiding a constrained link.

Control layer Analyse and decide

The controller evaluates available topology, policy, device capabilities and telemetry to calculate an appropriate forwarding strategy.

Infrastructure layer Forward the traffic

Switches and routers apply supported forwarding rules or configuration changes to implement the selected behaviour.

Feedback Observe the outcome

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.

Collect Read topology and device information.

Calculate Evaluate paths and policy constraints.

Install Apply compatible forwarding rules.

Verify Observe counters and traffic outcomes.

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:

Illustrative path score

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.

Visibility must lead to verified action

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.

Section takeaway

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.

Interactive lab · 04

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

Traffic engineering approach

Upper path utilisation85%

Illustrative utilisation for the R1–R2–R4 path.

Lower path utilisation35%

Illustrative utilisation for the R1–R3–R4 path.

Link condition

Controller can observe current link state and install forwarding rules

Uncheck this to model a controller-dependent decision that cannot be updated. Existing forwarding may persist, but adaptation is not assumed.

Ready to simulate.

2. View the forwarding decision

Selected forwarding pathUnavailable path

Selected path

R1–R3–R4

Modelled utilisation

35%

Decision state

Installed

The controller selects the less-utilised path in this illustrative model. Real SDN decisions depend on telemetry, policy, controller logic and the capabilities of the forwarding devices.

Educational model only. The utilisation values are illustrative inputs, not measured network telemetry. OpenFlow is one protocol that can be used between a controller and compatible switches; SDN can also use other southbound interfaces. A controller does not automatically provide global optimisation unless its data, policies and control logic support it.

Section 05 · From Network to Application

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.

Three different control problems

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.

Route tables Control packet forwarding

Routes associate destination ranges with next hops. Engineers should check route priority, destination specificity, reachability and the supported next-hop type.

Network connectivity Connect workloads and networks

Peering, VPNs, dedicated connectivity and gateways provide different connectivity models, each with its own routing and reachability constraints.

Observability Trace actual traffic behaviour

Flow logs, route inspection, health information and application telemetry help identify where traffic is delayed, dropped or sent along an unexpected path.

Capacity planning Match demand to resources

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.

Client Sends a connection or request.

Load balancer Evaluates policy and backend health.

Backend pool Receives traffic on selected endpoints.

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.

Failover must be capacity-aware

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.

Service Provide stable service access

A Kubernetes Service provides a stable abstraction for reaching a group of eligible endpoints, while the cluster's data plane handles traffic forwarding.

Ingress or gateway Control external application entry

Supported ingress or gateway implementations can route application traffic toward services using their configured rules and capabilities.

NetworkPolicy Restrict permitted connections

Policy rules can limit communication between workloads and other permitted peers, reducing unnecessary network exposure.

Telemetry Observe workload performance

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.

Section takeaway

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.

Interactive lab · 05

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

Traffic steering layer

Selection policy

Incoming traffic demand120 req/s

Illustrative requests per second reaching the service.

Backend health

Health checks or endpoint readiness can exclude unhealthy backends

If disabled, this simplified model may send traffic to an unhealthy backend, illustrating the importance of health-aware selection.

Ready to simulate.

2. Inspect the delivery path

Selected delivery pathUnused or unavailable path

Traffic delivered

120 req/s

Active backends

3 of 3

Unserved demand

0 req/s

Network layerRoute selection

Service layerBackend selection

App layerRequest policy

A cloud network route determines where packets are forwarded. A load balancer or service proxy selects a backend; these functions are related but not interchangeable.

Educational model only. Requests are divided evenly or by a simplified policy; no real cloud account, Kubernetes cluster, health probe, or application header is accessed. Kubernetes Services distribute traffic according to the cluster's networking implementation and endpoint state. Application-provided headers are not trusted identity unless validated by a trusted component.

Section 06 · Engineer the WAN

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.

Keep the functions separate

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.

Multipoint GRE Provide tunnel encapsulation

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 Resolve remote tunnel endpoints

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 Protect tunnel traffic

IPsec can provide confidentiality, integrity and peer authentication according to the configured security policy and negotiated parameters.

Routing protocol Exchange reachability

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.

Initial traffic Spoke A forwards toward Spoke B through the hub.

Redirect The hub indicates that a shortcut may be appropriate.

NHRP resolution Spoke A discovers the remote tunnel endpoint.

Direct path Eligible traffic can travel between the spokes.

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.

Measure the overlay and the underlay

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.

Section takeaway

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.

Interactive lab · 06

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

DMVPN operating model

Traffic destination

WAN condition

Hub-path delay estimate80 ms

Illustrative one-way delay estimate for the hub-mediated path.

Direct-path delay estimate30 ms

Illustrative one-way delay estimate for a direct spoke-to-spoke path.

NHRP resolution and shortcut formation are available where supported

IPv6 default-router preference

This illustrates RFC 4191 router preference, not latency measurement.

Ready to simulate.

2. Inspect the WAN path

Selected pathNHRP shortcutUnavailable tunnel

Forwarding path

A → B direct

Modelled delay

30 ms

Shortcut state

Formed

IPv6 default-router selection example

Router A preferenceMedium

Router B preferenceHigh

Illustrative preference outcomeRouter B preferred

In Phase 3, NHRP can help spokes discover a direct shortcut after traffic initially traverses the hub. Exact behaviour depends on platform, configuration, routing and tunnel state.

Educational model only. Delay values are user-entered illustrations, not live measurements. DMVPN phase behaviour depends on implementation and configuration. NHRP resolves protocol next-hop information and can support shortcut formation; it does not guarantee a faster path. IPv6 Router Advertisement default-router preference expresses High, Medium or Low preference and is not a live latency or performance metric.

Section 07 · Interactive lab

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.

Lab objective

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.

Path Selection Workbench Source: Edge A · Destination: Edge D · Two candidate routes through a diamond-shaped WAN.

Traffic-engineering strategy

Additional offered load: 20 Mbps

Selected path A–C–D

Estimated latency 28 ms

Peak link utilisation 55%

Path status Available

Selected route Available alternative Failed link

ROUTE SELECTED Balanced path selected

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.

What this demonstrates

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?

Section takeaway

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.

Network Insight · Interactive Lab 07

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.

1. Configure the network

Traffic engineering strategy

Offered traffic

Traffic demand 120 Mbps

Upper path capacity

R1 → R2 → R4 100 Mbps

Lower path capacity

R1 → R3 → R4 80 Mbps

Network condition

Enable automatic rerouting
Allow traffic to move to a surviving path when possible.

Scenario objective

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.

Upper path Lower path Unavailable or unused

Delivered traffic

120 Mbps

Unserved traffic

0 Mbps

Estimated path delay

18 ms

Traffic delivered

100%

2. Scenario result

Scenario ready

Run the scenario to evaluate the selected strategy against available path capacity.

Demand successfully delivered 100%

Upper: idle Lower: idle No failure

Engineering takeaway

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 Insight · Engineering Summary

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

01 · MEASURE

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.

02 · STEER

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.

03 · CONSTRAIN

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.

04 · CONTROL

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.

05 · INTEGRATE

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.

06 · RESILIENCE

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.

The engineering principle: the shortest path, the lowest-delay path and the least-congested path are not necessarily the same. Effective traffic engineering balances policy, available capacity, measured conditions and failure recovery.

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.

```

☕

Support Network Insight

Help support independent engineering guides, interactive networking tools, and future learning labs.

Support Network Insight ```

OpenFlow Protocol

Highlights: OpenFlow Protocol

Understanding OpenFlow Protocol

**Key OpenFlow Benefits**

**Key OpenFlow Features**

**OpenFlow Use Cases**

SDN: A History Guide

Example Technology: Policy-Based Routing

Real-World Applications of OpenFlow

OpenFlow Protocol

OpenFlow history

Highlighting SDN

OpenFlow Protocol: Separation of Planes

A: – The data plane

B: – The control plane

C: – The management plane

**The Idea of OpenFlow Protocol**

A key point: Open vSwitch

A key point: OpenFlow and Open Networking

OpenFlow protocol and decoupling

Flow table and OpenFlow forwarding model

OpenFlow ports

TCAM download protocol

OpenFlow Classifiers

OpenFlow Groups

Final Points: OpenFlow Protocol

Summary: OpenFlow Protocol

Network Traffic Engineering: Optimising Paths, Performance and Capacity

Measure the network

Control traffic behaviour

Choose suitable paths

Validate the outcome

Network Traffic Engineering: Optimising Paths, Performance and Capacity

Traffic Measurement, Congestion and Quality of Service

1.1 The measurements that matter

1.2 How congestion develops

1.3 Quality of Service: managing competing traffic

1.4 From monitoring to traffic engineering

Traffic Measurement & QoS Workbench

1. Traffic and capacity

2. Select a QoS policy

Simulation results

Routing-Based Traffic Engineering: OSPF, IS-IS, BGP and ECMP

2.1 Interior routing: OSPF and IS-IS

2.2 Equal-Cost Multipath: using multiple eligible routes

2.3 BGP traffic engineering: influence inter-domain traffic

2.4 Policy-Based Routing: steer traffic by policy

2.5 Performance-based optimisation and PfR

2.6 A practical routing-engineering workflow

Routing-Based Traffic Engineering Lab

1. Configure the routing scenario

2. Selected forwarding path

MPLS Traffic Engineering: RSVP-TE, Explicit Paths and Fast Reroute

3.1 Understanding the MPLS forwarding model

3.2 What is an MPLS Traffic Engineering tunnel?

3.3 RSVP-TE and constrained path selection

3.4 Why engineered paths can improve utilisation

3.5 Fast Reroute: protecting traffic against failure

3.6 MPLS-TE in modern network design

MPLS Traffic Engineering Workbench

1. Configure the LSP

2. Inspect the selected path

SDN, OpenFlow and Centralised Traffic Engineering

4.1 The main components of an SDN design

4.2 How OpenFlow can influence forwarding

4.3 Centralised path selection using network metrics

4.4 Example: selecting a path through a diamond topology

4.5 Centralised control versus distributed routing

4.6 Stability, security and safe deployment

4.7 Where SDN fits in the traffic-engineering toolkit

SDN Controller & Traffic Engineering Lab

1. Configure the network

2. View the forwarding decision

Cloud, Kubernetes and Application Traffic Engineering

5.1 Cloud virtual networks and route selection

5.2 Load balancing: distributing connections and requests

5.3 Cross-region traffic engineering

5.4 Kubernetes networking and NetworkPolicy

5.5 Application-aware traffic steering

5.6 Combining the controls into one design

Key OpenFlow Benefits

Key OpenFlow Features

OpenFlow Use Cases

The Idea of OpenFlow Protocol