main

MonitoringNetwork

How SDN change our vision on networks?

June 28, 2018 — by Alexander La rosa0

SDN-featured.png

SDN: Challenges for Network Administrator’s and Monitoring

SDN Software Defined Networking

SDN: Challenges for Network Administrator’s and Monitoring

Last December, Acumen Research and Consulting, a global provider of market research, published a report titled “Software Defined Network (SDN) Market” where they estimated a compound annual growth rate (CAGR) of 47% for SDN in the period of 2016 – 2022.

In 2016, Cisco launched its DNA (Digital Network Architecture), which is more based on software than hardware.

In 2017, Cisco acquired Viptela to complete its SD-WAN (Software Defined WAN) offer. Also, in 2017, IDC (International Data Corporation) estimated for SD-WAN infrastructure and services revenues a CAGR of 69.6% reaching $8 billion in 2021.

All those statistics show us that the business around network is changing, but apart from new offers from our ISP or cloud services provider, does SDN really imply a change in the way of understanding, designing, managing and monitoring networks?

We have to start by clarifying that SDN is an architectural approach not a specific product. Actually SDN is the result of the application of virtualization paradigm to the world of networks.

In general, virtualization seeks to separate the logical part from the physical part in any process. In server virtualization for example, we can create a fully functional server without having any particular physical equipment for it.

Let’s translate this paradigm to a basic function of a switch:

When a packet arrives at a switch, the rules built into its firmware tell the switch where to put the packet, so all the packets that share the same conditions are treated in the same way.

In a more advanced switch, we can define rules in a configuration environment through a command line interface (CLI) but we have to configure each one of the switches in our platform.

When applying virtualization, we have all the rules for all the switches (logical part) separated from the switches themselves (physical part). SDN applies this principle to all networking equipment.

Therefore SDN proposes the separation of:

  • Control Level: in this level, an application called SDN Controller decides how packets have to flow through the network, and it also performs configuration and management activities.
  • From Data Level: this level actually enables the movement of the packets from one point to another. Here we can find network nodes (any physical and virtual networking equipment). In SDN we say traffic moves through the network nodes rather than towards or from them.

With those two levels defined the idea is that network administrators can change any network rules when necessary interacting with a centralized control console without touching individual network nodes one by one.

This interaction defines a third level in the architecture called

  • Application Level: In this level we find programs that build an abstract view of the network for decision-making purposes. These applications have to work with user’s needs, service requirements, and management.

In the following image we can see a basic model of SDN architecture:

basic model of SDN architecture

Finally there are two elements to mention:

  • Northbound API: these APIs are used to allow the communication between SDN Controller and applications running over the network. By using a northbound API, an application can program the network and request services from it. They enable basic network functions like loop routing, avoidance, security and modifying or customizing network control among others.

    Northbound APIs are also used to integrate SDN Controller with external automation stacks and cloud operating systems like OpenStack, VCloud Director and CloudStack.

  • Southbound API: These APIs enable the communication between SDN Controller and network nodes. SDN Controller uses this communication to identify network topology, determine traffic flows, define the behavior of network nodes and implement the request generated by a Northbound API.

SDN was originally just about this separation of functions; however the architecture has evolved to embrace the automation and virtualization of network services as well, in order to bestow network administrators with the power to deliver network services wherever they are needed without regard to what specific equipment is required.

This automation implies that SDN-based networks have to detect changes in pattern of traffic flow and select the better path based on parameters like application type, quality of services and security rules.

Up to here, our brief introduction to SDN. If the reader wants to go deeper, we recommend visiting the websites of Open Networking Foundation and SDX central.

So, let’s go back to the original question: does SDN really imply a change in the way of understanding, designing, managing and monitoring networks?

Traditionally, network administrators have a very strong connection to the hardware; we usually configure every switch, router and firewall using a command line interface.

This “usual way of doing things” gives us a deep knowledge about the platform, however we have always agreed that this way of working is laborious, prone to errors and slows down changes. With SDN, we may have to think less about commands and configurations and think more about rules and services.

On the other hand, virtualization has taken a long time to impact the world of networks and has taken longer to make an impact in companies that are not Internet service providers or mega corporations

Then, this change may be less hard for those IT teams that have experience with server virtualization, containers and have faced the challenges of DevOps methodology (a topic we discussed previously in this same blog).

In terms of monitoring, the fundamental challenge is how to monitor networks considering the complexity and transience that SDN implies. For example, how to do application performance monitoring if the network topology can change several times a day.

There are some monitoring tools designed to be at an Application Level as part of Network Management Systems. Those tools face the problem of complexity, doing controller monitoring and regular network monitoring in the devices on the Data Level.

The real challenge with an agile structure is to identify the entry of new devices and automatically adjust the monitoring scheme.

Furthermore, troubleshooting on SDN-based networks requires an important effort in interactivity and contextual analysis. In practice, it will not be enough to see the network as it is in a certain moment, but we will need to move forward and backward in the topology in order to identify the performance problems associated with routes to optimize the whole process.

Therefore, we can foresee a large amount of data extracted from the platform that must be stored and then filtered under a flexible visualization scheme.

Finally, we must say that many of the challenges mentioned here have already been assumed by some monitoring tools. Those tools with flexible architectures and extensive experience in virtual environment monitoring can be successful. We invite you to know the full scope of Pandora FMS in virtualized environments by visiting our website.

Redactor técnico con más de diez años de experiencia manejando proyectos de monitorización. Es un auténtico apasionado del Yoga y la meditación.

Pandora FMSRelease

Pandora FMS v6.0 SP3 just released!

June 28, 2016 — by steve0

logo_pandora.png

Again we’ve been hard at work to make Pandora FMS work as best we can for you and we’re very proud to present Pandora FMS 6.0 SP3. Although SP2 came out only a few months ago, we felt it was still a little rough around the edges, and we haven’t rested until we felt comfortable with how it would look and perform in this new version. We are now sure that some of the most relevant trouble spots will be fixed and working correctly, and we highly recommend you update and install this new Service Pack.

MonitoringNetwork MonitoringPandora FMSServer Monitoring

Pandora FMS 6.0 SP2 is here!

April 13, 2016 — by steve0

pandora.png

After months of hard work and effort, we’re very proud to announce that Pandora FMS 6.0 SP2 is now available. In this post we’ll detail the changelog to further inform on the improvements this version has. Apart from fixes we’ve actually added some new features. We want to continue improving for you and this is just another way of doing so. We appreciate any feedback or user experience reports.

CloudCloud MonitoringIntegrationsMonitoringPandora FMSUsability

AWS Monitoring: Pandora FMS arrives on Amazon Web Services

March 28, 2016 — by steve2

gpu_amazon_ec2_logo.png

Pandora FMS is now available as an Amazon AMI (installed on CentOS Linux) in a way that’s completely compatible and optimized to work on your Amazon Web Services virtual enviroments. Since Amazon Web Services is a worldwide reference when it comes to cloud services, we decided to prove Pandora FMS’ flexibility, and that’s why we’ve created a free image file so you can fully monitor your AWS.

FeaturesRelease

Pandora FMS 6.0 is finally here!

October 19, 2015 — by Carla Andres2

captura4-1024x544.png

After several months of testing, analysis and effort, it has finally arrived the day when we present to the world the last stable version of Pandora FMS, the 6.0. With a completely renewed interface, full of improvements and new features, the 6.0 version will make a great step forward in terms of system monitoring.

Here we show a list of the most significant changes that you will find in this last version, available from today in the Download section of the Pandora FMS web.