using simple threshold‐based algorithms. In such cases, alerts can be issued to warn the administrators. Figure 1.2 reports the Zabbix architecture as an example.
Figure 1.2 Example of monitoring architecture.
Source: Courteously from Zabbix.
From an architecture point of view, all these platforms are similar. They have proxy modules, also called agent modules, to interact with different protocols and devices to collect data, which is then stored in a database module, based on open source solutions like MySQL, Postgre SQL, or commercial solutions like Oracle SQL. A typically web‐based GUI or dashboard allows the administrator to interact and navigate through the data. The dashboard can offer also configuration abilities, typically opening management connection with the devices. At last, a media gateway allows the system to raise and distribute alarms, via email, short message service, chat systems, ticketing systems, etc.
Some platforms are open source. They allow to integrate data collected from various deployment into a single centralized center, but rarely offer the ability to change the underlying configuration due to the difficulties in interfacing with different devices. Among those, Zabbix (https://www.zabbix.com), Nagios (https://www.nagios.org), or Cacti (https://www.cacti.net) are the oldest, with more modern solutions like LibreNMS (https://www.librenms.org) or Observium (https://www.observium.org) emerging as novel and more reactive solutions.
Proprietary solutions offer typically more options and flexibility, and include also the ability to change the network setup. Each vendor has a portfolio of solutions that fits different scenarios and deployment sizes, from small LANs to national‐wide Internet Service Providers. Solutions are also available from independent vendors that have typically multi‐platform support.
1.4 Novel Solutions and Scenarios
In the previous sections of this chapter, we have described the most standard approach to control and manage a network. Here we briefly present the most recent approaches which are still under investigations by the research and technical communities, with development quickly tacking grounds.
1.4.1 Software‐Defined Networking – SDN
Software‐defined networking (SDN) technology is an approach to network management that separate the control plane from the data plane. In the original internet design indeed, the control plane – where control protocols and management actions are performed – is tightly embedded in the data plane – where packets are routed and forwarded. SDN separates the two planes, so that switches become pure forwarding devices, while all the control and management operations are relegated to a centralized controller. The controller defines forwarding rules, which are then send to switches that use them to forward packets along the proper and desired path. This enables dynamic, programmatically efficient network configuration to improve network performance and monitoring. Martin Casado introduced the idea of relying to a centralized controller to improve network management in 2007 [35]. Since then, SDN technology has become mainstream [36], with support first for campus network, then extending its support for data center networks, and more recently in WANs via the SD‐WAN [37], bringing in the WAN area the benefits of decoupling the networking hardware from its control mechanism.
Figure 1.3 The SDN architecture.
Source: Courteously from Open Networking Foundation.
The SDN architecture identifies three planes – adding an application plane on the top of the control plane. Figure 1.3 depicts the overall architecture. SDN applications are programs that directly and programmatically communicate their requirements and desired behavior via the northbound interface to the SDN network controller. Applications get an abstracted global view of the network, and suggest decisions and actions such as explicit routes, filtering rules, etc. The SDN controller sits in between. It is a logically centralized entity that translates the requirements from applications to actual action to be implemented by the control plane elements, and provides the applications an updated a common view of the network status. Logically centralized, it can be implemented in a distributed fashion to guarantee both scalability and reliability. It supports both the concept of federated controllers – each responsible of managing a portion of the network; and of hierarchical controllers – where higher hierarchy controllers summarize the information received by lower layers and make it available to applications. At the bottom, the data plane – or the Datapath – is the logical network of devices which offer forwarding and data processing capabilities. Data forwarding engines are in charge of quickly switching packets. They communicate with the SDN controller via the southbound interface, which defines standard Application Programming Interfaces (API) to exchange information. Traffic processing functions implement decision based on packet payload. For instance, switching decision can be done considering both the sender and receiver addresses – enabling per‐flow routing. Similarly, filtering decision can be based on TCP port numbers.
SDN is often associated with the OpenFlow protocol [38] that enables the remote communication with the network plane elements and the controller. However, for many companies, it is no longer an exclusive solution, and proprietary techniques are now available like the Open Network Environment and Nicira's network virtualization platform. They all offer the standard API to communicate via the southbound interface.
1.4.2 Network Functions Virtualization – NFV
Network Functions Virtualization (NFV) is a network architecture that strongly builds on the top of virtualization concepts [39]. It offers the ability to virtualize network nodes and functions into building blocks which can be connected and chained to create more complex communication services. A virtualized network function (VNF) consists of one or more virtual machines and containers that run specific software to implement networking operations in software. Firewalls, access list controllers, load balancers, intrusions detection systems, VPN terminators, etc. can thus be implemented in software – without buying and installing expensive hardware solutions.
Figure 1.4 Network functions virtualization architecture.
Source: Courteously from Juniper Networks.
NFV consists of three main components as sketched in Figure 1.4: On the top, the VNFs to be implemented, using a software solution; the network functions virtualization infrastructure (NFVI) sits in the middle and offers the hardware components over which deploy the VNFs. It includes the physical servers and the network devices that build the NFV infrastructure; at last, the NFV MANagement and Orchestration (MANO) framework allows to manage the platform offering data repositories
