PSEFABRIC is a new approach to network management and automation. Step to the ideal

Before you start

• Everything that is discussed here relates more to data centers and office networks
• we will talk about the project https://github.com/nihole/PSEFABRIC
• see also the article setting out the basic principles of PSEFABRIC.

Perfect Network Management System

I dare say that from the point of view of management and automation, PSEFABRIC is now closest to all other solutions to what could be called "the ideal network manager."

If you have a good car, then you know what a good control system is. You, as a user, need to know only how to change the speed and direction of movement, and this and only this, by and large, provides you with an interface. In this case, the machines may be different, from different manufacturers, with different technical solutions - the interface is still the same: brake, throttle and steering wheel (suppose you have an automatic transmission).

Can this approach be transferred to networks and, if so, which control system would be ideal for the network?

To answer these questions, let's first answer the question, and who is the driver?
')
Networks, not being a “spherical horse in a vacuum,” do not exist for their own sake, they exist for one single purpose — data transfer. And the users of this service are applications. All the application needs is grids and connectivity between them. The configuration point should ideally be single for the entire network (and not a hundred different network devices) and the interface should be simple and unified.

And ... of course, this is an impossible task, because from the point of view of the network, everything is complicated: hundreds of protocols, types of equipment, vendors, designs are an ocean of all sorts of options. How to create a product with a simple unified interface that would take into account all this diversity? It is clear that the problem in this form can not be solved.

And yet, now we can say that there is a solution, and PSEFABRIC shows it. The task, of course, needs to be slightly modified, but, fortunately, this change is not significant.

Formulation of the problem

There are two good news.

The first is that after you have finished building your network and put it into operation, from this point on, the range of tasks that you do on the network is greatly narrowed.
Usually operational tasks are as follows:

• creation / deletion of the configuration associated with the configuration of L2 / L3 protocols for connecting devices (network, wilan, subinterfaces, ...).
  I will call this the creation / deletion of networks.
• opening / closing access
• creating / deleting virtual servers for balancing traffic

This gives us the opportunity to change the original requirement. We are not going to manage all network operations. We distinguish several interrelated operations, namely

• access creation
• networking (in the sense described above)
• creating virtual servers for balancing
• ...

The second good news is the interface.

Cisco ConfD product gives us everything you need. With the help of the language YANG, we can describe (and thus create) virtually any necessary logic of our interface. We will also have everything we love so much. Here are some of these:

• saving configuration
• candidate & running configuration version (commit option)
• checking syntax and change logic
• rollbacks
• AAA
• configurable via cli, http, rest, netconf, snmp

PSEFABRIC v.010

New version v.010 PSEFABRIC

• allows you to easily switch between contexts of different projects
• is easily customizable for a wide variety of designs, equipment and requirements. This is provided by the following PSEFABRIC properties:
  • p000 project, which is a template for other projects. The recommended approach when creating a new project is to copy the files of this project and then change them.
  • set of tools to customize PSEFABRIC. No code change required.
  • methodology describing the sequence of steps to be taken in the implementation of this solution

When this article was written a year ago, by and large, it was the answer to the question “is it possible in principle?”.

The example given then (now it is called the p001 project), being interesting in terms of the set of equipment (Cisco Routers, L3 Switches, Switches, Cisco ASA, Juniper SRX), is still somewhat artificial.

The big plus of this project (p001) is the presence of a laboratory (UNL) where you can “play around” with the settings of PSEFABRIC and all the above equipment, understand the principles of operation, the main points of the configuration, familiarize yourself with the diagnostic tools ...

The current version of PSEFABRIC (v.010) is already a complete product. You can take and apply it in your network or in the network of your client. To demonstrate the flexibility and power of this solution, another project was created ( p002 ).

This is a “combat” design that you can apply to yourself or the client. This is a popular and modern approach to building a data center based on long-standing ideas:

• Nested logical segmentation
  
  • logical devices (ACI Tenants, Palo-Alto VSYS, N7k VDCs, ...)
  • routing segmentation (VRFs)
• traffic control between logical segments on firewalls
• MPLS cloud for connecting data centers

Equipment: Palo-Alto, Cisco ACI.

In this half-hour video, we analyze example 0 in detail. In this example, using PSEFABRIC, we set up access between different network segments of the p002 project, setting up ACI and PA equipment accordingly.

Little about miracles

To understand how PSEFABRIC changes the idea of ​​network management, here are some examples.

Let's start with conceptual things.

• Flexability. After answering all the questions in the questionnaire, setting up PSEFABRIC for a new project takes from several days to several weeks. Much depends on how quickly you can create all the necessary templates. But in any case, 3 months looks like a realistic period for the introduction (along with testing) of this system. For example, setting up PSEFABRIC for project p002 took 1 week. Having experience in creating an access control system for ACI, I can say that even if we increase this time to 6 months for a complex project, it still remains a very, very good indicator.
• Disaster Recovery. You actually have the “operating” configuration of the “whole network” in a single file. You can easily apply it to new equipment. But interestingly, you can even replace the type of equipment (for example, was Juniper SRX, and became Palo-Alto FW), change PSEFABRIC settings (or create a new project with new settings) and apply the same configuration, but to a new type of equipment. And it really looks like a miracle, right?
• Access logging. The usual problem. If you are not logging, then very soon you no longer understand where and what and what access is needed, and which are already outdated, and in general you lose control over your network. If you are logging, then it takes a lot of time, and you are never sure that those accesses that are logged really correspond to the real configuration and in the end you stop doing it. Here you have both configuration and logging in one bottle.
• DevOps. Now setting up your network is a simple, easy-to-read text file. Accordingly, you can apply best practice developments to changes in your network.
• NaaS. Have you thought about how to implement the “Network as a service” solution? Now you have this solution with cli, netconf, REST, HTTP, SNMP interfaces.

And a few technical examples:

• Have you tried to answer questions like “where / where is access from / to such-and-such network”? If you have several data centers and access is controlled on a dozen different devices, the answer to this question can be quite difficult. In the case of PSEFABRIC, this is elementary.
• Some vendors offer solutions that are convenient in terms of access administration, such as a tag in Palo-Alto or TrustSec in Cisco. The bottom line is to automatically provide access to networks using tags. In PSEFABRIC, you can implement this for your entire network, regardless of the vendor. Looks like a miracle? Yes, I think so.
• You want to open access from several networks in which administrative resources are located (monitoring system, backup systems, ...) to all network devices and Linux servers. Usually, this leads to the fact that you have to open multiple accesses on multiple devices. A feasible, but not very pleasant procedure, and of course there can be many such examples. In the case of PSEFABRIC, this can be one policy and then PSEFABRIC itself will determine where and which configuration commands should be applied.

Frequently asked question

And how does this differ from conventional orchestration, for example, using Cisco UCSD?
What is new in this approach?

The new one is that the orchestration is usually not aware of the network configuration and if information is required, the orchestration should make requests to the real equipment.
For example, if you delete Contract on ACI, then the orchestration system has to look at all the ACGs on ACI to find all the providers and consumers for this contract. And it could be tens of thousands of EPG. And the point is not only in performance (although this too), but in that it greatly complicates the logic.

Well, just look at the previous chapter and answer the question, do you have all these advantages in case of orchestration?

Interesting?

PSEFABRIC is open source with an Apache License, Version 2.0.

https://github.com/nihole/PSEFABRIC
https://github.com/nihole/PSEFABRIC/wiki
https://github.com/nihole/PSEFABRIC/wiki/Installation