Musical ensemble playing classic music on various instruments while performing concert on outdoor stage

Hands on Kubernetes

 

 

Hands on Kubernetes

Kubernetes has emerged as a game-changing technology in the world of container orchestration. With its ability to automate and manage containerized applications, Kubernetes has become a go-to solution for organizations looking to scale and streamline their operations. This blog post will explore Kubernetes, how it works, and why it has become the de facto industry standard for container orchestration.

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform developed by Google. It provides a robust framework for automating containerized applications’ deployment, scaling, and management. Originally designed by Google engineers to manage their vast containerized infrastructure, Kubernetes has since been donated to the Cloud Native Computing Foundation (CNCF) and has gained widespread adoption across industries.

 

Highlight: Hands-on Kubernetes

  • Cloud Platform

Cloud Platform has a ready-made GOOGLE CONTAINER ENGINE enabling the deployment of containerized environments with Kubernetes. The following post illustrates hands-on Kubernetes with PODS and LABELS. Pods & Labels are the main differentiators between Kubernetes and container scheduler such as Docker Swarm. A group of one or more containers is called a Pod, and containers in a Pod act together. Labels are assigned to Pods for specific targeting, organizing Pods into groups.

 

You may find the following helpful information before you proceed. 

  1. Kubernetes Security Best Practice
  2. OpenShift Networking
  3. Kubernetes Network Namespace
  4. Neutron Network 
  5. Service Chaining

 



Hands on Kubernetes

Key Hands on Kubernetes Discussion points:


  • Introduction to Kubernetes but with a hands on approach to explanation.

  • Discussion on the Kubernetes cluster creation.

  • Kubernetes networking and components used.

  • Details on container creation.

  • A final note on Kubernetes services and labels.

 

Back to basics with the Kubernetes Networking Model

The Kubernetes networking model natively supports multi-host cluster networking. The unit of work in Kubernetes is called a pod. A pod includes one or more containers, which are consistently scheduled and run “together” on the same node. This connectivity allows individual service instances to be separated into distinct containers. Pods can communicate with each other by default, regardless of which host they are deployed on.

 

How does Kubernetes work?

At its core, Kubernetes relies on a master-worker architecture to manage and control containerized applications. The master node acts as the brain of the cluster, overseeing and coordinating the entire system. It keeps track of all the resources and defines the cluster’s desired state.

The worker nodes, on the other hand, are responsible for running the actual containerized applications. They receive instructions from the master node and ensure that the desired state is maintained. If a worker node fails, Kubernetes automatically redistributes the workload to other available nodes, ensuring high availability and fault tolerance.

Key Features and Benefits of Kubernetes:

1. Scalability: Kubernetes allows organizations to effortlessly scale their applications by automatically adjusting the number of containers based on resource demand. This ensures optimal utilization of resources and enhances performance.

2. Fault Tolerance: Kubernetes provides built-in mechanisms for handling failures and ensuring high availability. By automatically restarting failed containers or redistributing workloads, Kubernetes minimizes the impact of failures on the overall system.

3. Service Discovery and Load Balancing: Kubernetes simplifies service discovery by providing a built-in DNS service. It also offers load-balancing capabilities, ensuring traffic is evenly distributed across containers, enhancing performance and reliability.

4. Self-Healing: Kubernetes continuously monitors the state of containers and automatically restarts or replaces them if they fail. This self-healing capability reduces downtime and improves the overall reliability of applications.

5. Infrastructure Agnostic: Kubernetes is designed to be infrastructure agnostic, meaning it can run on any cloud provider or on-premises infrastructure. This flexibility allows organizations to avoid vendor lock-in and choose the deployment environment that best suits their needs.

 

Kubernetes Cluster Creation

The first step for Kubernetes basics and deploying a containerized environment is to create a Container Cluster. This is the mothership of the application environment. The Cluster acts as the foundation for all application services. It is where you place instance nodes, Pods, and replication controllers. By default, the Cluster is placed on a Default Network.

The default container networking construct has a single firewall. Automatic routes are installed so that each host can communicate internally. Cross-communication is permitted by default without explicit configuration. Any inbound traffic sourced externally to the Cluster must be specified with services mappings and ingress rules. By default, it will be denied. 

Container Clusters are created through the command line tool gcloud or the Cloud Platform. The following diagrams display the creation of a cluster on the Cloud Platform and local command line. First, you must fill out a few details, including the Cluster name, Machine type, and the number of nodes.

The scale you can build determines how many nodes you can deploy. Google currently has a 60-day free trial with $300 worth of credits.

 

Hands on Kubernetes

Once the Cluster is created, you can view the nodes assigned to the Cluster. For example, the extract below shows that we have three nodes with the status of Ready.

 

Hands on Kubernetes

Kubernetes Networking 101

Hands on Kubernetes: Kubernetes basics and Kubernetes cluster nodes

Nodes are the building blocks within a cluster. Each node runs a Docker runtime and hosts a Kubelet agent. The docker runtime is what builds and runs the Docker containers. The type and number of node instances are selected during cluster creation.

Select the node instance based on the scale you would like to achieve. It’s possible to increase and decrease the size of your Cluster with corresponding nodes after creation. If you increase instances, new instances are created with the same configuration as existing ones. When decreasing the size of a cluster, the replication controller reschedules the Pods onto the remaining instances.  

Once created, issue the following CLI commands to view the Cluster, nodes, and other properties. The screenshot above shows a small cluster machine, “n1-standard-1,” with three nodes. If unspecified, these are the default. Once the Cluster is created, the kubectl command creates and manages resources.

Kuberenetes

 

 

Hands on Kubernetes: Container creation

Once the Cluster is created, we can continue to create containers. Containers are isolated units sealing individual application entities. We have the option to create single-container Pods or multi-container Pods. Single-style Pods have one container, and multi-containers have more than one container per Pod.

A replication controller monitors Pod activity and ensures they run the correct number of Pod replicas. They are constantly monitoring and dynamically resizing. Even within a single container Pod design, it’s recommended to have a replication controller.

When creating a Pod, the name of the Pod will be applied to the replication controller. The following example displays the creation of a container from the docker image. We proceed to SSH to the container and view instances with the docker ps command.

 

docker

 

A container’s filesystem lives as long as the container is active. You may want container files to survive a restart or crash. For example, if you have MYSQL, you may want these files to be persistent. For this purpose, you mount persistent disks to the container.

Persistent disks exist independently of your instance, and data remains intact regardless of instance state. They enable the application to preserve the state during activities such as restarting and shutdown.

 

Hands on Kubernetes: Service and labels

An abstraction layer proves connectivity between application layers to interact with Pods and Containers with use services. Services map ports on a node to ports on one or more Pods. They provide a load-balancing style function across pods by identifying Pods with labels.

With a service, you tell the pods to proxy by identifying the Pod with a label key pair. It’s conceptually similar to an internal load balancer.

The critical values in the service configuration file are the ports field, selector, and labelThe port field is the port exposed on the cluster node, and the target port is the port exposed on the Pod. The selector is the label-value pair to highlight what Pods to target.

All Pods with this label are targeted. For example, a service named my app resolves to TCP port 9376 on any Pod with the app=example label. The service can be accessed through port 8765 on any of the nodes’ IP addresses.

 

servicefile

 

For service abstraction to work, the Pods we create must match the label and port configuration. If the correct labels are not assigned, then nothing works. There is also a flag used to specify a load-balancing operation. This uses a single IP address to spray traffic to all NODES.

The type Load Balancer flag creates an external IP on which the Pod accepts traffic. External traffic hits a public IP address and forwards to a port. The port is the service port to expose the cluster IP, and the target port is the port to target the pods. Ingress rules are used to permit inbound connections from external destinations to each Cluster. Ingress is a collection of rules.

Conclusion:

Kubernetes has revolutionized the way organizations deploy and manage containerized applications. Its ability to automate and streamline container orchestration has made it the go-to solution for modern application development. By leveraging Kubernetes, organizations can achieve greater scalability, fault tolerance, and agility in their operations. As the containerization trend continues to grow, Kubernetes is poised to play an even more significant role in the future of software development and deployment.

 

combination lock and different gadgets on white office table. privacy protection, encrypted connection concept, buying online

VMware NSX – Network and Security Virtualization

 

VMware NSX Security

 

VMware NSX Security

Ensuring robust network security is paramount in today’s rapidly evolving digital landscape. Organizations need to safeguard their data and protect their infrastructure from cyber threats. One powerful solution that has emerged in recent years is VMware NSX Security. In this blog post, we will explore the key features and benefits of VMware NSX Security and how it can help organizations enhance their network security.

 

Highlights: VMware NSX Security

Thank Andreas Gautschi from VMware for giving me a 2-hour demonstration and brain dump about NSX. Initially, even as an immature product, SDN got massive hype in its first year. However, the ratio from slide to production deployments was minimal. It was getting a lot of publicity even though it was mostly an academic and PowerPoint reality.

  • The Role of SDN

Recently, the ratio has changed, and the concepts of SDN apply to different types of network security components meeting various requirements. SDN enables network virtualization with many companies, such as VMware NSX, Midokura, Juniper Contrail, and Nuage, offering network virtualization solutions. The following post generally discusses network virtualization but focuses more on the NSX functionality.  

 

For additional pre-information, you may find the following helpful:

  1. WAN Virtualization
  2. Nexus 1000v
  3. Docker Security Options

 



Network Security Virtualization

Key VMware NSX Security Discussion points:


  • Introduction to VMware NSX Security, and where it can be used.

  • Discussion on Network Security Virtualization.

  • The role of containers and the changing workloads.

  • Distributed Firewalling and attack surface.

  •  Policy classification.

 

  • A key point: Back to basics with the Virtualization

The Virtualization of resources is crucial in fulfilling the required degree of adaptability. Therefore, we can perform Virtualization in many areas, including the Virtualization of servers, applications, storage devices, security appliances, and, not surprisingly, the network infrastructure. Server virtualization was the starting point for most.

Remember that security is a building block behind the virtualized network and a key driver. An essential component of a security policy is the definition of a network perimeter. Communications between the inside and the outside of the perimeter must occur through a checkpoint. With Virtualization, this checkpoint can now be at multiple network parts. Not just the traditional edge.

 

Key VMware NSX Points

1. Network Segmentation:

One of the fundamental aspects of VMware NSX Security is its ability to provide network segmentation. Organizations can create isolated environments for different applications and workloads by dividing the network into multiple virtual segments. This isolation helps prevent lateral movement of threats and limits the impact of a potential security breach.

2. Micro-segmentation:

With VMware NSX Security, organizations can implement micro-segmentation, which allows them to apply granular security policies to individual workloads within a virtualized environment. This level of control enables organizations to establish a zero-trust security model, where each workload is protected independently, reducing the attack surface and minimizing the risk of unauthorized access.

3. Distributed Firewall:

VMware NSX Security incorporates a distributed firewall that operates at the hypervisor level. Unlike traditional perimeter firewalls, which are typically centralized, the distributed firewall provides virtual machine-level security. This approach ensures that security policies are enforced regardless of the virtual machine’s location, providing consistent protection across the entire virtualized infrastructure.

4. Advanced Threat Prevention:

VMware NSX Security leverages advanced threat prevention techniques to detect and mitigate potential security threats. It incorporates intrusion detection and prevention systems (IDPS), malware detection, and network traffic analysis. These capabilities enable organizations to proactively identify and respond to potential security incidents, reducing the risk of data breaches and system compromises.

5. Automation and Orchestration:

Automation and orchestration are integral components of VMware NSX Security. With automation, organizations can streamline security operations, reducing the probability of human errors and speeding up the response to security incidents. Orchestration allows for integrating security policies with other IT processes, enabling consistent and efficient security management.

6. Integration with Existing Security Solutions:

VMware NSX Security can seamlessly integrate with existing security solutions, such as threat intelligence platforms, security information and event management (SIEM) systems, and endpoint protection tools. This integration enhances the overall security posture of an organization by aggregating security data from various sources and providing a holistic view of the network’s security landscape.

 

Network Security Virtualization

The Role of Network Virtualization

Virtualization provides network services independent of the physical infrastructure in its simplest form. Traditional network services were tied to physical boxes, lacking elasticity and flexibility. This results in many technical challenges, including central chokepoints, hair pinning, traffic trombones, and not to mention the underutilization of network devices.

Network virtualization combats this and abstracts network services ( different firewalling such as context firewall, routing, etc.) into software, making it easier to treat the data center fabric as a pool of network services. When a service is put into the software, it gains elasticity and fluidity qualities not present with physical nodes. The physical underlay provides a connectivity model only concerned with endpoint connectivity.

The software layer on top of the physical world provides the abstraction for the workloads, offering excellent application continuity. Now, we can take two data centers and make them feel like one. You can help facilitate this connection by incorporating kubernetes software to help delegate when a service needs to be done correctly, keeping on top of workload traffic.

The Different Traffic Flows

All east and west traffic flows via the tunnels. VMware’s NSX optimizes local egress traffic so that traffic exits the right data center and does not need to flow via the data center interconnect to egress. We used hacks with HSRP localization or complicated protocols such as LISP to overcome outbound TE with traditional designs. 

The application has changed from the traditional client-server model, where you know how many hosts you run on top of. To an application that moves and scales on numerous physical nodes that may change. With network virtualization, we don’t need to know what physical Host the application is on, as all the computing, storage, and networking move with the application.

If application X moves to location X, all its related services move to location X too. The network becomes a software abstract. Apps can have multiple tiers – front end, database, and storage with scale capabilities, automatically reacting to traffic volumes. It’s far more efficient to scale up docker containers with container schedules to meet traffic volumes than to deploy 100 physical servers, leaving them idle for half the year. If performance is not a vital issue, it makes sense to move everything to software.

 

VMware NSX Security: Changing Endpoints

The endpoints the network must support has changed. We now have container based virtualization, VMs, and mobile and physical devices. Networking is evolving, and it’s all about connecting all these heterogeneous endpoints that are becoming very disconnected from the physical infrastructure. Traditionally, a server is connected to the network with an Ethernet port.

Then, virtualization came along, offering the ability to architect new applications. Instead of single servers hosting single applications, we have multiple VMs hosting different applications on a single physical server. More recently, we see the introduction of docker containers, spawning in as little as 350ms.

 

The Challenge with Traditional VM

Traditional VLANs cannot meet this type of fluidity as each endpoint type holds different requirements on the network. The network must now support conventional physical servers, VMs, and Docker containers. All these stacks must cross each other and, more importantly, be properly secured in a multitenant environment.

Can traditional networking meet this? VMware NSX is a reasonably mature product offering virtualized network and security services that can secure various endpoints. 

Network endpoints have different trust levels. Administrators trust hypervisors more now, with only two VMware hypervisor attacks in the last few years. Unfortunately, the Linux kernel has numerous ways to attack it. Security depends on the attack surface, and an element with a large surface has more potential for exploitation. The Linux kernel has a large attack surface, while hypervisors have a small one.

The more options an attacker can exploit, the larger the attack surface. Containers run many workloads, so the attack surface is more extensive and varied. The virtual switch inside the container has a different trust level than a vswitch inside a hypervisor. Therefore, you must operate different security paradigms relating to containers than hypervisors. 

 

  • A key point: VMware NSX Security and Network Security Virtualization.

NSX provides isolation to all these endpoint types with microsegmentation. Microsegmentation allows you to apply security policy at a VM-NIC level. This offers the ability to protect east-west traffic and move policies with the workload.

This doesn’t mean that each VM NIC requires an individual configuration. NSX uses a distributed firewalls kernel module, and the hosts obtain the policy without individual config. Everything is controlled centrally but installed locally on each vSphere host. It scales horizontally, so you get more firewalls if you add more computing capacity.

All the policies are implemented in a distributed fashion, and the firewall is situated right in front of the VM in the hypervisor. So you can apply policy at a VM NIC level without hair pinning or trombone the traffic. Traffic doesn’t need to go across the data center to a central policy engine: offering optimum any to any traffic.

Even though the distributed firewall is a Kernal loadable module (KLM) of the ESXi Host, the policy enforcement is at the vNIC of the VM.

 

Network Security Virtualization: Policy Classification

A central selling point with NSX is that you get an NSX-distributed firewall. VMware operates with three styles of security:

  1. We have traditional network-focused 5-tuple matching.
  2. We then move up a layer with infrastructure-focused rules such as port groups, vCenter objects, etc.
  3. We have application-focused rule sets at a very high level, from the Web tier to the App tier permit TCP port 80.

Traditionally, we have used network-based rules, so the shift to application-based, while more efficient, will present the most barriers. People’s mindset needs to change. But the real benefit of NSX comes from this type of endpoint labeling and security. Sometimes more than a /8 is required!

What happens when you run out of /8? We start to implement kludges with NAT etc. Security labeling has been based on IP addresses in the past, and we should start moving with tagging or other types of labeling.

IP addresses are just a way to get something from point A to point B, but if we can focus on different ways to class traffic, the IP address should be irrelevant to security classification. The less tied we are to IP addresses as a security mechanism, the better we will be.

With NSX, endpoints are managed based on high-level policy language that adequately describes the security function. IP is a terrible way to do this as it imposes hard limits on mobile VMs and reduces flexibility. The policy should be independent of IP address assignment.

Conclusion:

Organizations must adopt robust and versatile security solutions in an era of constant cybersecurity threats. VMware NSX Security offers comprehensive features and capabilities that can significantly enhance network security. Organizations can build a robust security infrastructure that protects their data and infrastructure from evolving cyber threats by implementing network segmentation, micro-segmentation, a distributed firewall, advanced threat prevention, automation, and integration with existing security solutions. VMware NSX Security empowers organizations to take control of their network security and ensure the confidentiality, integrity, and availability of their critical assets.

 

network security virtualization

open vswitch

OVS Bridge and Open vSwitch (OVS) Basics

 

OVS bridge

 

Open vSwitch: What is OVS Bridge?

Open vSwitch (OVS) is an open-source multilayer virtual switch that provides a flexible and robust solution for network virtualization and software-defined networking (SDN) environments. It’s versatility and extensive feature set make it an invaluable tool for network administrators and developers. In this blog post, we will explore the world of Open vSwitch, its key features, benefits, and use cases.

Open vSwitch is a software switch designed for virtualized environments, enabling efficient network virtualization and SDN. It operates at layer 2 (data link layer) and layer 3 (network layer), offering advanced networking capabilities that enhance performance, security, and scalability.

 

Highlights: Open vSwitch

  • Barriers to Network Innovation

There are many barriers to network innovation, which makes it difficult for outsiders to drive features and innovate. Until recently, technologies were largely proprietary and controlled by a few vendors. The lack of tools available limited network virtualization and network resource abstraction. Many new initiatives are now challenging this space, and the Open vSwitch project with the OVS bridge, managed by the Open Network Foundation (ONF), is one of them. The ONF is a non-profit organization that promotes adopting software-defined networking through open standards and open networking.

  • The Role of OVS Switch

Since its release, the OVS switch has gained popularity and is now the de-facto open standard cloud networking switch. It changes the network landscape and moves the network edge to the hypervisor. The hypervisor is the new edge of the network. It resolves the problem of network separation; cloud users can now be assigned VMs with flexible configurations. It brings new challenges to networking and security, some of which the OVS network can alleviate in conjunction with OVS rules.

 

For pre-information, before you proceed, you may find the following post of interest:

  1. Container Networking
  2. OpenStack Neutron
  3. OpenStack Neuron Security Groups
  4. Neutron Networks
  5. Neutron Network

 



Open vSwitch.

Key OVS Bridge Discussion Points:


  • Introduction to OVS Bridge and how it can be used.

  • Discussion on virtual network bridges and flow rules.

  • Discussion on how the Open vSwitch works and the components involved.

  • Highlighting Flow Forwarding.

  • Programming the OVS switch with OVS rules.

  • A final note on OpenFlow and the OVS Bridge.

 

Back to Basics With Open vSwitch

The virtual switch

A virtual switch is a software-defined networking (SDN) device that enables the connection of multiple virtual machines within a single physical host. It is a Layer 2 device that operates within the virtualized environment and provides the same functionalities as a physical switch.

Virtual switches can be used to improve the performance and scalability of the network and are often used in cloud computing and virtualized environments. Virtual switches provide several advantages over their physical counterparts, including flexibility, scalability, and cost savings. In addition, as virtual switches are software-defined, they can be easily configured and managed by administrators.

Virtual switches are software-based switches that reside in the hypervisor kernel providing local network connectivity between virtual machines (and now containers). They deliver functions like MAC learning and features like link aggregation, SPAN, and sFlow, just like their physical switch companions have been doing for years. While these virtual switches are often found in more comprehensive SDN and network virtualization solutions, they are a switch that happens to be running in software.

Virtual Switch
Diagram: Virtual Switch. Source Fujitsu.

 

Network virtualization

network virtualization can also enable organizations to improve their network performance by allowing them to create multiple isolated networks. This can be particularly helpful when an organization’s network is experiencing congestion due to multiple applications, users, or customers. By segmenting the network into multiple isolated networks, each network can be optimized for the specific needs of its users.

In summary, network virtualization is a powerful tool that can enable organizations to control better and manage their network resources while still providing the flexibility and performance needed to meet the demands of their users. Network virtualization can help organizations improve their networks’ security, privacy, scalability, and performance by allowing organizations to create multiple isolated networks.

Network Virtualization
Diagram: Network and Server virtualization. Source Parallels.

 

Highlighting the OVS bridge

Open vSwitch is an open-source software switch designed for virtualized environments. It provides a multi-layer virtual switch designed to enable network connectivity and communication between virtual machines running within a single host or across multiple hosts. In addition, open vSwitch fully complies with the OpenFlow protocol, allowing it to be integrated with other OpenFlow-compatible software components.

The software switch can also manage various virtual networking functions, including LANs, routing, and port mirroring. Open vSwitch is highly configurable and can construct complex virtual networks. It supports a variety of features, including support for multiple VLANs, support for network isolation, and support for dynamic port configurations. As a result, open vSwitch is a critical component of many virtualized environments, providing an essential and powerful tool for managing the network environment.

 

  • A simple flow-based switch

Open vSwitch originates from the academic labs from a project known as Ethan – SIGCOMM 2007. Ethan created a simple flow-based switch with a central controller. The central controller has end-to-end visibility, allowing policies to be applied to one place while affecting many data plane devices. In addition, central controllers make orchestrating the network much more accessible. SIGCOMM 2007 introduced the OpenFlow protocol – SIGCOMM CCR 2008 and the first Open vSwitch (OVS) release in early 2009.

 

Key Features of Open vSwitch:

Virtual Switching: Open vSwitch allows the creation of virtual switches, enabling network administrators to define and manage multiple isolated networks on a single physical machine. This feature is particularly useful in cloud computing environments, where virtual machines (VMs) require network connectivity.

Flow Control: Open vSwitch supports flow-based packet processing, allowing administrators to define rules to handle network traffic efficiently. This feature enables fine-grained control over network traffic, implementing Quality of Service (QoS) policies, and enhancing network performance.

Network Virtualization: Open vSwitch enables network virtualization by supporting network overlays such as VXLAN, GRE, and Geneve. This allows the creation of virtual networks that span physical infrastructure, simplifying network management and enabling seamless migration of virtual machines across different hosts.

SDN Integration: Open vSwitch seamlessly integrates with SDN controllers, such as OpenDaylight and OpenFlow, enabling centralized network management and programmability. This integration empowers administrators to automate network provisioning, optimize traffic routing, and implement dynamic policies.

Benefits of Open vSwitch:

Flexibility: Open vSwitch offers a wide range of features and APIs, providing flexibility to adapt to various network requirements. Its modular architecture allows administrators to customize and extend functionalities per their needs, making it highly versatile.

Scalability: Open vSwitch scales effortlessly as network demands grow, efficiently handling large virtual machines and network flows. Its distributed nature enables load balancing and fault tolerance, ensuring high availability and performance.

Cost-Effectiveness: Being an open-source solution, Open vSwitch eliminates the need for expensive proprietary hardware. This reduces costs and enables organizations to leverage the benefits of software-defined networking without a significant investment.

Use Cases:

Cloud Computing: Open vSwitch plays a crucial role in cloud computing environments, enabling network virtualization, multi-tenant isolation, and seamless VM migration. It facilitates the creation and management of virtual networks, enhancing the agility and efficiency of cloud infrastructure.

SDN Deployments: Open vSwitch integrates seamlessly with SDN controllers, making it an ideal choice for SDN deployments. It allows for centralized network management, dynamic policy enforcement, and programmability, enabling organizations to achieve greater control and flexibility over their networks.

Network Testing and Development: Open vSwitch provides a powerful tool for testing and development. Its extensive feature set and programmability allow developers to simulate complex network topologies, test network applications, and evaluate network performance under different conditions.

 

Open vSwitch (OVS)

The OVS bridge is a multilayer virtual switch implemented in software. It uses virtual network bridges and flows rules to forward packets between hosts. It behaves like a physical switch, only virtualized. Namespaces and instance tap interfaces connect to what is known as OVS bridge ports.

Like a traditional switch, OVS maintains information about connected devices, such as MAC addresses. In addition, it enhances the monolithic Linux Bridge plugin and includes overlay networking (GRE & VXLAN), providing multi-tenancy in cloud environments. 

open vswitch
Diagram: The Open vSwitch basic layout.

 

Programming the Open vSwitch and OVS rules

The OVS switch can also be integrated with hardware and serve as the control plane for switching silicon. Programming flow rules work differently in the OVS switch than in the standard Linux Bridge. The OVS plugin does not use VLANs to tag traffic. Instead, it programs OVS flow rules on the virtual switches that dictate how traffic should be manipulated before being forwarded to the exit interface. The OVS rules essentially determine how inbound and outbound traffic should be treated. 

OVS has two fail modes a) Standalone and b) Secure. Standalone is the default mode and acts as a learning switch. Secure mode relies on the controller element to insert flow rules. Therefore, the secure mode has a dependency on the controller.

OVS bridge
Diagram: OVS Bridge: Source OpenvSwitch.

 

Open vSwitch Flow Forwarding.

Kernel mode, known as “fast path” processing, is where it does the switching. If you relate this to hardware components on a physical device, the kernel mode will map to the ASIC. User mode is known as the “slow path.” If there is a new flow, the kernel doesn’t know about the user mode and is instructed to engage. Once the flow is active, the user mode should not be invoked. So you may take a hit the first time.

The first packet in a flow goes to the userspace ovs-vswitchd, and subsequent packets hit cached entries in the kernel. When the kernel module receives a packet, the cache is inspected to determine if there is a flow entry. The associated action is carried out on the packet if a corresponding flow entry is found in the cache.

This could be forwarding the packet or modifying its headers. If no cache entry is found, the packet is passed to the userspace ovs-vswitchd process for processing. Subsequent packets are processed in the kernel without userspace interaction. The processing speed of the OVS is now faster than the original Linux Bridge. It also has good support for mega flows and multithreading

OVS rules
Diagram: OVS rules and traffic flow.

 

OVS component architecture

There are several CLI tools to interface with the various components:

CLI Component

OVS Component

Ovs-vsctl manages the state 

in the ovsdb-server

Ovs-appctl sends commands

to the ovs-vswitchd

Ovs-dpctl is the

Kernal module configuration

ovs-ofctl work with the 

 OpenFlow protocols

 

what is OVS bridge
Diagram: What is OVS bridge? The components involved.

 

You may have an off-host component, such as the controller. It communicates and acts as a manager of a set of OVS components in a cluster. The controller has a global view and manages all the components. An example controller is OpenDaylight. OpenDaylight promotes the adoption of SDN and serves as a platform for Network Function Virtualization (NFV).

NFV virtualized network services instead of using physical function-specific hardware. A northbound interface exposes the network application and southbound interfaces interface with the OVS components. 

  • RYU provides a framework for SDN controllers and allows you to develop controllers. It is written in Python. It supports OpenFlow, Netconf, and OF-config.

There are many interfaces used to communicate across and between components. The database has a management protocol known as OVSDB, RFC 7047. OVS has a local database server on every physical host. It maintains the configuration of the virtual switches. Netlink communicates between user and kernel modes and between different userspace processes. It is used between ovs-vswitchd and openvswitch.ko and is designed to transfer miscellaneous networking information.

 

OpenFlow and the OVS bridge

OpenFlow can also be used to talk and program the OVS. The ovsdb-server interfaces with an external controller (if used) and the ovs-vswitchd interface. Its purpose is to store information for the switches. Its state is persistent.

The central CLI tool is ovs-vsctlThe ovs-vswitchd interface with an external controller, kernel via Netlink, and the ovsdb server. Its purpose is to manage multiple bridges and is involved in the data path. It’s a core system component for the OVS. Two CLI tools ovs-ofctl and ovs-appctl are used to interface with this.

 

Linux containers and networking

OVS can make use of Linux and Docker containers. Containers provide a layer of isolation that reduces communication in humans. They make it easy to build out example scenarios. Starting a container takes milliseconds compared to the minutes of a virtual machine.

Deploying container images is much faster if less data needs to travel across the fabric. Elastic applications with frequent state changes and dynamic resource allocation can be built more efficiently with containers. 

Linux and Docker containers represent a fundamental shift in how we consume and manage applications. Libvirt is a tool used to make use of containers. It’s a virtualization application for Linux. Linux containers involve process isolation in Linux, so instead of running an entire-blown VM, you can do a container, but you share the same kernel but are entirely isolated.

Each container has its view of networking and processes. Containers isolate instances without the overhead of a VM. A lightweight way of doing things on a host and builds on the mechanism in the kernel.

 

Source versus package install

There are two paths for installation, a) Source code and b) Package installation based on your Linux distribution. The source code install is primarily used if you are a developer and is helpful if you are trying to make an extension or focusing on hardware component integration; before accessing the Repo-install, any build dependencies, such as git, autoconf, and libtool.

Then you pull the image from GitHub with the “clone” command. <git clone https://github.com/openvswitch/ovs>. Running from source code is a lot more difficult than installing through distribution. All the dependencies will be done for you when you install from packages. 

Conclusion:

Open vSwitch is a feature-rich and highly flexible virtual switch that empowers network administrators and developers to build efficient and scalable networks. Its support for network virtualization, flow control, and SDN integration makes it a valuable tool in cloud computing environments, SDN deployments, and network testing and development. By leveraging Open vSwitch, organizations can unlock the full potential of network virtualization and software-defined networking, enhancing their network capabilities and driving innovation in the digital era.

 

open vswitch

opencontrail

OpenContrail

 

 

OpenContrail

In today’s fast-paced world, where cloud computing and virtualization have become the norm, the need for efficient and flexible networking solutions has never been greater. OpenContrail, an open-source software-defined networking (SDN) solution, has emerged as a powerful tool. This blog post explores the capabilities, benefits, and significance of OpenContrail in revolutionizing network management and delivering enhanced connectivity in the cloud era.

OpenContrail, initially developed by Juniper Networks, is an open-source SDN platform offering comprehensive network capabilities for cloud environments. It provides a scalable and flexible network infrastructure that enables automation, network virtualization, and secure multi-tenancy across distributed cloud deployments.

 

Highlights: OpenContrail

  • The role of The VM

Virtual machines have been around for a long time, but we are beginning to spread our compute workloads in several different ways. When you throw in docker containers and bare metal servers, networking becomes more interesting. Network challenges arise when all these components require communication within the same subnet, access to Internet gateways, and Layer 3 MPLS/VPNs.

As a result, data center networks are moving towards IP underlay fabrics and Layer 2 overlays. Layer 3 data plane forwarding utilizes efficient Equal-cost multi-path routing (ECMP), but we lack Layer 2 multipathing by default. Now, similar to an SD WAN overlay approach, we can connect dispersed layer 2 segments and leverage all the good features of the IP underlay. To provide Layer 2 overlays and network virtualization, Juniper has introduced an SDN platform called Junipers OpenContrail in direct competition with

 

For additional pre-information, you may find the following post of use.

  1. ACI Cisco
  2. Network Traffic Engineering
  3. Spine Leaf Architecture
  4. IP Forwarding
  5. SDN Data Center
  6. Network Overlays
  7. Application Traffic Steering
  8. What is BGP Protocol in Networking

 



MPLS Overlay

Key OpenContrail Discussion Points:


  • Introduction to the OpenContrail solution and what is involved.

  • Highlighting data center networks and ECMP.

  • Critical points on network virtualization.

  • Technical details on the virtual overlay network.

  • Technical details virtual network implementation.

  • Layer 2 VPN and EVPN.

 

Back to Basics with OpenContrail

Key Features and Benefits:

Network Virtualization:

OpenContrail leverages network virtualization techniques to provide isolated virtual networks within a shared physical infrastructure. It offers a logical abstraction layer, enabling the creation of virtual networks that operate independently, complete with their own routing, security, and quality of service policies. This approach allows for the efficient utilization of resources, simplified network management, and improved scalability.

Secure Multi-Tenancy:

OpenContrail’s security features ensure tenants’ data and applications remain isolated and protected from unauthorized access. It employs micro-segmentation to enforce strict access control policies at the virtual machine level, reducing the risk of lateral movement within the network. Additionally, OpenContrail integrates with existing security solutions, enabling the implementation of comprehensive security measures.

Intelligent Automation:

OpenContrail automates various network provisioning, configuration, and management tasks, reducing manual intervention and minimizing human errors. Its programmable API and centralized control plane simplify the deployment of complex network topologies, accelerate service delivery, and enhance overall operational efficiency.

Scalability and Flexibility:

OpenContrail’s architecture is designed to scale seamlessly, supporting distributed cloud deployments across multiple locations. It offers a highly flexible solution that can adapt to changing network requirements, allowing administrators to dynamically allocate resources, establish new connectivity, and respond to evolving business needs.

OpenContrail in Practice:

OpenContrail has gained significant traction among cloud providers, service providers, and enterprises seeking to build robust, scalable, and secure networks. Its open-source nature has facilitated its adoption, which encourages collaboration, innovation, and customization. OpenContrail’s community-driven development model ensures continuous improvement and the availability of new features and enhancements.

opencontrail
Diagram: OpenContrail.

 

Highlighting Junipers OpenContrail

OpenContrail is an open-source network virtualization platform. The commercial controller and open-source product are identical; they share the same checksum on the binary image. Maintenance and support are the only difference. Juniper decided to open source to fit into the open ecosystem, which wouldn’t have worked in a closed environment.

OpenContrail offers similar features to VMware NSX and can apply service chaining and high-level security policies and provide the connection to Layer 3 VPNs for WAN integration. OpenContrail works with any hardware, but integration with Juniper’s product sets offers additional rich analytics for the underlay network.

Underlay and overlay network visibility are essential for troubleshooting. You need to look further than the first header of the packet; you need to look deeper into the tunnel to understand what is happening entirely. 

 

Network virtualization – Isolated networks

With a cloud architecture, network virtualization gives the illusion that each tenant has a separate isolated network. Virtual networks are independent of physical network location or state, and nodes within the physical underlay can fail without disrupting the overlay tenant. A tenant may be a customer or department, depending if it’s a public or private cloud.

The virtual network sits on top of a physical network, the same way the compute virtual machines sits on top of a physical server. Virtual networks are not created with VLANs; Contrail uses a system of the virtual overlay network for multi-tenancy and cross-tenant communication. Many problems exist with large-scale VLAN deployments for multi-tenancy in today’s networks.

They introduce a lot of states in the physical network, and the Spanning Tree Protocol (STP) also introduces well-documented problems. There are technologies (THRILL, SPB) to overcome these challenges, but they add complexity to the design of the network.

 

Service Chaining

Customers require the ability to apply policy at virtual network boundaries. Policies may include ACL and stateless firewalls provided within the virtual switch. But once you require complicated policy pieces between virtual networks, you need a more sophisticated version of policy control and orchestration called service chaining. Service chaining applies intelligent services between traffic from one tenant to another.

For example, if a customer requires content caching and stateful services, you must introduce additional service appliances and force next-hop traffic through these appliances. Once you deploy a virtual appliance, you need a scale-out architecture.

 

The ability to Scale-out

Scale-out is the ability to instantiate multiple physical and virtual machine instances and load balance traffic across them. Customers may also require the ability to connect with different tenants in dispersed geographic locations or connect to workloads in a remote private cloud or public cloud. Usually, people build a private cloud for the norm and then burst into a public cloud. 

Juniper has implemented a virtual networking architecture that meets these requirements. It is based on well-known technology, MPLS/layer 3 VPN. MPLS/layer 3 VPN is the base for Juniper designs.

MPLS Overlay

 

 

Junipers OpenContrail: Virtual Network Implementation 

MPLS Overlay

The SDN controller is responsible for the networking aspects of virtualization. When creating virtual networks, initiate the Northbound API and issue an instruction that attaches VM to the VN. The network responsibilities are delegated from Cloudstack or OpenStack to Contrail. The Contrail SDN controller automatically creates the overlay tunnel between virtual machines. The overlay can be either an MPLS overlay style with MPLS-over-GREMPLS-over-UDP, or VXLAN

 

  • L3VPN for routed traffic and EVPN for bridged traffic

Juniper’s OpenContrail is still a pure MPLS overlay of MPLS/VPN, using L3VPN for routed traffic and EVPN for bridged traffic. Traffic forwarding between end nodes has one MPLS label (VPN label), but they use various encapsulation methods to carry labeled traffic across the IP fabric. As mentioned above, this includes MPLS-over-GRE – a traditional encapsulation mechanism, MPLS-over-UDP – a variation of MPLS-over-GRE that replaces the GRE headers with UDP headers. And MPLS-over-VXLAN uses VXLAN packet format but stores the MPLS label in the Virtual Network Identifier (VNI) field.

 

  • The forwarding plane

The forwarding plane takes the packet from the VM and gives it to the “Vrouter,” which does a lookup and determines if the destination is a remote network. It encapsulates the packet and sends it across the tunnel if it is a remote network. The underlay that sites between the workloads forward are based on tunnel source and destination only.

No state belongs to end hosts ‘VMs, MAC addresses, or IPs. This type of architecture gives the Core a cleaner and more precise role. Generally, as a best practice, keeping “state” in the Core is a lousy design principle.

 

Northbound and southbound interfaces

To implement policy and service chaining, use the Northbound Interface and express your policy at a high level. For example, you may require HTTP or NAT and force traffic via load balancers or virtual firewalls. Contrail does this automatically and issues instructions to the Vrouter, forcing traffic to the correct virtual appliance. In addition, it can create all the right routes and tunnels, causing traffic through the correct sequence of virtual machines.

Contrail achieves this automatically with southbound protocols, such as XMPP (Extensible Messaging and Presence Protocol) or BGP. XMPP is a communications protocol based on XML (Extensible Markup Language).

 

WAN Integration

Junipers OpenContrail can connect virtual networks to external Layer 3 MPLS VPN for WAN integration. In addition, they gave the controller the ability to peer BGP to gateway routers. For the data plane, they support MPLS-over-GRE, and for the control plane, they speak MP- BGP.

Contrail communicates directly with PE routers, exchanging VPNv4 routes with MP-BGP and using MPLS-over-GRE encapsulation to pass IP traffic between hypervisor hosts and PE routers. Using standards-based protocols lets you choose any hardware appliance as the gateway node.

mpls overaly

 

This data and control plane makes integration to an MPLS/VPN backbone a simple task. First, establish MP-BGP between the controllers to PE-routers. Inter-AS Option B next hop self-approach should be used to establish some demarcation points.

 

Conclusion:

OpenContrail has emerged as a game-changer in software-defined networking, empowering organizations to build agile, secure, and scalable networks in the cloud era. With its advanced features, such as network virtualization, secure multi-tenancy, intelligent automation, and scalability, OpenContrail offers a comprehensive solution that addresses the complex networking challenges of modern cloud environments. As the demand for efficient and flexible network management continues to rise, OpenContrail provides a compelling option for organizations looking to optimize their network infrastructure and unlock the full potential of the cloud.

 

mpls overlay