What does SDN mean

BGP has a new friend – BGP-Based SDN

 

what does SDN mean

 

BGP SDN

In today’s digital age, where connectivity and data transfer are paramount, efficient and robust networking solutions have become increasingly crucial. One such solution that has gained significant attention is BGP SDN. This blog post will delve into BGP SDN, its key components, and how it revolutionizes network flexibility and scalability.

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

 

Highlights: BGP SDN

  • The Role of SDN

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

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

  • BGP and OpenFlow

BGP and OpenFlow are monolithic, meaning they are not used simultaneously. Integrating BGP to SDN offers several use cases, such as DDoS mitigationexception routing, forwarding optimizationsgraceful shutdown, and integration with legacy networks. Some of these use cases are available using OpenFlow Traffic Engineering; others, like graceful shutdown and integration with the legacy network, are easier to accomplish with BGP SDN. 

 



What Does SDN Mean?

Key BGP SDN Discussion Points:


  • Introduction to BGP SDN and what is involved.

  • Highlighting the the different components involved in a SDN BGP network.

  • Discussing creating an SDN architecture.

  • Technical details on the use of BGP and IGP.

  • The role of BGP-LS.

 

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

  1. BGP Explained
  2. Transport SDN
  3. What is OpenFlow
  4. Software Defined Perimeter Solutions
  5. WAN SDN
  6. OpenFlow And SDN Adoption
  7. HP SDN Controller

 

Back to basics with BGP SDN

What is BGP?

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

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

• Communities

• AS_PATH filters

• Local preference

• Multiple exit discriminator (MED

 

Critical Components of BGP SDN:

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

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

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

Benefits of BGP SDN:

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

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

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

Use Cases for BGP SDN:

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

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

 

Highlighting BGP-based SDN 

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

What does SDN mean
Diagram: What does SDN mean with BGP SDN?

 

Creating an SDN architecture

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

 

Central policy, visibility, and control

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

If the BGP SDN controller acts as a BGP route reflector, all announcements go to the controller, but the network runs fine without it. The controller is just adding value to the usual forwarding process. BGP-based SDN architecture augments the network; it does not replace it. Decentralizing the control plane is the only way; look at Big Switch and NEC’s SDN design changes over the last few years. Centralized control planes cannot scale.

 

Why use BGP?

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

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

 

The use of open-source BGP daemons

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

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

 

IGP to the controller?

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

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

 

Introducing BGP-LS

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

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

 

  • A key point: SDN controller cannot leak information back

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

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

 

BGP scale-out architectures

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

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

BGP SDN

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

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

Conclusion:

BGP SDN combines the power of BGP routing and SDN to create a networking paradigm that enhances flexibility, scalability, and manageability. By leveraging BGP SDN, organizations can build dynamic networks that adapt to their changing needs and optimize resource utilization. As the demand for faster, more reliable, and flexible networks continues to grow, BGP SDN is poised to play a critical role in shaping the future of network infrastructure.

 

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