PSEFABRIC - a new approach to network management and automation

What is this article about?

This is an open source project: PSEFABRIC

PSEFABRIC is short for pseudo fabric and reflects the fact that, from an administrative point of view, it largely looks like a network factory with the ability to manage the entire network (or part of it) as a single device, but from a control / data plane point of view it is all the same a regular network, with the same architecture as before the PSEFABRIC implementation, with the network solutions that you chose and which you think you need. That is, in general, this is not a network built on high-speed switches (although your network may contain them), which is a distinctive feature of network factories, and that is why it is a PSEUDO fabric.

PSEFABRIC is a logical add-on to your network architecture and does not require the purchase of new hardware or software.
')
It should be noted that a few years ago, the implementation of this project at a qualitative level would be a much more complicated and time-consuming task. But the creation of such a wonderful product as ConfD solved an important interface problem, reducing it (the interface problem) to a completely solvable and simple programming task YANG.

General introduction to the problem

Despite the complexity and diversity of modern computer networks, from the point of view of the application, the main thing is the ability to transmit data. And for IP networks this, roughly speaking, comes down to two things:

• Creating subnets and connectivity to them
• Ensuring connectivity between them (on the right ports)

But from the point of view of network configuration, everything looks completely uneasy, and all network protocols, technologies and approaches are aimed at solving these two problems.

We have a contradiction between the simplicity of the formulation of the problem in terms of the application and the huge number of options and the complexity of its implementation. This suggests that, in the general case, this contradiction will most likely not be effectively resolved.

But the good news is that when you have already created a network, then usually, if your architectural solution was correct, then you have a completely clear and algorithmized sequence of actions to solve both problems.

Of course, for each network these actions will be different.

This suggests that creating a product that resolves this contradiction requires an approach that:

• Provides a simple, intuitive interface to manage your entire network (or part of it) as a single entity, allowing you to operate on entities important for the application (for example, subnets and accesses between them) and not worry about the private details specific to your particular network solution;
• It would be so flexible that it would easily adapt to different architectures, vendors, types of equipment.

PSEFABRIC is this solution.

PSEFABRIC Description

By and large, we need to solve 4 problems.

1. Create and provide a convenient and simple interface, sufficient to solve our problem.
2. This interface should have the ability to provide information about the structure of our network, on the basis of which we could make a decision on which equipment and which configuration we should create.
3. We need to provide an opportunity to somehow describe our design, the logic that we need to follow when configuring.
4. We must be able to according to the information described in paragraphs. 2 and 3, create the correct configurations on the right devices.

The first problem with the advent of the ConfD product is solved quite easily and flexibly. For this is used YANG.

The key tasks are tasks 2 through 4, and they are common. Regardless of the implementation, these tasks, one way or another, need to be addressed. Therefore, the PSEFABRIC is based on 3 concepts:

• Structure
• Global Logic
• PSEFABRIC Management Data Flow Model ( PMDFM )

Interface

The logic is borrowed from the juniper SRX interface. She seemed to me the most convenient.

To open access between subnets, we must:

• Create addresses
• Combine these addresses into address-sets. In contrast to the SRX in this implementation of the interface, this is a prerequisite. We do not open access between lists of addresses - only between lists of address-sets
• Create applications
• Create application-sets. As with addresses, we should always use application-sets
• Create a policy

Here is an example of what these commands might look like:

• Create addresses (do not pay attention to the structure yet)

addresses dc1-vlan111 ipv4-prefix 10.101.1.0/24 structure dc DC1 zone none device dc1_sw1 interface e0/0 vlan 111 vrf VRF1 addresses dc1-vlan112 ipv4-prefix 10.101.2.0/24 structure dc DC1 zone none device dc1_sw1 interface e0/0 vlan 112 vrf VRF1 addresses dc2-vlan221 ipv4-prefix 10.202.1.0/24 structure dc DC2 zone none device dc2_sw1 interface e0/1 vlan 221 vrf TRUST 

• Create address-sets

 address-sets dc1-vlan111-set addresses dc1-vlan111 address-sets dc1-vlan112-set addresses dc1-vlan112 address-sets dc2-vlan221-set addresses dc2-vlan221 

• Create applications

 applications http-app prot 6 ports destination-port-range lower-port 80 upper-port 80 applications https-app prot 6 ports destination-port-range lower-port 443 upper-port 443 applications icmp-app prot 1 

• Create application-sets

 application-sets web-app-set applications [ http-app https-app ] application-sets icmp-app-set applications [ icmp-app ] 

• Create access

 policies test match source-address-sets [ dc1-vlan111-set dc1-vlan112-set ] destination-address-sets dc2-vlan221-set application-sets [ icmp-app-set web-app-set ] 

ConfD gives us the full feeling that we are working with a separate network device. For example, we have the ability to do "commit" and "rollback".

PSEFABRIC is not tied to the ConfD functions and does not use the ConfD code anywhere. The only element that we customize is a set of YANG scripts to create the interface we need. When “commit” is performed, PSEFABRIC reads the latest configuration from ConfD over NETCONF and, comparing it with the previous one, creates configuration files for network equipment.

Structure

Here we start talking about what makes the PSEFABRIC approach so flexible. It will discuss how to take into account the architecture of a specific network.

It is clear that we must have a set of variables, the values ​​of which would accurately indicate what equipment we should configure. These variables will then be used in conjunction with the global logic on the Demultiplexer Layer of the PMDFM model.

This variable set is specified in the YANG file. In this implementation, we have the following list:

• data centers
• equipment
• vrf
• zone
• interface
• vlans

For a particular network for which we use PSEFABRIC, you need to set the values ​​that these parameters can take, for example, in our test environment, this is set by the commands:

 conf t structure data-centers [ none DC1 DC2 DC3 ] structure equipment [ none dc1_sw1 dc1_fw1 dc3_r1 dc3_sw1 dc2_fw1 dc2_sw1 ] structure vrf [ none DMZ TRUST VRF1 VRF2 VRF3 ] structure zone [ none ] structure interface [ none e0/0 e0/1 e0/2 e0/3 ] structure vlans none vlan-number 0 structure vlans Vlan111 vlan-number 111 structure vlans Vlan112 vlan-number 112 structure vlans Vlan121 vlan-number 121 structure vlans Vlan122 vlan-number 122 

...

There are no attachments or hierarchies, although if this seems useful, they can be foreseen. Now every time you create a subnet, you must bind the structure to the subnet.

This and the global logic you define should be enough to know exactly what to do with these grids, where to write them, where to open accesses between them, how to forward the vilans, etc. If this is not enough, enter additional parameters in your structure.

Global logic

The structure we set all the necessary parameters that allow us to unambiguously determine what and how to configure. But now we need to describe the logic of our network.

In this implementation of PSEFABRIC, we use the python dictionary to describe global logic.
With this logic we must describe all possible actions. In our case it is

• Create / delete addresses
• Create / delete address-sets
• Create / delete applications
• Creating / deleting application-sets
• Creating / Deleting policies

Global logic produces a sequence of commands, depending on the set of elements of the structure. These commands are described by templates.

PSEFABRIC Management Data Flow Model

This is a key element of PSEFABRIC and is perhaps the main result of the study.
We can distinguish 7 levels of this model.

1. Configuration Management Engine
2. Configuration Analyzer
3. Demultiplexer
4. Configurator
5. Configuration Encapsulator
6. MOs Configuration Loader
7. Control / Data Plans of MOs

The basic principles of PMDFM:

• There are 2 types of control data flow: configuration data and diagnostic data. They go in opposite directions. The diagnostic data stream in this example PSEFABRIC is not currently implemented.
• Configuration data always moves from top to bottom (from level 1 to level 7).
• The exchange of configuration data always takes place either between adjacent layers or within the same layer.

The description of the levels and the scheme can be found on the project wiki .

Hardware configuration

Levels 5,6 of the PMDFM model are automation levels. You can use any automation that is convenient for you. If you have already implemented any automation, then this is a good start, and you can integrate it into PSEFABRIC.

Level 6 is the level of the scripts themselves and other tools (ansible, pappet, ...).

Level 5 is designed to bring the configuration files (which it receives from level 4) to the required format for the tool that you use at level 6.

In this example PSEFABRIC, I used python and perl scripts.

The following sequence of actions is recommended:

• After performing “commit”, we analyze the generated configuration files for network equipment.
• If we do not see any errors, then “fill in” them with QA and carry out the necessary tests.
• If all is well, then “fill” them with “combat” equipment.
• If the procedure is debugged, and we have repeatedly seen the correctness of the results for certain actions, then for them it is possible to exclude paragraphs. 1.2 and “commit” immediately “upload” configurations to equipment

In the end, this should lead to the fact that a large or at least a substantial part of operational processes can proceed without intermediate checks.

Example

To test the approach was created laboratory bench. Its description and the file with the network emulation can be found in the project wiki.

I did not try to facilitate the task, so the scheme is as close as possible to the possible “combat” scenario. We have several data centers, various vendors (Cisco, Juniper), various types of firewalls (ASA, SRX, ZBF), various types of switches (L2, L3). I also tried to create a non-trivial topology with different zones and VRF.

How it all works can be viewed in the video , links to which can be found on the project wiki .

Of course, this should work not only when creating entities, but also when deleting and modifying, which was not such a trivial task, but still solvable.

What do you get from the implementation of PSEFABRIC?

• It costs nothing but time and effort.
• If you want to implement NaaS, IaaS, PaaS, then the implementation of PSEFABRIC will help greatly in this.
• PSEFABRIC gives you a simple, unified administration interface, as in the case of network factories or sdn solutions, but it retains all the strengths of traditional networks (for example, full-fledged firewalls, load balancers).
• It gives the advantages of conventional automation (perl / python / etc. Scripting, ansible, puppet), but automation is only one of the components of the approach.
• It makes it possible to easily implement the DevOps approach to configuring the network, embed the change procedure for the network into general procedures.
• Gives significant advantages for recovery procedures, because stores information about the network in a universal form. This should make it easy to change equipment, vendors, and even architecture.
• And this, of course, is not a complete list.