data center design

Open Networking

Open Networking

In today's digital age, connectivity is at the forefront of our lives. From smart homes to autonomous vehicles, the demand for seamless and reliable network connectivity continues to grow. This is where Open Networking comes into play. In this blog post, we will explore the concept of Open Networking, its benefits, and its impact on the future of technology.

Open Networking refers to separating hardware and software components of a network infrastructure. Traditionally, network equipment vendors provided closed, proprietary systems that limited flexibility and innovation.

However, with Open Networking, organizations can choose the hardware and software components that best suit their needs, fostering greater interoperability and driving innovation.

Table of Contents

Highlights: Open Networking

The Role of Transformation

To undertake an effective SDN data center transformation strategy, we must accept that demands on data center networks come from internal end-users, external customers, and considerable changes in the application architecture. All of which put pressure on traditional data center architecture.

Dealing effectively with these demands requires the network domain to become more dynamic, potentially introducing Open Networking and Open Networking solutions. We must embrace digital transformation and the changes it will bring to our infrastructure for this to occur. Unfortunately, keeping current methods is holding back this transition.

Modern Network Infrastructure

In modern network infrastructures, as has been the case on the server side for many years, customers demand supply chain diversification regarding hardware and silicon vendors. This diversification reduces the Total Cost of Ownership because businesses can drive better cost savings. In addition, replacing the hardware underneath can be seamless because the software above is standard across both vendors.

Further, as architectures streamline and spine leaf architecture increases from the data center to the backbone and the Edge, a typical software architecture across all these environments brings operational simplicity. This perfectly aligns with the broader trend of IT/OT convergence.  

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

  1. OpenFlow Protocol
  2. Software-defined Perimeter Solutions
  3. Network Configuration Automation
  4. SASE Definition
  5. Network Overlays
  6. Overlay Virtual Networking



Open Networking Solutions

Key Open Networking Discussion points:


  • Popularity of Spine Leaf architecture.

  • Lack of fabric-wide automation.

  • Automation and configuration management.

  • Open networking vs open protocols.

  • Challenges with integrated vendors.

Back to Basics: Open Networking

SDN and an SDN Controller

SDN’s three concepts are:

  • Programmability.
  • The separation of the control and data planes.
  • Managing a temporary network state in a centralized control model, regardless of the degree of centralization.

So, we have an SDN controller. In theory, an SDN controller provides services that can realize a distributed control plane and abet temporary state management and centralization concepts. 

open networking
Diagram: Open Networking for a data center topology.

The Role of Zero Trust

Zero Trust Security Strategy

Zero Trust Security Main Components

  • Zero trust security is a paradigm shift in the way organizations approach their cybersecurity.

  • Every user, device, or application, regardless of its location, must undergo strict verification and authorization processes.

  • Organizations can fortify their defenses, protect sensitive data, and mitigate the risks associated with modern cyber threats.

♦ Benefits of Open Networking:

1. Flexibility and Customization: Open Networking enables organizations to tailor their network infrastructure to their specific requirements. By decoupling hardware and software, businesses can choose the best-of-breed components and optimize their network for performance, scalability, and cost-effectiveness.

2. Interoperability: Open Networking promotes interoperability by fostering open standards and compatibility between different vendors’ equipment. This allows organizations to build multi-vendor networks, reducing vendor lock-in and enabling seamless integration of network components.

3. Cost Savings: With Open Networking, organizations can lower their networking costs by leveraging commodity hardware and open-source software. This reduces capital expenditures and allows for more efficient network management and more effortless scalability.

4. Innovation and Collaboration: Open Networking encourages collaboration and innovation by providing a platform for developers to create and contribute to open-source networking projects. The community’s collective effort drives continuous improvements, leading to faster adoption of new technologies and features.

Open Networking in Practice:

Open Networking is already making its mark across various industries. Cloud service providers, for example, rely heavily on Open Networking principles to build scalable and flexible data center networks. Telecom operators also embrace Open Networking to deploy virtualized network functions, enabling them to offer services more efficiently and adapt to changing customer demands.

Moreover, adopting Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) further accelerates the realization of Open Networking’s benefits. SDN separates the control plane from the data plane, providing centralized network management and programmability. NFV virtualizes network functions, allowing for dynamic provisioning and scalability.

Open Networking in Practice

Cloud service providers

Virtualized Network Function

Virtual Private Networks

Software-Defined Networking (SDN

Network Function Virtualization

Dynamic Provisioning and Scalability

Open-source network operating systems (NOS)

Leveraging White-box Switches

Reducing Vendor Lock-in

Freedom to choose best-of-breed components

Intent-based Networking

Network Virtualization

 

Open Networking Solutions

Open networking solutions: Data center topology

Now, let’s look at the evolution of data centers to see how we can achieve this modern infrastructure. So, to evolve and to be in line with current times, you should use technology and your infrastructure as practical tools. You will be able to drive the entire organization to become digital.

Of course, the network components will play a key role. Still, the digital transformation process is an enterprise-wide initiative focusing on fabric-wide automation and software-defined networking.

Open networking solutions: Lacking fabric-wide automation

One central pain point I have seen throughout networking is the necessity to dispense with manual work lacking fabric-wide automation. In addition, it’s common to deploy applications by combining multiple services that run on a distributed set of resources. As a result, configuration and maintenance are much more complex than in the past. You have two options to implement all of this.

First, you can connect up these services by, for example, manually spinning up the servers, installing the necessary packages, SSHing to each one, or you can go down the path of open network solutions with automation, in particular, Ansible automation with Ansible Engine or Ansible Tower with automation mesh. As automation best practice, use Ansible variables for flexible playbook creation that can be easily shared and used amongst different environments.  

Agility and the service provider

For example, in the case of a service provider that has thousands of customers, it needs to deploy segmentation to separate different customers. Traditionally, the technology of choice would be VRFs or even full-blown MPLS, which requires administrative touchpoints for every box.

As I was part of a full-blown MPLS design and deployment for a more significant service provider, the costs and time were extreme. Even when it is finally done, the design lacks agility compared to what you could have done with Open Networking.

This would include Provider Edge (PE) Edge routers at the Edge, to which the customer CPE would connect. And then, in the middle of the network, we would have what is known as P ( Provider ) routers that switch the traffic based on a label.

Although the benefits of label switching were easy to implement IPv6 with 6PE ( 6PE is a technique that provides global IPv6 reachability over IPv4 MPLS ) that overcomes many IPv6 fragmentation issues, we could not get away from the manual process without investing heavily again. It is commonly a manual process.

Fabric-wide automation and SDN

However, deploying a VRF or any technology, such as an anycast gateway, is a dynamic global command in a software-defined environment. We now have fabric-wide automation and can deploy with one touch instead of numerous box-by-box configurations.

Essentially, we are moving from a box-by-box configuration to the atomic programming of a distributing fabric of a single entity. The beauty is that we can carry out deployments with one configuration point quickly and without human error.

fabric wide automation
Diagram: Fabric wide automation.

Open networking solutions: Configuration management

Manipulating configuration files by hand is a tedious and error-prone task. Not to mention time-consuming. Equally, performing pattern matching to make changes to existing files is risky. The manual approach will result in configuration drift, where some servers will drift from the desired state.

Configuration drift is caused by inconsistent configuration items across devices, usually due to manual changes and updates and not following the automation path. Ansible architecture can maintain the desired state across various managed assets.

The managed assets that can range from distributed firewalls to Linux hosts are stored in what’s known as an inventory file, which can be static or dynamic inventory. Dynamic inventories are best suited for a cloud environment where you want to gather host information dynamically. Ansible is all about maintaining the desired state for your domain.

ansible automation
Diagram: Ansible automation.

The issue of Silos

To date, the networking industry has been controlled by a few vendors. We have dealt with proprietary silos in the data center, campus/enterprise, and service provider environments. The major vendors will continue to provide a vertically integrated lock-in solution for most customers. They will not allow independent, 3rd party network operating system software to run on their silicon.

Typically, these silos were able to solve the problems of the time. The modern infrastructure needs to be modular, open, and straightforward. Vendors need to allow independent, 3rd party network operating systems to run on their silicon to break from being a vertically integrated lock-in solution.

Cisco has started this for the broader industry regarding open networking solutions with the announcement of the Cisco Silicon ONE. 

network overlay
Diagram: The issue of vendor lock-in.

The Rise of Open Networking Solutions

New data center requirements have emerged; therefore, the network infrastructure must break the silos and transform to meet these trending requirements. One can view the network transformation as moving from a static and conservative mindset that results in cost overrun and inefficiencies to a dynamic routed environment that is simple, scalable, secure, and can reach the far edge. For effective network transformation, we need several stages. 

Firstly, transition to a routed data center design with a streamlined leaf-spine architecture. Along with a standard operating system across cloud, Edge, and 5G networks. A viable approach would be for all of this to be done with open standards, without proprietary mechanisms. Then, we need good visibility.

The need for visibility

As part of the transformation, the network is no longer considered a black box that needs to be available and provide connectivity to services. Instead, the network is a source of deep visibility that can aid a large set of use cases: network performance, monitoring, security, and capacity planning, to name a few. However, visibility is often overlooked with an over-focus on connectivity and not looking at the network as a valuable source of information.

Network management
Diagram: The requirement for deep visibility.

Monitoring a network: Flow level

For efficient network management, we must provide deep visibility for the application at a flow level on any port and device type. Today, you would deploy a redundant monitoring network if you want anything comparable. Such a network would consist of probes, packet brokers, and tools to process the packet for metadata.

The traditional network monitoring tools, such as packet brokers, require life cycle management. A more viable solution would integrate network visibility into the fabric and would not need many components. This enables us to do more with the data and aids with agility for ongoing network operations.

There will always be some requirement for application optimization or a security breach, where visibility can help you quickly resolve these issues.

Monitoring is used to detect known problems and is only valid with pre-defined dashboards with a problem you have seen before, such as capacity reaching its limit. On the other hand, we have the practices of Observability that can detect unknown situations and is used to aid those in getting to the root cause of any problem, known or unknown: Observability vs Monitoring

Evolution of the Data Center

We are transitioning, and the data center has undergone several design phases. Initially, we started with layer 2 silos, suitable for the north-to-south traffic flows. However, layer 2 designs hindered east-west communication traffic flows of modern applications and restricted agility, which led to a push to break network boundaries.

Hence, there is a move to routing at the Top of the Rack (ToR) with overlays between ToR to drive inter-application communication. This is the most efficient approach, which can be accomplished in several ways. 

The leaf spine “clos” popularity

The demand for leaf and spine “clos” started in the data center and spread to other environments. A clos network is a type of non-blocking, multistage switching architecture. This network design extends from the central/backend data center to the micro data centers at the EdgeEdge. Various parts of the edge network, PoPs, central offices, and packet core have all been transformed into leaf and spine “clos” designs. 

leaf spine
Diagram: Leaf Spine.

The network overlay

Building a complete network overlay is common to all software-defined technologies when increasing agility. An overlay is a solution that is abstracted from the underlying physical infrastructure. This means separating and disaggregating the customer applications or services from the network infrastructure. Think of it as a sandbox or private network for each application that is on an existing network.

More often, the network overlay will be created with VXLAN. The Cisco ACI uses an ACI network of VXLAN for the overlay, and the underlay is a combination of BGP and IS-IS. The overlay abstracts a lot of complexity, and Layer 2 and 3 traffic separation is done with a VXLAN network identifier (VNI).

The VXLAN overlay

VXLAN uses a 24-bit network segment ID, called a VXLAN network identifier (VNI), for identification. This is much larger than the 12 bits used for traditional VLAN identification. The VNI is just a fancy name for a VLAN ID, but it now supports up to 16 Million VXLAN segments. 

This is considerably more than the traditional 4094 supported endpoints with VLANs. Not only does this provide more hosts, but it enables better network isolation capabilities, having many little VXLAN segments instead of one large VLAN domain.

The VXLAN network has become the de facto overlay protocol and brings many advantages to network architecture regarding flexibility, isolation, and scalability. VXLAN effectively implements an Ethernet segment virtualizing a thick Ethernet cable.

VXLAN unicast mode

Traditional policy deployment

Traditionally, deploying an application to the network involves propagating the policy to work through the entire infrastructure. Why? Because the network acts as an underlay, segmentation rules configured on the underlay are needed to separate different applications and services.

This creates a rigid architecture that cannot react quickly and adapt to changes, therefore lacking agility. The applications and the physical network are tightly coupled. Now, we can have a policy in the overlay network with proper segmentation per customer.

How VXLAN works: ToR

What is VXLAN? Virtual networks and those built with VXLAN are built from servers or ToR switches. Either way, the underlying network transports the traffic and doesn’t need to be configured to accommodate the customer application. That’s all done in the overlay, including the policy. Everything happens in the overlay network, which is most efficient when done in a fully distributed manner.

Overlay networking
Diagram: Overlay Networking with VXLAN

Now, application and service deployment occurs without touching the physical infrastructure. For example, if you need to have Layer 2 or Layer 3 paths across the data center network, you don’t need to tweak a VLAN or change routing protocols.

Instead, you add a VXLAN overlay network. This approach removes the tight coupling between the application and network, creating increased agility and simplicity in deploying applications and services.

the network overlay
Diagram: The VXLAN overlay network.

Extending from the data center

Edge computing creates a fundamental disruption among the business infrastructure teams. We no longer have the framework where IT only looks at the backend software, such as Office365, and OT looks at the routing and switching product-centric elements. There is convergence.

Therefore, you need a lot of open APIs. The edge computing paradigm brings processing closer to the end devices. This reduces the latency and improves the end-user experience. It would help if you had a network that could work with this model to support this. Having different siloed solutions does not work. 

Common software architecture

So the data center design went from the layer 2 silo to the leaf and spine architecture with routing to the ToR. However, there is another missing piece. We need a standard operating software architecture across all the domains and location types for switching and routing to reduce operating costs. The problem remains that even on one site, there can be several different operating systems.

Through recent consultancy engagements, I have experienced the operational challenge of having many Cisco operating systems on one site. For example, I had an IOS XR for service provider product lines, IOS XE for enterprise, and NS OX for the data center, all on a single site.

Open networking solutions and partially open-source 

Some major players, such as Juniper, started with one operating system and then fragmented significantly. It’s not that these are not great operating systems. Instead, it would be best if you partitioned into different teams, often a team for each operating system.

Standard operating system software provides a seamless experience across the entire environment. Therefore, your operational costs go down, your ability to use software for the specific use cases you want goes up, and you can reduce the cost of ownership. In addition, this brings Open Networking and partially open source.

What Is Open Networking

The traditional integrated vendor

Traditionally, networking products were a combination of hardware and software that had to be purchased as an integrated solution. Open networking, on the other hand, disaggregates hardware from software. They were allowing IT to mix and match at will.

With Open Networking, we are not reinventing how packets are forwarded or routers communicate. With Open Networking solutions, you are never alone and never the only vendor. The value of software-defined networking and Open Networking is doing as much as possible in software so you don’t depend on delivering new features from a new generation of hardware. If you want a new part, it’s quickly implemented in software without swapping the hardware or upgrading line cards.

Move intelligence to software.

You want to move as much intelligence as possible into software, thus removing the intelligence from the physical layer. You don’t want to build in hardware features; you want to use the software to provide the new features. This is a critical philosophy and is the essence of Open Networking. Software becomes the central point of intelligence, not the hardware; this intelligence is delivered fabric-wide.

As we have seen with the rise of SASE. From the customer’s point of view, they get more agility as they can move from generation to generation of services without having hardware dependency and don’t have the operational costs of constantly swapping out the hardware.

SDN network

Open Networking Solutions and Open Networking Protocols

Some vendors build into the hardware the differentiator of the offering. For example, with different hardware, you can accelerate the services. With this design, the hardware level is manipulated to make improvements but does not use standard Open Networking protocols. 

When you look at your hardware to accelerate your services, the result is that you are 100% locked and unable to move as the cost of moving is too much. You could have numerous generations of, for example, line cards, and all have different capabilities, resulting in a complex feature matrix.

It is not that I’m against this, and I’m a big fan of the prominent vendors, but this is the world of closed networking, which has been accepted as the norm until recently. So you must adapt and fit; we need to use open protocols.

Open networking is a must; open source is not.

The proprietary silo deployments led to proprietary alternatives to the prominent vendors. This meant that the startups and options offered around ten years ago were playing the game on the same pitch as the incumbents. Others built their software and architecture by, for example, saying the Linux network subsystem and the OVS bridge are good enough to solve all data center problems.

With this design, you could build small PoPs with layer 2. But the ground shifts as the design requirements change to routing. So, let’s glue the Linux kernel and Quagga FRRouting (FRR) and devise a routing solution. Unfortunately, many didn’t consider the control plane architecture or the need for multiple data center use cases.

Limited scale

Gluing the operating system and elements of open-source routing provides a limited scale and performance and results in operationally intensive and expensive solutions. The software is built to support the hardware and architectural demands.

Now, we see a lot of open-source networking vendors tackling this problem from the wrong architectural point of view, at least from where the market is moving to. It is not composable, microservices-based, or scalable from an operational viewpoint.

There is a difference between open source and Open Networking. The open-source offerings (especially the control plane) have not scaled because of sub-optimal architectures. 

On the other hand, Open Networking involves building software from first principles using modern best practices, with Open API (e.g., OpenConfig/NetConf) for programmatic access without compromising on the massive scale-up and scale-out requirements of modern infrastructure.

SDN Network Design Options

We have both controller and controllerless options. With a controllerless solution, setup is faster, increases agility, and provides robustness in single-point-of-failure, particularly for out-of-band management, i.e., connecting all the controllers.

A controllerless architecture is more self-healing; anything in the overlay network is also part of the control plane resilience. An SDN controller or controller cluster may add complexity and impede resiliency. Since the network depends on them for operation, they become a single point of failure and can impact network performance. The intelligence kept in a controller can be a point of attack.

So, there are workarounds where the data plane can continue forward without an SDN controller but always avoid a single point of failure or complex ways to have a quorum in a control-based architecture.

software defined architecture
Diagram: Software defined architecutre.

Software Defined Architecture & Automation

We have two main types of automation to consider. Day 0 and days 1-2. First and foremost, day 0 automation simplifies and reduces human error when building the infrastructure. Days 1-2 touch the customer more. This may include installing services quickly on the fabric, e.g., VRF configuration and building Automation into the fabric. 

Day 0 automation

As I said, day 0 automation builds basic infrastructures, such as routing protocols and connection information. These stages need to be carried out before installing VLANs or services. Typical tools software-defined networking uses are Ansible or your internal applications to orchestrate the build of the network.

These are known as fabric automation tools. Once the tools discover the switches, the devices are connected in a particular way, and the fabric network is built without human intervention. It simplifies traditional automation, which is helpful in day 0 automation environments.

Configuration Management

Ansible is a configuration management tool that can help alleviate manual challenges. Ansible replaces the need for an operator to tune configuration files manually and does an excellent job in application deployment and orchestrating multi-deployment scenarios.  

Ansible configuration
Diagram: Ansible Configuration

Pre-deployed infrastructure

Ansible does not deploy the infrastructure; you could use other solutions like Terraform that are best suited for this. Terraform is infrastructure as a code tool. Ansible is often described as a configuration management tool and is typically mentioned along the same lines as Puppet, Chef, and Salt. However, there is a considerable difference in how they operate.

Most notably, the installation of agents. Ansible automation is relatively easy to install as it is agentless. The Ansible architecture can be used in large environments with Ansible Tower using the execution environment and automation mesh. I have recently encountered an automation mesh, a powerful overlay feature that enables automation closer to the network’s edge.

Current and desired stage [ YAML playbooks, variables ]

Ansible ensures that the managed asset’s current state meets the desired state. Ansible is all about state management. It does this with Ansible Playbooks, more specifically, YAML playbooks. A playbook is a term Ansible uses for a configuration management script and ensuring the desired state is met. Essentially, playbooks are Ansible’s configuration management scripts. 

open networking solutions
Diagram: Configuration management.

Day 1-2 automation

With day 1-2 automation, SDN does two things.

Firstly, the ability to install or provision services automatically across the fabric. With one command, human error is eliminated. The fabric synchronizes the policies across the entire network. It automates and disperses the provisioning operations across all devices. This level of automation is not classical, as this strategy is built into the SDN infrastructure. 

Secondly, it integrates network operations and services with virtualization infrastructure managers such as OpenStack, VCenter, OpenDaylight, or, at an advanced level, OpenShift networking SDN. How does the network adapt to the instantiation of new workloads via the systems? The network admin should not even be in the loop if, for example, a new virtual machine (VM) is created. 

There should be a signal that a VM with specific configurations should be created, which is then propagated to all fabric elements. You shouldn’t need to touch the network when the virtualization infrastructure managers provide a new service. This represents the ultimate in agility as you are removing the network components. 

The first steps of creating a software-defined data center

It is agreed that agility is a necessity. So, what is the prime step? One critical step is creating a software-defined data center that will allow the rapid deployment of computing and storage for workloads. In addition to software-defined computing and storage, the network must be automated and not be an impediment. 

The five critical layers of technology

To achieve software-defined agility for the network, we need an affordable solution that delivers on four essential layers of technology:

  1. Comprehensive telemetry/granular visibility into endpoints and traffic traversing the network fabric for performance monitoring and rapid troubleshooting.
  2. Network virtualization overlay, like computer virtualization, abstracts the network from the physical hardware for increased agility and segmentation.
  3. Software-defined networking (SDN) involves controlling and automating the physical underlay to eliminate the mundane AND error-prone box-by-box configuration.
  4. Open network underlay is a cost-effective physical infrastructure with no proprietary hardware lock-in that can leverage open source.
  5. Open Networking solutions are a must, as understanding the implications of open source in large, complex data center environments is essential.

The Future of Open Networking:

Open Networking will be crucial in shaping the future as technology evolves. The rise of 5G, the Internet of Things (IoT), and artificial intelligence (AI) will require highly agile, scalable, and intelligent networks. Open Networking’s flexibility and interoperability will meet these demands and enable a connected future.

Summary: Open Networking

Networking is vital in bringing people and ideas together in today’s interconnected world. Traditional closed networks have their limitations, but with the emergence of open networking, a new era of connectivity and collaboration has dawned. This blog post explored the concept of open networking, its benefits, and its impact on various industries and communities.

Section 1: What is Open Networking?

Open networking uses open standards, open-source software, and open APIs to build and manage networks. Open networking promotes interoperability, flexibility, and innovation, unlike closed networks that rely on proprietary systems and protocols. It allows organizations to customize and optimize their networks based on their unique requirements.

Section 2: Benefits of Open Networking

2.1 Enhanced Scalability and Agility

Open networking enables organizations to scale their networks more efficiently and adapt to changing needs. Decoupling hardware and software makes adding or removing network components easier, making the network more agile and responsive.

2.2 Cost Savings

With open networking, organizations can choose hardware and software components from multiple vendors, promoting competition and reducing costs. This eliminates vendor lock-in and allows organizations to use cost-effective solutions without compromising performance or reliability.

2.3 Innovation and Collaboration

Open networking fosters innovation by encouraging collaboration among vendors, developers, and users. Developers can create new applications and services that leverage the network infrastructure with open APIs and open-source software. This leads to a vibrant ecosystem of solutions that continually push the boundaries of what networks can achieve.

Section 3: Open Networking in Various Industries

3.1 Telecommunications

Open networking has revolutionized the telecommunications industry. Telecom operators can now build and manage their networks using standard hardware and open-source software, reducing costs and enabling faster service deployments. It has also paved the way for adopting virtualization technologies like Network Functions Virtualization (NFV) and Software-Defined Networking (SDN).

3.2 Data Centers

In the world of data centers, open networking has gained significant traction. Data center operators can achieve greater agility and scalability by using open standards and software-defined networking. Open networking also allows for better integration with cloud platforms and the ability to automate network provisioning and management.

3.3 Enterprise Networks

Enterprises are increasingly embracing open networking to gain more control over their networks and reduce costs. Open networking solutions offer greater flexibility regarding hardware and software choices, enabling enterprises to tailor their networks to meet specific business needs. It also facilitates seamless integration with cloud services and enhances network security.

Conclusion:

Open networking has emerged as a powerful force in today’s digital landscape. Its ability to promote interoperability, scalability, and innovation makes it a game-changer in various industries. Whether revolutionizing telecommunications, transforming data centers, or empowering enterprises, open networking connects the world in ways we never thought possible.

sd-wan3

VIPTELA SD-WAN – WAN Segmentation

 

 

VIPTELA SD-WAN

Problem Statement

WAN edge networks sit too far from business logic and are built, and designed with limited application and business flexibility. On the other hand, applications sit closer to business logic. It’s time for networking to bridge this gap using policies and business logic-aware principles. For additional information on WAN, challenges proceed to this SD WAN tutorial.

 

Traditional Segmentation

Network segmentation is defined as a portion of the network that is separated from the rest. Segmentation can be physical or logical. Physical segmentation involves complete isolation at a device and link level. Some organizations require the physical division of individual business units for security, political, or other reasons. At a basic level, logical segmentation begins with VLAN boundaries at Layer 2. VLAN consists of a group of devices that communicate as if they were connected to the same wire. As VLANs are logical and not physical connections, they are flexible and can span multiple devices.

While VLANs provide logical separation at Layer 2, virtual routing and forwarding (VRF) instances provide separation at Layer 3. Layer 2 VLAN can now map to Layer 3 VRF instances. However, every VRF has a separate control plane and configuration completed on a hop-by-hop basis. Individual VRFs with separate control planes from individual routing protocol neighbor relationships, hamper router performance.

VIPTELA VRF
VRF Separation

MPLS/VPNs overcome hop-by-hop configurations to allow segmentation. This enables physically divided business units to be logically divided without the need for individual hop-by-hop VPN configurations throughout the network. Instead, only the PE edge routers carry VPN information. This supports a variety of topologies such as hub and spoke, partial mesh, or any to any connectivity. While MPLS/VPNs have their benefits, they also introduce a unique set of challenges.

MPLS Challenges

MPLS topologies, once provisioned, are difficult to modify. This is due to the fact that all the impacted PE routers have to be re-provisioned with each new policy change. In this way, MPLS topologies are similar to the brick foundation of a house. Once the foundation is laid, it’s hard to make changes to the original structure without starting over.

Most modifications to VPN site topologies must go through an additional design phase. If a Wide Area Network (WAN) is outsourced to a carrier, it would require service provider intervention with additional design & provisioning activities. A simple task such as mapping application subnets to new or existing RT may involve onsite consultants, new high-level design, and configuration templates which would have to be applied by provisioning teams. Service provider provisioning and design activities are not free and usually have long lead times.

Some flexible Edge MPLS designs do exist. For example, community tagging and matching. During the design phase, the customer and service provider agree on predefined communities. Once these are set by the customer (attached to a prefix) they are matched by the provider to perform a certain type of traffic engineering (TE).

While community tagging and matching do provide some degree of flexibility and are commonly used, it remains a fixed, predefined configuration. Any subsequent design changes may still require service provider intervention.

Applications Must Fit A Certain Topology

The model forces applications to fit into a network topology that is already built and designed. It lacks the flexibility for the network to keep up with changing business needs. What’s needed is a way to map application requirements to the network. Applications are exploding and each has a variety of operational and performance requirements, which should be met in isolation.

Viptela SD-WAN & Topologies Per Application

By moving from hardware and diverse control planes to software & unified control planes at the WAN edge, SD-WAN evolves the fixed network approach. It abstracts the details of WAN; allowing application-independent topologies. SD-WAN provides segmentation between traffic sets and could be a good way to help create on-demand applications. Essentially, creating multiple on-demand topologies per application or group of applications. Each application can have its own topology and dynamically changing policies which are managed by a central controller.

The application controls the network design.

SD-WAN - Application flows
SD-WAN – Application flows

In SD-WAN, the central controller is hosted and managed by the customer, not a service provider. This enables the WAN to be segmented for each application at the customer’s discretion. For example, PCI traffic can be transported using an overlay specifically designed for compliance via Provider A. Meanwhile, ATM traffic can travel over the same provider network but using an overlay specifically designed for ATM. Meanwhile, each overlay can have different performance characteristics for path failover so that if the network does not reach a certain round-trip time (RTT) metric, traffic can reroute over another path. The customer has complete control over what application goes where and has the power to change policies on the fly.

The SDN controller, which acts as the brain, can set different applications to run over different paths based on business requirements and performance SLAs, not on a fixed topology. Each topology is segmented from the others and applications can share or have independent on-demand topologies. SD-WAN dramatically accelerates the time it takes to adapt the network to changing business needs.

SD-WAN Topologies

The network topologies can be depicted either physically or logically. Common topologies such as Star, Mesh, Full, and Ring are categorized under a centralized or decentralized function. In a physical world, these topologies are fixed and cannot be automatically changed. Logical topologies may also be hindered by physical device footprints.

In contrast, SD-WAN fully supports the coexistence of multiple application topologies regardless of existing physical footprints. For example, Lync message and video subscriptions may require different path topologies with separate SLAs. Messages may travel over low-cost links while video requires lower latency transports.

SD-WAN can flexibly cater to the needs of any type of application. In retail environments, store-specific applications may require a hub and spoke topology for authentication or security requirements. Surveillance systems may require full mesh topology. Guest Wi-fi may require local Internal access compared to normal user traffic that is scrubbed via a hub site. This per-application topology gives designers better control over the network. Viptela SD-WAN endpoints support multiple logical segments (regardless of the existing physical network), each of which can use a unique topology (full mesh, hub and spoke, ring) and be managed via its own policy.

Viptela SD-WAN: Predictable Application Performance

Obtaining predictable services is achieved by understanding the per-application requirements and routing appropriately.

Traditional MPLS WANs, offer limited fabric visibility. For example, providers allow enterprises to perform traceroute and pings, but bits-per-second is a primitive and unreliable method for measuring end-to-end application performance. Instead, WANs should be monitored at multiple layers, not just at the packet layer.

If a service provider is multiple autonomous systems (AS) away and experiencing performance problems, these cannot be addressed and detected using traditional distance-vector methods. This makes it impossible to route around problems and detect transitory oscillations. If errors on a transit path exist, a way must exist to penalize those paths.

Currently, there’s no way to detect when a remote network on the Internet is experiencing brownouts. Since the routing protocol is still operating, the best path does not change as neighbors might still be up. Routing should exist at the transport and application layer, and monitor both application flows and transactions. SD-WAN provides this function and delivers visibility at the device, transport, and application layer for insight into how the network is performing at any given time. This makes it possible to react to transitory failures before they can impact users.

“This post is sponsored by Viptela, an SD-WAN company. All thoughts and opinions expressed are the authors”

 

viptela1

Viptela Software Defined WAN (SD-WAN)

 

viptela sd wan

Viptela SD WAN

Why can’t enterprise networks scale like the Internet? What if you could virtualize the entire network?

Wide Area Network (WAN) connectivity models follow a hybrid approach, and companies may have multiple types – MPLS and the Internet. For example, branch A has remote access over the Internet, while branch B employs private MPLS connectivity. Internet and MPLS have distinct connectivity models, and different types of overlay exist for the Internet and MPLS-based networks.

The challenge is to combine these overlays automatically and provide a transport-agnostic overlay network. The data consumption model in enterprises is shifting. Around 70% of data is; now Internet-bound, and it is expensive to trombone traffic from defined DMZ points. Customers are looking for topological flexibility, causing a shift in security parameters. Topological flexibility forces us to rethink WAN solutions for tomorrow’s networks and leads towards Viptela SD-WAN.

 

Before you proceed, you may find the following helpful:

  1. SD WAN Tutorial
  2. SD WAN Overlay
  3. SD WAN Security 
  4. WAN Virtualization
  5. SD-WAN Segmentation

 

Solution: Viptela SD WAN

Viptela created a new overlay network called Secure Extensible Network (SEN) to address these challenges. For the first time, encryption is built into the solution. Security and routing are combined into one solution. Enables you to span environments, anywhere-to-anywhere in a secure deployment. This type of architecture is not possible with today’s traditional networking methods.

Founded in 2012, Viptela is a Virtual Private Network (VPN) company utilizing concepts of Software Defined Networking (SDN) to transform end-to-end network infrastructure. Based in San Jose, they are developing an SDN Wide Area Network (WAN) product offering any-to-any connectivity with features such as application-aware routing, service chaining, virtual Demilitarized Zone (DMZ), and weighted Equal Cost Multipath (ECMP) operating on different transports.

The key benefit of Viptela is any-to-any connectivity product offering. Connectivity was previously found in Multiprotocol Label Switching (MPLS) networks. They purely work on the connectivity model and not security frameworks. They can, however, influence-traffic paths to and from security services.

Viptela sd wan

 

Ubiquitous data plane

MPLS was attractive because it had a single control plane and a ubiquitous data plane. As long as you are in the MPLS network, connection to anyone is possible. Granted, you have the correct Route Distinguisher (RD) and Route Target (RT) configurations. But why can’t you take this model to Wide Area Network? Invent a technology that can create a similar model and offer ubiquitous connectivity regardless of transport type ( Internet, MPLS ).

 

Why Viptela SDN WAN?

The business today wants different types of connectivity modules. When you map service to business logic, the network/service topology is already laid out. It’s defined. Services have to follow this topology. Viptela is changing this concept by altering the data and control plane connectivity model using SDN to create an SDN WAN technology.

SDN is all about taking intensive network algorithms out of the hardware. Previously, in traditional networks, this was in individual hardware devices using control plane points in the data path. As a result, control points may become congested (for example – OSPF max neighbors reached). Customers lose capacity on the control plane front but not on the data plane. SDN is moving the intensive computation to off-the-shelf servers. MPLS networks attempt to use the same concepts with Route-Reflector (RR) designs.

They started to move route reflectors off the data plane to compute the best-path algorithms. Route reflectors can be positioned anywhere in the network and do not have to sit on the data path. Controller-based SDN approach, you are not embedding the control plane in the network. The controller is off the path. Now, you can scale out and SDN frameworks centrally provision and push policy down to the data plane.

Viptela can take any circuit and provide the ubiquitous connectivity MPLS provided, but now, it’s based on a policy with a central controller. Remote sites can have random transport methods. One leg could be the Internet, and the other could be MPLS. As long as there is an IP path between endpoint A and the controller, Viptela can provide the ubiquitous data plane.

 

Viptela SD WAN and Secure Extensible Network (SEN)

Managed overlay network

If you look at the existing WAN, it is two-part: routing and security. Routing connects sites, and security secures transmission. We have too many network security and policy configuration points in the current model. SEN allows you to centralize control plane security and routing, resulting in data path fluidity. The controller takes care of routing and security decisions.

It passes the relevant information between endpoints. Endpoints can pop up anywhere in the network. All they have to do is set up a control channel for the central controller. This approach does not build excessive control channels, as the control channel is between the controller and endpoints. Not from endpoint to endpoint. The data plane can flow based on the policy in the center of the network.

Viptela SD WAN

 

Viptela SD WAN: Deployment considerations

Deployment of separate data plane nodes at the customer site is integrated into existing infrastructure at Layer 2 or 3. So you can deploy incrementally, starting with one node and ending with thousands. It is so scalable because it is based on routed technology. The model allows you to deploy, for example, a guest network and then integrate it further into your network over time. Internally they use Border Gateway Protocol (BGP). One the data plane, they use standard IPSec between endpoints. It also works over Network Address Translation (NAT), meaning IPSec over UDP.

When an attacker gets access to your network, it is easy for them to reach the beachhead and hop from one segment to another. Viptela enables per-segment encryption, so even if they get to one segment, they will not be able to jump to another. Key management on a global scale has always been a challenge. Viptela solves this with a propitiatory distributed manager based on a priority system. Currently, their key management solution is not open to the industry.

 

SDN controller

You have a controller and VPN termination points i.e data plane points. The controller is the central management piece that assigns the policy. Data points are modules that are shipped to customer sites. The controller allows you to dictate different topologies for individual endpoint segments. Similar to how you influence-routing tables with RT in MPLS.

The control plane is at the controller.

 

Data plane module

Data plane modules are located at the customer site. They connect this data plane module, which could be a PE hand-off to the internal side of the network. The data plane module must be in the data plane path on the customer site. Internal side, they discover the routing protocols and participate in prefix learning. At Layer 2, they discover the VLANs. Their module can either be the default gateway or perform the router neighbor relationship function. WAN side, data plane module registers uplink IP address to WAN controller/orchestration system. The controller builds encrypted tunnels between the data endpoints. The encrypted control channels are only needed when you build over untrusted third parties.

If the problem occurs with controller connectivity, the on-site module can stop being the default gateway and usually participate in Layer 3 forwarding for existing protocols. It backs off from being the primary router for off-net traffic. It’s like creating VRF for different businesses and default routes for each VRF with a single peering point to the controller; Policy-Based Routing (PBR) for each VRF for data plane activity. The PBR is based on information coming from the controller. Each control segment can have a separate policy (for example – modifying the next hop). From a configuration point of view, you need an IP on the data plane module and the remote controller IP. The controller pushes down the rest.

 

  • Viptela SD WAN: Use cases

For example, you have a branch office with three distinct segments, and you want each endpoint to have its independent topology. The topology should be service driven, and the service should not follow existing defined topology. Each business should depict how they want their business to connect to the network team should not say this is how the topology is, and you must obey our topology.

From a carrier’s perspective, they can expand their MPLS network to areas they do not have a physical presence. And bring customers with this secure overlay to their closest pop where they have an MPLS peering. MPLS providers can expand their footprint to areas where they do not have service. If MPLS has customers in region X and wants to connect to the customer in region Y, they can use Viptela. Having those different data plane endpoints through a security framework would be best before entering the MPLS network.

Viptela allows you to steer traffic based on the SLA requirements of the application, aka Application-Aware Routing. For example, if you have two sites with dual connectivity to MPLS and Internet, data plane modules (located at customer sites) nodes can steer traffic over either the MPLS or Internet transport based on end-to-end latency or drops. They do this by maintaining the real-time loss, latency, and jitter characteristics and then applying policies on the centralized controller. As a result, critical traffic is always steered to the most reliable link. This architecture can scale to 1000 nodes in a full mesh topology.

 

viptela sd wan