SDN Controller

Setting up Physical SDN Controllers

author
4 minutes, 9 seconds Read

Software-Defined Typically, networking scenarios are defined as sandboxes or testbeds in order to evaluate SDN controllers or new applications. This is typically defined in a virtual manner, thereby virtualizing the physical infrastructure. This document instead focuses on actual hardware deployment.

Commonly, the emulation of a physical infrastructure enables the rapid deployment of a network by defining its topology, size, and capabilities. The Mininet platform and OVS devices are ideal candidates for instantly booting local deployments or testing topologies.

On the opposite end of the spectrum, physical equipment is used to provide users with production-like service. In other words, replace the virtual network with physical hardware. Therefore, the definition and wiring of this physical infrastructure are more complicated than its virtual counterpart.

Designing the Topology 

The SDN testbed must include the planes or layers listed below:

  • Control plane: communicate with the SDN controller to learn how to forward packets.
  • Data plane: Perform the forwarding of data packets (from the user).
  • Management plane: operate the devices (configure or monitor).

In practice, enabling the operations provided by each plane necessitates: (i) wiring the devices in a specific manner so that they can be accessed by the SDN controller; (ii) providing a separate network for packet forwarding that spans all network devices; and (iii) granting the operator access to configuration and monitoring tools for the network devices.

Controller Connectivity

The SDN controller must have an exhaustive view of the network. This layer will then be used to send and receive signals between devices. A distinct portion of the network can be designated for the issue. 

Packet Forwarding 

The data plane will carry the traffic of the users. Assuming this traffic comes from more than one place, this data plane needs the following:

  • Users will generate traffic from a number of locations, requiring connectivity between devices and locations. These must be able to reach the devices.
  • Connectivity between devices: networking devices will be interconnected and form a particular topology. These devices must be visible to others in order to forward end-to-end traffic (possibly between two different locations).

Operator Access 

While the previous two layers are concerned with forwarding information and applications, this layer is concerned with administrator access to devices. As this is required for proper configuration and monitoring, a separate network shall be provided for infrastructure operators to connect their devices to. In general, devices offer management interfaces that are isolated from the remaining ports.

Problematic Condition 

Beware of potentially hazardous conditions, such as introducing loops into this L2 topology. Providing multiple connections between servers and switches or defining a full-mesh topology can facilitate this occurrence. If loops are created on purpose, they should be controlled at the hardware level (by turning on spanning tree protocol at the switches) or by the SDN controller or its applications (that is, by the flows sent to the devices).

With the aforementioned information in mind, it is now possible to define the testbed’s topology. It can range from a high-level topology view to quickly identify connected services, servers, network devices, or networks to a low-level wiring diagram that specifies port/port and port/interface connections, based on the needs of the operators. There are many ways to make network diagrams, including desktop programs, online services (like Microsoft Visio or free ones, like Dia), and websites.

Note that as the number of connections or devices increases, your design should become more organized. Thus, a simple port-to-port or interface-to-interface wiring definition is preferred for small, spurious testing scenarios, whereas labels with naming conventions and references to network subsections are recommended for larger, more stable testing scenarios. An example is provided below.

Wire it up 

With the assistance of a network administrator and the design in hand, porting this to the data center should be simple. Whether you find the days of switchboard operators romantic or not, this will be comparable. Obviously, SDN makes it possible to do it once and eliminates the need for tedious end-to-end manual wiring or configuration for each user service!

Configuring the Devices

The configuration step varies significantly based on the vendor-supplied firmware. If available, consult the operation’s manual or simply navigate the CLI or configuration GUIs of the devices. Common actions include enabling the device and entering configuration/operation/cli mode. Before exiting, remember to save the configurations.

Testing the traffic 

After design and configuration, the end-to-end forwarding of packets must be examined via testing. The simplest exam should consist of the following:

  • Management plane. Utilize the switches. Verify correct access to each from the gateway (s).
  • Control plane. Utilize the controller. Assess whether it can see all connected devices.
  • Data plane. Configure the interfaces so that they share the same subnet. This should be done for the user’s endpoints or the locations from which the user submits traffic. 

Test connectivity. If the ping is achieved; congratulations! The set-up is complete. 

If you are someone who wants to know more about the comptia security+ study guide. Click Here

Also Read: Your Online Guide About Google Skillshop

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *