OpenFlow Traffic Engineering Archives

BGP has a new friend – BGP-Based SDN

September 16, 2015

by Matt Conran Blog

BGP-Based SDN

The world of networking continues to evolve rapidly, with new technologies and approaches emerging to meet the growing demands of modern communication. Two such technologies, BGP (Border Gateway Protocol) and SDN (Software-Defined Networking), have gained significant attention for their impact on network flexibility and management. In this blog post, we will delve into the fascinating intersection of BGP and SDN, exploring how they work together to empower network administrators and optimize network operations.

Border Gateway Protocol (BGP) serves as the backbone of the internet, facilitating the exchange of routing information between networks. BGP enables dynamic routing, allowing routers to determine the best paths for data transmission based on various factors such as network policies, path preferences, and traffic conditions. It plays a crucial role in inter-domain routing, where multiple networks connect and exchange data.

Software-Defined Networking (SDN) introduces a paradigm shift in network management by decoupling the control plane from the data plane. In traditional networks, network devices such as switches and routers possess both control and data plane functionalities. SDN separates these functions, with a centralized controller managing the network's behavior and forwarding decisions. The data plane, consisting of switches and routers, simply follows the instructions provided by the controller.

When BGP and SDN converge, we unlock a new realm of network possibilities. SDN's centralized control and programmability complement BGP's routing capabilities, offering enhanced flexibility and control over network operations. By leveraging SDN controllers, network administrators can dynamically adjust BGP routing policies, optimize traffic flows, and respond to changing network conditions in real-time. This dynamic interaction between BGP and SDN empowers organizations to adapt their networks to ever-evolving requirements efficiently.

The combination of BGP and SDN brings forth several advantages and opens up exciting use cases. Network operators can implement traffic engineering techniques to optimize network paths, improve performance, and minimize congestion. They can also utilize SDN's programmability to automate BGP configuration and provisioning, reducing human errors and accelerating network deployment. Additionally, BGP-SDN integration facilitates the implementation of policies for traffic prioritization, security, and load balancing.

The convergence of BGP and SDN represents a powerful synergy that empowers network administrators to achieve unprecedented levels of flexibility, control, and efficiency. By combining BGP's robust routing capabilities with SDN's programmability and centralized management, organizations can adapt their networks swiftly to meet evolving demands. As the networking landscape continues to evolve, the BGP-SDN combination will undoubtedly play a pivotal role in shaping the future of network architecture.

Matt Conran

Highlights: BGP-Based SDN

Understanding BGP and SDN

1- BGP (Border Gateway Protocol) is a routing protocol used to exchange routing information between different networks on the internet. On the other hand, SDN is an architectural approach that separates the control plane from the data plane, allowing network administrators to centrally manage and configure networks through software.

2- BGP-based SDN combines the power of BGP routing with the flexibility and programmability of SDN. Network operators gain enhanced control, scalability, and agility in managing their networks by leveraging BGP as the control plane protocol in an SDN architecture. This marriage of BGP and SDN opens up new possibilities for network automation, policy-driven routing, and dynamic traffic engineering.

3- One critical advantage of BGP-based SDN is its ability to simplify network management. With centralized control and programmability, network operators can define policies and rules that govern their networks’ behavior.

4- This paves the way for efficient traffic engineering and the ability to respond dynamically to changing network conditions. Additionally, BGP-based SDN provides better scalability, allowing for the distribution of control plane functions across multiple controllers.

Knowledge Check: Prefer EBGP over iBGP

### What is eBGP?

eBGP, or External BGP, is used for routing between different autonomous systems (AS). An autonomous system is essentially a collection of IP networks and routers under the control of a single organization. eBGP is employed when these networks communicate with each other. Its primary purpose is to exchange routing information between these independent systems, ensuring data can travel from one network to another across the globe.

eBGP is characterized by its scalability and efficiency in handling large amounts of routing information. It operates by sending updates about network reachability, allowing each AS to determine the best path for data transmission. This makes it an indispensable tool for ISPs and large enterprises managing extensive network infrastructures.

### Understanding iBGP

On the other hand, iBGP, or Internal BGP, operates within a single autonomous system. Its purpose is to distribute routing information obtained from eBGP to all routers within the same AS. Unlike eBGP, which is concerned with external communication, iBGP ensures that all routers within the AS have a consistent view of the network topology.

iBGP is crucial for maintaining the integrity and efficiency of a network’s internal routing. It prevents routing loops and ensures that data packets find the most optimal path within the AS. Additionally, it works seamlessly with other interior gateway protocols like OSPF and IS-IS to enhance network performance.

### Key Differences Between eBGP and iBGP

While both eBGP and iBGP are integral parts of the BGP protocol, they serve distinct purposes and operate under different conditions. Here are some key differences:

1. **Operational Scope**: eBGP is used between different AS, whereas iBGP operates within a single AS.

2. **Path Selection**: eBGP selects routes based on the AS path, preferring shorter paths, while iBGP relies on the IGP metrics to determine the best route within the AS.

3. **Hop Count**: eBGP sessions are typically limited to a single hop, although multi-hop configurations are possible. iBGP sessions, however, can span multiple hops within the AS.

4. **Route Propagation**: eBGP routes are advertised to iBGP peers, but iBGP routes are not automatically advertised to other iBGP peers, requiring additional configuration to propagate routes.

### Practical Applications and Considerations

Network administrators must carefully consider their use of eBGP and iBGP when designing and managing network infrastructures. eBGP is essential for connecting to external networks and the internet, while iBGP ensures efficient internal routing. Balancing both is key to achieving optimal network performance and reliability.

When configuring BGP, it is also important to implement security measures to prevent attacks such as route hijacking. This includes using route filtering, authentication, and monitoring tools to safeguard network operations.

## The Role of BGP in Traditional Networking ##

BGP has long been the backbone of internet routing, enabling data to traverse global networks efficiently. Its robust, policy-driven approach allows for complex routing decisions based on a variety of factors like path attributes and network policies. However, traditional BGP setups can be rigid, often requiring manual configurations that are time-consuming and error-prone. This is where SDN comes into play, offering a more dynamic and programmable approach to network management.

## Integrating BGP with SDN: A New Era

The integration of BGP with SDN is not just about replacing old systems but augmenting them. By leveraging SDN’s centralized control and programmability, BGP-based SDN allows for automated policy changes and real-time network optimization. This results in a more agile network that can adapt to changing demands and conditions. The centralized SDN controller can dynamically manage BGP routes, reducing the complexity and improving the responsiveness of the network.

## BGP SDN Challenges

Despite its advantages, implementing BGP-based SDN is not without its challenges. Integrating SDN with existing BGP infrastructures can be complex and requires careful planning and execution. There is also the need for network professionals to acquire new skills and knowledge to effectively manage these advanced systems. Furthermore, ensuring compatibility between different SDN solutions and traditional network devices remains a critical consideration.

## Note: New Attack Surface

While BGP-based SDN holds immense potential, it also poses certain challenges. One of the primary concerns is the complexity of implementation and migration. Integrating BGP with SDN requires careful planning and coordination to ensure a smooth transition. Moreover, security and privacy considerations must be considered when deploying BGP-based SDN, as centralized control introduces new attack vectors that must be mitigated.

Critical Components of BGP SDN:

a. BGP Routing: BGP SDN leverages the BGP protocol to manage the routing decisions between different networks. This enables efficient and optimized routing and seamless communication across various domains.

b. SDN Controller: The SDN controller acts as the centralized brain of the network, providing a single point of control and management. It enables network administrators to define and enforce network policies, configure routing paths, and allocate network resources dynamically.

c. OpenFlow Protocol: BGP SDN uses the OpenFlow protocol to communicate between the SDN controller and the network switches. OpenFlow enables the controller to programmatically control the forwarding behavior of switches, resulting in greater flexibility and agility.

Example BGP Technology: IPv6 BGP

### IPv6 and BGP: A Synergistic Relationship

Transitioning to IPv6 doesn’t just mean more addresses; it means enhancing the operational capacity of BGP. IPv6 introduces features like simplified header formats and improved multicast routing, which can streamline the BGP process. This section will explore how IPv6 enhances BGP operations, offering benefits such as reduced latency, improved security, and better support for mobile networks.

### Challenges and Considerations in IPv6 BGP Deployment

Despite its advantages, the deployment of IPv6 within BGP is not without challenges. Network engineers face hurdles such as compatibility with existing IPv4 infrastructure, the complexity of dual-stack configurations, and the need for updated hardware and software. We’ll examine these challenges and provide insights into how organizations can navigate them to successfully implement IPv6 in their BGP configurations.

Benefits of BGP SDN:

a. Enhanced Flexibility: BGP SDN allows network administrators to tailor their network infrastructure to meet specific requirements. With centralized control, network policies can be easily modified or updated, enabling rapid adaptation to changing business needs.

b. Improved Scalability: Traditional network architectures often struggle to handle the growing demands of modern applications. BGP SDN provides a scalable solution by enabling dynamic allocation of network resources, optimizing traffic flow, and ensuring efficient bandwidth utilization.

c. Simplified Network Management: BGP SDN’s centralized management simplifies network operations. Network administrators can configure, monitor, and manage the entire network from a single interface, reducing complexity and improving overall efficiency.

Use Cases for BGP SDN:

a. Data Centers: BGP SDN is well-suited for data center environments, where rapid provisioning, scalability, and efficient workload distribution are critical. By leveraging BGP SDN, data centers can seamlessly integrate physical and virtual networks, enabling efficient resource allocation and workload migration.

b. Service Providers: BGP SDN allows service providers to offer their customers flexible and customizable network services. It enables the creation of virtual private networks, traffic engineering, and service chaining, resulting in improved service delivery and customer satisfaction.

BGP Technologies in BGP SDN

Understanding BGP Route Reflection

A – 🙂 BGP route reflection is a technique used to alleviate the burden of full-mesh connectivity in BGP networks. Traditionally, in a fully meshed BGP configuration, all routers must establish a direct peer-to-peer connection with every other router, resulting in complex and resource-intensive setups. Route reflection introduces a hierarchical approach that reduces the number of required connections, providing a more scalable alternative.

B – 🙂 Route reflectors act as centralized points within a BGP network and reflect and propagate routing information to other routers. They collect BGP updates from their clients and reflect them to other clients, ensuring a simplified and efficient distribution of routing information. Route reflectors maintain the overall consistency of the BGP network while reducing the number of required peer connections.

C- 🙂 To implement BGP route reflection, one or more routers within the network need to be configured as route reflectors. These route reflectors should be strategically placed to ensure efficient routing information dissemination. Clients, also known as non-route reflectors, establish peering sessions with the route reflectors and send their BGP updates to be reflected. Route reflector clusters can also be formed to provide redundancy and load balancing.

Understanding BGP Multipath

BGP multipath, short for Border Gateway Protocol multipath, is a feature that enables the use of multiple paths for traffic forwarding in a network. Traditionally, BGP selects a single best path based on attributes like AS path length, origin type, and MED (Multi-Exit Discriminator) value. However, with BGP multipath, multiple paths can be utilized simultaneously, distributing traffic across multiple links.

Enhanced Network Performance: BGP multipath optimizes network performance by load-balancing traffic using multiple paths. This helps avoid congestion on specific links and ensures efficient utilization of available bandwidth, resulting in faster and more reliable data transmission.

Improved Resilience: BGP multipath enhances network resilience by providing redundancy. In case of link failures or congestion, traffic can be automatically rerouted through alternative paths, minimizing downtime and ensuring continuous connectivity. This dramatically improves the overall reliability of the network infrastructure.

SDN and BGP

BGP SDN, or Border Gateway Protocol Software-Defined Networking, combines two powerful technologies: the Border Gateway Protocol (BGP) and Software-Defined Networking (SDN). BGP, a routing protocol, facilitates inter-domain routing, while SDN provides centralized control and programmability of the network. Together, they offer a dynamic and adaptable networking environment.

While Border Gateway Protocol (BGP) was initially designed to connect networks operated by different companies, such as transit service providers, providers of large-scale data centers discovered that it could be used for spine and leaf fabrics.

BGP can also be used as an SDN because it already runs on all routers. According to the diagram below, each router in the fabric is connected to an iBGP controller.

Augmented Model

After the iBGP sessions are established, the controller can read the entire topology to determine which path the flow should be pinned to and which flows should avoid the path over which the flow is passing.

An augmented model uses a centralized control plane that interacts directly with a distributed control plane (eBGP). Interestingly, the same protocol used to push policy (the southbound interface) is also used to discover and distribute topology and reachability information in this hybrid model implementation.

The Role of SDN

Before we start our journey on BGP SDN, let us first address what SDN means. The Software-Defined Networking (SDN) framework has a large and varied context. Multiple components, including the OpenFlow protocol, may or may not be used. Some evolving SDN use cases leverage the capabilities of the OpenFlow protocol, while others do not require it.

OpenFlow is only one of those protocols within the SDN architecture. This post addresses using the Border Gateway Protocol (BGP) as the transfer protocol between the SDN controller and forwarding devices, enabling BGP-based SDN, also known as BGP SDN.

BGP and OpenFlow

– BGP and OpenFlow are monolithic, meaning they are not used simultaneously. Integrating BGP to SDN offers several use cases, such as DDoS mitigation, exception routing, forwarding optimizations, graceful shutdown, and integration with legacy networks.

– Some of these use cases are available using OpenFlow Traffic Engineering; others, like graceful shutdown and integration with the legacy network, are easier to accomplish with BGP SDN.

– When BGP and OpenFlow are combined, they create a powerful synergy that enhances network control and performance. BGP provides the foundation for inter-domain routing and connectivity, while OpenFlow facilitates granular traffic engineering within a domain.

– Together, they enable network administrators to fine-tune routing decisions, balance traffic across multiple paths, and enforce quality of service (QoS) policies.

BGP Add Path Feature

The BGP Add Path feature is designed to address the limitations of traditional BGP routing, where only the best path to a destination is advertised. With Add Path, BGP routers can advertise multiple paths to a destination network, providing increased routing options and allowing for more efficient traffic engineering.

Introducing the Add Path feature brings several benefits to network administrators and service providers. Firstly, it enables better load balancing and traffic distribution across multiple paths, leading to optimized network utilization. Additionally, it enhances network resiliency by providing alternative paths in case of link failures or congestion.

Before you proceed, you may find the following post helpful:

BGP-Based SDN

What is BGP?

What is the BGP protocol in networking? Border Gateway Protocol (BGP) is the routing protocol under the Exterior Gateway Protocol (EGP) category. In addition, we have separate protocols, which are Interior Gateway Protocols (IGPs). However, IGP can have some disadvantages.

Firstly, policies are challenging to implement with an IGP because of the need for more flexibility. Usually, a tag is the only tool available that can be problematic to manage and execute on a large-scale basis. In the age of increasingly complex networks in both architecture and services, BGP presents a comprehensive suite of knobs to deal with complex policies, such as the following:

• Communities

• AS_PATH filters

• Local preference

• Multiple exit discriminator (MED

Highlighting BGP-based SDN

BGP-based SDN involves two main solution components that may be integrated into several existing BGP technologies. First, we have an SDN controller component that speaks BGP and decides what needs to be done. Second, we have a BGP originator component that sends BGP updates to the SDN controller and other BGP peers. For example, the controller could be a BGP software package running on Open Daylight. BGP originators are Linux daemons or traditional proprietary vendor devices running the BGP stack.

Creating an SDN architecture

To create the SDN architecture, these components are integrated with existing BGP technologies, such as BGP FlowSpec (RFC 5575), L3VPN (RFC4364), EVPN (RFC 7432), and BGP-LS. BGP FlowSpec distributes forwarding entries, such as ACL and PBR, to devices’ TCAMs. L3VPN and EVPN offer the mechanism to integrate with legacy networks and service insertion. BGP-LS extracts IGP network topology information and passes it to the SDN controller via BGP updates.

**Central policy, visibility, and control**

Introducing BGP into the SDN framework does not mean a centralized control plane. We still have a central policy, visibility, and control, but this is not a centralized control plane. A centralized control plane would involve local control plane protocols establishing adjacencies or other ties to the controller. In this case, the forwarding devices outright require the controller to forward packets; forwarding functionality is limited when the controller is down.

If the BGP SDN controller acts as a BGP route reflector, all announcements go to the controller, but the network runs fine without it. The controller is just adding value to the usual forwarding process. BGP-based SDN architecture augments the network; it does not replace it.

Decentralizing the control plane is the only way; look at Big Switch and NEC’s SDN design changes over the last few years. Centralized control planes cannot scale.

Why use BGP?

BGP is well-understood and field-tested. It has been extended on many occasions to carry additional types of information, such as MAC addresses and labels. Technically, BGP can be used as a replacement for Label Distribution Protocol (LDP) in an MPLS core. Labels can be assigned to IPv6 prefixes (6PE) and labeled switched across an IPv4-only MPLS core.

BGP is very extensible. It started with IPv4 forwarding, and address families were added for multicast and VPN traffic. Using multiple addresses inside a single BGP process was widely accepted and implemented as a core technology. The entire Internet is made up of BGP, and it carries over 500,000 prefixes. It’s very scalable and robust. Some MPLS service providers are carrying over 1 million customer routes.

The use of open-source BGP daemons

There are many high-quality open-source BGP daemons available. Quagga is one of the most popular, and its quality has improved since it adopted Cumulus and Google. Quagga is a routing suite that provides IGP support for IS-IS and OSPF. Also, a BIRD daemon is available. The implementation is based around Internet exchange points as the route server element. BIRD is currently carrying over 100,000 prefixes.

Using BGP-based SDN on an SDN controller integrates easily with your existing network. You don’t have to replace any existing equipment, deploy the controller, and implement the add-on functionality that BGP SDN offers. It enables a preferred step-by-step migration approach, not a risky big bang OpenFlow deployment.

IGP to the controller?

Why not run OSPF or ISIS to the controller? IS-IS is extendable with TLVs and, too, can carry a variety of information. The real problem is not extensibility but the lack of trust and policy control. IGP extension to the SDN controller with few controls could present a problem. OSPF sends LSA packets; there is no input filter. BGP is designed with policy control in mind and acts as a filter by implementing controls on individual BGP sessions.

BGP offers control on the network side and predicts what the controller can do. For example, the blast radius is restricted if the controller encounters a bug or is compromised. BGP also provides excellent policy mechanisms between the SDN controller and physical infrastructure.

Example IGP Technology: IPv6 OSPFv3

**The Evolution from OSPFv2 to OSPFv3**

OSPFv2, originally developed for IPv4, has been a reliable protocol for decades. However, with the transition to IPv6, a more robust solution was needed to handle the complexities of the new addressing scheme. Enter OSPFv3. This updated version retains the core principles of OSPFv2, such as using link-state routing and the Dijkstra algorithm, but introduces significant improvements. OSPFv3 supports larger address spaces, offers better security options, and is more flexible in its deployment, making it a natural choice for IPv6 networks.

**Key Features of OSPFv3**

One of the standout features of OSPFv3 is its address family support, which allows for the simultaneous routing of both IPv4 and IPv6. This dual capability is essential for networks transitioning between the two protocols. Additionally, OSPFv3 enhances security through the use of IPsec for authentication and confidentiality, addressing the vulnerabilities present in OSPFv2. The protocol also introduces a simplified packet structure, reducing overhead and increasing efficiency in data transmission.

**Implementing OSPFv3 in Your Network**

For network administrators, implementing OSPFv3 can seem daunting, but the benefits far outweigh the challenges. The protocol’s compatibility with both IPv4 and IPv6 means that it can be integrated into existing infrastructure with minimal disruption. When setting up OSPFv3, it’s crucial to ensure that all routers in the network are configured correctly to prevent routing loops and ensure seamless data flow. Regularly updating network configurations and monitoring performance can help maintain optimal operation.

Introducing BGP-LS

SDN requires complete topology visibility. The picture is incomplete if some topology information is hidden in IGP and other NLRIs in BGP. If you have an existing IGP, how do you propagate this information to the BGP controller? Border Gateway Protocol Link-State (BGP-LS) is cleaner than establishing an IGP peering relationship with the SDN controller.

BGP-LS extracts network topology information and updates it to the BGP controller. Once again, BGPv4 is extended to provide the capability to include the new Network Layer Reachability Information (NLRI) encoding format. It sends information from IS-IS or OSPF topology database through BGP updates to the SDN controller. BGP-LS can configure the session to be unidirectional and stop incoming updates to enhance security between the physical and SDN worlds.

SDN controller cannot leak information back

As a result, the SDN controller cannot leak information back into the running network. BGP-LS is a relatively new concept. It focuses on the mechanism to export IGP information and does not describe how the SDN controller can use it. Once the controller has the complete topology information, it may be integrated with traffic engineers and external path computing solutions to interact with information usually only carried by an IGP database.

For example, the Traffic Engineering Database (TED), built by ISIS and OSPF-TE extensions, is typically distributed by IGPs within the network. Previously, each node maintained its own TED, but now, this can be exported to a BGP RR SDN application for better visibility.

BGP scale-out architectures

SDN controller will always become the scalability bottleneck. It can scale better when it’s not participating in data plane activity, but eventually, it will reach its limits. Every controller implementation eventually hits this point. The only way to grow is to scale out.

Reachability and policy information is synchronized between individual controllers. For example, reachability information can be transferred and synchronized with MP-BGP, L3VPN for IP routing, or EVPN for layer-2 forwarding.

Utilizing BGP between controllers offers additional benefits. Each controller can be placed in a separate availability zone, and tight BGP policy controls are implemented on BGP sessions connecting those domains, offering a clean failure domain separation.

An error in one available zone is not propagated to the next available zone. BGP is a very scalable protocol, and the failure domains can be as large as you want, but the more significant the domain, the longer the convergence times. Adjust the size of failure domains to meet scalability and convergence requirements.

Final Points: BGP-Based SDN

To appreciate the value of BGP-based SDN, it is essential to understand its components. BGP, the protocol that powers the internet by determining the best paths for data transmission, offers unparalleled scalability and stability. On the other hand, SDN introduces a dynamic and flexible approach to network management by decoupling the control plane from the data plane. When combined, BGP’s robust path selection and SDN’s centralized control create a network environment that is both resilient and adaptive to changing demands.

One of the primary advantages of integrating BGP with SDN is its ability to enhance network visibility and control. With centralized management, network administrators can implement comprehensive policies that optimize traffic flow, reduce latency, and improve security. Additionally, BGP-based SDN facilitates rapid deployment of new services and applications, enabling businesses to respond swiftly to market changes. This synergy also simplifies network troubleshooting and maintenance, leading to reduced operational costs and increased uptime.

BGP-based SDN is not just a theoretical concept; it is being actively implemented across various sectors. In data centers, it enables efficient resource utilization and supports the seamless scaling of services. Telecommunications companies leverage BGP-based SDN for efficient routing and traffic engineering, ensuring optimal performance and reliability. Furthermore, enterprises adopting hybrid cloud environments benefit from the enhanced connectivity and simplified management that this approach offers, allowing them to maintain competitive advantage in a digital-first world.

Summary: BGP-Based SDN

In today’s rapidly evolving technological landscape, software-defined networking (SDN) has emerged as a groundbreaking approach to network management. One of the key components within the realm of SDN is the Border Gateway Protocol (BGP). In this blog post, we delved into the world of BGP SDN, exploring its significance, functionality, and how it transforms traditional networking architectures.

Understanding BGP

BGP, or Border Gateway Protocol, is a routing protocol that facilitates the exchange of routing information between different autonomous systems (AS). It plays a crucial role in determining the optimal path for data packets to traverse across the internet. Unlike other routing protocols, BGP operates on a policy-based routing model, allowing network administrators to have granular control over traffic flow and network policies.

The Evolution of SDN

To comprehend the importance of BGP SDN, it is essential to understand the evolution of software-defined networking. SDN revolutionizes traditional network architectures by decoupling the control plane from the underlying physical infrastructure. This separation enables centralized network control, programmability, and dynamic configuration, enhancing flexibility and scalability.

BGP in the SDN Paradigm

Within the SDN framework, BGP plays a pivotal role in interconnecting different SDN domains, providing a scalable and flexible solution for routing between virtual networks. By incorporating BGP into the SDN architecture, organizations can achieve dynamic network provisioning, traffic engineering, and efficient handling of network policy changes.

Benefits of BGP SDN

The integration of BGP within the SDN paradigm brings forth numerous benefits. Firstly, it enables seamless interoperability between SDN and traditional networking environments, ensuring a smooth transition towards software-defined infrastructures. Additionally, BGP SDN empowers network administrators with enhanced control and visibility, simplifying the management of complex network topologies and policies.

Conclusion:

In conclusion, BGP SDN represents a significant milestone in the networking industry. Its ability to merge the power of BGP with the flexibility of software-defined networking opens new horizons for network management. By embracing BGP SDN, organizations can achieve greater agility, scalability, and control over their networks, ultimately leading to more efficient and adaptable infrastructures.

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 ```