The following items are included:

 

• ✓Questionnaire
• ✓Gathering Customer requirements and finalizing them in the document
• ✓Solution design document
• ✓Network ready-for-use test plan

 

The following items are included:

 

• ✓

 

T

There are two topology options for ACI Fabric:

 

• ✓Two-tier fabric
• ✓Three-tier fabric with Tier-1 and Tier-2 Leaf switches

 

ACI Benefits

 

Network operation and deployment:

• ✓Fabric deployment automation - ACI provides capabilities for fast provisioning of new fabric, pod, leaf, or spine.
• ✓Centralized network management and monitoring
• ✓Multi-tenancy environment
• ✓Provides Layer 2 connectivity between pods and sites

 

Security:

 

• ✓Micro-Segmentation capabilities
• ✓Consistent security policies for physical and virtual servers, container services, and multi-cloud environments

 

Automation:

 

• ✓North-bound API for integration with other NetDevOps system
• ✓Ready for Infrastructure-as-Code (IaC) approach using integrations with HashiCorp Terraform and Red Hat Ansible

 

Cloud:

 

• ✓Public Cloud integrations
• ✓Seamless connectivity between on-prem ACI and public Cloud ACI environment

VXLAN provides the following benefits:

 

• ✓Multi-tenancy
• ✓Seamless VM Mobility
• ✓Overcomes limitation of 4K VLANs by using VNI (up to 16M VNIs could be used)
• ✓Efficient use of bandwidth - Leverages ECMP for optimal path usage over the underlay network
• ✓Flexibility: Workload can be extended anywhere. Any VLAN can be extended to any Leaf switch using VXLAN EPVN overlay over the L3 underlay. (Although it is worth mentioning that extending L2 is often a poor design choice.)
• ✓Scalability: Leaf-Spine architecture can be easily scaled up by adding new Spines/Leaves

 

Package Content

 

The Cisco NX-OS VXLAN Fabric design option recommends VXLAN EVPN NX-OS Multi-Site Architecture. Multi-Pod Fabrics are still valid designs and are supported by Cisco TAC, but you will not find them in the Nexus 9000 White Paper list https://www.cisco.com/c/en/us/products/switches/nexus-9000-series-switches/white-paper-listing.html.

 

Highlighted below are some of the Multi-Pod design challenges:

• ✓Scalability issue. Multi-Pod requires "full-mesh" End-to-End VXLAN tunnels between Leaf devices, which leads to a scalability limit of the number of leaf switches in a Multi-Pod environment
• ✓Single Overlay Control Plane. EPVN Updates are propagated End-to-End between Leaf devices
• ✓Single Underlay Control Plane. To provide VTEP-to-VTEP reachability, information about loopbacks must be propagated through the whole Multi-Pod domain

 

Multi-Site design solves the above challenges by providing the following:

• ✓Scaling by adding new VXLAN EVPN sites. L2 and L3 services can be extended between sites
• ✓Multiple isolated Underlay Control Plane domains. Loopback reachability is required only within sites; no need to advertise loopback IP addresses between sites
• ✓Multiple Overlay Control Plane domains. Overlay routing information is exchanged between Lead and BGW within the site and between BGWs of different sites
• ✓Multiple BUM replication domains. Propagation of BUM traffic can be controlled by configuring storm-control features on Border Gateway devices

 

Multi-site use-cases:

• ✓Scaling single Data Center
• ✓Data Center Interconnect (DCI) for VxLAN fabrics
• ✓DCI capability for the legacy 3-Tier DC networks via vPC Border Gateway devices
• ✓Migration from Legacy 3-Tier networks to VxLAN/EVPN via vPC Border Gateway devices

 

We have run fabric audits which helped customers to:

• detect configuration errors that could result in fabric downtime in case of a single- failure scenario
• speed up convergency times
• adjust fabric configurations to best practices
• adjust configuration across devices to a single golden template
• optimize traffic flows
• scale VxLAN fabrics better

The benefits of implementing the IaC approach with ACI are:

• Increase the speed of deployments
• Reduce the chance of configuration errors
• Improve configuration consistency
• Enhance visibility and logging of configuration changes

NX-OS fabrics automation options

 

With NDFC

For the customers who choose to build their data center network on Cisco Nexus 9000 switches with NX-OS operating system onboard, Cisco provides a ready-to-go automation platform: the Nexus Dashboard Fabric Controller (NDFC), previously known as the Data Center Network Manager (DCNM).

 

Nexus Dashboard Fabric Controller runs on top of the Nexus Dashboard (ND) cluster. ND is a platform to run data center-related applications by Cisco - NDFC, ACI NDO, Nexus Insights, and Network Assurance Engine. It also supports the installation of 3rd party apps which were approved by Cisco. Under the hood, ND is a Kubernetes cluster with master and worker nodes.

 

The Nexus Dashboard cluster form factors are:

• physical servers (UCS nodes)
• virtual machines (ESXi, KVM)
• bare metal Linux (RHEL)
• cloud (AWS/Azure)

 

While Nexus Dashboard Fabric Controller provides a nice GUI, it could be laborious and error-prone when configuring new services in the Fabric.

 

Cisco provides two main instruments to automate an NDFC configuration:

• DCNM Ansible Galaxy Collection (https://galaxy.ansible.com/cisco/dcnm)
• DCNM Terraform Provider (https://registry.terraform.io/providers/CiscoDevNet/dcnm/latest/docs)

 

In this case, Ansible or Terraform is used to automate NFDC via REST API. The NDFC itself is responsible for configuring Nexus devices via SSH.

 

Without NFDC

The Nexus Dashboard Fabric Controller is an optional tool for fabric automation. If the networking team decides to operate NX-OS Fabric without NDFC, the most popular automation options are still the same: Ansible and Terraform. But in this case, these tools will configure the switches directly.

 

Here are the links to the Ansible Collection and Terraform Provider for the NX-OS:

• NX-OS Ansible Galaxy Collection (https://galaxy.ansible.com/cisco/nxos)
• NX-OS Terraform Provider (https://registry.terraform.io/providers/netascode/nxos/0.3.22)