DHCP server is a service to automatically configure IP addresses. Using a DHCP Relay server, DHCP servers can be centralized in a single place. Under Cisco ACI, configuring a DHCP Relay server is a very simple task. Steps: Create a DHCP Server policy: Tenants -> <tenant name> -> Policies -> Protocol -> DHCP Relay -> Create DHCP Relay Policy and specify the IP address of the DHCP server and the associated EPG.
An important question about contracts on Cisco ACI is: are contracts stateful or are they stateless? Or, in other words, do are contracts simple ACLs? Let’s assume two VMs, one in each specific EPG. VM2 is a web server, VM1 is a client. Define a contract so the client (consumer) can connect to the web server (provider) using the port 80, and also apply on both direction (reversing filter ports, and missing the stateful flag).
This scheme will represents all Cisco ACI elements in a draggable diagram.
In this post we’ll show some scenario for L3Out or, in other words, how to manage static routes from a Cisco ACI fabric to external networks. Topology: VM1 connected to VLAN181, bridge domain BD_181 (VRFA). VM2 connected to VLAN181, bridge domain BD_181 (VRFA), and to an external network. VM3 connected to VLAN180, bridge domain BD_180 (VRFA). VM4 connected to VLAN182, bridge domain BD_182 (VRFB). VM5 connected to VLAN183, bridge domain BD_182 (BRFB).
The first and important step with a Cisco ACI fabric, is the connection of an external entity (switch, router, firewall…) to the fabric. Starting from the previous post “) we’ll modify the Switch2 so it will be connected as an external device. In other words, the Switch2 will be bound to another EPG and a contract will be defined to allow communication between Switch1 and Switch2. If Switch1 will be bound (at the end) to a physical (internal) domain, Switch2 will be bound (at the end) to an external domain.
The first and important step with a Cisco ACI fabric, is the connection of an external entity (switch, router, firewall…) to the fabric. An external entity is something not managed directly by the APIC, and it’s a mandatory step for brownfield installation. The connection between the Cisco ACI fabric and the entity is usually called L2Out, because one or more broadcast domain are extended to the entity. L2Out can be internal or external:
This post summarizes how to create any interface policy on Cisco ACI using API. Cisco ACI allows to download any object in different formats (json, xml). That downloaded file can be used as a template to create objects. Using the GUI navigate to Fabric -> Access Policies -> Interface Policies -> Policies and create, for example a new policy for CDP: Name: CDP_on Description: Enable CDP Admin State: Enabled Confirm then right click on the CDP_on policy and save it:
One of the most common error while connecting devices to a Cisco ACI fabric is related to an invalid path configuration. The full error is: Fault delegate: Configuration failed for uni/tn-TenantName/ap-AppName/epg-EpgName node 101 PC_to_Switch1 due to Invalid Path Configuration, debug message: invalid-path: vlan-200 :There is no domain, associated with both EPG and Port, that has required VLAN; In other words, there is a mismaatch/misconfiguration between the tenant view and the fabric view regarding VLAN, physical ports or physical domain:
On a Cisco ACI fabric ports can be defined as trunk, access (802.1P), or access (untagged). It sounds redundant, but the differences can be very important and leads to limits or incompatibilities. Before explaining the differences between trunk, access 802.1P and access untagged, a limit of Cisco ACI fabrics should be mentioned: Error:400 - Validation failed: Validation failed for fv::EPg: uni/tn-TenantName/ap-AppProfile/epg-EpgName vlan: vlan-200 fvMode should be either set tagged or untagged on all ports.
This post will list all ACI elements and how they are connected each others. The draggable diagram has been moved here. Tenant A tenant is a logical container for application policies that enable an administrator to exercise domain-based access control. Tenants can represent a customer in a service provider setting, an organization or domain in an enterprise setting, or just a convenient grouping of policies. Tenants can be isolated from one another or can share resources.