OpenFlow Protocol

September 24, 2015

by Matt Conran Blog

OpenFlow Protocol

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

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

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

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

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

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

Matt Conran

Highlights: OpenFlow Protocol

Understanding OpenFlow Protocol

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

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

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

Key Point: Flow-Based Forwarding

## Understanding the Basics of Flow-Based Forwarding

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

## The Role of OpenFlow in Flow-Based Forwarding

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

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

Key OpenFlow Benefits

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

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

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

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

Key OpenFlow Features

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

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

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

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

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

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

OpenFlow Use Cases

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

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

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

SDN: A History Guide

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

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

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

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

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

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

Example Technology: Policy-Based Routing

**The Mechanics of Policy-Based Routing**

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

**Benefits of Implementing PBR**

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

**Challenges and Considerations**

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

Real-World Applications of OpenFlow

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

**The Creation of Virtual Networks**

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

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

OpenFlow Protocol

OpenFlow history

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

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

Highlighting SDN

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

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

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

A key point: The OpenFlow Protocol versions

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

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

OpenFlow Protocol: Separation of Planes

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

A: – The data plane

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

B: – The control plane

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

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

C: – The management plane

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

Diagram: Switch functions. Source is Bradhedlund

The Idea of OpenFlow Protocol

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

Example: Use case of vendors and OpenFlow hardware.

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

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

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

A key point: Open vSwitch

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

OVS bridge — Diagram: OVS Bridge: Source OpenvSwitch.

A key point: OpenFlow and Open Networking

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

OpenFlow protocol and decoupling

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

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

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

Flow table and OpenFlow forwarding model

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

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

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

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

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

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

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

OpenFlow ports

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

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

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

TCAM download protocol

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

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

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

OpenFlow Classifiers

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

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

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

OpenFlow Groups

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

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

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

Final Points: OpenFlow Protocol

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

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

Summary: OpenFlow Protocol

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

Understanding OpenFlow

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

The Key Components of OpenFlow

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

Benefits and Advantages

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

Real-World Applications

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

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

OpenFlow and SDN Adoption

August 20, 2015

by Matt Conran Blog

OpenFlow and SDN Adoption

In the ever-evolving world of networking, new technologies and approaches continue to reshape the landscape. One such technology that has gained significant attention is OpenFlow, which forms the backbone of Software-Defined Networking (SDN). In this blog post, we will delve into the concept of OpenFlow and explore its growing adoption in the networking industry.

OpenFlow can be best described as a protocol that enables the separation of the control plane and the data plane in a network. Traditionally, network devices handled both the control and data forwarding aspects, leading to limited flexibility and scalability. With OpenFlow, the control plane is centralized in a controller, allowing for dynamic network management and programmability.

Benefits of OpenFlow: The adoption of OpenFlow brings forth a multitude of benefits. Firstly, it offers network administrators unprecedented control and visibility into the network, empowering them to efficiently manage traffic flows and implement changes on the fly. Additionally, OpenFlow promotes network programmability, enabling the development of innovative applications and services that can harness the full potential of the network infrastructure.

OpenFlow in Action: Numerous organizations and industries have recognized the potential of OpenFlow and have embraced it in their networks. For instance, data centers have leveraged OpenFlow to create virtual networks with enhanced security and improved resource allocation. Internet Service Providers (ISPs) have also adopted OpenFlow to optimize traffic routing and enhance network performance.

Challenges and Considerations: While OpenFlow holds great promise, it is not without its challenges. One of the primary concerns is ensuring interoperability across different vendors and devices, as OpenFlow relies on a standard set of protocols and features. Additionally, network security and policy enforcement must be carefully addressed to prevent unauthorized access and protect sensitive data.

OpenFlow and SDN adoption are revolutionizing the networking industry, offering unprecedented control, programmability, and scalability. As organizations continue to recognize the benefits of OpenFlow, we can expect to see further advancements and innovations in the realm of network management and infrastructure.

Matt Conran

Highlights: OpenFlow and SDN Adoption

Understanding OpenFlow

OpenFlow is a communication protocol that enables the separation of the control plane and the data plane in network switches. By doing so, it allows for centralized control and programmability of network devices. This revolutionary approach replaces traditional, fixed-function network devices with programmable switches, enabling more flexibility and agility in network management.

SDN provides network administrators with a holistic view of the network, allowing them to monitor and manage network traffic with granular control. This increased visibility enables better troubleshooting, efficient resource allocation, and improved security measures.

**Simplified Network Management**

With SDN, network configurations can be abstracted and managed through software, eliminating the need for manual, device-by-device configuration changes. This simplification streamlines network management, reduces human errors, and accelerates network provisioning and deployment.

The programmability of SDN allows for dynamic network provisioning and scaling, making it easier to adapt to changing network demands. Whether it’s scaling up to accommodate increased traffic or reconfiguring network paths, SDN offers unparalleled flexibility, enabling networks to evolve and grow seamlessly.

**SDN & Virtualization**

SDN opens doors to network virtualization, where multiple virtual networks can coexist on a shared physical network infrastructure. This concept enables efficient resource utilization, isolation of traffic, and improved network efficiency.

By decoupling the control plane from the data plane, SDN fosters an environment for experimentation and innovation. Developers can create and deploy custom network applications, allowing for rapid prototyping and testing of new networking concepts without disrupting the underlying infrastructure.

**Basics of Network Virtualization**

Network virtualization involves creating a virtual network that operates independently of the underlying physical hardware. This is achieved through software-defined networking (SDN) and network functions virtualization (NFV). SDN separates the network’s control plane from the data plane, allowing for centralized management and control of network traffic. NFV, on the other hand, replaces traditional network hardware functions with software-based solutions, enabling greater flexibility and scalability.

Use Cases and Real-World Applications

A: -) OpenFlow and SDN have been found to be extensively used in various domains and industries. From data centers and cloud computing environments to enterprise networks and even telecommunications, the versatility of OpenFlow and SDN is undeniable.

B: -) They enable dynamic traffic engineering, efficient load balancing, and improved network security. Furthermore, SDN has paved the way for network function virtualization (NFV), allowing the deployment of network services as software applications rather than dedicated hardware.

Background: OpenFlow L2 Switching & VLAN Handling

Layer 2 OpenFlow switching relies on a structured pipeline where packets enter Table 0 for initial classification and then move to Table 1 for forwarding. VLAN tags play a central role in segmenting traffic, and actions such as push_vlan, pop_vlan, and set_vlan_id allow the pipeline to add, remove, or rewrite VLAN identifiers as packets traverse the network. This lab demonstrates how VLAN-aware forwarding behaves inside an SDN-driven LAN.

When a packet arrives, the switch evaluates its fields—source MAC, destination MAC, and VLAN ID—against the flow entries in each table. If a match exists, the associated actions are applied, modifying the VLAN tag or directing the packet to the correct output port. If no match is found, the packet is surfaced for further processing, allowing new flow entries to be added dynamically. This mechanism ensures the pipeline adapts to traffic patterns and VLAN requirements.

The three test cases highlight different aspects of VLAN manipulation within the OpenFlow pipeline. Test 1 shows VLAN retagging, where traffic arriving on VLAN 10 is processed and forwarded using VLAN 20. Test 2 demonstrates VLAN removal, with VLAN 30 traffic being stripped and delivered as an untagged frame. Test 3 illustrates VLAN rewriting, where an unknown VLAN 999 is converted into VLAN 20 to maintain consistent segmentation across the forwarding path.

These tests collectively show how flexible VLAN handling enables predictable forwarding in SDN-based LANs. By retagging, removing, or rewriting VLANs, the pipeline ensures that hosts receive traffic in the correct segment regardless of how packets enter the network. This approach eliminates reliance on traditional MAC learning and provides deterministic, rule-driven forwarding that scales cleanly across multi-switch topologies.

Impact on the Networking Landscape

– At its core, OpenFlow is a communications protocol that enables the separation of the control plane and the data plane in networking devices. It allows for the programmability and centralized control of network switches and routers. With OpenFlow, network administrators can dynamically manage traffic, define routing paths, and apply policies, all through a centralized controller.

– SDN takes the concept of OpenFlow further by providing a framework for network management and configuration. It abstracts the underlying network infrastructure and allows for programmability and automation through a software-based controller. SDN architectures offer flexibility, scalability, and agility, making adapting to evolving network demands easier.

– The combination of OpenFlow and SDN brings numerous benefits to network operators, administrators, and end-users. Firstly, it simplifies network management by providing a centralized view and control of the entire network.

– This simplification leads to enhanced network visibility, easier troubleshooting, and faster deployment of new services. Additionally, OpenFlow and SDN enable network virtualization, allowing for the creation of logical networks decoupled from the physical infrastructure.

The SDN Layers

The Application Layer:

As its name suggests, this layer includes network applications. Examples of these applications include communication applications, such as VoIP prioritization, and security applications, such as firewalls. Also included in this layer are utilities and network services.

Switches and routers traditionally handled these applications. SDN simplifies their management by offloading them. In addition, companies can save a lot of money by stripping down the hardware.

The Control Layer:

Switches and routers are now controlled by a centralized control plane, which allows the network to be programmed. As an open-source network protocol, OpenFlow has become the industry standard despite Cisco’s OpenFlow variant.

The Infrastructure Layer:

This layer includes data, switches, and routers. Traffic is moved according to flow tables. SDN leaves this layer essentially unchanged since routers and switches still move packets. The main difference is the centralization of traffic flow rules. However, the intelligence of vendor devices is not stripped away.

The API provides centralized control of SDN for large network providers to protect their intellectual property. However, the cost of generic packet-forwarding devices is much lower than traditional networking equipment.

A Programmable Network

Developers have made it possible for network administrators to create “slices” that allow generic networking hardware to support multiple configurations by adding a virtualization layer between the control system and the hardware layer. It resembles how a hypervisor can run a virtual machine (VM) on a single server. Using SDN, an administrator can create different rules and applications for various groups of users.

Because most applications are not installed on the devices, SDN enables the network to appear as one big switch/router. There could be three devices on the network or 30,000. They are all the same as centralized applications. (Some applications are just nodes on the network.) Therefore, upgrades, changes, additions, and configurations are much more accessible.

The role of OpenFlow

Firstly, the basis of the SDN adoption report is the OpenFlow protocol, an existing technology derived from academic labs. Its origins can be traced back to 2006 when Martin Casado, part of the “Clean Slate” program, developed Ethane. They were trying to figure out ways to manage the network states via a centrally managed global policy.

The idea that networks are dynamic and non-symmetrical poses challenges in keeping track of their state to enforce programmability. The program has stopped but produced several follow-up programs, including OpenFlow and SDN.

SDN OpenFlow is not revolutionary new. Similar ideas have been available, and previous projects have tried to solve the same problems OpenFlow is trying to solve today. Besides the central viewpoint use case, whatever you can do with OpenFlow today is possible with Policy-Based Routing (PBR) and ACL. The problem is that these tools are clumsy and do not scale well.

You may find the following useful for pre-information:

OpenFlow and SDN Adoption

What is OpenFlow?

OpenFlow is an open standard that enables the separation of the control plane and the data plane in network devices. It allows network administrators to centrally control and manage the behavior of network switches and routers, resulting in increased network programmability, flexibility, and scalability. OpenFlow provides a standardized protocol that facilitates communication between the control and data planes, enabling the network to be programmed and controlled through software.

Understanding SDN Adoption:

SDN is a paradigm shift in network architecture that leverages OpenFlow and other technologies to virtualize and abstract network resources. With SDN, the control plane is decoupled from the underlying physical infrastructure, allowing network administrators to configure and manage networks dynamically through a centralized controller. This centralized control simplifies network operations, enhances automation, and creates innovative network services.

The use of APIs:

Besides the network abstraction, the SDN architecture will deliver a set of APIs that streamline the implementation of standard network services. These network services include routing, security, access control, and traffic engineering. Consequently, we can achieve exceptional programmability, automation, and network control, enabling us to build highly scalable and flexible networks that readily adapt to changing business needs. Then, we have OpenFlow and the SDN story. OpenFlow is the first standard interface explicitly designed for SDN, providing high-performance and granular traffic control across multiple networking devices.

Benefits of OpenFlow and SDN Adoption

The adoption of OpenFlow and SDN comes with numerous benefits for organizations of all sizes:

1. Enhanced Network Programmability: OpenFlow and SDN enable network administrators to program and control networks through software, making implementing new network services and policies easier.

2. Increased Flexibility and Scalability: SDN allows for dynamic network reconfiguration and resource allocation, ensuring networks can adapt to changing requirements and scale efficiently.

3. Centralized Network Management: With SDN, network administrators can manage and configure multiple network devices from a centralized controller, simplifying network operations and reducing the complexity of managing traditional networks.

4. Improved Network Security: SDN facilitates the implementation of granular security policies, enabling network administrators to quickly detect and respond to security threats, enhancing overall network security.

Challenges and Considerations

While OpenFlow and SDN offer significant advantages, their adoption comes with a few challenges that organizations need to address:

1. Compatibility: Not all network devices and vendors fully support OpenFlow and SDN, requiring organizations to consider device compatibility carefully before implementation.

2. Skillset and Training: SDN introduces new concepts and requires network administrators to acquire skills and knowledge to deploy and manage SDN-based networks effectively.

3. Transition from Legacy Infrastructure: Migrating from traditional networking solutions to SDN-based architectures requires careful planning and a phased approach to minimize disruptions and ensure a smooth transition.

Starting Points for SDN Adoption

SDN Architectures and OpenFlow

SDN architectures and OpenFlow offer several advantages. You can influence traffic forwarding behavior at a more granular flow level. A holistic view instead of a partial view of distributed devices simplifies the network. Traffic engineering with SDN becomes easier to implement when you have a centralized view; this is how Google implemented SDN. Google has two network backbones: an Internet-facing backbone and a data center backbone.

They noticed that the cost/bit was not decreasing as the network grew. It was doing the opposite. Their solution was to implement a centralized controller and manage the WAN as a fabric, not as a collection of individual nodes.

SDN adoption report: Virtual switching fabric

SDN architectures allow networks to move from loosely coupled systems to a virtual switching fabric. One extensive flat virtualized network that appears and can be managed as a single switch has many operational advantages. The switch fabric consists of multiple physical nodes but behaves like one big switch. For example, a port on any underlying switch fabric nodes or virtual switch appears as a port to the single switching fabric.

The entire data plane becomes an abstraction. By employing this architecture, we manage the data plane as a whole entity instead of a set of loosely coupled connected devices. If we study existing networks, the control and data planes are distributed to the same locations. No central point controls individual nodes, resulting in complex cross-network interactions.

Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) calculates the shortest path tree from each node to every other node. Each OSPF neighbor must establish an adjacency and build and synchronize the link-state databases (LSB). The complexity can be reduced by designing OSPF areas with ABRs but by sacrificing some precision of route information. Imagine that every node reports and synchronizes its LSB to a central controller with an OSPF SDN application instead of individual nodes.

The controller can perform the Shortest Path First (SPF) calculation and directly update each node’s forwarding information base (FIB). The network now becomes programmable. While it does bring advantages, the laws of physics have not changed.

OpenFlow does not decrease latency or let you push more bits through a link. It does, however, let you better manage and control your network. It removes the box-by-box mentality and introduces automation and programmability.

Example Routing Technology with OSPF

#### Introduction to OSPFv3

In the realm of networking, efficient and reliable routing protocols are crucial for ensuring seamless data transmission. One such protocol that has gained prominence is OSPFv3 (Open Shortest Path First version 3). This blog post will delve into the intricacies of OSPFv3, exploring its features, benefits, and the role it plays in modern networks.

#### Understanding OSPFv3 Basics

OSPFv3 is an evolution of the OSPF protocol, specifically designed to support IPv6. While it retains the core functionalities of its predecessor, OSPFv2, OSPFv3 brings enhancements that make it more suitable for IPv6-based networks. Unlike OSPFv2, which operates at the network layer, OSPFv3 is designed to work with both IPv4 and IPv6, offering greater flexibility and future-proofing networks as organizations transition to IPv6.

#### Key Features of OSPFv3

One of the standout features of OSPFv3 is its capability to support multiple instances per link. This means that different OSPFv3 processes can operate over the same network link, providing advanced network segmentation and improved routing efficiency. Additionally, OSPFv3 introduces a simplified header format, reducing overhead and enhancing performance. The protocol also supports address families, allowing for more granular control over routing decisions.

#### OSPFv3 vs. OSPFv2: What’s the Difference?

While OSPFv2 and OSPFv3 share a common heritage, there are notable differences between them. OSPFv3’s support for IPv6 is the most significant distinction, but it also includes changes in LSA (Link State Advertisement) types and packet structures. Furthermore, OSPFv3 operates with a more modular approach, separating topology information from routing information, thereby improving scalability and efficiency in complex network environments.

Do you think OpenFlow will be derailed?

SDN OpenFlow has come up against some market adoption barriers, such as silicon challenges and numerous vendor-specific extensions. In addition, the lack of conformance tests has led to some inconsistencies. It depends on how you define it. To explain it, you need to know what it is not. It is not a controller or a forwarding switch but a communication between the two.

It has a distinct place in the SDN architecture and does not run anywhere except between the control (controller) and the data plane, such as the OVS bridge acting as the switch infrastructure. SDN OpenFlow is also not alone in this space; other technologies provide control and data plane communications, such as BGP, Open vSwitch Database Management Protocol (OVSDB), NETCONF, and Extensible Message and Presence Protocol (XMPP).

Juniper’s OpenContrail uses XMPP.

It is evolving, and emerging technologies are sometimes slow to adopt. For example, in the early days of Novell networks, there were 4-frame types. Likewise, OpenFlow is changing and adapting as time progresses. For example, the original version of OpenFlow did not have multiple flow tables; now, versions 1.3 and 1.4 have multiple tables with various actions and many additional features.

Will it be used for program forwarding paths instead of BGP?

Probably not, but it will augment BGP and other traditional technologies. It is not strictly a YES or NO answer as the SDN adoption falls into two buckets: one with OpenFlow and one without. Take the IPv6 adaptations as the IPv4 “replacement.” There was a “D” day of IPv4 address exhaustion, but IPv4 is still widely used. New “transition” mechanisms such as 6to4 and NAT64 are still widely deployed. It is the same with SDN and OpenFlow.

Example IPv6 Technology: NAT64

**How NAT64 Works**

NAT64, short for Network Address Translation from IPv6 to IPv4, acts as a translator between IPv6 and IPv4. It allows IPv6 clients to access IPv4 services by translating IPv6 addresses into IPv4 addresses and vice versa. This is achieved through a NAT64 gateway, which facilitates the exchange of data between the two different protocols. The gateway assigns an IPv6 prefix for the IPv4 address pool, enabling seamless communication across the network. Understanding this process is vital for network administrators tasked with managing hybrid networks during the transition phase.

**Benefits of Implementing NAT64**

Implementing NAT64 offers numerous benefits for organizations and network administrators. Firstly, it aids in the gradual transition to IPv6 by allowing IPv6-only devices to access IPv4 content. This is particularly beneficial for mobile networks and new internet service providers aiming to future-proof their infrastructure. Additionally, NAT64 reduces the need for dual-stack configurations, which can be complex and resource-intensive. By simplifying network configurations, NAT64 helps cut operational costs and streamline network management.

There will be ways to make traditional networks communicate with SDN and OpenFlow. BGP was invented as an EBGP, but people use EBGP Internal in their network. BGP is also used as an SDN control plane. It will be the case that you have controllers that provide automation and a holistic view but can speak BGP or OSPF to program the forwarding devices. SDN migrations will come incrementally, similar to what we see with IPv4 and IPv6

The lack of clarity in the controller space has limited OpenFlow’s progress. However, the controller market is consolidating now, which gives users a clear path forward. This emergence is a good thing and will move OpenFlow forward. Maintaining SDN applications on different controllers is a dead end, but now that OpenDaylight is emerging, we have controller unity.

A market with numerous open-source controllers would make SDN application development difficult. There will always be business drivers for proprietary controllers serving a particular niche and corner case problems the open community did not invest in. Even today, specialized UNIX platforms exist when you look at open Linux. Similarly, this adoption of technology will be evident for OpenFlow controllers.

Example BGP Technology: EBGP and IBGP

### Understanding BGP: The Basics

Before diving into the preferences, it’s crucial to understand what BGP is. Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the internet. It is key to ensuring data finds the most efficient path across the complex web of networks.

– **eBGP vs. iBGP:** eBGP is used for communication between different autonomous systems, while iBGP is used within the same autonomous system. This distinction is fundamental in understanding their roles and why eBGP is often preferred.

### The Preference for eBGP: Key Reasons

1. **Policy Control and Flexibility:** eBGP allows for more granular policy control, enabling network administrators to implement routing policies that align with business objectives. This flexibility is less pronounced in iBGP, which is typically used to propagate routes within an AS.

2. **Route Propagation and Stability:** eBGP sessions are generally between routers in different administrative domains, which inherently adds a layer of stability and security in route propagation. eBGP routes are often considered more reliable due to the distinct boundaries they operate across.

3. **Loop Prevention Mechanics:** eBGP inherently prevents routing loops by default, due to its AS-path attribute which records the path that routing information has traversed. iBGP requires additional mechanisms, such as route reflectors or confederations, to handle loop prevention efficiently.

### Practical Implications for Network Administrators

Understanding the preference for eBGP over iBGP can significantly impact how network administrators design and manage networks. For instance, leveraging eBGP for inter-AS communication can lead to more robust and secure network architectures. Additionally, the ability to set preferences for route selection can optimize traffic flow and enhance network performance.

The Future of OpenFlow and SDN:

The adoption of OpenFlow and SDN has gained significant momentum in recent years, and the future looks promising for these technologies. With the increasing demand for flexible, scalable, and programmable networks, OpenFlow and SDN are vital in deploying 5G networks, Internet of Things (IoT) applications, and network virtualization.

OpenFlow and SDN adoption revolutionizes network infrastructure, offering increased programmability, flexibility, and centralized management. While challenges exist, the benefits of OpenFlow and SDN far outweigh the drawbacks.

As organizations continue to embrace digital transformation, OpenFlow and SDN will continue to shape the future of networking, enabling agile, scalable, and secure networks that can adapt to the evolving needs of modern businesses.

Closing Points on SDN and OpenFlow

In the realm of modern networking, OpenFlow and Software-Defined Networking (SDN) stand as pioneers of a transformative journey. Traditional networks, often rigid and complex, are evolving into more dynamic and programmable entities, thanks to these groundbreaking technologies. OpenFlow, a protocol that enables the separation of the control and data planes, is at the heart of this transformation. Combined with SDN, which offers centralized control over network devices, organizations can now manage their networks with unprecedented flexibility and efficiency.

Adopting OpenFlow and SDN brings a plethora of advantages. First and foremost, network administrators gain enhanced control and visibility over their entire network infrastructure. This centralized management simplifies the deployment of new services and reduces the time needed for troubleshooting. Additionally, the programmability of SDN allows for rapid adaptation to changing business needs, providing a competitive edge in today’s fast-paced digital landscape. Cost savings are another major benefit, as organizations can optimize resource usage and reduce hardware dependency.

While the benefits are clear, the road to adopting OpenFlow and SDN is not without its challenges. One of the primary obstacles is the need for a shift in mindset. Network engineers accustomed to traditional methods must embrace new skills and paradigms. There is also the challenge of interoperability, as integrating OpenFlow and SDN with existing systems can be complex. Security concerns, too, must be addressed, as the centralized nature of SDN can introduce new vulnerabilities if not properly managed.

Despite the challenges, many organizations have successfully adopted OpenFlow and SDN. For instance, large data centers and cloud service providers have leveraged these technologies to enhance scalability and performance. In the telecommunications sector, companies have implemented SDN to improve network traffic management and service delivery. These success stories illustrate the transformative potential of OpenFlow and SDN, providing a blueprint for others to follow.

Summary: OpenFlow and SDN Adoption

In today’s rapidly evolving technological landscape, Software-Defined Networking (SDN) and OpenFlow have emerged as game-changing innovations revolutionizing the world of networking. This blog post delves into the intricacies of SDN and OpenFlow, exploring their capabilities, benefits, and their potential to reshape the future of networking.

Understanding SDN

SDN, short for Software-Defined Networking, is a paradigm that separates the control plane from the data plane, enabling centralized network management. Unlike traditional networking approaches, SDN decouples network control, making it programmable and agile. It empowers network administrators with unprecedented flexibility and control over their infrastructure.

Unveiling OpenFlow

At the core of SDN lies OpenFlow, a protocol that enables communication between the control and data planes. OpenFlow facilitates the flow of network packets, allowing administrators to define and manage network traffic dynamically. Providing a standardized interface promotes interoperability between different vendors’ networking equipment, fostering innovation and cost-effectiveness.

Benefits of SDN and OpenFlow

Enhanced Network Flexibility and Scalability: SDN and OpenFlow enable network administrators to adjust network resources dynamically, optimize traffic flow, and respond to changing demands. This flexibility and scalability empower organizations to adapt swiftly to evolving network requirements, ensuring efficient resource utilization.

Simplified Network Management: With SDN and OpenFlow, network administrators can centrally manage and orchestrate network devices, eliminating the need for manual configurations on individual devices. This centralized control simplifies network management, reduces human errors, and accelerates the deployment of new services.

Improved Network Security: SDN’s centralized control allows for better security management. Administrators gain granular control over network access, threat detection, and response by implementing security policies and protocols at the controller level. This enhanced security posture helps safeguard critical assets and data.

Data Center Networking: SDN and OpenFlow find extensive applications in data centers, where virtualization and cloud computing demand dynamic resource allocation and efficient traffic management. By abstracting network control, SDN facilitates seamless scalability, load balancing, and efficient utilization of data center resources.

Campus and Enterprise Networks: In campus and enterprise networks, SDN and OpenFlow enable administrators to manage and optimize network traffic, prioritize critical applications, and quickly respond to changing user demands. These technologies also facilitate network slicing, allowing organizations to create virtual networks tailored to specific requirements.

In conclusion, SDN and OpenFlow represent a paradigm shift in networking, offering immense potential for increased efficiency, scalability, and security. As organizations continue to embrace digital transformation, these technologies will play a pivotal role in shaping the future of networking. By decoupling network control and leveraging the power of programmability, SDN and OpenFlow empower administrators to build agile, intelligent, and future-ready networks.

Optimal Layer 3 Forwarding

March 10, 2015

by Matt Conran Blog

Network Insight · Routing & Forwarding

Optimal Layer 3 Forwarding

How does a router decide where a packet should go next? Optimal Layer 3 forwarding brings together routing information, next-hop selection and hardware-assisted packet forwarding to move traffic efficiently across an IP network.

Every packet travelling beyond its local IP subnet depends on a sequence of forwarding decisions. A router examines the destination IP address, consults its forwarding information and identifies the appropriate next hop and outgoing interface. Repeating this process across the network allows packets to reach remote destinations.

The challenge is not simply finding a route. Networks must select suitable paths, resolve next-hop addresses, use available link capacity and respond to failures without creating unnecessary complexity. Routing protocols such as OSPF, EIGRP and BGP contribute routing information, while the router's forwarding plane applies the installed forwarding state to individual packets.

These decisions become especially important in data centres, enterprise networks and cloud environments, where multiple paths, redundant links, traffic policies and large routing tables influence how traffic moves. Technologies such as Cisco Express Forwarding (CEF), Equal-Cost Multipath (ECMP), policy-based routing and BGP multipath address different parts of this challenge.

The engineering principle

The best routing choice and the actual packet-forwarding action are related but distinct. Routing protocols determine eligible routes and best paths; the forwarding plane uses the installed forwarding table to send packets. Effective optimisation must consider reachability, policy, path cost, resilience and the capabilities of the network platform.

Your learning roadmap

Explore the Article

Navigate through the fundamentals, routing decisions, forwarding technologies and engineering practices behind optimal Layer 3 forwarding.

Ready to explore 0% viewed

Section 01 · Forwarding Fundamentals

How Layer 3 Forwarding Works

Layer 3 forwarding is the process of moving IP packets towards their destination across one or more networks. Each router makes a local forwarding decision using the packet's destination IP address and the forwarding information installed on that device.

When a packet arrives at a router, the router processes its Layer 2 frame, examines the IP header and identifies the destination address. It then looks up that address in its forwarding information base (FIB). The result identifies the applicable next hop, outgoing interface or other forwarding action.

The packet's destination IP address normally remains unchanged as it travels through ordinary routed networks. The Layer 2 header, however, is rewritten for the next link. At each routed hop, the router constructs an appropriate outgoing frame and forwards the packet, subject to the relevant forwarding and security rules.

The packet-forwarding sequence

1 Receive Accept the incoming frame and process its headers.

2 Look up Match the destination IP against the forwarding table.

3 Resolve Identify the next hop and required Layer 2 adjacency.

4 Forward Transmit the packet through the selected interface.

Routing table versus forwarding table

A router's routing information base (RIB) contains routes learned from connected networks, static configuration and routing protocols. Route selection determines which routes are eligible for installation. The selected results are used to program the FIB, which is optimised for packet forwarding. The precise implementation varies by platform.

Control plane · RIB

Learns and evaluates routes, applies routing policy, and determines which routes should be installed for forwarding.

Forwarding plane · FIB

Performs packet lookups using installed forwarding entries and directs traffic towards the appropriate next hop and interface.

Longest-prefix match: choosing the destination route

A router may have several routes that match a destination address. For ordinary IP forwarding, it selects the matching route with the longest prefix—the most specific network match. This is different from comparing routing protocols by administrative distance or comparing candidate BGP paths.

Consider a router with the following IPv4 routes and a packet destined for 10.20.30.45.

Route	Prefix specificity	Match?
10.0.0.0/8	Broad network	Yes
10.20.0.0/16	More specific	Yes
10.20.30.0/24	Most specific match	Selected

In this example, 10.20.30.0/24 wins because it matches more leading bits of the destination address than the broader routes. If no more-specific route exists, the router may use a less-specific matching route or a default route, provided one is installed and usable.

Engineering distinction: route selection is not longest-prefix match

Routing protocols and the router's route-installation process determine which routes become available for forwarding. Longest-prefix match then selects the most specific installed prefix for the packet's destination. These are separate stages of the forwarding process.

Next-hop resolution and Layer 2 rewriting

The selected route may identify a directly connected destination, a specific next-hop IP address, or a route through a tunnel or other logical interface. When forwarding over Ethernet, the router must also determine the destination MAC address for the next hop. IPv4 commonly uses ARP, while IPv6 uses Neighbor Discovery.

If the required adjacency is not yet available, the router may need to resolve it before forwarding can proceed. If the destination has no usable route, or a required next hop cannot be resolved, the packet may be dropped or handled according to the platform's configured behaviour.

Why this matters for optimal forwarding

Efficient forwarding depends on more than selecting a route. The installed FIB entry, next-hop reachability, interface state, adjacency information, hardware capacity and applicable policies all influence whether the packet can be forwarded successfully.

Key takeaway: Routing determines the available paths and installs forwarding state. Longest-prefix match identifies the applicable destination route, while next-hop resolution and the forwarding plane enable the packet to move onto the next link. These fundamentals provide the basis for understanding OSPF, EIGRP, BGP, ECMP and advanced data-centre forwarding.

Interactive Lab 01 · Forwarding Fundamentals

Follow a Packet Through a Router

Enter a destination IP address and see how a router compares routing entries, selects the most specific matching prefix, resolves the next hop and prepares the packet for forwarding.

Destination IPv4 address

Forwarding scenario

Forwarding decision

Route selected: 10.20.30.0/24

The destination matches several routes. The /24 prefix is the most specific matching route in this example.

Selected prefix 10.20.30.0/24

Next hop 192.0.2.1

Outgoing interface GigabitEthernet0/1

1. Compare the routing entries

The router considers only prefixes that contain the destination. The matching route with the longest prefix length wins.

Routing entry	Next hop	Match?	Decision
10.0.0.0/8	192.0.2.8	Yes	Less specific
10.20.0.0/16	192.0.2.16	Yes	Less specific
10.20.30.0/24	192.0.2.1	Yes	Selected
0.0.0.0/0	192.0.2.254	Yes	Fallback

2. Follow the forwarding process

Receive the IP packet

The router reads the destination address in the IP header.

Perform a forwarding lookup

The forwarding table is checked for matching destination prefixes.

Select the longest matching prefix

The most specific installed matching route determines the forwarding entry.

Resolve the next hop and adjacency

The router identifies the outgoing interface and the required Layer 2 rewrite.

Forward the packet

The router applies the relevant forwarding operations and transmits the packet, if the path is usable.

Engineering note: This is an educational model, not a live router or packet capture. Real routers forward using installed forwarding information and platform-specific hardware or software. Route installation, next-hop resolution, ACLs, MTU, TTL and other policies can affect whether a packet is actually forwarded.

Section 02 · Route Learning and Selection

Routing Protocols and Next-Hop Selection

Optimal Layer 3 forwarding starts with the routes available to a router. Connected networks, static configuration and dynamic routing protocols contribute routing information, but each source serves a different purpose. Understanding how routes are learned, selected and installed is essential to understanding the forwarding decision.

A router does not automatically use every route it learns. It evaluates route information, applies the platform's route-selection rules and routing policies, and installs eligible routes into its routing table. The resulting forwarding information is then used to move packets towards their destinations.

Where routes come from

Directly connected

Connected routes

Created when a Layer 3 interface is operational and has an appropriate IP address configured. These routes provide reachability to the associated connected subnet.

Manually configured

Static routes

Configured by an administrator to specify a destination and forwarding path. They can provide predictable routing, explicit traffic steering or a default route.

Internal routing

OSPF and EIGRP

Interior routing protocols exchange reachability information within an organisation or routing domain. Their algorithms and metrics help determine preferred internal paths.

Inter-domain routing

BGP

The Border Gateway Protocol exchanges reachability between autonomous systems and can also distribute routes within an autonomous system. Policy and path attributes play a central role.

Administrative distance and route preference

On platforms that use administrative distance, it expresses the relative trust assigned to routes from different sources when otherwise competing routes to the same destination are considered. A lower value is generally preferred. Administrative distance is vendor-specific and is not a universal metric shared between all routing implementations.

For example, a Cisco IOS-style configuration commonly uses the following default administrative-distance values. These values illustrate one vendor's convention; other vendors and configurations may differ.

Route source	Example distance	What it represents
Connected	0	Directly attached network
Static	1	Manually configured route
EIGRP internal	90	Internal EIGRP route
OSPF	110	Route learned through OSPF
RIP	120	Route learned through RIP
eBGP	20	Route learned from an external BGP peer
iBGP	200	Route learned from an internal BGP peer

Important: administrative distance is not the BGP best-path algorithm

Administrative distance is used by platforms that implement it to compare route sources. BGP first evaluates candidate paths using its own path-selection rules. Attributes such as local preference, AS_PATH, origin and MED can influence that decision, subject to the implementation and configuration. Administrative distance should not be confused with BGP path attributes.

How BGP selects a path

BGP can learn multiple paths to the same IP prefix from different peers. A router evaluates those paths using a sequence of decision rules. The exact order and available tie-breakers can vary by vendor, software version and configuration, so the following attributes should be understood as key factors rather than a universal complete decision sequence.

Attribute or factor	Role in path selection
Local Preference	Expresses the preferred exit path within an autonomous system; higher is generally preferred.
AS_PATH	Lists autonomous systems traversed; a shorter path is generally preferred when earlier decision criteria do not decide the outcome.
Origin	Indicates how the route was originated in BGP; IGP origin is generally preferred over EGP, then incomplete.
MED	Can signal a preferred entry point into an autonomous system; comparison behaviour depends on policy and implementation.
Next-hop reachability	The next hop must be resolvable for the path to be usable for forwarding.

BGP also uses other decision criteria, including locally configured policy, weight on some platforms, eBGP versus iBGP preference and tie-breakers. The path that wins is not necessarily the path with the lowest latency or the fewest physical hops. If the network needs to optimise for those properties, it may require explicit policy, measurement or traffic-engineering mechanisms.

Next-hop reachability: a selected route must be usable

Routing information can identify a next-hop address without that address being directly connected to the router. The router must resolve the next hop through another usable route or forwarding mechanism. In BGP, for example, an advertised prefix may carry a next-hop address that must be reachable through the local routing table.

If the next hop cannot be resolved, the route may be ineligible for installation or forwarding, depending on the protocol and platform. This is one reason why a routing protocol can appear operational while traffic to a particular destination still fails.

1. Learn Receive route information from connected, static or dynamic sources.

2. Evaluate Apply route-selection rules and routing policy to candidate routes.

3. Install Install eligible routes and build forwarding entries with usable next hops.

Engineering takeaway

A route in a protocol's database is not automatically proof that packets can use it. Check the selected route, its next-hop resolution, the installed FIB entry and the outgoing interface. These checks help distinguish a route-selection problem from a forwarding or adjacency problem.

Key takeaway: Connected routes, static routes, OSPF, EIGRP and BGP provide different ways to learn or define reachability. Route-selection rules determine which information is installed, and next-hop reachability determines whether the chosen path can actually support forwarding. The next section explores ECMP, hardware-assisted forwarding and data-centre designs that use these routes to distribute traffic efficiently.

Interactive Lab 02 · Routing Decisions

Who Wins the Route?

Explore two separate decisions: which route source is installed in the routing table, and which path BGP prefers within its own process. Change the inputs to see how each decision works.

Part A — Compare route sources

This example uses typical Cisco IOS administrative-distance defaults. Lower administrative distance is preferred when competing routes to the same prefix are otherwise eligible for installation.

Destination prefix

Static route availability

OSPF route available eBGP route available iBGP route available

Route installation result

Static route preferred

The static route has an administrative distance of 1 in this example, lower than the competing route sources.

Route-source comparison

Route source	Example AD	Available?	Result

Part B — Explore BGP best-path selection

Three illustrative BGP paths advertise the same prefix. Select a scenario to see how local preference, AS-path length and next-hop reachability can affect the outcome.

Illustrative BGP decision

Path A selected

Path A has the highest local preference among the currently eligible paths in this simplified example.

Understand the decision sequence

Check route eligibility

A route generally needs a valid, resolvable next hop to be usable.

Compare BGP attributes

Depending on the implementation and policy, attributes such as local preference and AS-path length influence selection.

Select and install the route

The BGP decision process selects a best path; the routing system then determines what is installed for forwarding.

Important: The route-source example and BGP example are separate models. Administrative-distance values are vendor-specific; the BGP model simplifies the full best-path algorithm and omits many implementation-specific tie-breakers. A real router may also retain multiple paths when multipath conditions are satisfied.

Section 03 · Multipath and High-Performance Networks

ECMP, CEF and Data-Centre Forwarding

Selecting a usable route is only part of optimal forwarding. Networks must also distribute traffic across available paths, forward packets efficiently at scale, and maintain connectivity when links or devices fail. ECMP, hardware-assisted forwarding and resilient Layer 3 designs help address these requirements.

In modern enterprise and data-centre networks, multiple paths may connect the same source and destination. Using more than one eligible path can increase aggregate capacity and reduce dependence on a single link. The forwarding design must balance traffic distribution, predictable packet delivery and fast recovery from failures.

Equal-Cost Multipath (ECMP)

ECMP allows a router to install and use multiple eligible next hops for the same destination prefix when those paths satisfy the platform's equal-cost and multipath rules. Instead of forwarding every packet over one next hop, the router can distribute traffic across the available forwarding paths.

Source

Destination

Conceptual illustration: multiple forwarding paths can serve traffic towards the same destination.

Many implementations use a hash based on packet or flow fields to select a next hop. This often keeps packets from the same flow on the same path, helping avoid packet reordering. The exact hash inputs, distribution method and available balancing options vary by platform.

Capacity

Use parallel paths

Eligible paths can contribute to aggregate forwarding capacity, rather than leaving all traffic dependent on a single route.

Resilience

Recover from path loss

If a path becomes unavailable and the network converges correctly, traffic can use remaining eligible next hops.

ECMP does not guarantee perfectly equal traffic volumes

Hash-based distribution generally balances flows or packets according to the implementation. A small number of large flows can create uneven utilisation even when several equal-cost paths are available. Unequal-cost load sharing is a separate capability and is not automatically provided by ECMP.

Cisco Express Forwarding (CEF)

Cisco Express Forwarding is a Cisco forwarding architecture designed to accelerate packet forwarding. It uses a Forwarding Information Base (FIB) for destination lookups and an adjacency structure for information needed to transmit packets to the next hop. This separates fast packet forwarding from the routing calculations that populate the forwarding structures.

Component	Purpose	Operational value
RIB	Maintains selected routing information.	Provides routes used to construct forwarding state.
FIB	Maps destination prefixes to forwarding actions and next hops.	Enables efficient destination lookups.
Adjacency information	Stores information required to transmit packets over the next link.	Helps avoid repeating neighbour-resolution work for every packet.

On supported platforms, forwarding structures may be programmed into specialised hardware such as ASICs. This allows packets to be forwarded at high rates without requiring the main CPU to process every packet individually. Exact hardware pipelines and exception handling depend on the device architecture.

Layer 3 EtherChannel and link aggregation

A Layer 3 EtherChannel combines multiple physical Ethernet links into a single logical routed interface on platforms that support it. Routing operates over the logical interface, while the device distributes traffic across member links according to its hashing and forwarding implementation.

Logical routed interface

The bundle presents one Layer 3 interface to the routing configuration, simplifying addressing and route management.

Multiple physical members

Several links can provide combined capacity and link-level resilience, provided the remaining bundle has sufficient capacity.

Link aggregation and ECMP are related but different mechanisms. An EtherChannel distributes traffic across member links inside a logical bundle. ECMP distributes traffic across multiple eligible next hops or routed paths. A network can use both mechanisms at different points in the forwarding topology.

Data-centre forwarding: leaf-spine and routed fabrics

Many data-centre networks use a leaf-spine topology. Servers connect to leaf switches, and each leaf connects to multiple spine switches. A routed fabric can provide multiple equal-cost paths between leaves, allowing ECMP to distribute traffic across the fabric.

This design supports predictable scaling: adding capacity can involve adding links or fabric devices, subject to the topology, oversubscription goals and platform limits. Routing protocols such as eBGP or OSPF can provide reachability between fabric devices, depending on the design.

High availability requires more than multiple links

Redundant paths only help when failures are detected, routing and forwarding state are updated correctly, and the surviving network has enough capacity. Convergence behaviour, failure domains, configuration consistency and traffic symmetry should all be considered during design and testing.

Other forwarding designs: VARP and vPC

Data-centre platforms may also provide features for gateway availability and multi-device link aggregation. Their purpose and implementation should be understood separately from ECMP.

Arista VARP

Virtual ARP provides a shared virtual gateway address and MAC behaviour across participating Arista switches. It can allow hosts to use a resilient default gateway in supported designs.

Cisco vPC

Virtual PortChannel allows a downstream device to form a port channel across two supported Cisco Nexus peers. It provides multi-device Layer 2 attachment; it is not itself an ECMP routing algorithm.

These features address different parts of network availability. VARP concerns gateway behaviour, vPC concerns multi-device port-channel connectivity, and ECMP concerns forwarding across multiple eligible routed next hops. They may coexist in a larger architecture, but they should not be treated as interchangeable technologies.

Key takeaway: ECMP distributes traffic across eligible routed paths, CEF provides an efficient forwarding architecture on supported Cisco platforms, and Layer 3 EtherChannel aggregates physical links into a logical routed interface. Leaf-spine fabrics, gateway redundancy and multi-device link aggregation build on related principles to support scalable, resilient networks. The next section examines troubleshooting, fast failure detection, policy-based routing and traffic control.

Interactive Lab 03 · Multipath Forwarding

How Does ECMP Distribute Traffic?

Simulate traffic from one router to a destination through multiple equal-cost paths. Change the number of paths and the distribution method to see why flow-based hashing behaves differently from packet-by-packet round-robin scheduling.

1. Configure the forwarding scenario

Available equal-cost paths

Traffic distribution model

Number of test flows

Selected / used path Available path Router / endpoint

Simulation result

Traffic distributed across 3 paths

Flow-based hashing assigns each flow to one path in this illustrative simulation. Different flows can be distributed unevenly.

Test flows 30

Active paths 3

Distribution Illustrative

2. Inspect the traffic distribution

Path 1

10 flows

Path 2

10 flows

Path 3

10 flows

3. What happens inside the forwarding plane?

Component	Role in forwarding	What to validate
RIB	Holds routing information and route-selection results.	Expected prefix and selected route source.
FIB	Provides the destination-prefix lookup used for packet forwarding.	Installed forwarding entry and next-hop set.
Adjacency	Provides next-hop forwarding details, including Layer 2 rewrite information where applicable.	Neighbour resolution and usable egress interface.
ECMP hash	Can map packet-flow fields to one of several eligible equal-cost paths.	Path eligibility, hash inputs and actual traffic distribution.

Engineering note: The chart is a deterministic educational simulation, not a hardware benchmark. Real ECMP implementations vary by platform, hash fields, resilient-hashing support, flow patterns and path eligibility. Equal-cost paths do not guarantee equal traffic volumes.

Section 04 · Resilience and Operational Control

Resilience, Troubleshooting and Traffic Engineering

Optimal forwarding is not simply about choosing the fastest path. A production network must detect failures, recover from changing topology, apply traffic policies and provide enough visibility to identify forwarding problems. Resilience depends on how these mechanisms work together.

A route can be correct when it is installed but become unusable after an interface failure, a neighbour becomes unreachable, or an intermediate network stops forwarding traffic. Effective network operations therefore examine both the routing control plane and the actual forwarding path.

Failure detection and routing convergence

When a link or neighbour fails, the network needs to detect the event, update relevant routing and forwarding state, and direct traffic over a surviving path where one exists. The time required for the network to settle on a usable path is part of its convergence behaviour.

Detection

Bidirectional Forwarding Detection (BFD)

BFD provides rapid detection of forwarding-path failures between participating endpoints. Routing protocols can use BFD events to react more quickly than relying solely on longer protocol hello or dead timers, where integration is supported.

Recovery

Routing convergence

After a failure is detected, the routing system recalculates or selects alternatives and updates forwarding entries. Actual recovery time depends on protocol behaviour, timers, topology, hardware and configuration.

Fast detection is not the same as instant recovery

BFD can help identify a failed forwarding path quickly, but it does not independently calculate a new route or guarantee that traffic will be restored immediately. Routing convergence, forwarding programming and the availability of an alternative path also affect recovery.

Diagnosing the forwarding path with traceroute

Traceroute helps identify the sequence of Layer 3 hops that respond to probes on the way towards a destination. Traditional implementations use probes with progressively increasing IP TTL or IPv6 Hop Limit values. Routers that reduce the value to zero may return an ICMP time-exceeded response, revealing an intermediate hop.

The output must be interpreted carefully. Some routers filter or rate-limit probe responses, so an asterisk does not necessarily indicate a forwarding failure. Return paths may differ from outbound paths, and load balancing can cause probes to reveal different paths depending on the probing method and network configuration.

Observed symptom	Possible explanation	Useful next check
Destination is unreachable	Missing route, invalid next hop or explicit rejection.	Inspect the route table, FIB and relevant interface state.
Traceroute shows asterisks	Probe responses may be filtered, rate-limited or unsupported.	Test end-to-end reachability and inspect the responding hops.
High latency begins at a hop	Congestion, queueing, control-plane response limits or a real path issue.	Compare end-to-end measurements and interface counters.
Traffic fails after a link event	Convergence delay, stale state or no usable alternate path.	Check routing neighbours, logs, FIB entries and adjacency state.

Policy-Based Routing (PBR)

Conventional routing primarily selects a forwarding path using the destination address and the installed routing information. Policy-Based Routing can apply additional rules to selected traffic, using supported packet attributes such as source address, protocol or transport ports to choose a different next hop or forwarding action.

PBR is useful when specific applications, source networks or traffic classes must follow a path that differs from the ordinary destination-based route. For example, a network might steer selected traffic through a security appliance or a dedicated WAN connection.

Potential benefits

Enables traffic steering, service chaining and application-specific forwarding policies when supported by the platform.

Operational considerations

Policy rules can create asymmetric paths, bypass expected controls or send traffic towards an unreachable next hop if they are not designed and monitored carefully.

Quality of Service (QoS) and congestion

QoS mechanisms classify traffic and apply actions such as marking, policing, shaping and queue scheduling. They influence how traffic is handled when resources are constrained, particularly on busy links. QoS does not replace route selection, but it can strongly influence the performance experienced by traffic using a chosen path.

For example, a real-time voice flow may be assigned to a low-latency queue, while bulk transfers use another queue. The benefit depends on consistent classification and configuration along the path, and on the available bandwidth and congestion conditions.

Routing and QoS solve different problems

Routing determines where packets should go. QoS determines how packets are treated when they compete for network resources. A preferred route can still perform poorly if the outgoing interface is congested or its queueing policy is inappropriate.

Next-hop tracking and route validity

Forwarding depends on the continued availability of the next hop. A route may need to be withdrawn, marked unusable or replaced when its next-hop reachability changes. Some routing implementations support next-hop tracking to associate route validity with changes in the reachability of a specified next-hop address.

In BGP environments, next-hop reachability is especially important: a BGP path can be present in the BGP table but not be usable for forwarding if its next hop cannot be resolved. Troubleshooting should therefore check both the BGP path and the underlying route that provides next-hop reachability.

A practical Layer 3 troubleshooting workflow

Confirm the symptom. Identify the source, destination, affected protocol and whether the problem is intermittent or persistent.
Check interfaces and links. Inspect operational state, errors, drops, utilisation and recent link events.
Inspect the route. Verify the destination prefix, selected route, route source and any applicable policy.
Validate next-hop reachability. Confirm that the next hop resolves and the expected adjacency is present.
Inspect forwarding state. Where platform tools permit, compare the RIB with the FIB and check for unresolved or missing forwarding entries.
Trace and test. Use ping, traceroute and application-level tests while accounting for filtering, asymmetric routing and load balancing.
Review resilience mechanisms. Check routing neighbours, BFD state, failover events and convergence after a failure.
Check traffic treatment. Review PBR, access controls, QoS policies and any intermediate services that may affect the flow.

A disciplined workflow avoids changing routing configuration before establishing where the failure occurs. The objective is to distinguish a control-plane problem from a forwarding problem, an adjacency issue, congestion or an intentional policy decision.

Interactive Lab 04 · Resilience

Investigate a Layer 3 Forwarding Failure

A destination suddenly becomes unreachable. Simulate a path failure, inspect the remaining forwarding options, and work through the checks an engineer would use to distinguish physical failure, routing convergence and next-hop resolution problems.

1. Select a failure scenario

Network event

Detection method

Available forwarding path Failed path Topology link

Network operating normally

Both illustrative paths are available. Inject a failure to see how the forwarding state and investigation sequence change.

Available paths 2 / 2

Detection model BFD

Forwarding outcome Reachable

2. Follow the investigation timeline

1. Establish the baseline

Confirm the destination route and both available paths.

2. Detect the event

Identify the failed link, adjacency or next-hop condition.

3. Update routing and forwarding state

Check route selection, the FIB and usable next hops.

4. Verify end-to-end traffic

Test reachability and confirm the actual forwarding path.

3. Complete the troubleshooting checklist

Interface and physical layer: verify interface state, errors, optics and link events.

Neighbour and next hop: confirm adjacency state and next-hop resolution.

Routing table: verify the prefix, route source and alternate path.

Forwarding table: confirm the FIB has a usable next hop and adjacency.

Traffic test: use suitable ping, traceroute, counters or flow telemetry.

0 of 5 checks completed

Important distinction: BFD can detect forwarding-path failures quickly when configured and supported, but it does not itself select a replacement route. Routing protocols and forwarding mechanisms must react to the event. Detection and convergence times depend on platform, configuration and failure type.

Section 05 · Cloud and Advanced Architectures

Cloud Networking, VXLAN, IPv6 and Advanced Forwarding

Modern Layer 3 forwarding extends beyond traditional enterprise routers. Cloud networks, virtualised data centres and software-defined environments combine routing, overlays, policy and distributed infrastructure to connect workloads across increasingly complex network boundaries.

The core forwarding principles remain familiar: identify the destination, select an applicable route, resolve the next hop and transmit the packet. What changes is the environment in which these decisions occur. Virtual networks, encapsulation, cloud route tables and centralised policy systems can introduce additional forwarding stages that must be understood during design and troubleshooting.

Cloud networking and virtual routing

Public cloud platforms provide virtual networks with configurable subnets, routes, gateways and traffic controls. These constructs allow cloud workloads to communicate with one another, with on-premises networks and with external destinations. The exact routing model, supported route types and forwarding behaviour depend on the cloud provider and service.

Virtual networks

Cloud route tables

Define how traffic from a subnet or virtual network is directed towards local destinations, gateways, peering connections or other supported next hops.

Hybrid connectivity

Cloud and on-premises routing

VPNs and dedicated connectivity services can exchange or provide routes between private networks, subject to provider features, route propagation and security policy.

Cloud troubleshooting should examine more than the guest operating system's route table. Virtual network routes, subnet associations, security rules, network interfaces, gateway configuration and provider-specific forwarding behaviour can all affect connectivity.

Cloud forwarding is a multi-layer investigation

A valid route inside a virtual machine does not guarantee that the cloud network will permit the traffic. Confirm the workload's local route, the cloud-side forwarding path and the applicable security controls before concluding that the problem is a routing failure.

VXLAN: extending Layer 2 over a Layer 3 underlay

Virtual Extensible LAN (VXLAN) is an overlay encapsulation technology used to carry Layer 2 Ethernet frames across a Layer 3 IP network. It allows logical Layer 2 segments to span a routed underlay without requiring the underlay itself to operate as one large Layer 2 domain.

VXLAN tunnel endpoints (VTEPs) encapsulate and decapsulate traffic. The outer IP header is routed through the underlay, while the encapsulated Ethernet frame represents the overlay traffic. VXLAN uses a 24-bit VXLAN Network Identifier (VNI), allowing a large number of logical segments.

1. Ingress VTEP Receives the original frame and applies overlay forwarding logic.

2. Encapsulation Adds VXLAN and outer transport headers to the frame.

3. Routed underlay Forwards the outer IP packet towards the remote VTEP.

Overlay and underlay are separate forwarding contexts

The overlay determines how tenant or segment traffic is represented and delivered between VTEPs. The underlay provides IP reachability between those endpoints. An overlay can fail even when the underlay is reachable, for example because of incorrect VNI mapping, missing endpoint information, filtering or encapsulation issues.

IPv6 forwarding and neighbour discovery

IPv6 follows the same broad forwarding model as IPv4: routers examine the destination address and use the most specific applicable route. However, IPv6 has a different address format, header structure and neighbour-resolution mechanism. IPv6 uses Neighbor Discovery Protocol (NDP), carried in ICMPv6, rather than ARP.

Concept	IPv4	IPv6
Address size	32 bits	128 bits
Neighbour resolution	ARP on Ethernet	Neighbor Discovery using ICMPv6
Address configuration	Manual configuration or DHCPv4, among other methods	Manual configuration, SLAAC and/or DHCPv6, depending on the design
Default route notation	0.0.0.0/0	::/0

IPv6 deployments must also account for Router Advertisements, prefix configuration, link-local addresses and ICMPv6 behaviour. Filtering essential ICMPv6 messages indiscriminately can disrupt functions required for normal operation, including neighbour discovery and Path MTU Discovery.

Software-defined networking and programmable forwarding

Software-defined networking (SDN) separates aspects of network control and policy from the individual forwarding devices. Depending on the architecture, a controller or orchestration system can coordinate configuration and distribute forwarding policy across switches, routers and virtual network components.

Centralised policy

Network-wide intent and configuration can be managed through common systems, helping maintain consistent connectivity and segmentation rules.

Programmable forwarding

Supported platforms can expose programmable data-plane functions or APIs that allow specialised packet-processing behaviour beyond conventional destination-based forwarding.

SDN does not mean that every packet must pass through a central controller. In many designs, the controller distributes policy or forwarding state while switches and routers continue to forward packets locally. The precise control model depends on the technology.

Network functions virtualisation and service chaining

Network Functions Virtualisation (NFV) allows network functions such as firewalls, routers and load balancers to run as software on virtualised or cloud infrastructure. Service chaining directs selected traffic through a sequence of services, such as inspection, filtering and application delivery.

These designs introduce additional forwarding decisions and operational dependencies. Engineers need to verify route symmetry where required, service reachability, encapsulation, capacity and the behaviour of each service in the chain.

Load balancing, direct server return and edge delivery

Load balancers distribute client traffic across available back-end servers using configured algorithms and health checks. In some architectures, Direct Server Return (DSR) allows the server to send response traffic directly back towards the client rather than returning it through the load balancer. The appropriate design depends on address handling, routing symmetry, platform support and operational requirements.

Content delivery networks and edge architectures move content or processing closer to users. DNS responses, anycast announcements, application-layer decisions and regional routing can all influence which service endpoint a client reaches. These mechanisms complement IP forwarding but are not the same as a router's per-packet longest-prefix match.

Do not confuse service selection with IP route selection

A CDN or load balancer may decide which server or service endpoint should receive a request. The network then forwards packets towards that endpoint. Application-layer selection and Layer 3 forwarding interact, but they solve different parts of the delivery problem.

Advanced forwarding: matching the tool to the problem

Requirement	Relevant mechanism	Key consideration
Multiple routed paths	ECMP	Path eligibility, hashing and capacity
Logical Layer 2 segments across a routed fabric	VXLAN	VTEP reachability, VNI configuration and MTU
Cloud workload connectivity	Virtual network routes and gateways	Provider routing, security controls and route propagation
Traffic-specific path steering	PBR or supported policy-based mechanisms	Policy order, symmetry and next-hop validity
Centralised network configuration	SDN and orchestration	Controller availability, policy consistency and operational visibility
IPv6 network reachability	IPv6 routing and Neighbor Discovery	Prefix design, ICMPv6 and address configuration

Interactive Lab 05 · Modern Forwarding

Explore Cloud, VXLAN and IPv6 Forwarding

Choose a networking environment and follow a packet through its forwarding stages. Compare a cloud route-table decision, a VXLAN overlay carried by an IP underlay, and native IPv6 forwarding.

1. Select a forwarding environment

Destination

Route-table entry

Routed forwarding VXLAN encapsulation / overlay IPv6 forwarding

Packet trace

The route table selects a local destination path

A forwarding device checks the destination against its installed routes and forwards the packet using the selected entry.

Forwarding decision Local route

Packet treatment Route lookup

Outcome Forward

2. Inspect the forwarding stages

Identify the destination

The packet's destination address determines which route is relevant.

Look up the route

The forwarding plane uses its installed forwarding information.

Resolve the next hop

Determine the egress interface and required link-layer forwarding details.

Forward or drop

Forward when a usable path exists; otherwise investigate the missing route or unusable next hop.

Engineering note: This is an educational model, not a live cloud account or router. Real route selection and forwarding behaviour depends on the platform, route-table rules, policies, encapsulation and the actual forwarding state.

Section 06 · Engineering Framework

Optimal Layer 3 Forwarding: Design Checklist and Conclusion

Effective Layer 3 forwarding combines correct route selection, efficient packet processing, resilient paths and clear operational visibility. This final section brings the key concepts together into a practical framework for designing, validating and maintaining routed networks.

No single protocol or feature guarantees optimal forwarding. A network may use OSPF or BGP to learn routes, ECMP to distribute traffic, hardware-assisted forwarding to process packets, and BFD or other mechanisms to detect failures. The right combination depends on the topology, application requirements, scale and operational constraints.

Six principles of optimal Layer 3 forwarding

01 · Correctness

Build accurate routing information

Ensure that connected, static and dynamically learned routes reflect the intended topology and that routing policy produces the required reachability.

02 · Reachability

Validate next hops

Confirm that selected next hops resolve correctly, interfaces are operational and the necessary forwarding adjacencies exist.

03 · Efficiency

Use forwarding resources effectively

Consider FIB capacity, hardware forwarding capabilities, ECMP distribution, interface utilisation and packet-processing requirements.

04 · Resilience

Design for failures

Provide appropriate path diversity, failure detection, convergence behaviour and enough remaining capacity to handle expected failure scenarios.

05 · Policy

Control traffic intentionally

Apply routing policy, PBR, segmentation and QoS where required. Verify that these mechanisms support the intended traffic flows.

06 · Visibility

Make forwarding observable

Monitor routes, neighbours, interface health, traffic counters, drops, latency and failure events so problems can be isolated and measured.

Practical engineering validation checklist

Use this checklist when reviewing a new routed design, investigating a connectivity issue or validating a network change.

Destination reachability Confirm the expected prefix exists, the selected route is correct and longest-prefix match leads to the intended forwarding entry.

Route selection and policy Review route sources, administrative distance where applicable, routing metrics, BGP attributes and policy filters.

FIB and adjacency state Verify that the selected route has been installed for forwarding and that next-hop resolution and Layer 2 adjacency are valid.

Path capacity and distribution Check ECMP eligibility, traffic hashing, link utilisation, congestion and whether the surviving paths can carry expected loads.

Failure and recovery behaviour Test relevant link or neighbour failures in a controlled environment and verify detection, convergence and restoration of traffic.

Security and traffic treatment Review ACLs, segmentation, PBR, QoS and intermediate services that may alter or block the intended flow.

Operational evidence Compare configuration, route tables, forwarding entries, counters, logs and end-to-end tests before and after changes.

Match the requirement to the forwarding mechanism

Engineering requirement	Mechanisms to evaluate
Learn and select routes	Static routing, OSPF, EIGRP, BGP and routing policy
Forward packets efficiently	FIB, adjacency resolution and platform forwarding hardware
Use multiple routed paths	ECMP and supported multipath routing features
Aggregate physical links	Layer 3 EtherChannel or equivalent link aggregation
Detect failures quickly	BFD, interface monitoring and routing-protocol failure detection
Steer selected traffic	PBR and supported traffic-engineering mechanisms
Connect overlay segments	VXLAN, VTEP reachability and a routed underlay
Operate in cloud environments	Virtual route tables, gateways, network policy and provider controls

Measure the outcome, not just the configuration

A design should be validated against measurable requirements: reachability, throughput, latency, packet loss, convergence time, capacity under failure and policy compliance. A configuration that looks correct on paper is not sufficient without testing the resulting forwarding behaviour.

Conclusion: making Layer 3 forwarding optimal

Optimal Layer 3 forwarding is the result of several cooperating systems. Routing protocols and static configuration provide reachability; route-selection rules determine which information is installed; longest-prefix match identifies the applicable destination route; and the forwarding plane moves packets through usable next hops.

Technologies such as ECMP, CEF, link aggregation, BFD, QoS, PBR, VXLAN and cloud routing extend these fundamentals to support higher capacity, resilience, traffic control and modern virtualised environments.

The strongest designs are not necessarily the most complicated. They are designs with clear routing intent, verified forwarding state, appropriate redundancy, predictable failure behaviour and sufficient visibility to diagnose problems quickly.

```

☕

Support Network Insight

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

Support Network Insight ```

What is OpenFlow

September 25, 2014

by Matt Conran Blog

What is OpenFlow?

In today's rapidly evolving digital landscape, network management and data flow control have become critical for businesses of all sizes. OpenFlow is one technology that has gained significant attention and is transforming how networks are managed. In this blog post, we will delve into the concept of OpenFlow, its advantages, and its implications for network control.

OpenFlow is an open-standard communications protocol that separates the control and data planes in a network architecture. It allows network administrators to have direct control over the behavior of network devices, such as switches and routers, by utilizing a centralized controller.

Traditional network architectures follow a closed model, where network devices make independent decisions on forwarding packets. On the other hand, OpenFlow introduces a centralized control plane that provides a global view of the network and allows administrators to define network policies and rules from a centralized location.

OpenFlow operates by establishing a secure channel between the centralized controller and the network switches. The controller is responsible for managing the flow tables within the switches, defining how traffic should be forwarded based on predefined rules and policies. This separation of control and data planes allows for dynamic network management and facilitates the implementation of innovative network protocols.

One of the key advantages of OpenFlow is its ability to simplify network management. By centralizing control, administrators can easily configure and manage the entire network from a single point of control. This reduces complexity and enhances the scalability of network infrastructure. Additionally, OpenFlow enables network programmability, allowing for the development of custom networking applications and services tailored to specific requirements.

OpenFlow plays a crucial role in network virtualization, as it allows for the creation and management of virtual networks on top of physical infrastructure. By abstracting the underlying network, OpenFlow empowers organizations to optimize resource utilization, improve security, and enhance network performance. It opens doors to dynamic provisioning, isolation, and efficient utilization of network resources.

Matt Conran

Highlights: What is OpenFlow?

How does OpenFlow work?

1: OpenFlow allows network controllers to determine the path of network packets in a network of switches. There is a difference between switches and controllers. With separate control and forwarding, traffic management can be more sophisticated than access control lists (ACLs) and routing protocols.

2: An OpenFlow protocol allows switches from different vendors, often with proprietary interfaces and scripting languages, to be managed remotely. Software-defined networking (SDN) is considered to be enabled by OpenFlow by its inventors.

3: With OpenFlow, Layer 3 switches can add, modify, and remove packet-matching rules and actions remotely. By doing so, routing decisions can be made periodically or ad hoc by the controller and translated into rules and actions with a configurable lifespan, which are then deployed to the switch’s flow table, where packets are forwarded at wire speed for the duration of the rule.

The Role of OpenFlow Controllers

If the switch cannot match packets, they can be sent to the controller. The controller can modify existing flow table rules or deploy new rules to prevent a structural traffic flow. It may even forward the traffic itself if the switch is instructed to forward packets rather than just their headers.

OpenFlow uses Transport Layer Security (TLS) over Transmission Control Protocol (TCP). Switches wishing to connect should listen on TCP port 6653. In earlier versions of OpenFlow, port 6633 was unofficially used. The protocol is mainly used between switches and controllers.

### Origins of OpenFlow

The inception of OpenFlow can be traced back to the early 2000s when researchers at Stanford University sought to create a more versatile and programmable network architecture. Traditional networking relied heavily on static and proprietary hardware configurations, which limited innovation and adaptability. OpenFlow emerged as a solution to these challenges, offering a standardized protocol that decouples the network control plane from the data plane. This separation allows for centralized control and dynamic adjustment of network traffic, fostering innovation and agility in network design.

### How OpenFlow Works

At its core, the OpenFlow protocol facilitates communication between network devices and a centralized SDN controller. It does this by using a series of flow tables within network switches, which are programmed by the controller. These flow tables dictate how packets should be handled, whether they are forwarded to a destination, dropped, or modified in some way. By leveraging OpenFlow, network administrators can deploy updates, optimize performance, and troubleshoot issues with unprecedented speed and precision, all from a single point of control.

Introducing SDN

Recent changes and requirements have driven networks and network services to become more flexible, virtualization-aware, and API-driven. One major trend affecting the future of networking is software-defined networking ( SDN ). The software-defined architecture aims to extract the entire network into a single switch.

Software-defined networking (SDN) is an evolving technology defined by the Open Networking Foundation ( ONF ). It involves the physical separation of the network control plane from the forwarding plane, where a control plane controls several devices. This differs significantly from traditional IP forwarding that you may have used in the past.

The Core Concepts of SDN

At its heart, Software-Defined Networking decouples the network control plane from the data plane, allowing network administrators to manage network services through abstraction of lower-level functionality. This separation enables centralized network control, which simplifies the management of complex networks. The control plane makes decisions about where traffic is sent, while the data plane forwards traffic to the selected destination. This approach allows for a more flexible, adaptable network infrastructure.

The activities around OpenFlow

Even though OpenFlow has received a lot of industry attention, programmable networks and decoupled control planes (control logic) from data planes have been around for many years. To enhance ATM, Internet, and mobile networks’ openness, extensibility, and programmability, the Open Signaling (OPENING) working group held workshops in 1995. A working group within the Internet Engineering Task Force (IETF) developed GSMP to control label switches based on these ideas. June 2002 marked the official end of this group, and GSMPv3 was published.

Data and control plane

Therefore, SDN separates the data and control plane. The main driving body behind software-defined networking (SDN) is the Open Networking Foundation ( ONF ). Introduced in 2008, the ONF is a non-profit organization that wants to provide an alternative to proprietary solutions that limit flexibility and create vendor lock-in.

The insertion of the ONF allowed its members to run proof of concepts on heterogeneous networking devices without requiring vendors to expose their software’s internal code. This creates a path for an open-source approach to networking and policy-based controllers.

Knowledge Check: Data & Control Plane

### Data Plane: The Highway for Your Data

The data plane, often referred to as the forwarding plane, is responsible for the actual movement of packets of data from source to destination. Imagine it as a network’s highway, where data travels at high speed. This component operates at the speed of light, handling massive amounts of data with minimal delay. It’s designed to process packets quickly, ensuring that the information arrives where it needs to be without interruption.

### Control Plane: The Brain Behind the Operation

While the data plane acts as the highway, the control plane is the brain that orchestrates the flow of traffic. It makes decisions about routing, managing the network topology, and controlling the data plane’s operations. The control plane uses protocols to determine the best paths for data and to update routing tables as needed. It’s responsible for ensuring that the network operates efficiently, adapting to changes, and maintaining optimal performance.

### Interplay Between Data and Control Planes

The synergy between the data and control planes is what enables modern networks to function effectively. The control plane provides the intelligence and decision-making necessary to guide the data plane. This interaction ensures that data packets take the best possible paths, reducing latency and maximizing throughput. As networks evolve, the lines between these planes may blur, but their distinct roles remain pivotal.

### Real-World Applications and Innovations

The concepts of data and control planes are not just theoretical—they have practical applications in technologies such as Software-Defined Networking (SDN) and Network Function Virtualization (NFV). These innovations allow for greater flexibility and scalability in managing network resources, offering businesses the agility needed to adapt to changing demands.

Building blocks: SDN Environment

As a fundamental building block of an SDN deployment, the controller, the SDN switch (for example, an OpenFlow switch), and the interfaces are present in the controller to communicate with forwarding devices, generally the southbound interface (OpenFlow) and the northbound interface (the network application interface).

In an SDN, switches function as basic forwarding hardware, accessible via an open interface, with the control logic and algorithms offloaded to controllers. Hybrid (OpenFlow-enabled) and pure (OpenFlow-only) OpenFlow switches are available.

OpenFlow switches rely entirely on a controller for forwarding decisions, without legacy features or onboard control. Hybrid switches support OpenFlow as well, in addition to traditional operation and protocols. Today, hybrid switches are the most common type of commercial switch. A flow table performs packet lookup and forwarding in an OpenFlow switch.

### The Role of the OpenFlow Controller

The OpenFlow controller is the brain of the SDN, orchestrating the flow of data across the network. It communicates with the network devices using the OpenFlow protocol to dictate how packets should be handled. The controller’s primary function is to make decisions on the path data packets should take, ensuring optimal network performance and resource utilization. This centralization of control allows for dynamic network configuration, paving the way for innovative applications and services.

### OpenFlow Switches: The Workhorses of the Network

While the controller is the brain, OpenFlow switches are the workhorses, executing the instructions they receive. These switches operate at the data plane, where they forward packets based on the rules set by the controller. Each switch maintains a flow table that matches incoming packets to particular actions, such as forwarding or dropping the packet. This separation of control and data planes is what sets SDN apart from traditional networking, offering unparalleled flexibility and control.

### Flow Tables: The Heart of OpenFlow Switches

Flow tables are the core component of OpenFlow switches, dictating how packets are handled. Each entry in a flow table consists of match fields, counters, and a set of instructions. Match fields identify the packets that should be affected by the rule, counters track the number of packets and bytes that match the entry, and instructions define the actions to be taken. This modular approach allows for precise traffic management and is essential for implementing advanced network policies.

OpenFlow Table & Routing Tables

### What is an OpenFlow Flow Table?

OpenFlow is a protocol that allows network controllers to interact with the forwarding plane of network devices like switches and routers. At the heart of OpenFlow is the flow table. This table contains a set of flow entries, each specifying actions to take on packets that match a particular pattern. Unlike traditional routing tables, which rely on predefined paths and protocols, OpenFlow flow tables provide flexibility and programmability, allowing dynamic changes in how packets are handled based on real-time network conditions.

### Understanding Routing Tables

Routing tables are a staple of traditional networking, used by routers to determine the best path for forwarding packets to their final destinations. These tables consist of a list of network destinations, with associated metrics that help in selecting the most efficient route. Routing protocols such as OSPF, BGP, and RIP are employed to maintain and update these tables, ensuring that data flows smoothly across the interconnected web of networks. While reliable, routing tables are less flexible compared to OpenFlow flow tables, as changes in network traffic patterns require updates to routing protocols and configurations.

Example of a Routing Table

### Key Differences Between OpenFlow Flow Table and Routing Table

The primary distinction between OpenFlow flow tables and routing tables lies in their approach to network management. OpenFlow flow tables are dynamic and programmable, allowing for real-time adjustments and fine-grained control over traffic flows. This makes them ideal for environments where network agility and customization are paramount. Conversely, routing tables offer a more static and predictable method of packet forwarding, which can be beneficial in stable networks where consistency and reliability are prioritized.

### Use Cases: When to Use Each

OpenFlow flow tables are particularly advantageous in software-defined networking (SDN) environments, where network administrators need to quickly adapt to changing conditions and optimize traffic flows. They are well-suited for data centers, virtualized networks, and scenarios requiring high levels of automation and scalability. On the other hand, traditional routing tables are best used in established networks with predictable traffic patterns, such as those found in enterprise or service provider settings, where reliability and stability are key.

You may find the following useful for pre-information:

What is OpenFlow?

OpenFlow was the first protocol of the Software-Defined Networking (SDN) trend and is the only protocol that allows the decoupling of a network device’s control plane from the data plane. In most straightforward terms, the control plane can be thought of as the brains of a network device. On the other hand, the data plane can be considered hardware or application-specific integrated circuits (ASICs) that perform packet forwarding.

Numerous devices also support running OpenFlow in a hybrid mode, meaning OpenFlow can be deployed on a given port, virtual local area network (VLAN), or even within a regular packet-forwarding pipeline such that if there is not a match in the OpenFlow table, then the existing forwarding tables (MAC, Routing, etc.) are used, making it more analogous to Policy Based Routing (PBR).

What is SDN?

Despite various modifications to the underlying architecture and devices (such as switches, routers, and firewalls), traditional network technologies have existed since the inception of networking. Using a similar approach, frames and packets have been forwarded and routed in a limited manner, resulting in low efficiency and high maintenance costs. Consequently, the architecture and operation of networks need to evolve, resulting in SDN.

By enabling network programmability, SDN promises to simplify network control and management and allow innovation in computer networking. Network engineers configure policies to respond to various network events and application scenarios. They can achieve the desired results by manually converting high-level policies into low-level configuration commands.

Often, minimal tools are available to accomplish these very complex tasks. Controlling network performance and tuning network management are challenging and error-prone tasks.

A modern network architecture consists of a control plane, a data plane, and a management plane; the control and data planes are merged into a machine called Inside the Box. To overcome these limitations, programmable networks have emerged.

How OpenFlow Works:

At the core of OpenFlow is the concept of a flow table, which resides in each OpenFlow-enabled switch. The flow table contains match-action rules defining how incoming packets should be processed and forwarded. The centralized controller determines these rules and communicates using the OpenFlow protocol with the switches.

When a packet arrives at an OpenFlow-enabled switch, it is first matched against the rules in the flow table. If a match is found, the corresponding action is executed, including forwarding the packet, dropping it, or sending it to the controller for further processing. This decoupling of the control and data planes allows for flexible and programmable network management.

What is OpenFlow SDN?

The main goal of SDN is to separate the control and data planes and transfer network intelligence and state to the control plane. These concepts have been exploited by technologies like Routing Control Platform (RCP), Secure Architecture for Network Enterprise (SANE), and, more recently, Ethane.

In addition, there is often a connection between SDN and OpenFlow. The Open Networking Foundation (ONF) is responsible for advancing SDN and standardizing OpenFlow, whose latest version is 1.5.0.

An SDN deployment starts with these building blocks.

For communication with forwarding devices, the controller has the SDN switch (for example, an OpenFlow switch), the SDN controller, and the interfaces. An SDN deployment is based on two basic building blocks: a southbound interface (OpenFlow) and a northbound interface (the network application interface).

As the control logic and algorithms are offloaded to a controller, switches in SDNs may be represented as basic forwarding hardware. Switches that support OpenFlow come in two varieties: pure (OpenFlow-only) and hybrid (OpenFlow-enabled).

Pure OpenFlow switches do not have legacy features or onboard control for forwarding decisions. A hybrid switch can operate with both traditional protocols and OpenFlow. Hybrid switches make up the majority of commercial switches available today. In an OpenFlow switch, a flow table performs packet lookup and forwarding.

OpenFlow reference switch

The OpenFlow protocol and interface allow OpenFlow switches to be accessed as essential forwarding elements. A flow-based SDN architecture like OpenFlow simplifies switching hardware. Still, it may require additional forwarding tables, buffer space, and statistical counters that are difficult to implement in traditional switches with integrated circuits tailored to specific applications.

There are two types of switches in an OpenFlow network: hybrids (which enable OpenFlow) and pores (which only support OpenFlow). OpenFlow is supported by hybrid switches and traditional protocols (L2/L3). OpenFlow switches rely entirely on a controller for forwarding decisions and do not have legacy features or onboard control.

Hybrid switches are the majority of the switches currently available on the market. This link must remain active and secure because OpenFlow switches are controlled over an open interface (through a TCP-based TLS session). OpenFlow is a messaging protocol that defines communication between OpenFlow switches and controllers, which can be viewed as an implementation of SDN-based controller-switch interactions.

Openflow switch — Diagram: OpenFlow switch. The source is cable solution.

Identify the Benefits of OpenFlow

Application-driven routing. Users can control the network paths.	The networks paths.A way to enhance link utilization.
An open solution for VM mobility. No VLAN reliability.	A means to traffic engineer without MPLS.
A solution to build very large Layer 2 networks.	A way to scale Firewalls and Load Balancers.
A way to configure an entire network as a whole as opposed to individual entities.	A way to build your own encryption solution. Off-the-box encryption.
A way to distribute policies from a central controller.	Customized flow forwarding. Based on a variety of bit patterns.
A solution to get a global view of the network and its state. End-to-end visibility.	A solution to use commodity switches in the network. Massive cost savings.

The following table lists the Software Networking ( SDN ) benefits and the problems encountered with existing control plane architecture:

Identify the benefits of OpenFlow and SDN	Problems with the existing approach
Faster software deployment.	Large scale provisioning and orchestration.
Programmable network elements.	Limited traffic engineering ( MPLS TE is cumbersome )
Faster provisioning.	Synchronized distribution policies.
Centralized intelligence with centralized controllers.	Routing of large elephant flows.
Decisions are based on end-to-end visibility.	Qos and load based forwarding models.
Granular control of flows.	Ability to scale with VLANs.
Decreases the dependence on network appliances like load balancers.

A key point: The lack of a session layer in the TCP/IP stack

Regardless of the hype and benefits of SDN, neither OpenFlow nor other SDN technologies address the real problems of the lack of a session layer in the TCP/IP protocol stack. The problem is that the client’s application ( Layer 7 ) connects to the server’s IP address ( Layer 3 ), and if you want to have persistent sessions, the server’s IP address must remain reachable.

This session’s persistence and the ability to connect to multiple Layer 3 addresses to reach the same device is the job of the OSI session layer. The session layer provides the services for opening, closing, and managing a session between end-user applications. In addition, it allows information from different sources to be correctly combined and synchronized.

The problem is the TCP/IP reference module does not consider a session layer, and there is none in the TCP/IP protocol stack. SDN does not solve this; it gives you different tools to implement today’s kludges.

Control and data plane

When we identify the benefits of OpenFlow, let us first examine traditional networking operations. Traditional networking devices have a control and forwarding plane, depicted in the diagram below. The control plane is responsible for setting up the necessary protocols and controls so the data plane can forward packets, resulting in end-to-end connectivity. These roles are shared on a single device, and the fast packet forwarding ( data path ) and the high-level routing decisions ( control path ) occur on the same device.

What is OpenFlow | SDN separates the data and control plane?

Control plane

The control plane is part of the router architecture and is responsible for drawing the network map in routing. When we mention control planes, you usually think about routing protocols, such as OSPF or BGP. But in reality, the control plane protocols perform numerous other functions, including:

Connectivity management ( BFD, CFM )	Interface state management ( PPP, LACP )
Service provisioning ( RSVP for InServ or MPLS TE)	Topology and reachability information exchange ( IP routing protocols, IS-IS in TRILL/SPB )
Adjacent device discovery via HELLO mechanism	ICMP

Control plane protocols run over data plane interfaces to ensure “shared fate” – if the packet forwarding fails, the control plane protocol fails as well.

Most control plane protocols ( BGP, OSPF, BFD ) are not data-driven. A BGP or BFD packet is never sent as a direct response to a data packet. There is a question mark over the validity of ICMP as a control plane protocol. The debate is whether it should be classed in the control or data plane category.

Some ICMP packets are sent as replies to other ICMP packets, and others are triggered by data plane packets, i.e., data-driven. My view is that ICMP is a control plane protocol that is triggered by data plane activity. After all, the “C” is ICMP does stand for “Control.”

Data plane

The data path is part of the routing architecture that decides what to do when a packet is received on its inbound interface. It is primarily focused on forwarding packets but also includes the following functions:

ACL logging	Netflow accounting
NAT session creation	NAT table maintenance

The data forwarding is usually performed in dedicated hardware, while the additional functions ( ACL logging, Netflow accounting ) typically happen on the device CPU, commonly known as “punting.” The data plane for an OpenFlow-enabled network can take a few forms.

However, the most common, even in the commercial offering, is the Open vSwitch, often called the OVS. The Open vSwitch is an open-source implementation of a distributed virtual multilayer switch. It enables a switching stack for virtualization environments while supporting multiple protocols and standards.

Software-defined networking changes the control and data plane architecture.

The concept of SDN separates these two planes, i.e., the control and forwarding planes are decoupled. This allows the networking devices in the forwarding path to focus solely on packet forwarding. An out-of-band network uses a separate controller ( orchestration system ) to set up the policies and controls. Hence, the forwarding plane has the correct information to forward packets efficiently.

In addition, it allows the network control plane to be moved to a centralized controller on a server instead of residing on the same box carrying out the forwarding. Moving the intelligence ( control plane ) of the data plane network devices to a controller enables companies to use low-cost, commodity hardware in the forwarding path. A significant benefit is that SDN separates the data and control plane, enabling new use cases.

A centralized computation and management plane makes more sense than a centralized control plane.

The controller maintains a view of the entire network and communicates with Openflow ( or, in some cases, BGP with BGP SDN ) with the different types of OpenFlow-enabled network boxes. The data path portion remains on the switch, such as the OVS bridge, while the high-level decisions are moved to a separate controller. The data path presents a clean flow table abstraction, and each flow table entry contains a set of packet fields to match, resulting in specific actions ( drop, redirect, send-out-port ).

When an OpenFlow switch receives a packet it has never seen before and doesn’t have a matching flow entry, it sends the packet to the controller for processing. The controller then decides what to do with the packet.

Applications could then be developed on top of this controller, performing security scrubbing, load balancing, traffic engineering, or customized packet forwarding. The centralized view of the network simplifies problems that were harder to overcome with traditional control plane protocols.

A single controller could potentially manage all OpenFlow-enabled switches. Instead of individually configuring each switch, the controller can push down policies to multiple switches simultaneously—a compelling example of many-to-one virtualization.

Now that SDN separates the data and control plane, the operator uses the centralized controller to choose the correct forwarding information per-flow basis. This allows better load balancing and traffic separation on the data plane. In addition, there is no need to enforce traffic separation based on VLANs, as the controller would have a set of policies and rules that would only allow traffic from one “VLAN” to be forwarded to other devices within that same “VLAN.”

The advent of VXLAN

With the advent of VXLAN, which allows up to 16 million logical entities, the benefits of SDN should not be purely associated with overcoming VLAN scaling issues. VXLAN already does an excellent job with this. It does make sense to deploy a centralized control plane in smaller independent islands; in my view, it should be at the edge of the network for security and policy enforcement roles. Using Openflow on one or more remote devices is easy to implement and scale.

It also decreases the impact of controller failure. If a controller fails and its sole job is implementing packet filters when a new user connects to the network, the only affecting element is that the new user cannot connect. If the controller is responsible for core changes, you may have interesting results with a failure. New users not being able to connect is bad, but losing your entire fabric is not as bad.

Spanning tree VXLAN — Diagram: Loop prevention. Source is Cisco

A traditional networking device runs all the control and data plane functions. The control plane, usually implemented in the central CPU or the supervisor module, downloads the forwarding instructions into the data plane structures. Every vendor needs communications protocols to bind the two planes together to download forward instructions.

Therefore, all distributed architects need a protocol between control and data plane elements. The protocol binding this communication path for traditional vendor devices is not open-source, and every vendor uses its proprietary protocol (Cisco uses IPC—InterProcess Communication ).

Openflow tries to define a standard protocol between the control plane and the associated data plane. When you think of Openflow, you should relate it to the communication protocol between the traditional supervisors and the line cards. OpenFlow is just a low-level tool.

OpenFlow is a control plane ( controller ) to data plane ( OpenFlow enabled device ) protocol that allows the control plane to modify forwarding entries in the data plane. It enables SDN to separate the data and control planes.

Proactive versus reactive flow setup

OpenFlow operations have two types of flow setups: Proactive and Reactive.

With Proactive, the controller can populate the flow tables ahead of time, similar to a typical routing. However, the packet-in event never occurs by pre-defining your flows and actions ahead of time in the switch’s flow tables. The result is all packets are forwarded at line rate. With Reactive, the network devices react to traffic, consult the OpenFlow controller, and create a rule in the flow table based on the instruction. The problem with this approach is that there can be many CPU hits.

The following table outlines the critical points for each type of flow setup:

Proactive flow setup	Reactive flow setup
Works well when the controller is emulating BGP or OSPF.	Used when no one can predict when and where a new MAC address will appear.
The controller must first discover the entire topology.	Punts unknown packets to the controller. Many CPU hits.
Discover endpoints ( MAC addresses, IP addresses, and IP subnets )	Compute forwarding paths on demand. Not off the box computation.
Compute off the box optimal forwarding.	Install flow entries based on actual traffic.
Download flow entries to the data plane switches.	Has many scalability concerns such as packet punting rate.
No data plane controller involvement with the exceptions of ARP and MAC learning. Line-rate performance.	Not a recommended setup.

Hop-by-hop versus path-based forwarding

The following table illustrates the key points for the two types of forwarding methods used by OpenFlow: hop-by-hop forwarding and path-based forwarding:

Hop-by-hop Forwarding	Path-based Forwarding
Similar to traditional IP Forwarding.	Similar to MPLS.
Installs identical flows on each switch on the data path.	Map flows to paths on ingress switches and assigns user traffic to paths at the edge node
Scalability concerns relating to flow updates after a change in topology.	Compute paths across the network and installs end-to-end path-forwarding entries.
Significant overhead in large-scale networks.	Works better than hop-by-hop forwarding in large-scale networks.
FIB update challenges. Convergence time.	Core switches don’t have to support the same granular functionality as edge switches.

Obviously, with any controller, the controller is a lucrative target for attack. Anyone who knows you are using a controller-based network will try to attack the controller and its control plane. The attacker may attempt to intercept the controller-to-switch communication and replace it with its commands, essentially attacking the control plane with whatever means they like.

An attacker may also try to insert a malformed packet or some other type of unknown packet into the controller ( fuzzing attack ), exploiting bugs in the controller and causing the controller to crash.

Fuzzing attacks can be carried out with application scanning software such as Burp Suite. It attempts to manipulate data in a particular way, breaking the application.

The best way to tighten security is to encrypt switch-to-controller communications with SSL and self-signed certificates to authenticate the switch and controller. It would also be best to minimize interaction with the data plane, except for ARP and MAC learning.

To prevent denial-of-service attacks on the controller, you can use Control Plane Policing ( CoPP ) on Ingress to avoid overloading the switch and the controller. Currently, NEC is the only vendor implementing CoPP.

The Hybrid deployment model is helpful from a security perspective. For example, you can group specific ports or VLANs to OpenFlow and other ports or VLANs to traditional forwarding, then use traditional forwarding to communicate with the OpenFlow controller.

Software-defined networking or traditional routing protocols?

The move to a Software-Defined Networking architecture has clear advantages. It’s agile and can react quickly to business needs, such as new product development. For businesses to succeed, they must have software that continues evolving.

Otherwise, your customers and staff may lose interest in your product and service. The following table displays the advantages and disadvantages of the existing routing protocol control architecture.

+Reliable and well known.	-Non-standard Forwarding models. Destination-only and not load-aware metrics**
+Proven with 20 plus years field experience.	-Loosely coupled.
+Deterministic and predictable.	-Lacks end-to-end transactional consistency and visibility.
+Self-Healing. Traffic can reroute around a failed node or link.	-Limited Topology discovery and extraction. Basic neighbor and topology tables.
+Autonomous.	-Lacks the ability to change existing control plane protocol behavior.
+Scalable.	-Lacks the ability to introduce new control plane protocols.
+Plenty of learning and reading materials.

** Basic EIGRP IETF originally proposed an Energy-Aware Control Plane, but the IETF later removed this.

Software-Defined Networking: Use Cases

Edge Security policy enforcement at the network edge.	Authenticate users or VMs and deploy per-user ACL before connecting a user to the network.
Custom routing and online TE.	The ability to route on a variety of business metrics aka routing for dollars. Allowing you to override the default routing behavior.
Custom traffic processing.	For analytics and encryption.
Programmable SPAN ports	Use Openflow entries to mirror selected traffic to the SPAN port.
DoS traffic blackholing & distributed DoS prevention.	Block DoS traffic as close to the source as possible with more selective traffic targeting than the original RTBH approach**. The traffic blocking is implemented in OpenFlow switches. Higher performance with significantly lower costs.
Traffic redirection and service insertion.	Redirect a subset of traffic to network appliances and install redirection flow entries wherever needed.
Network Monitoring.	The controller is the authoritative source of information on network topology and Forwarding paths.
Scale-Out Load Balancing.	Punt new flows to the Openflow controller and install per-session entries throughout the network.
IPS Scale-Out.	OpenFlow is used to distribute the load to multiple IDS appliances.

**Remote-Triggered Black Hole: RTBH refers to installing a host route to a bogus IP address ( RTBH address ) pointing to NULL interfaces on all routers. BGP is used to advertise the host routes to other BGP peers of the attacked hosts, with the next hop pointing to the RTBH address, and it is mainly automated in ISP environments.

SDN deployment models

Guidelines:

Start with small deployments away from the mission-critical production path, i.e., the Core. Ideally, start with device or service provisioning systems.
Start at the Edge and slowly integrate with the Core. Minimize the risk and blast radius. Start with packet filters at the Edge and tasks that can be easily automated ( VLANs ).
Integrate new technology with the existing network.
Gradually increase scale and gain trust. Experience is key.
Have the controller in a protected out-of-band network with SSL connectivity to the switches.

There are 4 different models for OpenFlow deployment, and the following sections list the key points of each model.

Native OpenFlow

They are commonly used for Greenfield deployments.
The controller performs all the intelligent functions.
The forwarding plane switches have little intelligence and solely perform packet forwarding.
The white box switches need IP connectivity to the controller for the OpenFlow control sessions. If you are forced to use an in-band network for this communication path using an isolated VLAN with STP, you should use an out-of-band network.
Fast convergence techniques such as BFD may be challenging to use with a central controller.
Many people believe that this approach does not work for a regular company. Companies implementing native OpenFlow, such as Google, have the time and resources to reinvent the wheel when implementing a new control-plane protocol ( OpenFlow ).

Native OpenFlow with Extensions

Some control plane functions are handled from the centralized controller to the forwarding plane switches. For example, the OpenFlow-enabled switches could load balancing across multiple links without the controller’s previous decision. You could also run STP, LACP, or ARP locally on the switch without interaction with the controller. This approach is helpful if you lose connectivity to the controller. If the low-level switches perform certain controller functions, packet forwarding will continue in the event of failure.
The local switches should support the specific OpenFlow extensions that let them perform functions on the controller’s behalf.

Hybrid ( Ships in the night )

This approach is used where OpenFlow runs in parallel with the production network.
The same network box is controlled by existing on-box and off-box control planes ( OpenFlow).
Suitable for pilot deployment models as switches still run traditional control plane protocols.
The Openflow controller manages only specific VLANs or ports on the network.
The big challenge is determining and investigating the conflict-free sharing of forwarding plane resources across multiple control planes.

Integrated OpenFlow

OpenFlow classifiers and forwarding entries are integrated with the existing control plane. For example, Juniper’s OpenFlow model follows this mode of operation where OpenFlow static routes can be redistributed into the other routing protocols.
No need for a new control plane.
No need to replace all forwarding hardware
It is the most practical approach as long as the vendor supports it.

Closing Points on OpenFlow

OpenFlow is a communication protocol that provides access to the forwarding plane of a network switch or router over the network. It was initially developed at Stanford University and has since been embraced by the Open Networking Foundation (ONF) as a core component of SDN. OpenFlow allows network administrators to program the control plane, enabling them to direct how packets are forwarded through the network. This decoupling of the control and data planes is what empowers SDN to offer more dynamic and flexible network management.

The architecture of OpenFlow is quite straightforward yet powerful. It consists of three main components: the controller, the switch, and the protocol itself. The controller is the brains of the operation, managing network traffic by sending instructions to OpenFlow-enabled switches. These switches, in turn, execute the instructions received, altering the flow of network data accordingly. This setup allows for centralized network control, offering unprecedented levels of automation and agility.

**Advantages of OpenFlow**

OpenFlow brings several critical advantages to network management and control:

1. Flexibility and Programmability: With OpenFlow, network administrators can dynamically reconfigure the behavior of network devices, allowing for greater adaptability to changing network requirements.

2. Centralized Control: By centralizing control in a single controller, network administrators gain a holistic view of the network, simplifying management and troubleshooting processes.

3. Innovation and Experimentation: OpenFlow enables researchers and developers to experiment with new network protocols and applications, fostering innovation in the networking industry.

4. Scalability: OpenFlow’s centralized control architecture provides the scalability needed to manage large-scale networks efficiently.

**Implications for Network Control**

OpenFlow has significant implications for network control, paving the way for new possibilities in network management:

1. Software-Defined Networking (SDN): OpenFlow is a critical component of the broader concept of SDN, which aims to decouple network control from the underlying hardware, providing a more flexible and programmable infrastructure.

2. Network Virtualization: OpenFlow facilitates network virtualization, allowing multiple virtual networks to coexist on a single physical infrastructure.

3. Traffic Engineering: By controlling the flow of packets at a granular level, OpenFlow enables advanced traffic engineering techniques, optimizing network performance and resource utilization.

OpenFlow represents a paradigm shift in network control, offering a more flexible, scalable, and programmable approach to managing networks. By separating the control and data planes, OpenFlow empowers network administrators to have fine-grained control over network behavior, improving efficiency, innovation, and adaptability. As the networking industry continues to evolve, OpenFlow and its related technologies will undoubtedly play a crucial role in shaping the future of network management.

Summary: What is OpenFlow?

In the rapidly evolving world of networking, OpenFlow has emerged as a game-changer. This revolutionary technology has transformed the way networks are managed, offering unprecedented flexibility, control, and efficiency. In this blog post, we will delve into the depths of OpenFlow, exploring its definition, key features, and benefits.

What is OpenFlow?

OpenFlow can be best described as an open standard communications protocol that enables the separation of the control plane and the data plane in network devices. It allows centralized control over a network’s forwarding elements, making it possible to program and manage network traffic dynamically. By decoupling the intelligence of the network from the underlying hardware, OpenFlow provides a flexible and programmable infrastructure for network administrators.

Key Features of OpenFlow

a) Centralized Control: One of the core features of OpenFlow is its ability to centralize network control, allowing administrators to define and implement policies from a single point of control. This centralized control improves network visibility and simplifies management tasks.

b) Programmability: OpenFlow’s programmability empowers network administrators to define how network traffic should be handled based on their specific requirements. Through the use of flow tables and match-action rules, administrators can dynamically control the behavior of network switches and routers.

c) Software-Defined Networking (SDN) Integration: OpenFlow plays a crucial role in the broader concept of Software-Defined Networking. It provides a standardized interface for SDN controllers to communicate with network devices, enabling dynamic and automated network provisioning.

Benefits of OpenFlow

a) Enhanced Network Flexibility: With OpenFlow, network administrators can easily adapt and customize their networks to suit evolving business needs. The ability to modify network behavior on the fly allows for efficient resource allocation and improved network performance.

b) Simplified Network Management: By centralizing network control, OpenFlow simplifies the management of complex network architectures. Policies and configurations can be applied uniformly across the network, reducing administrative overhead and minimizing the chances of configuration errors.

c) Innovation and Experimentation: OpenFlow fosters innovation by providing a platform for the development and deployment of new network protocols and applications. Researchers and developers can experiment with novel networking concepts, paving the way for future advancements in the field.

Conclusion

OpenFlow has ushered in a new era of network management, offering unparalleled flexibility and control. Its ability to separate the control plane from the data plane, coupled with centralized control and programmability, has opened up endless possibilities in network architecture design. As organizations strive for more agile and efficient networks, embracing OpenFlow and its associated technologies will undoubtedly be a wise choice.

Cisco Switch Virtualization Nexus 1000v

September 11, 2014

by Matt Conran Blog

Cisco Switch Virtualization Nexus 1000v

Virtualization has become integral to modern data centers in today's digital landscape. With the increasing demand for agility, flexibility, and scalability, organizations are turning to virtual networking solutions to meet their evolving needs. One such solution is the Nexus 1000v, a virtual network switch offering comprehensive features and functionalities. In this blog post, we will delve into the world of the Nexus 1000v, exploring its key features, benefits, and use cases.

The Nexus 1000v is a distributed virtual switch that operates at the hypervisor level, providing advanced networking capabilities for virtual machines (VMs). It is designed to integrate seamlessly with VMware vSphere, offering enhanced network visibility, control, and security.

Cisco Switch Virtualization is a revolutionary concept that allows network administrators to create multiple virtual switches on a single physical switch. By abstracting the network functions from the hardware, it provides enhanced flexibility, scalability, and efficiency. With Cisco Switch Virtualization, businesses can maximize resource utilization and simplify network management.

At the forefront of Cisco's Switch Virtualization portfolio is the Nexus 1000v. This powerful platform brings the benefits of virtualization to the data center, enabling seamless integration between virtual and physical networks. By extending Cisco's renowned networking capabilities into the virtual environment, Nexus 1000v empowers organizations to achieve consistent policy enforcement, enhanced security, and simplified operations.

The Nexus 1000v boasts a wide range of features that make it a compelling choice for network administrators. From advanced network segmentation and traffic isolation to granular policy control and deep visibility, this platform has it all. By leveraging the power of Cisco's Virtual Network Services (VNS), organizations can optimize their network infrastructure, streamline operations, and deliver superior performance.

Deploying Cisco Switch Virtualization, specifically the Nexus 1000v, requires careful planning and consideration. Organizations must evaluate their network requirements, ensure compatibility with existing infrastructure, and adhere to best practices. From designing a scalable architecture to implementing proper security measures, attention to detail is crucial to achieve a successful deployment.

To truly understand the impact of Cisco Switch Virtualization, it's essential to explore real-world use cases and success stories. From large enterprises to service providers, organizations across various industries have leveraged the power of Nexus 1000v to transform their networks. This section will highlight a few compelling examples, showcasing the versatility and value that Cisco Switch Virtualization brings to the table.

Matt Conran

Highlights: Cisco Switch Virtualization Nexus 1000v

Hypervisor and vSphere Introduction

An operating system can run multiple operating systems on a single hardware host using a hypervisor, also known as a virtual machine manager. Operating systems use the host’s processor, memory, and other resources. Hypervisors control the host processor, memory, and other resources and allocate what each operating system needs. Hypervisors run guest operating systems or virtual machines on top of them.

Designed specifically for integration with VMware vSphere environments, the Cisco Nexus 1000V Series Switch runs Cisco NX-OS software. Enterprise-class performance, scalability, and scalability are delivered by VMware vSphere 2.0 across multiple platforms. Within the VMware ESX hypervisor, the Nexus 1000V runs. With the Cisco Nexus 1000V Series, you can take advantage of Cisco VN-Link server virtualization technology

• Policy-based virtual machine (VM) connectivity

• Mobile VM security

• Network policy

• Nondisruptive operational model for your server virtualization and networking teams

As with physical servers, virtual servers can be configured with the same network configuration, security policy, diagnostic tools, and operational models as physical servers. The Cisco Nexus 1000V Series is also compatible with VMware vSphere, vCenter, ESX, and ESXi.

A brief overview of the Nexus 1000V system

There are two primary components of the Cisco Nexus 1000V Series switch:

VEM (Virtual Ethernet Module): Executes inside hypervisors
VSM (External Virtual Supervisor Module): Manages VEMs

Nexus 1000v implements a generic concept of Cisco Distributed Virtual Switch (DVS). VMware ESX or ESXi executes the Cisco Nexus 1000V Virtual Ethernet Module (VEM). The VEM’s application programming interface (API) is VMware vNetwork Distributed Switch (vDS).

By integrating the API with VMware VMotion and Distributed Resource Scheduler (DRS), advanced networking capabilities can be provided to virtual machines. In the VEM, Layer 2 switching and advanced networking functions are performed based on configuration information from the VSM:

Virtual routing and forwarding

Virtual routing and forwarding form the basis of this stack. Firstly, network virtualization comes with two primary methods: 1) One too many and 2) Many to one. The “one too many” network virtualization method means you segment one physical network into multiple logical segments. Conversely, the “many to one” network virtualization method consolidates numerous physical devices into one logical entity. By definition, they seem to be opposites, but they fall under the same umbrella in network virtualization.

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

Network virtualization

Before we get stuck in Cisco virtualization, let us address some basics. For example, if you have multiple virtual endpoints share a physical network. Still, different virtual endpoints belong to various customers, and the communication between these endpoints also needs to be isolated. In other words, the network is a resource, too, and network virtualization is the technology that enables the sharing of a standard physical network infrastructure.

Virtualization uses software to simulate traditional hardware platforms and create virtual software-based systems. For example, virtualization allows specialists to construct a single virtual network or partition a physical network into multiple virtual networks.

Cisco Switch Virtualization: Logical segmentation: One too many

We have one-to-many network virtualization for the Cisco switch virtualization design; a single physical network is logically segmented into multiple virtual networks. For example, each virtual network could correspond to a user group or a specific security function.

End-to-end path isolation requires the virtualization of networking devices and their interconnecting links. VLANs have been traditionally used, and hosts from one user group are mapped to a single VLAN. To extend the path across multiple switches at Layer 2, VLAN tagging (802.1Q) can carry VLAN information between switches. These VLAN trunks were created to transport multiple VLANs over a single Ethernet interface.

The diagram below displays two independent VLANs, VLAN201 and VLAN101. These VLANs can share one physical wire to provide L2 reachability between hosts connected to Switch B and Switch A via Switch C, but they remain separate entities.

VLANs are sufficient for small Layer 2 segments. However, today’s networks will likely have a mix of Layer 2 and 3 routed networks. In this case, Layer 2 VLANs alone are insufficient because you must extend the Layer 2 isolation over a Layer 3 device. This can be achieved by using Virtual Routing and Forwarding ( VRF ), the next step in the Cisco switch virtualization. A virtual routing and forwarding instance logically carves a Layer 3 device into several isolated independent L3 devices. The virtual routing and forwarding configured locally cannot communicate directly.

The diagram below displays one physical Layer 3 router with three VRFs: VRF Yellow, VRF Red, and VRF Blue. These virtual routing and forwarding instances are completely separated; without explicit configuration, routes in one virtual routing and forwarding instance cannot be leaked to another.

Virtual Routing and Forwarding

The virtualization of the interconnecting links depends on how the virtual routers are connected. If they are physically ( directly ) connected, you could use a technology known as VRF-lite to separate traffic and 802.1Q to label the data plane. This is known as hop-by-hop virtualization.

However, it’s possible to run into scalability issues when the number of devices grows. This design is typically used when you connect virtual routing and forwarding back to back, i.e., no more than two devices.

When the virtual routers are connected over multiple hops through an IP cloud, you can use generic routing encapsulation ( GRE ) or Multiprotocol Label Switching ( MPLS ) virtual private networks.

GRE is probably the simpler of the Layer 3 methods, and it can work over any IP core. GRE can encapsulate the contents and transport them over a network with the network unaware of the packet contents. Instead, the core will see the GRE header, virtualizing the network path.

Cisco Switch Virtualization: The additional overhead

When designing Cisco switch virtualization, you need to consider the additional overhead. There are a further 24 bytes overhead for the GRE header, so it may be the case that the forwarding router may break the datagram into two fragments, so the packet may not be larger than the outgoing interface MTU. To resolve the fragmentation issue, you can correctly configure MTU, MSS, and Path MTU parameters on the outgoing and intermediate routers.

The GRE standard is typically static. You only need to configure tunnel endpoints, and the tunnel will be up as long as you can reach those endpoints. However, recent designs can establish a dynamic GRE tunnel.

MPLS/VPN, on the other hand, is a different beast. It requires signaling to distribute labels and build an end-to-end Label Switched Path ( LSP ). The label distribution can be done with BGP+label, LDP, and RSVP. Unlike GRE tunnels, MPLS VPNs do not have to manage multiple point-to-point tunnels to provide a full mesh of connectivity. Instead, they are used for connectivity, and packets’ labels provide traffic separation.

Cisco switch virtualization: Many to one

Many-to-one network consolidation refers to grouping two or more physical devices into one. Examples of this Cisco switch virtualization technology include a Virtual Switching System ( VSS ), Stackable switches, and Nexus VPC. Combining many physicals into one logical entity allows STP to view the logical group as one, allowing all ports to be active. By default, STP will block the redundant path.

Software-defined networking takes this concept further; it completely abstracts the entire network into a single virtual switch. The control and data planes are on the same device on traditional routers, yet they are decoupled with SDN. The control plan is now on a policy-driven controller, and the data plane is local on the OpenFlow-enabled switch.

Network Virtualization

Server and network virtualization presented the challenge of multiple VMs sharing a single network physical port, such as a network interface controller ( NIC ). The question then arises: how do I link multiple VMs to the same uplink? How do I provide path separation? Today’s networks need to virtualize the physical port and allow the configuration of policies per port.

NIC-per-VM design

One way to do this is to have a NIC-per-VM design where each VM is assigned a single physical NIC, and the NIC is not shared with any other VM. The hypervisor, aka virtualization layer, would be bypassed, and the VM would access the I/O device directly. This is known as VMDirectPath.

This direct path or pass-through can improve performance for hosts that utilize high-speed I/O devices, such as 10 Gigabit Ethernet. However, the lack of flexibility and the ability to move VMs offset higher performance benefits.

Virtual-NIC-per-VM in Cisco UCS (Adapter FEX)

Another way to do this is to create multiple logical NICs on the same physical NIC, such as Virtual-NIC-per-VM in Cisco UCS (Adapter FEX). These logical NICs are assigned directly to VMs, and traffic gets marked with a vNIC-specific tag on the hardware (VN-Tag/802.1ah).

The actual VN-Tag tagging is implemented in the server NICs so that you can clone the physical NIC in the server to multiple virtual NICs. This technology provides faster switching and enables you to apply a rich set of management features to local and remote traffic.

Software Virtual Switch

The third option is to implement a virtual software switch in the hypervisor. For example, VMware introduced virtual switching compatibility with its vSphere ( ESXi ) hypervisor, called vSphere Distributed Switch ( VDS ). Initially, they introduced a local L2 software switch, which was soon phased out due to a lack of distributed architecture.

Data physically moves between the servers through the external network, but the control plane abstracts this movement to look like one large distributed switch spanning multiple servers. This approach has a single management and configuration point, similar to stackable switches – one control plane with many physical data forwarding paths.

The data does not move through a parent partition but logically connects directly to the network interface through local vNICs associated with each VM.

Network virtualization and Nexus 1000v ( Nexus 1000 )

The VDS introduced by VMware lacked any good networking features, which led Cisco to introduce the Nexus 1000V software-based switch. The Nexus 1000v is a multi-cloud, multi-hypervisor, and multi-services distributed virtual switch. Its function is to enable communication between VMs.

Nexus 1000 components: VEM and VSM

The Nexus 1000v has two essential components:

The Virtual Supervisor Module ( VSM )
The Virtual Ethernet Module ( VEM ).

Compared to a physical switch, the VSM could be viewed as the supervisor, setting up the control plane functions for the data plane to forward efficiently, and the VEM as the physical line cards that do all the packet forwarding. The VEM is the software component that runs within the hypervisor kernel. It handles all VM traffic, including inter-VM frames and Ethernet traffic between a VM and external resources.

The VSM runs its NX-OS code and controls the control and management planes, which integrate into a cloud manager, such as a VMware vCenter. You can have two VSMs for redundancy. Both modules remain constantly synchronized with unicast VSM-to-VSM heartbeats to provide stateful failover in the event of an active VSM failure.

The two available communication options for VSM to VEM are:

Layer 2 control mode: The VSM control interface shares the same VLAN with the VEM.
Layer 3 control mode: The VEM and the VSM are in different IP subnets.

The VSM also uses heartbeat messages to detect a loss of connectivity between it and the VEM. However, the VEM does not depend on connectivity to the VSM to perform its data plane functions and will continue forwarding packets if the VSM fails.

With Layer 3 control mode, the heartbeat messages are encapsulated in a GRE envelope.

Nexus 1000 and VSM best practices

L2 control is recommended for new installations.
Use MAC pinning instead of LACP.
Packet, Control, and Management in the same VLAN.
Do not use VLAN 1 for Control and Packet.
Use 2 x VSM for redundancy.

The max latency between VSM and VEM is ten milliseconds. Therefore, a VSM can be placed outside the data center if you have a high-quality DCI link, and the VEM can still be controlled.

Nexus 1000v InterCloud – Cisco switch virtualization

A vital element of the Nexus 1000 is its use case for hybrid cloud deployments and its ability to place workloads in private and public environments via a single pane of glass. In addition, the Nexus 1000v interCloud addresses the main challenges with hybrid cloud deployments, such as security concerns and control/visibility challenges within the public cloud.

The Nexus 1000 interCloud works with Cisco Prime Service Controller to create a secure L2 extension between the private data center and the public cloud.

This L2 extension is based on Datagram Transport Layer Security ( DTLS ) protocol and allows you to securely transfer VMs and Network services over a public IP backbone. DTLS derives the SSL protocol and provides communications privacy for datagram protocols, so all data in motion is cryptographically isolated and encrypted.

Nexus 1000v Hybrid Cloud Components

Cisco Prime Network Service Controller for InterCloud **	A VM that provides a single pane of glass to manage all functions of the inter clouds
InterCloud VSM	Manage port profiles for VMs in the InterCloud infrastructure
InterCloud Extender	Provides secure connectivity to the InterCloud Switch in the provider cloud. Install in the private data center.
InterCloud Switch	Virtual Machine in the provider data center has secure connectivity to the InterCloud Extender in the enterprise cloud and secure connectivity to the Virtual Machines in the provider cloud.
Cloud Virtual Machines	VMs in the public cloud running workloads.

Prerequisites

Port 80	HTTP access from PNSC for AWS calls and communicating with InterCloud VMs in the provider cloud
Port 443	HTTPS access from PNSC for AWS calls and communicating with InterCloud VMs in the provider cloud
Port 22	SSH from PNSC to InterCloud VMs in the provider cloud
UDP 6644	DTLS data tunnel
TCP 6644	DTLS control tunnel

VXLAN – Virtual Extensible LAN

The requirement for applications on demand has led to an increased number of required VLANs for cloud providers. The standard 12-bit identifier, which provided 4000 VLANs, proved to be a limiting factor in multi-tier, multi-tenant environments, and engineers started to run out of isolation options.

This has introduced a 24-bit VXLAN identifier, offering 16 million logical networks. Now, we can cross Layer 3 boundaries. The MAC in UDP encapsulation uses switch hashing to analyze UDP packets and efficiently distribute all packets in a port channel.

VXLAN works like a layer 2 bridge ( Flood and Learn ); the VEM learn does all the heavy lifting, learns all the VM source MAC and Host VXLAN IPs, and encapsulates the traffic according to the port profile to which the VM belongs. Broadcast, Multicast, and unknown unicast traffic are sent as Multicast.

At the same time, unicast traffic is encapsulated and shipped directly to the destination host’s VXLAN IP, aka destination VEM. Enhanced VXLAN offers VXLAN MAC distribution and ARP termination, making it more optional.

VXLAN Mode Packet Functions

Packet	VXLAN(multicast mode)	Enhanced VXLAN(unicast mode)	Enhanced VXLANMAC Distribution	Enhanced VXLANARP Termination
Broadcast /Multicast	Multicast Encapsulation	Replication plus Unicast Encap	Replication plus Unicast Encap	Replication plus Unicast Encap
Unknown Unicast	Multicast Encapsulation	Replication plus Unicast Encap	Drop	Drop
Known Unicast	Unicast Encapsulation	Unicast Encap	Unicast Encap	Unicast Encap
ARP	Multicast Encapsulation	Replication plus Unicast Encap	Replication plus Unicast Encap	VEM ARP Reply

vPath – Service chaining

Intelligent Policy-based traffic steering through multiple network services.

vPath allows you to intelligently traffic steer VM traffic to virtualized devices. It intercepts and redirects the initial traffic to the service node. Once the service node performs its policy function, the result is cached, and the local virtual switch treats the subsequent packets accordingly. In addition, it enables you to tie services together to push the VM through each service as required. Previously, if you wanted to tie services together in a data center, you needed to stitch the VLANs together, which was limited by design and scale.

Cisco virtualization — Nexus and service chaining

vPath 3.0 is now submitted to the IETF for standardization, allowing service chaining with vPath and non-vpath network services. It enables you to use vpath service chaining between multiple physical devices and supporting multiple hypervisors.

License Options

Nexus 1000 Essential Edition	Nexus 1000 Advanced Edition
Full Layer-2 Feature Set	All Features of Essential Edition
Security, QoS Policies	VSG firewall
VXLAN virtual overlays	VXLAN Gateway
vPath enabled Virtual Services	TrustSec SGA
Full monitoring and management capabilities	A platform for other Cisco DC Extensions in the Future
Free	$695 per CPU MSRP

Nexus 1000 features and benefits

Switching	L2 Switching, 802.1Q Tagging, VLAN, Rate Limiting (TX), VXLAN IGMP Snooping, QoS Marking (COS & DSCP), Class-based WFQ
Security	Policy Mobility, Private VLANs w/ local PVLAN Enforcement Access Control Lists, Port Security, Cisco TrustSec Support Dynamic ARP inspection, IP Source Guard, DHCP Snooping
Network Services	Virtual Services Datapath (vPath) support for traffic steering & fast-path off-load[leveraged by Virtual Security Gateway (VSG), vWAAS, ASA1000V]
Provisioning	Port Profiles, Integration with vC, vCD, SCVMM*, BMC CLM Optimized NIC Teaming with Virtual Port Channel – Host Mode
Visibility	VM Migration Tracking, VC Plugin, NetFlow v.9 w/ NDE, CDP v.2 VM-Level Interface Statistics, vTrackerSPAN & ERSPAN (policy-based)
Management	Virtual Centre VM Provisioning, vCenter Plugin, Cisco LMS, DCNM Cisco CLI, Radius, TACACs, Syslog, SNMP (v.1, 2, 3) Hitless upgrade, SW Installer

Advantages and disadvantages of the Nexus 1000

Advantages	Disadvantages
The Standard edition is FREE; you can upgrade to an enhanced version when needed.	VEM and VSM internal communication is very sensitive to latency. Due to their chatty nature, they may not be good for inter-DC deployments.
Easy and Quick to deploy	VSM – VEM, VSM (active) – VSM (standby) heartbeat time of 6 seconds makes it sensitive to network failures and congestion.
It offers you many rich network features unavailable on other distributed software switches.	VEM over-dependency on VSM reduces resiliency.
Hypervisor agnostic	VSM is required for vSphere HA, FT, and VMotion to work.
Hybrid Cloud functionality

Closing Points on Cisco Nexus 1000v

Virtual Ethernet Module (VEM):

The Nexus 1000v employs the Virtual Ethernet Module (VEM), which runs as a module inside the hypervisor. This allows for efficient and direct communication between VMs, bypassing the traditional reliance on the hypervisor networking stack.

Virtual Supervisor Module (VSM):

The Virtual Supervisor Module (VSM) serves as the control plane for the Nexus 1000v, providing centralized management and configuration. It enables network administrators to define policies, manage virtual ports, and monitor network traffic.

Policy-Based Virtual Network Management:

With the Nexus 1000v, administrators can define policies to manage virtual networks. These policies ensure consistent network configurations across multiple hosts, simplifying network management and reducing the risk of misconfigurations.

Advanced Security and Monitoring Capabilities:

The Nexus 1000v offers granular security controls, including access control lists (ACLs), port security, and dynamic host configuration protocol (DHCP) snooping. Additionally, it provides comprehensive visibility into network traffic, enabling administrators to monitor and troubleshoot network issues effectively.

Benefits of the Nexus 1000v:

Enhanced Network Performance:

By offloading network processing to the VEM, the Nexus 1000v minimizes the impact on the hypervisor, resulting in improved network performance and reduced latency.

Increased Scalability:

The distributed architecture of the Nexus 1000v allows for seamless scalability, ensuring that organizations can meet the growing demands of their virtualized environments.

Simplified Network Management:

With its policy-based approach, the Nexus 1000v simplifies network management tasks, enabling administrators to provision and manage virtual networks more efficiently.

Use Cases:

Data Centers:

The Nexus 1000v is particularly beneficial in data center environments where virtualization is prevalent. It provides a robust and scalable networking solution, ensuring optimal performance and security for virtualized workloads.

Cloud Service Providers:

Cloud service providers can leverage the Nexus 1000v to enhance their network virtualization capabilities, offering customers more flexibility and control over their virtual networks.

The Nexus 1000v is a powerful virtual network switch that provides advanced networking capabilities for virtualized environments. Its rich features, policy-based management approach, and seamless integration with VMware vSphere allow organizations to achieve enhanced network performance, scalability, and management efficiency. As virtualization continues to shape the future of data centers, the Nexus 1000v remains a valuable tool for optimizing virtual network infrastructures.

Summary: Cisco Switch Virtualization Nexus 1000v

Welcome to our blog post, where we dive into the world of Cisco Switch Virtualization, explicitly focusing on the Nexus 1000v. In this article, we will unravel the complexities surrounding switch virtualization, explore the key features of the Nexus 1000v, and understand its significance in modern networking environments.

Understanding Switch Virtualization

Switch virtualization is a technique that allows for creating multiple virtual switches on a single physical switch, enabling greater flexibility and efficiency in network management. Organizations can consolidate their infrastructure, reduce costs, and streamline network operations by virtualizing switches.

Introducing the Nexus 1000v

The Cisco Nexus 1000v is a powerful switch virtualization solution that extends the functionality of VMware environments. Unlike traditional virtual switches, it provides a more comprehensive set of features and advanced network control. It seamlessly integrates with VMware vSphere, offering enhanced visibility, security, and policy management.

Key Features of the Nexus 1000v

– Distributed Virtual Switch: The Nexus 1000v operates as a distributed virtual switch, distributing network intelligence across all hosts in the virtualized environment. This ensures consistent policies, simplified troubleshooting, and improved performance.

– Virtual Port Profiles: With virtual port profiles, administrators can define consistent network policies for virtual machines, irrespective of their physical location. This simplifies network provisioning and reduces the chances of misconfigurations.

– Network Analysis Module (NAM): The Nexus 1000v incorporates NAM, a robust monitoring and analysis tool that provides deep visibility into virtual network traffic. This enables administrators to identify and resolve network issues, ensuring optimal performance quickly.

Deployment Considerations

When planning to deploy the Nexus 1000v, it is essential to consider factors such as network architecture, compatibility with existing infrastructure, and scalability requirements. It is advisable to consult with Cisco experts or certified partners to ensure a smooth and successful implementation.

Conclusion:

In conclusion, the Cisco Nexus 1000v is a game-changer in switch virtualization. Its advanced features, seamless integration with VMware environments, and extensive network control make it an ideal choice for organizations seeking to optimize their network infrastructure. By understanding the fundamentals of switch virtualization and exploring Nexus 1000v’s capabilities, network administrators can unlock a world of possibilities in network management and performance.

OpenFlow Protocol

Highlights: OpenFlow Protocol

Understanding OpenFlow Protocol

**Key OpenFlow Benefits**

**Key OpenFlow Features**

**OpenFlow Use Cases**

SDN: A History Guide

Example Technology: Policy-Based Routing

Real-World Applications of OpenFlow

OpenFlow Protocol

OpenFlow history

Highlighting SDN

OpenFlow Protocol: Separation of Planes

A: – The data plane

B: – The control plane

C: – The management plane

**The Idea of OpenFlow Protocol**

A key point: Open vSwitch

A key point: OpenFlow and Open Networking

OpenFlow protocol and decoupling

Flow table and OpenFlow forwarding model

OpenFlow ports

TCAM download protocol

OpenFlow Classifiers

OpenFlow Groups

Final Points: OpenFlow Protocol

Summary: OpenFlow Protocol

OpenFlow and SDN Adoption

Highlights: OpenFlow and SDN Adoption

Understanding OpenFlow

Use Cases and Real-World Applications

Background: OpenFlow L2 Switching & VLAN Handling

Impact on the Networking Landscape

The SDN Layers

A Programmable Network

The role of OpenFlow

OpenFlow and SDN Adoption

What is OpenFlow?

**Benefits of OpenFlow and SDN Adoption**

**Challenges and Considerations**

Starting Points for SDN Adoption

SDN Architectures and OpenFlow

SDN adoption report: Virtual switching fabric

Open Shortest Path First (OSPF)

Example Routing Technology with OSPF

Do you think OpenFlow will be derailed?

**Will it be used for program forwarding paths instead of BGP?**

Example IPv6 Technology: NAT64

Example BGP Technology: EBGP and IBGP

The Future of OpenFlow and SDN:

Closing Points on SDN and OpenFlow

Summary: OpenFlow and SDN Adoption

Optimal Layer 3 Forwarding

The engineering principle

The packet-forwarding sequence

Routing table versus forwarding table

Control plane · RIB

Forwarding plane · FIB

Longest-prefix match: choosing the destination route

Next-hop resolution and Layer 2 rewriting

1. Compare the routing entries

2. Follow the forwarding process

Where routes come from

Connected routes

Static routes

OSPF and EIGRP

BGP

Administrative distance and route preference

How BGP selects a path

Next-hop reachability: a selected route must be usable

Part A — Compare route sources

Route-source comparison

Part B — Explore BGP best-path selection

Understand the decision sequence

Equal-Cost Multipath (ECMP)

Use parallel paths

Recover from path loss

Cisco Express Forwarding (CEF)

Layer 3 EtherChannel and link aggregation

Logical routed interface

Key OpenFlow Benefits

Key OpenFlow Features

OpenFlow Use Cases

The Idea of OpenFlow Protocol

Benefits of OpenFlow and SDN Adoption

Challenges and Considerations

Will it be used for program forwarding paths instead of BGP?