Category: Networking

Cisco ACI – API Calls vs JSON POST

API Calls method

The fancy way of configuring Cisco ACI Fabric is by using Python script for generating API calls. Those API calls are then used to configure Cisco ACI by pushing those calls to APIC controller using POSTMAN (or similar tool). Configuration changes done this way are those that you are doing often and without much chance of making mistakes.

You write a Python script and that script will take your configuration variables and generate API call that will configure the system quickly and correctly every time.

The thing is that you need to take the API call example and use Python to write a script that will recreate that API calls with your variables of configuration and do that correctly. You need to know to code in Python and you will need a certain amount of time to write that script.

POST JSON file method

Cisco ACI – Configuring by POSTing JSON

If you are configuring Cisco ACI datacenter fabric it will sooner or later get to the point that you need to configure multiple objects inside the GUI which will, by using the click-n-click method, take a huge amount of time.

While using POSTMAN to create multiple objects of the same type is the preferred method that everybody is speaking about (because you can generate REST API calls using Python or something similar), the quickest way to do it is using POST of JSON configuration file directly through the GUI.

POSTing JSON config example

As described above, the POST of JSON for some simple yet repetitive configuration is the way to go. Let’s see how it’s done:

Creating multiple BDs inside a tenant in Cisco ACI:

Juniper SRX Cluster Failover Tuning

If you check Juniper configuration guide for SRX firewall clustering, there will be a default example of redundancy-group weight values which are fine if you have one Uplink towards outside and multiple inside interfaces on that firewall.

set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-5/0/5 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-5/0/4 weight 255

This is the one: https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-chassis-cluster-verification.html

But if!

If you get to a situation where you may have multiple outside interfaces which are giving you Internet access or WAN access redundancy then maybe you don’t want failover to secondary SRX box to occur when you lose one of those two uplinks. If that’s the case, you should follow this article and get your SRX cluster to behave as it should.

Juniper SRX cluster failover

Configuring MACsec Encryption

This article describes the simplest way to enable MACSec using preconfigured static key-string. The example was tried on Catalyst 3850 and should work on other switches too.

There is another article that I wrote years ago which describes a more complex implementation with dot1x etc.

MACSec

Media Access Control Security is the way to secure point-to-point Ethernet links by implementing data integrity check and encryption of Ethernet frame.

When you configure MACsec on a switch interface (and of course, on the other switch connected to that interface), all traffic going through the link is secured using data integrity checks and encryption.

Data integrity is done by appending 8-byte header and a 16-byte trailer to the Ethernet packet which is generated before a data is sent and checked upon receiving on the other switch to prove that the data inside the frame was not modified on the way. If the check fails, the packet gets dropped.

How to Advertise a Route from ACI Layer2 BD Outside the Fabric?

Sometimes you will have some L2 domains (Bridge Domains – BD) in your datacenter that will be used with hardware appliances like F5 NLB or something like an additional firewall, WAF or something similar. That is the case where ACI will not route or bridge but the only L3 point of exit from that kind of segment would be on actual hardware appliance outside ACI Fabric – connected to the Leaf port.

We will take an example here and use it throughout the article where BIG IP F5 NLB is used as an L3 termination of L2 BD 10.10.10.0/24.

F5 is directly connected to ACI Leaf and routing from 10.10.10.0/24 subnet (L2 BD) is done directly on F5 device which is default gateway for that subnet endpoints.

ACI L2 BD Host Routing

In those cases for some particular implementations when you decide not to use PBR or Service graphs, it will happen that appliances like our F5 would become L3 termination for some ACI L2 BD like the 10.10.10.0/24 from my beautiful image above.