Openflow protocol

OpenFlow Protocol

 

 

OpenFlow Protocol

In today’s fast-paced and interconnected world, network management has become increasingly complex. Traditional networking architectures often struggle to keep up with the demands of modern networks. However, an innovative solution called OpenFlow Protocol has emerged, promising to revolutionize network management by providing a more flexible and efficient approach. This blog post will explore the critical concepts of OpenFlow Protocol and its potential benefits for network administrators and organizations.

OpenFlow Protocol is an open standard that separates network control and forwarding plane. It allows network administrators to centrally control and manage network devices, such as switches and routers, through a separate controller. This controller acts as a brain for the network, making decisions on handling network traffic and directing it to its intended destination.

 

Highlights: OpenFlow Protocol

  • The role 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:

  1. SDN Adoption Report
  2. Network Traffic Engineering
  3. BGP SDN
  4. NFV Use Cases
  5. Virtual Switch 
  6. HP SDN Controller

 



OpenFlow protocol.

Key OpenFlow Discussion Points:


  • Introduction to OpenFlow and what is involved.

  • Highlighting the separation of planes.

  • Discussing the data plane, control plane, and management plane.

  • Technical details of the OpenFlow protocol and its operation.

  • The role of the different OpenFlow hardware components.

 

Back to basics with OpenFlow

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 have existed since the inception of networking, consisting of switches, routers, and firewalls. We have data at each layer 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 the operations of networks, 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.

 

Key Features and Benefits:

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.

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.

 

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.

 

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.

 

The control plane

The control plane is responsible for giving the data plane the required information enabling 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; it’s 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.

 

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.

Switch functions
Diagram: Switch functions. Source is Bradhedlund

 

 

The Idea of OpenFlow Protocol

OpenFlow is not revolutionary new; similar ideas have been around for the last 20 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 a specific matching doesn’t mean that the hardware can match on those fields. For example, Juniper uses OpenFlow 1.3, permitting IPv6 handling, but their 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 forwarding needs of that switch. As a result, the model for the OpenFlow forwarding model was one simple 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.

Openflow protocol
Diagram: OpenFlow protocol

 

  • 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 action of the packet 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 send 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, for example, 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.

 

OpenFlow Ports

  • PORT ALL: flooding to all ports.

  • PORT CONTROLLER: punt packets to the controller.

  • PORT LOCAL: forward to the local switch control plane.

  • PORT NORMAL: forward to local switch regular data plane.

  • PORT FLOOD: local switch flooding mechanism.

 

  • 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; for example, NORMAL port for traditional processing, LOCAL PORT for the local control plane, and CONTROLLER port to send 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 but 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 send to port 1, and bucket 2 to port 2 but 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.

 

Conclusion:

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.

 

openflow

OpenFlow Service Chaining

OpenFlow and SDN Adoption

 

SDN Adoption report

 

SDN Adoption

In networking, OpenFlow and Software-Defined Networking (SDN) have emerged as groundbreaking technologies that are transforming how networks are designed, managed, and operated. This blog post aims to provide a comprehensive understanding of OpenFlow and SDN adoption, shedding light on their benefits, challenges, and the future of network infrastructure.

 

Highlights: SDN Adoption

  • 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 something that is revolutionary new. Similar ideas have been available, and previous projects 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:

  1. Virtual Overlay Network
  2. SDN Router
  3. What is OpenFlow
  4. BGP SDN
  5. SDN BGP
  6. Hyperscale Networking
  7. SDN Data Center

 



SDN Adoption Report.

Key SDN Adoption Discussion Points:


  • Introduction to SDN OpenFlow and what is involved.

  • Highlighting the SDN architecture.

  • Critical points on the virtual switching fabric.

  • Technical details on the use of OSPF.

  • Technical details for programming the forwarding paths.

  • Final comments on SDN OpenFlow.

 

Back to basics with the SDN.

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 through a centralized controller dynamically. 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 detect and respond to security threats quickly, 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; Internet-facing and 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. The control and data planes are distributed to the same locations if we study existing networks. No central point controls individual nodes, resulting in complex cross-network interactions.

 

sdn adoption

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, 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 manage and control your network better. It removes the box-by-box mentality and introduces automation and programmability.

SDN CONTROLLER

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.

 

SDN ADOPTION

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.

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 the progress in OpenFlow. But; now, the controller market is consolidating, 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 flow of technology adoption will be evident for OpenFlow controllers.

 

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.

Conclusion:

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.

 

 

SDN Adoption report

SDN applications

HP SDN Controller

 

HP OpenFlow

 

HP SDN Controller

In today’s fast-paced digital world, efficient network management is crucial for organizations to stay competitive. Traditional network infrastructures often struggle to keep up with the increasing demands of modern applications and services. Enter the HP SDN Controller, a revolutionary solution transforming how networks are managed. In this blog post, we will delve into the world of the HP SDN Controller, exploring its features, benefits, and how it is reshaping the future of network management.

The HP SDN Controller is a software-defined networking (SDN) solution designed to simplify and automate network management. By decoupling the network control plane from the underlying infrastructure, the SDN Controller empowers organizations to manage and control their networks centrally, making it easier to deploy, scale, and adapt to changing business needs.

 

Highlights: SDN Controller

  • Application SDN

This post discusses HP SDN Controller and its approach to HP OpenFlow based on the OpenFlow protocol. All of which enables an exciting approach to Application SDN. It takes too long to provision network services for an application. As a result, the network lacks agility, and making changes is still a manual process.

Usually, when an application is rolled out, you must reconfigure every device with a command CLI interface. This type of manual configuration cannot accommodate today’s application requirements. Furthermore, static rollout frameworks prohibit dynamic changes to the network, blocking the full potential that applications can bring to the business.

  • The Role of SDN

Software-Defined Networking (SDN) aims to take rigidity out of networks and give you the visibility to make real-time changes and responses. The HP SDN Application Suite changes how the network responds to business needs by programming the network differently. The following post discusses the HP SDN controller and how it works with HP OpenFlow, where HP operates the best part of OpenFlow and uses it with traditional routing and switching. I will also provide an example of an application SDN, such as a network protector and network optimizer.

 

Before you proceed, you may find the following helpful post for pre-information:

  1. SDN Traffic Optimizations
  2. What Is OpenFlow
  3. BGP SDN 
  4. What Does SDN Mean
  5. SDN Adoption Report
  6. WAN SDN 
  7. Hyperscale Networking

 



SDN Controller

Key HP SDN Controller Discussion Points:


  • Introduction to HP SDN Controller and what is involved.

  • Highlighting HP OpenFlow and the components involved.

  • Critical points on the SDN VAN controller.

  • Technical details on Application SDN: Network Protector.

  • Technical details on Application SDN: Network Optimizer

 

Back to basics with SDN

Software-Defined Networking (SDN) is the decoupling of network control from networking devices that are used to forward the traffic. The network control functionality, also known as the control plane, is decoupled from the data forwarding functionality (also known as the data plane). Furthermore, the split control is programmable by exposing several APIs. The migration of control logic, which used to be tightly integrated into networking devices into logically centralized controllers, enables the underlying networking infrastructure to be abstracted from an application’s point of view.

 

Key Features of HP SDN Controller:

Centralized Management: The SDN Controller provides a centralized platform for managing and configuring network devices, eliminating the need for manual configurations on individual switches or routers. This streamlined approach improves efficiency and reduces the risk of human errors.

Programmable Network: With the HP SDN Controller, network administrators can program and control the behavior of the network through open APIs. This programmability enables organizations to tailor their network infrastructure to meet specific requirements, such as optimizing performance, enhancing security, or enabling new services.

Network Virtualization: Virtualizing the network infrastructure allows organizations to create multiple virtual networks on a shared physical infrastructure. The SDN Controller enables network virtualization, providing isolation and segmentation of traffic, improving network scalability, and simplifying network management.

Traffic Engineering and Performance Optimization: HP SDN Controller enables dynamic traffic engineering, allowing administrators to route traffic based on real-time conditions intelligently. This capability improves network performance, reduces congestion, and enhances user experience.

Benefits of HP SDN Controller:

Improved Network Agility: The SDN Controller enables organizations to respond quickly to changing business needs, allowing for a more agile and flexible network infrastructure. It simplifies the deployment of new applications and services, reduces time-to-market, and enhances the organization’s ability to innovate.

Enhanced Security: With the SDN Controller’s centralized control and programmability, organizations can implement security policies and access control measures more effectively. It enables granular control and visibility, empowering administrators to monitor and secure the network infrastructure against potential threats.

Cost Savings: By automating network management tasks and optimizing resource allocation, HP SDN Controller helps organizations reduce operational costs. It eliminates the need for manual configurations on individual devices, reduces human errors, and improves overall network efficiency.

Scalability and Flexibility: The SDN Controller allows organizations to scale their network infrastructure as their business snowballs. It supports integrating new devices, services, and technologies without disrupting the existing network, ensuring flexibility and future infrastructure-proofing.

Real-World Applications of HP SDN Controller:

Data Centers: HP SDN Controller facilitates the management and orchestration of network resources in data centers, enabling organizations to allocate resources efficiently, optimize workload distribution, and enhance overall performance.

Campus Networks: By centralizing network management, the SDN Controller simplifies the configuration and deployment of services across campus networks. It allows for seamless integration of wired and wireless networks, improves scalability, and enhances user experience.

Service Providers: HP SDN Controller empowers providers to deliver agile and scalable customer services. It enables the creation of virtualized network functions and improves service provisioning, reducing time-to-market and enhancing service quality.

 

HP SDN

Hewlett Packard (HP) has taken a different approach to SDN. They do not want to recreate every wheel invented and roll out a blanket greenfield OpenFlow solution. Routing has worked for 40 years, so we cannot expect to see some revolutionary change to routing as it’s simply not there. Consider how complicated distributed systems are. Filing all Layer 2 and 3 protocols with OpenFlow is nearly impossible.

Layer 2 switches learn MAC addresses automatically, building a table that can selectively forward packets. So, why is there a need to replace how switches learn via Layer 2? The layer 2-learning mechanism works fine, and no real driver can replace it. There are Potential drivers for Spanning Tree Protocol (STP) replacement as it is dangerous, but there is no reason to replace the layer 2-learning mechanism. So, why attempt this with OpenFlow?

 

HP OpenFlow

OpenFlow comes with its challenges. It derives from Stanford and is very academic. It’s hard to use and deploy in its pure form. HP adds to it and makes it more usable. They tune its implementation to match today’s network requirements using parts of OpenFlow, considering this to be HP OpenFlow and traditional routing. OpenFlow is generally not good, but certain narrow niche cases exist where it can be used. Campus networks are one of those niches, and HP is marketing its product set for this niche.

Their HP SDN controller product sets markets the network edge and leaves the core to what it does best. This allows an easy migration path by starting at the edge and moving gradually to the core ( if needed). This type of migration path keeps the potential blast radius to a minimum. An initial migration strategy by starting at the edge with SDN islands sounds appealing.

 

Diagram: HP SDN Controller.

 

HP SDN: The SDN VAN controller

HP removed the North-South bottleneck communication. They are not sending anything to the controller. Any packets that miss an OpenFlow rule hit what is known as the last rule and are sent with standard packet processing via traditional methods.

The last rule, “Forward match all – forward normal,” reverts to the regular forwarding plane, and the network does what it’s always done. If no OpenFlow match exists, packets are forwarded via traditional means. They use a conventional distributed control plane so it can scale. Suppose you consider a controller that has to learn the topology and compute the best path through a topology.

In that case, controller-based “routing” is almost certainly more complex than distributed routing protocols. HP SDN design does not do this and combines the best from OpenFlow and Routing. OpenFlow rules take precedence over most of the control plane elements.

However, most Layer 2-control plane protocols are left to traditional methods. As a general rule, you keep time-critical things such as Link Aggregation Control Protocol (LACP) and Bidirectional Forwarding Detection (BFD) with conventional methods, and other controls that are not as time-critical can be done with OpenFlow.

 

  • HP OpenFlow: HP uses Openflow to glean and not modify the forwarding plane.

 

The controller can work in several modes. The first is the Hybrid model that forwards with OpenFlow rules. If all OpenFlow rules are not matched, it will fall back to standard processing. The second mode is Discovery. This is where the local SDN switches send copies of ARP and DHCP packets to the controller. By analyzing this information, the controller knows where all the hosts are and can build a network topology map. A centralized view of the network topology is a significant benefit to SDN.

They also use BBDP, which is similar to LLDP. It uses a broadcast domain and is not just link-level, enabling it to fly through OpenFlow-enabled switches. The controller is not directly influencing forwarding; it scans the topology by listening to endpoint discovery information. The controller now contains a topology view, but there is no intercepting or redirecting traffic. Instead, it provides endpoint visibility across the network.

HP has started to integrate its SDN controller with Microsoft Active Directory. This gives the controller a different layer of visibility, not just IP and Subnet-based. It now gives you a higher-level language to control your network. It is making decisions based on users and groups, not subnets.

 

Application SDN: Network Protector  

There are a lot of issues with Malware and Spyware, and the HP Protector product can help with these challenges. It enables real-time assessment and security across all SDN devices. The application SDN pushes down one rule – UDP 53 redirects to the controller. It intercepts UDP 53 and can push down ACL rules to block certain types of traffic.

They extract DNS traffic on the network’s edge and pass it to the controller. Application features rank the reputation of an external site and determine how likely you will get something nasty if you go to that site. Additional hit count capability lets the network admin track who requests what. For example, if a host requests 3000 DNS requests per second, it is considered an infected host and quarantined by sending down additional OpenFlow rules.

 

application sdn
Diagram: Application SDN

 

  • A key point: Application SDN and Network visualizer  

SDN application for network admins assists in troubleshooting by defining where the traffic is and where it is going. The network admin can select traffic, make copies, and send it to a location. Similar to tapping, except it is quicker and easier to roll out. Now, your network traffic is viewable on any port and switch. This App lets you go the wire straight away.

As it is now integrated with Active Directory, when a user calls and says he has a network problem, you can extract his traffic by user ID and debug it remotely.

All you need is the User ID; in 30 seconds, you can see his packets. This is a level of visibility previously not available. HP gives you a level of network traffic detail incapable in the past. You could also grab ingress OSPF for analysis. This is not something you could do in the past. You can mirror LSAs and recreate the entire topology. You need access to one switch in the OSPF area.

 

  • A key point: Application SDN and Network optimizer  

This application SDN is used for Microsoft LYNC and SKYPE for business. It provides automated provisioning of network policy and quality of service to endpoints. Lync and Microsoft created a diagnostic API called SDN API. This diagnostic API sends information about the calls, username, IP, and port number on both sides – ingress and egress.

It can reach the ingress switch on each side and remark the Differentiated Services Code Point (DSCP) for the ingress flows. This is how SDN applications should work. SDN implementations should be where the application requests service from the network, and the network responds. We were at Layer 4 with ACL and QoS, not the Layer 7 application. Now, with HP Network Optimizer, the application can notify the network, and the network can respond.

 

Closing SDN comments

The HP SDN suite is about adding value to the network’s edge. Where do you allow the dynamic value of SDN to give value up to customers’ risk appetite? Keeping the dynamic SDN to the edge while keeping the core static is a significant value of SDN and an excellent migration strategy. The SDN concept takes information otherwise out of the network to the network.

 

Conclusion:

The HP SDN Controller is a game-changer in network management, revolutionizing how organizations manage their networks. Its centralized control, programmability, and automation capabilities provide numerous benefits, including improved network agility, enhanced security, cost savings, and scalability. As organizations strive to keep up with the ever-evolving digital landscape, the HP SDN Controller offers a powerful solution to streamline network management and drive innovation.

 

HP OpenFlow

hyperscale networking

Hyperscale Networking

 

 

Hyperscale Networking

In today’s digital age, where data is generated at an unprecedented rate, traditional networking infrastructures are struggling to keep up with the demand. Enter hyperscale networking, a revolutionary paradigm transforming how we build and manage networks. In this blog post, we will explore the concept of hyperscale networking, its benefits, and its impact on various industries.

Hyperscale networking refers to quickly and seamlessly scaling network infrastructure to accommodate massive amounts of data, traffic, and users. It is a distributed architecture that leverages cloud-based technologies and software-defined networking (SDN) principles to achieve unprecedented scalability, agility, and efficiency.

Throughout the last 5-years, data center innovation has come from companies such as Google, Facebook, Amazon, and Microsoft. These companies are referred to as hyper-scale players. The vision of Big Switch is to take hyperscale concepts developed by these companies and bring them to smaller data centers around the world in the version of hyperscale networking, enabling a hyperscale architecture.

 

Before you proceed, you may find the following helpful post for pre-information:

  1. Virtual Data Center Design
  2. ACI Networks
  3. Application Delivery Architecture
  4. ACI Cisco
  5. Data Center Design Guide

 



Hyperscale Networking

Key Hyperscale Architecture Discussion Points:


  • Introduction to hyperscale architecture and what is involved.

  • Highlighting the challenges of a standard chassis design.

  • Critical points on bare metal switches.

  • Technical details on the core and pod designs.

  • SDN controller architecture and distributed routing.

 

  • A key point: Video on Hyperscale computing

In the following video, we will address Hyperscale computing. In computing, hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system. Hyperscale is the ability to scale, for example, compute, memory, networking, and storage resources appropriately to demand to facilitate distributed computing environments.

They employ a disaggregated architectural approach, scaling to over 50,000 servers, often seen in cloud computing and big data environments. Hyperscale architecture is the secret sauce for Facebook and Google. It allowed them to respond efficiently to massively complex workloads while lowering costs.

 

Technology Brief : Cloud Computing - Introducing Hypercomputing
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Back to basic with OpenFlow

With OpenFlow, the switching device has no control plane, as the controller interacts directly with the FIB. Instead, OpenFlow provides a packet format and protocol to carry these packets that now describes forwarding table entries in the FIB. In OpenFlow documentation, the FIB is referred to as the flow table, as it contains information about each flow the switch needs to know about.

Critical Benefits of Hyperscale Networking:

1. Scalability: Hyperscale networking allows organizations to scale their networks effortlessly as demand grows. With traditional networking, scaling often involves costly hardware upgrades and complex configurations. In contrast, hyperscale networks can scale horizontally by adding more commodity hardware, resulting in significantly lower costs and simplified network management.

2. Agility: In the fast-paced digital landscape, businesses must adapt quickly to changing requirements. Hyperscale networking enables organizations to deploy and provision network resources on demand, reducing time-to-market for new services and applications. This agility empowers businesses to respond rapidly to customer demands and gain a competitive edge.

3. Enhanced Performance: Hyperscale networks are designed to handle massive data and traffic efficiently. By distributing workloads across multiple nodes, these networks can deliver superior performance, low latency, and high throughput. This translates into a seamless user experience and improved productivity for businesses.

4. Cost Efficiency: Traditional networking often involves significant upfront investments in proprietary hardware and complex infrastructure—hyperscale networking leverages off-the-shelf hardware and cloud-based technologies, resulting in cost savings and reduced operational expenses. Moreover, the ability to scale horizontally eliminates the need for expensive equipment upgrades.

Hyperscale Networking in Various Industries:

1. Cloud Computing: Hyperscale networking is the backbone of cloud computing platforms. It enables cloud service providers to deliver scalable and reliable services to millions of users worldwide. By leveraging hyperscale architectures, these providers can efficiently manage massive workloads and deliver high-performance cloud services.

2. Internet of Things (IoT): The proliferation of IoT devices generates enormous amounts of data that must be processed and analyzed in real time. Hyperscale networking provides the infrastructure to handle the massive data influx from IoT devices, ensuring seamless connectivity, efficient data processing, and rapid insights.

3. E-commerce: The e-commerce industry heavily relies on hyperscale networking to handle the ever-increasing number of online transactions, user interactions, and inventory management. With hyperscale networks, e-commerce platforms can ensure fast and secure transactions, reliable inventory management, and personalized user experiences.

 

Hyperscale Architecture

Hyperscale networking consists of three things. The first element is bare metal and open switch hardware. Bare metal switches are sold without software, making up 10% of all ports shipped. The second hyperscale aspect is Software Defined Networking (SDN). In SDN vision, you have one device acting as a controller, which manages the physical and virtual infrastructure.

The third element is the actual data architecture—Big Switch leverages what’s known as the Core-and-Pod design. Core-and-Pod differs from the traditional core, aggregation, and edge model, allowing incredible scale and automation when deploying applications.

 

hyperscale networking
Diagram: Hyperscale Networking

 

Standard Chassis Design vs. SDN Design

Standard chassis-based switches have supervisors, line cards, and fabric backplanes. In addition, a proprietary protocol runs between the blades for controls. Big Switch has all of these components but is named differently. Under the covers, the supervisor module acts like an SDN controller, programming the line cards and fabric backplane.

Instead of supervisors, they have a controller, and the internal chassis proprietary protocol is OpenFlow. The leaf switches are treated like line cards, and the spine switches are like the fabric backplane. In addition, they offer an OpenFlow-integrated architecture.

Hyperscale architecture
Diagram: Hyperscale architecture

 

Traditional data center topologies operate on hierarchical tree architecture. The big switch follows a new networking architecture called spine leaf architecture, which overcomes the shortcomings of conventional tree architectures. To map the leaf and spine to traditional data center terminology, the leaf is accessed, and the spine is a core switch.

In addition, the leaf and spine operate on the concept that every leaf has equidistant endpoints. Designs with equidistant endpoints make POD placement and service insertion easier than hierarchical tree architecture.

Big Switch hyperscale architecture has multiple connection points. Similar to Equal Cost Multipath (ECMP) fabric and Multi-Chassis Link Aggregation (MLAG), enabling layer 2 and layer 3 multipathing. This type of connectivity allows you to have network partition problems without having a global effect. You still lose your spin switch’s capacity but have not lost connectivity. The controller controls all this and has a central view.

 

  • Losing a leaf switch in a leaf and spine architecture is not a big deal as long as you have configured multiple paths.

Bare metal switches

The first hyperscale design principle is to utilize bare metal switches. Bare metal switches are Ethernet switches sold without software. Disaggregating the hardware from the switches software allows you to build your switch software stack. Cheaper in terms of CAPEX and allows you to better tune the operating system to what you need. It gives you the ability to tailor the operations to specific requirements.

 

Core and pod design

Traditional core-agg-edge is a monolithic design that cannot evolve. Hyperscale companies are now designing to a core-and-pod design, allowing operations to improve faster. Data centers are usually made up of two core components. One is the core with the Layer 3 routes for ingress and egress routing. Then, you have a POD, a self-contained unit connected to the core.

Intra-communication between PODs is done via core. A POD is a certified design of servers, storage, and network. They are all grouped into standard services. Each POD contains an atomic networking, computing, and storage unit attached directly to the core via Layer 2 or Layer 3. Due to a PODs-fixed configuration, automation is simple and stable.

 

Hyperscale Networking and Big Switch Products

Big Tap and Big Cloud Fabric are two-product streams from Big Switch. Both use a fabric architecture built on white box switches with a centralized controller and POD design. Big clouds hyperscale architecture is designed to be a network for a POD.

Each Big Cloud architecture instance is a pair of redundant SDN controllers, and a leaf/spine topology is the network for your POD. Switches have zero-touch, so they are stateless, turn them on, and it boots and downloads the switch image and configuration. It auto-discovers all of the links and troubleshoots any physical problems.

 

OpenFlow

 

 

SDN controller architecture

There are generic architectural challenges of SDN controller-based networks. The first crucial question is, where are the controller and network devices split? In OpenFlow, it’s clear that the split is between the control plane and the data plane. The split affects the outcomes from various events, such as a controller bug, controller failure, network partitions, and the size of the failure domain.

You might have an SDN controller cluster, but every single controller is; still a single point of failure. The controller cluster protects you from hardware failures but not from software failures. If someone misconfigures or corrupts the controller database, you lose the controller regardless of how many controllers are in a cluster.

Every controller is a single fat fingers domain. Due to the complexity of clusters and clustering protocols, you could implement failures by the lousy design. Every distributed system is complex, and it is even more challenging if it has to work with real-time data.

 

SDN Controllers

 

 

SDN controller – Availability Zones

The optimum design is to build controllers per availability zones. If one controller fails, you lose that side of the fabric but still have another fabric. You must-have applications that can run in multiple availability zones to use this concept. Availability zones are great, but applications must be adequately designed to use them. Availability zones usually relate to a single failure domain.

How do you deal with failures, and what failure rate is acceptable? The failure rate acceptance level drives the redundancy in your network. Full redundancy is a great design goal as it reduces the probability of total network failure. But full redundancy will never give you 100% availability. Network partitions still happen with fully redundant networks.

Be careful of split-brain scenarios when you have one controller looking after one partition and another looking after the other partitions. The way Big Switch overcomes time is with a distributed control plane. The forwarding elements are aligned so a network partition can happen.

 

Hyperscale Architecture: Big Switch distributed routing.

For routing, they have the concept known as a tenant router. With the tenant router, you can say that these two-broadcast domains can talk to each other via policy points. A tenant router is a logical router physically distributed throughout the entire network. Every switch has a copy of the tenant routers routing table local to it. The routing state is spread everywhere. No specific layer 3 points that traffic needs to cross to get from one layer 2 segment to the other.

As all the leaf switches have a distributed copy of the database, all routing takes the most optimal path. When two-broadcast domains are on the same leaf switch, traffic does not have to hairpin to a physical layer 3 points.

You can map the application directly to the tenant router, which acts like a VRF with VRF packet forwarding hardware. This is known as micro-segmentation. With this, you can put a set of applications or VM in a tenant, demarc the network by the tenant, and have per tenant policy.

Conclusion:

Hyperscale networking is revolutionizing how we build and manage networks in the digital era. Its ability to scale effortlessly, provide agility, enhance performance, and reduce costs makes it a game-changer in various industries. As data volumes grow, organizations must embrace hyperscale networking to stay competitive, deliver exceptional user experiences, and drive innovation in a rapidly evolving digital landscape.

 

Optimal VARP Deployment

Optimal Layer 3 Forwarding

Layer 3 forwarding is crucial in ensuring efficient and seamless network data transmission. Optimal Layer 3 forwarding, in particular, is an essential aspect of network architecture that enables the efficient routing of data packets across networks. In this blog post, we will explore the significance of optimal Layer 3 forwarding and its impact on network performance and reliability.

Layer 3 forwarding directs network traffic based on its network layer (IP) address. It operates at the network layer of the OSI model, making it responsible for routing data packets across different networks. Layer 3 forwarding involves analyzing the destination IP address of incoming packets and selecting the most appropriate path for their delivery.

Table of Contents

Highlights: Optimal Layer 3 Forwarding

The Role of Optimal Layer 3 Forwarding:

Optimal Layer 3 forwarding ensures that data packets are transmitted through the most efficient path, improving network performance. It minimizes packet loss, latency, and jitter, enhancing user experience. By selecting the best path, optimal Layer 3 forwarding also enables load balancing, distributing the traffic evenly across multiple links, thus preventing congestion.

Example: Arista with Large Layer-3 Multipath

Arista EOS supports hardware for Leaf ( ToR ), Spine, and Spline data center design layers. They have a wide product range supporting large layer-3 multipath ( 16 – 64-way ECMP ) with excellent optimal Layer 3-forwarding technologies. Unfortunately, multi-protocol Label Switching ( MPLS ) limits to static MPLS labels, which could become an operational nightmare, and as of yet, no Fibre Channel over Ethernet ( FCoE ) support.

Arista supports massive Layer-2 Multipath with ( Multichassis Link aggregation ) MLAG. Validated designs with Arista Core 7508 switches ( offer 768 10GE ports ) and Arista Leaf 7050S-64 support over 1980 x 10GE server ports with 1:2,75 oversubscription. That’s a lot of 10GE ports. Do you think layer 2 domains should be designed to that scale?

 

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

  1. Scaling Load Balancers
  2. Virtual Switch
  3. Data Center Network Design
  4. Layer-3 Data Center
  5. What Is OpenFlow

 



Optimal Layer 3 Forwarding

Key Optimal Layer 3 Forwarding Discussion Points:


  • Introduction to optimal layer 3 forwarding and what is involved.

  • Highlighting the details of using deep buffers.

  • Critical points on the use case of Arista and virtual ARP.

  • Technical details on load balancing enhancements and LACP fallback.

  • Technical details on Direct Server Return and detecting server failures.

 

Back to Basics: Router operation and IP forwarding

Every IP host in a network is configured with its IP address and mask and the IP address of the default gateway. Suppose the host wants to send traffic, which, in our case, is to a destination address that does not belong to a subnet that the host is directly attached to; the host passes the packet to the default gateway. For example, the default gateway would be a Layer 3 router.

The Role of The Default Gateway 

A standard misconception is how the address of the default gateway is used. People mistakenly believe that when a packet is sent to the Layer 3 default router, the sending host sets the destination address in the IP packet as the default gateway router address. However, if this were the case, the router would consider the packet addressed to itself and not forward it any further. So why configure the default gateway’s IP address, then?

First, the host uses the Address Resolution Protocol (ARP) to find the specified router’s Media Access Control (MAC) address. Then, having acquired the router’s MAC address, the host sends the packets directly to it as data link unicast submissions.

 

Benefits of Optimal Layer 3 Forwarding:

1. Enhanced Scalability: Optimal Layer 3 forwarding allows networks to scale effectively by efficiently handling a growing number of connected devices and increasing traffic volumes. It enables seamless expansion without compromising network performance.

2. Improved Network Resilience: By selecting the most efficient path for data packets, optimal Layer 3 forwarding enhances network resilience. It enables networks to quickly adapt to network topology or link failure changes, rerouting traffic to ensure uninterrupted connectivity.

3. Better Resource Utilization: Optimal Layer 3 forwarding optimizes resource utilization by distributing traffic across multiple links. This enables efficient utilization of available network capacity, reducing the risk of bottlenecks and maximizing the network’s throughput.

4. Enhanced Security: Optimal Layer 3 forwarding plays a role in network security by ensuring traffic is directed through secure paths. It enables the implementation of firewall policies and access control lists, protecting the network from unauthorized access and potential security threats.

 

Implementing Optimal Layer 3 Forwarding:

To achieve optimal Layer 3 forwarding, various technologies and protocols are utilized, such as:

1. Routing Protocols: Dynamic routing protocols, such as OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol), enable networks to exchange routing information automatically and determine the best path for data packets.

2. Quality of Service (QoS): QoS mechanisms prioritize network traffic, ensuring that critical applications receive the necessary bandwidth and reducing the impact of congestion.

3. Network Monitoring and Analysis: Continuous network monitoring and analysis tools provide real-time visibility into network performance, enabling administrators to identify and resolve potential issues promptly.

 

Arista deep buffers: Why are they important?

A vital switch table you need to be concerned with for large 3 networks is the size of Address Resolution Protocol ( ARP ) tables. When ARP tables become full and packets are offered with the destination ( next hop ) that isn’t cached, the network will experience flooding and suffer performance problems.

Arista Spine switches have deep buffers, ideal for bursty and latency-sensitive environments. In addition, deep buffers are perfect when you have little knowledge of the application traffic matrix, as they can handle most types efficiently.

Finally, deep buffers are most useful in Spine layers as this is where traffic concentration occurs. If you are concerned that ToR switches do not have enough buffers, physically direct servers to chassis-based switches in the Core / Spine layer.

 

Optimal layer 3 forwarding  

Every data center has some mix of layer 2 bridging and layer 3 forwardings. The design selected depends on layer 2 / layer 3 boundaries. Data centers that use MAC-over-IP usually have layer 3 boundaries on the ToR switch. While fully virtualized data centers require large layer two domains ( for VM mobility ); VLANs span Core or Spine layers.

Either of these designs can result in suboptimal traffic flow. Layer 2 forwarding in ToR switches and layer 3 forwarding in Core may result in servers in different VLANs connected to the same ToR switches being hairpinned to the closest Layer 3 switch.

Solutions that offer optimal Layer 3 forwarding in the data center were available. These may include stacking ToR switches, architectures that present the whole fabric as a single layer 3 elements ( Juniper QFabric ), and controller-based architectures (NEC’s Programmable Flow ). While these solutions may suffice for some business requirements, they don’t have optimal Layer 3 forward across the whole data center while using sets of independent devices.

Arista Virtual ARP does this. All ToR switches share the same IP and MAC with a common VLAN. Configuration involves the same first-hop gateway IP address on a VLAN for all ToR switches and mapping the MAC address to the configured shared IP address. The design ensures optimal Layer 3 forwarding between two ToR endpoints and optimal inbound traffic forwarding.

Optimal VARP Deployment
Diagram: Optimal VARP Deployment

Load balancing enhancements

Arista 7150 is an ultra-low latency 10GE switch ( 350 – 380 ns ). It offers load-balancing enhancements other than the standard 5-tuple mechanism. Arista supports new load-balancing profiles. Load-balancing profiles allow you to decide what bit and byte of the packet you want to use as the hash for the load-balancing mechanism—offering more scope and granularity than the traditional 5-tuple mechanism.

 

LACP fallback

With traditional Link Aggregation ( LAG ), LAG is enabled after receiving the first LACP packet. This is because before receiving LACP packets, the physical interfaces are not operational and are down / down. This is viable and perfectly OK unless you need auto-provisioning. What does LACP fallback mean?

If you don’t receive an LACP packet and the LACP fallback is configured, one of the links will still become active and will be UP / UP. Continue to use the Bridge Protocol Data Unit BPDU ) guard on those ports, as you don’t want a switch to bridge between two ports and create a forwarding loop.

 

 

Direct server return

7050 series supports Direct Server Return. The load balancer in the forwarding path does not do NAT. Implementation includes configuring VIP on the load balancer’s outside IP and the internal servers’ loopback. It is essential not to configure the same IP address on server LAN interfaces, as ARP replies will clash. The load balancer sends the packet unmodified to the server, and the server sends it straight to the client.

Requires layer 2 between the load balancer and servers; load balancer needs to use MAC address between the load balancer and servers. It is possible to use IP, which is called Direct Server Return IP-in-IP. Requires any layer 3 connectivity between the load balancer and servers.

Arista 7050 IP-in-IP Tunnel supports essential load balancing, so one can save the cost of not buying an external load-balancing device. However, it’s a scaled-down model, and you don’t get the advanced features you might have with Citrix or F5 load balancers.

 

Link flap detection

Networks have a variety of link flaps. Networks can experience fast and regular flapping; sometimes, you get irregular flapping. Arista has a generic mechanism to detect flaps so you can create flap profiles that offer more granularity to flap management. Flap profiles can be configured on individual interfaces or globally. It is possible to have multiple profiles on one interface.

 

Detecting failed servers

The problem is when we have scale-out applications, and you need to detect server failures. When no load balancer appliance exists, this has to be with application-level keepalives or, even worse, Transmission Control Protocol ( TCP ) timeouts. TCP timeout could take minutes. Arista uses Rapid Indication of Link Loss ( RAIL ) to improve performance. RAIL improves the convergence time of TCP-based scale-out applications.

 

OpenFlow support

Arista matches 750 complete entries or 1500 layer 2 match entries, which would be destination MAC addresses. They can’t match IPv6 or any ARP codes or inside ARP packets, which are part of OpenFlow 1.0. Limited support enables only VLAN or layer 3 forwardings. If matching on layer 3 forwarding, match either the source or destination IP address and rewrite the layer 2 destination address to the next hop.

Arista offers a VLAN bind mode, configuring a certain amount of VLANs belonging to OpenFlow and another set of VLANs belonging to standard Layer 3. Openflow implementation is known as “ships in the night.”

Arista also supports a monitor mode. Monitor mode is regular forwarding with OpenFlow on top of it. Instead of allowing the OpenFlow controller to forward forwarding entries, forwarding entries are programmed by traditional means via Layer 2 or Layer 3 routing protocol mechanism. OpenFlow processing is used in parallel to conventional routing—openflow then copies packets to SPAN ports, offering granular monitoring capabilities.

 

DirectFlow

Direct Flow – I want all traffic from source A to destination A to go through the standard path, but any HTTP traffic goes via a firewall for inspection. i.e., set the output interface to X and a similar entry for the return path, and now you have traffic going to the firewall but for port 80 only.

It offers the same functionality as OpenFlow but without a central controller piece. DirectFlow can configure OpenFlow with forwarding entries through CLI or REST API and is used for Traffic Engineering ( TE ) or symmetrical ECMP. Direct Flow is easy to implement as you don’t need a controller. Just use a REST API available in EOS to configure the flows.

 

Optimal Layer 3 Forwarding: Final Points

Optimal Layer 3 forwarding is a critical network architecture component that significantly impacts network performance, scalability, and reliability. Efficiently routing data packets through the best paths enhances network resilience, resource utilization, and security.

Implementing optimal Layer 3 forwarding through routing protocols, QoS mechanisms, and network monitoring ensures a robust and efficient network infrastructure. Embracing this technology allows organizations to deliver seamless connectivity and a superior user experience in today’s increasingly interconnected world.

Summary: Optimal Layer 3 Forwarding

In the ever-evolving networking world, maximizing efficiency and performance is crucial. One key aspect of network optimization is layer 3 forwarding. In this blog post, we explored the concept of optimal layer 3 forwarding and its significance in enhancing network performance.

Section 1: What is Layer 3 Forwarding?

Layer 3 forwarding, also known as IP forwarding, is the process of routing network traffic between different networks or subnets. It involves analyzing the destination IP address of incoming packets and determining the best path for forwarding them to their intended destinations. Layer 3 forwarding operates at the network layer of the OSI model and forms the backbone of modern network communication.

Section 2: The Importance of Optimal Layer 3 Forwarding

Optimal layer 3 forwarding is vital in achieving efficient and reliable network performance. Making intelligent routing decisions ensures that network traffic is efficiently distributed across available paths, minimizing congestion and maximizing throughput. This results in improved network response times and reduced latency, leading to a seamless user experience.

Section 3: Factors Affecting Layer 3 Forwarding Efficiency

Several factors influence the efficiency of layer 3 forwarding. One such factor is the quality and accuracy of routing tables. Outdated or incomplete routing information can lead to suboptimal forwarding decisions and inefficient network utilization. Network topology, link capacities, and traffic patterns also impact layer 3 forwarding efficiency.

Section 4: Techniques for Optimizing Layer 3 Forwarding

To achieve optimal layer 3 forwarding, network administrators can employ various techniques. One common approach uses dynamic routing protocols, such as OSPF or BGP, which continuously exchange routing information and adapt to network changes. Additionally, implementing traffic engineering techniques, such as Quality of Service (QoS) and load balancing, can enhance forwarding efficiency.

Section 5: Case Study: Enhancing Network Performance with Optimal Layer 3 Forwarding

To illustrate the real-world benefits of optimal layer 3 forwarding, let’s consider a case study. A multinational enterprise with geographically dispersed offices experienced network performance issues due to suboptimal routing decisions. Implementing dynamic routing protocols and fine-tuning their routing configurations significantly improved network response times and reduced packet loss.

Conclusion:

Optimal layer 3 forwarding is a cornerstone of network optimization. Intelligently routing traffic enhances network performance, reduces latency, and improves the overall user experience. Network administrators should strive to implement best practices and leverage modern techniques to maximize the efficiency of layer 3 forwarding in their networks.

What is OpenFlow

What is OpenFlow

 

identify the benefits of openflow

 

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.

 

  • Introducing SDN

Recent changes and requirements drive networks and network services to become more flexible, virtualization-aware, and API-driven. One major trend that is 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 is an evolving technology defined by the Open Networking Foundation ( ONF ). Software Defined Networking is the physical separation of the network control plane from the forwarding plane, where a control plane controls several devices. This somewhat differs significantly from traditional IP forwarding that you may have used in the past.

 

  • 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 the internal code of their software. This creates a path for an open-source approach to networking and policy-based controllers. Now let us identify the benefits of OpenFlow in the following tables.

 

You may find the following useful for pre-information:

  1. OpenFlow Protocol
  2. Network Traffic Engineering
  3. What is VXLAN
  4. SDN Adoption Report
  5. Virtual Device Context

 

Identify the Benefits of OpenFlow

Key What is OpenFlow Discussion Points:


  • Introduction to what is OpenFlow and what is involved with the protocol.

  • Highlighting the details and benefits of OpenFlow.

  • Technical details on the lack of session layers in the TCP/IP model.

  • Scenario: Control and data plane separation with SDN. 

  • A final note on proactive vs reactive flow setup.

 

Back to basics. What is OpenFlow?

What is OpenFlow?

OpenFlow was the first protocol of the Software Defined Networking (SDN) trend and is the only protocol that allows the decoupling 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 OpenFlow
Diagram: What is OpenFlow? The source is cable solutions.

 

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 needed 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. These rules are determined by the centralized controller, which communicates with the switches using the OpenFlow protocol.

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. A flow table performs packet lookup and forwarding in an OpenFlow switch.

 

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 pures (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 list the Software Defined 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.

what is openflow
What is OpenFlow? Lack of a session layer

 

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 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 ) usually 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. This is often referred to as the OVS. The Open vSwitch is an open-source implementation of a distributed virtual multilayer switch. It enabled a switching stack for virtualization environments while supporting multiple protocols and standards.

 

  • A key point: Identify the benefits of OpenFlow

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. The movement of 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 key point: Identify the benefits of OpenFlow

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

 

What Is OpenFlow? Identify the Benefits of OpenFlow

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 to bind 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. OpenFlow enables the capability so that SDN separates the data and control plane.

 

identify the benefits of openflow

 

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, consults 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.

OpenFlow protocol

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 keys point 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.

 

Identify the benefits of OpenFlow with security.

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 would be to encrypt switch-to-controller communications with SSL and self-signed certificates to authenticate the switch and controller. It would be best to minimize interaction with the data plane, except for ARP and MAC learning.

To prevent denial of services attacks on the controller, you can use Control Plane Policing ( CoPP ) on Ingress so you don’t overload the switch and the controller. Currently, NEC is the only vendor implementing CoPP.

sdn separates the data and control plane

 

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.

 

Identify the Benefits of OpenFlow

Software-defined networking or traditional routing protocols?

The move to a Software Defined Networking architecture has its clear advantages. It’s agile and can react quickly to business needs, such as new product development. And for businesses to achieve success, they must have software that continues to move with the times.

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 for advertising the host routes to other BGP peers of the attacked hosts, with the next-hop pointing to the RTBH address and mostly automated in ISP environments.

 

SDN deployment models

Guidelines:

  1. Start with small deployments away from the mission-critical productions path, i.e., the Core. Ideally, start with device or service provisioning systems.
  2. 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 ).
  3. Integrate new technology with the existing network.
  4. Gradually increase scale and gain trust. Experience is key.
  5. 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. This should be done with an out-of-band network if you are forced to use an in-band network for this communication path using an isolated VLAN with STP.
  • Fast convergence techniques such as BFD may be challenging to use with a central controller.
  • Many people view that this approach does not work for a regular company. Companies implementing native OpenFlow, such as Google, have the time and resources to reinvent all the wheels 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
  • Most practical approach as long as the vendor supports it.

 

Closing Points on OpenFlow

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.

Conclusion:

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.

 

identify the benefits of openflow

Cisco switch virtualization

Cisco Switch Virtualization Nexus 1000v

 

Cisco switch virtualization

 

Nexus1000v

In today’s digital landscape, virtualization has become integral to modern data centers. 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.

 

  • 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 multiple 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:

  1. Container Based Virtualization
  2. Virtual Switch
  3. What is VXLAN
  4. Redundant Links
  5. WAN Virtualization
  6. What Is FabricPath

 

Cisco Switch Virtualization.

Key Nexus 1000v Discussion Points:


  • Introduction to Nexus1000v and what is involved.

  • Highlighting the details on Cisco switch virtualization. Logical separation. 

  • Technical details on the additional overhead from virtualization.

  • Scenario: Network virtualization.

  • A final note on software virtual switch designs.

 

  • A key point: Video on network virtualization

In this video, we will address the basics of network virtualization. We have an underlay and an overlay design. Overlay/Underlay Essentially, an overlay is placing Layer 2 or 3 over a Layer 3 Core. The Layer 3 Core is known as the underlay.

This removes many drawbacks and scaling issues with traditional Layer 2 connectivity, which uses VLANs. The multi-tenant nature of overlays is designed to get away from these L2 challenges allowing you to build networks at a much larger scale.

 

Technology Brief : VXLAN - Introducing Overlay Networking
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Back to basics with network virtualization

Before we get stuck in Cisco virtualization, let us address some basics. For example, if you’re going to have multiple virtual endpoints share a physical network, but different virtual endpoints belong to different customers, the communication between these virtual endpoints also needs to be isolated. In other words, the network is a resource, too, and network virtualization is the technology that enables 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. VLANs 201, and 101 remain separate entities.

Nexus1000v
Nexus1000v: The operation

 

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. There is complete separation between these virtual routing and forwarding instances; without explicit configuration, routes in one virtual routing and forwarding cannot be leaked to another virtual routing and forwarding instance.

Virtual Routing and Forwarding

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 additional 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 standard for GRE is typically static. You only need to configure tunnel endpoints, and the tunnel will be up as long as you have reachability to those endpoints. However, you can have a dynamic GRE tunnel establishment in recent designs.

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. On traditional routers, the control and the data plane are on the same device, yet the control and data planes 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.

Nexus 1000

 

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 vNIC specific tag in hardware (VN-Tag/802.1ah). The actual VN-Tag tagging is implemented in the server NICs so 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 3rd option is to implement a virtual software switch in the hypervisor. For example, VMware introduced virtual switching compatibility with their 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 move 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.

Nexus1000v
Nexus1000v: Virtual Distributed Switch.

 

Nexus 1000 components: VEM and VSM

The Nexus 1000v has two essential components:

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

Compared to a physical switch, you could view the VSM 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 forwarding of packets. 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 integrates 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:

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

The VSM also uses heartbeat messages to detect loss of connectivity between the VSM 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 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 if you have a high-quality DCI link, a VSM can be placed outside the data center and still control the VEM.

 

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 1000
Nexus 1000 and Hybrid Cloud.

 

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 look into UDP packets and distribute all packets in a port channel efficiently.

nexus 1000
VXLAN operations

 

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 IP, 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 destination hosts VXLAN IP, aka destination VEM. Enhanced VXLAN offers VXLAN MAC distribution and ARP termination making it more optional.

 

  • A key point: Video on VXLAN and Dynamic MAC learning

The following video discusses dynamic MAC learning. Initially, Ethernet started with a Thick Coax Cable – a single cable was used to connect all workstations. It was later replaced by the twisted pair cables – unshielded UTP and shielded twisted pair STP in the late 1990-2000s. On Ethernet networks, each host has a unique MAC address for identification.

 

Technology Brief : VXLAN - Dynamic MAC Learning
Prev 1 of 1 Next
Prev 1 of 1 Next

 

 

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

Key Features and Functionalities:

Virtual Ethernet Module (VEM):

The Nexus 1000v employs the concept of 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 set of features, policy-based management approach, and seamless integration with VMware vSphere allows 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.

 

Cisco switch virtualization