SDN-based Architecture

Many protocol combinations produce an SDN-based architecture to enable application traffic steering; native OpenFlow is only one of those protocols. Some companies view OpenFlow as a core SDN design component while others don’t even include it, aka BGP SDN controller and BGP SDN. For example, the Forwarding and Control Element Separation ( ForCES) working group has spent several years working on mechanisms for separating the control and data plane.

The role of OpenFlow

They created their southbound protocol and didn’t use OpenFlow to connect the data and control planes. On the other hand, NEC was one of the first organizations to take full advantage of the OpenFlow protocol. The market’s acceptance of SDN use cases has created products that fall into an OpenFlow or non-OpenFlow bucket. The following post discusses traffic steering that outright requires OpenFlow.

The OpenFlow protocol offers additional granular control to steer traffic through an ordered list of user-specific services. A task that traditional IP destination-based forwarding struggles to do efficiently. OpenFlow offers additional flow granularity and provides topology-independent service insertion required by network overlays, such as a VXLAN. 

Shortest-path routing

Every dynamic network backbone has some congested links, while others still need to be utilized. That’s because shortest-path routing protocols transmit traffic down the shortest path without regarding other network parameters, such as utilization and traffic demands. So, we need to employ application traffic engineering or traffic steering to use our network links.

Using Traffic Engineering (TE), we can redistribute packet flows to attain a more uniform distribution across all links in our network. Forcing traffic onto specific pathways lets you get the most out of your current network capacity while making it easier to deliver consistent service levels.

SD-WAN and Application-Aware Routing

Network administrators can specify service-level agreements for business-critical traffic using Application-Aware Routing.

Organizations can establish multiple connectivity paths between locations by replacing or augmenting MPLS transport circuits with Internet-as-a-Transport. By utilizing all of their bandwidth in an active/active fashion rather than continuing to invest in upgrading circuits, enterprises can realize cost savings by moving to the Internet as a means of transport while still providing the required end-user experience.

In the Application-Aware Routing process, packet loss, latency, and jitter are calculated per tunnel, then mapping network data flows to transport tunnels. A lookup in the traditional routing table is the first step in determining which tunnel should forward a specific flow. An App-Route Policy is evaluated only if multiple equal-cost matches exist in the routing table.

Before evaluating any App-Route policy, the routing table must always be considered. Depending on the routing table, the App-Route policy may select one or more paths from the list if there are multiple equal-cost routes for the destination.

The traffic will be forwarded based on the only route in the routing table, and the App-Route policy will not apply if there is only one OMP best path installed in the table and multiple equal-cost routes exist. The routing table can only be used to choose between various, equal best paths using Application-Aware Routing policies.

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

1. WAN Design Considerations
2. What is OpenFlow
3. BGP SDN
4. Network Security Components
5. Network Traffic Engineering
6. Application Delivery Architecture
7. Technology Insights for Microsegmentation
8. Layer 3 Data Center
9. IPv6 Attacks

 Back to basics with Traffic Engineering (TE)

The Role of Load Balancers:

Load balancing serves as the backbone of Application Traffic Steering. They act as intermediaries between clients and servers, receiving incoming requests and distributing them across multiple servers based on specific algorithms. These algorithms consider server load, response time, and availability to make informed decisions.

Multicast Traffic Steering

Multicast traffic steering is a technique used to direct data packets efficiently to multiple recipients simultaneously. It is beneficial in scenarios where a single source needs to transmit data to various destinations. Instead of sending individual copies of the data to each recipient, multicast traffic steering enables the source to transmit a single copy efficiently distributed to all interested recipients.

Lab Guide on IGMPv1

IGMPv1 is a communication protocol that enables hosts on an Internet Protocol (IP) network to join and leave multicast groups. Multicast groups allow the simultaneous transmission of data packets from a single sender to multiple recipients.

By utilizing IGMPv1, hosts can efficiently manage their participation in multicast groups and receive relevant data from senders.

Below, we have one router and two hosts. We will enable multicast routing and IGMP on the router’s Gigabit 0/1 interface.

• • First, we enabled multicast routing globally; this is required for the router to process IGMP traffic.
  • We enabled PIM on the interface. PIM is used for multicast routing between routers and is also required for the router to process IGMP traffic.

Benefits of Multicast Traffic Steering:

1. Bandwidth Efficiency:

Multicast traffic steering reduces network congestion and optimizes bandwidth utilization. By transmitting a single copy of the data, it minimizes the duplication of data packets, resulting in significant bandwidth savings. This is especially advantageous in scenarios where large volumes of data must simultaneously be transmitted to multiple destinations, such as video streaming or software updates.

2. Scalability:

In networks with many recipients, multicast traffic steering ensures efficient data delivery without overwhelming the network infrastructure. Instead of creating a separate unicast connection for each recipient, multicast traffic steering establishes a single multicast group, reducing the burden on the network and enabling seamless scalability.

3. Reduced Network Latency:

Multicast traffic steering reduces network latency by eliminating the need for multiple unicast connections. Data packets are delivered directly to all interested recipients, minimizing the delay caused by establishing and maintaining individual connections for each recipient. This is particularly crucial for real-time applications, such as video conferencing or live streaming, where low latency is essential for a seamless user experience.

Benefits of Application Traffic Steering:

1. Enhanced Performance: By distributing traffic across multiple servers, Application Traffic Steering reduces the load on individual servers, resulting in improved response times and reduced latency. This ensures faster and more reliable application performance.

2. Scalability: Application Traffic Steering enables horizontal scalability, allowing organizations to add or remove servers as per demand. This helps effectively handle increasing application traffic without compromising performance.

3. High Availability: By intelligently distributing traffic, Application Traffic Steering ensures high availability by rerouting requests away from servers experiencing issues or offline. This minimizes the impact of server failures and enhances overall uptime.

4. Seamless User Experience: With load balancers directing traffic to the most optimal server, users experience consistent application performance, regardless of the server they are connected to. This leads to a seamless and satisfying user experience.

Application Traffic Steering Techniques:

1. Round Robin: This algorithm distributes traffic evenly across all available servers in a cyclic manner. While it is simple and easy to implement, it does not consider server load or response times, which may result in uneven distribution and suboptimal performance.

2. Least Connections: This algorithm directs traffic to the server with the fewest active connections at a given time. It ensures optimal resource utilization by distributing traffic based on the server’s current load. However, it doesn’t consider server response times, which may lead to slower performance on heavily loaded servers.

3. Weighted Round Robin: This algorithm assigns weights to servers based on their capabilities and performance. Servers with higher weights receive a larger share of traffic, enabling organizations to prioritize specific servers over others based on their capacity.

Traditional Layer 2 and Layer 3 Service Insertion

Example: Traditional Layer 2

In a flat Layer 2 environment, everybody can reach each other by their MAC address. There is no IP routing. If you want to intercept traffic, the switch in the middle must intercept and forward to a service device, such as a firewall.

The firewall doesn’t change anything; it’s a transparent bump in the wire. You would usually insert the same service in both directions so the firewall will see both directions of the TCP session. Service insertion at Layer 2 is achieved with VLAN chaining.

For example, VLAN-1 is used on one side and VLAN-2 on the other; different VLAN numbers link areas. VLAN chaining is limited and impossible to implement for individual applications. It is also an excellent source for creating network loops. You may encounter challenges when firewalls or service nodes do not pass the Bridge Protocol Data Unit (BPDU). Be careful to use this for large-scale service insertion production environments.

Example: Layer 3 Service Insertion

Layer 3 service insertion is much safer as forwarding is based on IP headers, not Layer 2 MAC addresses. Layer 3 IP headers have a “time-to-live” field that prevents loops from looping around the network. Layer 2 frames are redirected to a transparent or inter-subnet appliance.

This means the firewall device can do a MAC header rewrite on layer 2, or if the firewall is placed in different subnets, the MAC rewrite would be automatic as you will be doing layer 3 forwardings. Layer 3 service insertion is typically implemented with Policy-Based Routing (PBR).

“User-specific services may include firewall, deep packet inspection, caching, WAN acceleration and authentication.”

Application traffic steering, service function chaining, and dynamic service insertion

Application traffic steering, service function chaining, and dynamic service insertion functionally mean the same thing. They want to insert networking functions based on endpoints or applications in the forwarding path.

Service chaining applies a specific list of ordered services (service changing) to individual traffic flows. The main challenge is the ability to steer traffic to various devices. Such devices may be physical appliances or follow the Network Function Virtualization (NFV) format.

Designing with traditional mechanisms leads to cumbersome configurations and multiple device touchpoints. For example, service appliances that need to intercept and analyze traffic could be centralized in a data center or service provider network. Service centralization results in users’ traffic “tromboning” to the central service device for interaction.

Traffic tromboning

Traffic tromboning may not be an issue for data center leaf and spine architecture with equidistant endpoints. However, other aggregated network designs that don’t follow the leaf and spine model may run into interesting problems. A central service network point also represents a “choking point” and may increase path latency. Service integration should be flexible and not designed with a “meet me” architecture.

• The requirement for “flow” level granularity

Traditional routing is based on destination-based forwarding and cannot provide the granularity needed for topology-independent traffic steering. You may implement tricks with PBR and ACL, but they increase complexity and have vendor-specific configurations. Efficient traffic steering requires a granular “flow” level of interaction, which is not offered by default destination-based forwarding.

The requirement for large-scale cloud networks drives multitenancy, and network overlays are becoming the defacto technology used to meet this requirement. Network overlays require new services to be topology-independent.

Unfortunately, IP routing is limited, and different types of traffic going to the same destination cannot be distinguished. Traffic steering based on traditional Layer 2 or 3 mechanisms is inefficient and does not allow dynamic capabilities.

SDN Adoption

A single OpenFlow rule pushed down from the central SDN controller provides the same effect as complex PBR and ACL designs. Traffic steering is accomplished with OpenFlow at an IP destination or IP flow layer of granularity. This dramatically simplifies network operations as there is no need for PBR and ACL configurations. There is less network and component state as all the rules and intelligence are maintained at the SDN central controller.

A holistic viewpoint enables singular points for configuration, not numerous touchpoints throughout the network. A virtual switch can be used for the data, such as the Open vSwitch. It is a multi-layered switch that is highly well-featured.

There are alternatives for pushing ACL rules down to network devices, such as RFC 5575 and Dissemination of Flow Specification Rules. It works with a BGP control plane (BGP flow spec) that can install rules and ACL to network devices.

One significant difference between BGP flow spec and OpenFlow for traffic steering is that the OpenFlow method has a central control policy. BGP flow spec consists of several distributed devices, and configuration changes will require multiple touchpoints in the network.