New Project Setup Prerequisites

Before you start setting up PSEFABRIC for a new project, you need to collect the following information.

0. Operations

For which operations are you going to use PSEFABRIC?

• security rules management
• subnets management
• VMs creation/deleting
• Load Balancing VSs creation/deleting
• ...

For example

• p001 project: security rules and subnets management
• p002 project: security rules management only

1. Describe the equipment types

For example for p001 we have:

• dc1_sw1 - cisco L3 switch
• dc1_fw1 - juniper SRX
• dc2_fw1 - cisco ASA
• dc2_sw1 - cisco l3 switch
• dc3_sw1 - cisco l2 switch
• dc3_r1 - cisco router with ZBF

2. PSEFABRIC objects mapping onto the network infrastructure

In this PSEFABRIC implementation we have the next PSEFABRIC configuration objects:

• Addresses
• Address-sets
• Services
• Service-sets
• Application
• Application-sets
• Policies

We may have different vendors and different types of equipment in our network. We have to map PSEFABRIC configuration objects onto our real network.

For example, for the project p002 we have 2 different kinds of equipment: Palo Alto FWs and Cisco ACI. And the mapping is:

• Addresses
  • PA: address objects
  • ACI: Endpoints
• Address-sets
  • PA: Address groups
  • ACI: EPGs
• Services
  • PA: Services
  • ACI: Filters
• Service-sets
  • PA: Service groups
  • ACI: Subjects
• Applications
  • PA: Applications
  • ACI: n/a
• Application-sets
  • PA: Application groups
  • ACI: n/a
• Policies
  • PA: Security rules
  • ACI: Contracts

If you can create a one-to-one correspondence relationship across the entire infrastructure, this is a good sign, because you will have a unified approach. If this is not the case, you can use other PSEFABRIC tools to mitigate this.

3. Network Logical Segmentation

First of all, we must think about a PSEFABRIC Structure Elements and Global Logic.

So we have to answer the next questions:

• Which network logical segmentation entities are essential for the decision-making process at Demultiplexer layer?
  • Example 1 (p001 project): data-centers, VRFs, security zones, devices, interfaces, VLANs
  • Example 2 (p002 project): data-centers, areas, zones, sub-zones
• Which Structure Elements will make up the Resolver Element?
  • Example 1 (p001 project): data-centers, VRFs
  • Example 2 (p002 project): data-centers, areas, zones, sub-zones

For each Structural Element, you may also have different entities for different vendors/equipment. As in the case of PSEFABRIC objects mapping (see the section above) you have to create a one-to-one correspondence for the logical segments across the entire infrastructure.

Example (p002 project):

• Data-center
  • data-center for PA
  • data-center for ACI
• Area
  • VSYS for PA
  • Tenant for ACI
• Zone
  • Security zone for PA
  • VRF for ACI
• Sub-zone
  • n/a for PA
  • EPG for ACI

4. Object parameters

For all PSEFABRIC objects, parameters should be defined. Up to 8 parameters may be defined. Two of them are logical and 6 are string types. The most common implementation of parameters are

• informing PSYFABRIC about the creation/not creation of a configuration for this object
• use of different object names for different equipment

5. Equipment parameter

This parameter, as well as the device name and the list of commands, is attached to the PSEFABRIC object at the Demultiplexer level (psef_logic.py).

The fact is that it is not enough to know the name (or IP address) of the device must be configured. Some extra information may also be required, such as the name of device-group or template in case of Palo-Alto Panorama or tenant name for Cisco ACI APIC configuration.

If it is possible it is a good idea to correlate the logical segments and equipment parameters.

For example, in the p002 project, we have this mathing for PA:

• Data-center 'dc1', area 'a1' -> Panorama device group 'dc1_a1'
• Data-center 'dc1', area 'a2' -> Panorama device group 'dc1_a2'
• Data-center 'dc2', area 'a1' -> Panorama device group 'dc2_a1'
• Data-center 'dc2', area 'a2' -> Panorama device group 'dc2_a2'

6. Global Logic

This is a central concept od PSEFABRIC.

We need to describe which commands we need to implement and for which network elements as a response to a PSEFABRIC configuration change. The decision is made on the Demultiplexer layer on the basis of Structural Elements and parameters.

The command, in this case, means no more than some name of the operation, for example, 'create_vlan'.

7. Configuration data format

• Which format are we going to use for configuration data?
  • cli
  • xml
  • json
  • ...
• are we going to use some additional automation tools (do we need to adapt our data to the required format)?

8. Templates

Now for each command, we have to provide a template (in a correct data format).

9. Uploading tools.

At this stage, we must answer the question of how we are going to load the configuration into real equipment.

Actually, this is not a question of this project to provide you with methods of configuration uploading. This is some separate task and we have to use some known tools or use something simple like netconf, python scripts or even copy & paste.

PSEFABRIC setup

Refer to Project setup tools.

After receiving the answers to all the questions above, you can start a new project setup with PSEFABRIC.

Now you can

• change YANG files according to PSEFABRIC interface we want to use
• fill out the Vocabulary with new parameters and names of Structure Elements
• create dictionaries in psef_logic.py in accordance with PSEFABRIC Logic
• create templates for each command used in psef_logic.py
• describe equipment in host_to_type.py
• create encapsulation scripts, if necessary, to adapt configuration to the automation tools or equipment management interface
• create configuration uploading scripts or integrate PSEFABRIC with an existing automation solution