1. 1. Should we
configure the speed and duplex setting on interface or on port-channel?
Answer: Speed and duplex should be configured on the physical
interfaces.
2. 2. Should the
switchport command be configured on physical interfaces or on port-channel?
Answer: The switchport command should be configured on
both the physical interfaces and the port-channel.
moquery in Cisco ACI: Safe, Powerful & Zero ImpactWhen working with Cisco ACI, the moquery command is one of the most valuable troubleshooting tools. It allows engineers to query the Management Information Tree (MIT) and extract detailed information about ACI objects—tenants, VRFs, EPGs, BDs, contracts, endpoints, and more.
The best part?
moquery is completely safe.It is 100% read‑only, meaning it does not modify, push, or impact any ACI policies or traffic. Running it has no effect on leaf/spine switches, and it produces only minimal overhead on the APIC—similar to refreshing a GUI page.
moquerymoquery is your safest and most powerful command. It gives you deep visibility without any operational risk—making it a must-have tool for every ACI engineer.Understanding Cisco ACI VRF Enforced Mode (Simple & Secure Explanation)
In Cisco ACI, VRF Enforced Mode is the default and most secure policy model. It follows a strict white‑list approach, meaning EPGs cannot communicate with each other unless a contract explicitly allows that traffic. Even if two EPGs exist in the same VRF, they still need a contract for inter‑EPG communication.
Navigate to:
Tenants → [Tenant Name] → Networking → VRFs
Under Policy Control Enforcement Preference, choose:
🔒 Enforced
Once enabled, contracts become mandatory for any EPG-to-EPG communication.
If you’re tightening security from an unenforced setup, you can enable Preferred Groups to avoid breaking existing traffic flows during the transition. This allows a smooth shift while still moving toward full policy enforcement.
Understanding Ansible Roles: The Smart Way to Organize Your Automation
When your automation projects start growing, keeping playbooks clean and reusable becomes essential. That’s where Ansible roles step in—providing a structured, scalable way to organize your automation logic.
An Ansible role bundles together everything your playbook needs, such as:
This modular approach not only keeps your work tidy but also makes it effortless to reuse and maintain automation across multiple projects.
Ansible offers a built‑in utility called ansible-galaxy to generate a ready‑to-use role structure. This creates a fully structured directory containing all folders required for your role.
While a role contains multiple folders, a few are especially important for network engineers:
This folder holds baseline default values for your variables. If your playbook does not pass a variable, Ansible uses the value defined here.
The heart of any role.
All reusable task logic lives here—allowing you to write shorter playbooks and maintain your automation in one central place.
Used to store Jinja2 templates that your tasks render dynamically during execution.
This is where you define variables used within tasks or templates.
Defaults can be kept in the defaults/ directory, but if a variable has no fallback value, it must be defined here for the role to work properly.
Ansible roles bring clarity, modularity, and reusability to your automation workflows. Whether you're building network configs or managing large infrastructure deployments, roles ensure consistency while drastically reducing repetitive work.
Service graphs in Cisco ACI simplify network and security integration by offering several key benefits:
However, in Service Policy Mode:
Bottom Line:
Service graphs offer a streamlined, application-focused approach compared to traditional designs—but choose wisely based on your operational needs.
Cisco ACI provides three distinct approaches to manage service graphs, each offering different levels of control and integration:
Network Policy Mode (Unmanaged)
In this mode, ACI configures only the network aspects of the service graph within the fabric. No configuration changes are pushed to the L4-L7 device, making it suitable when device policies are managed externally.
Service Policy Mode (Managed)
Here, ACI not only handles the fabric configuration but also manages VLAN settings on the L4-L7 device. The APIC administrator can directly input device-specific configurations through the APIC interface, ensuring centralized control.
Service Manager Mode
This model allows the firewall or load balancer administrator to define L4-L7 policies. ACI takes care of the fabric and VLAN configurations, while the APIC administrator links these policies with the network policy, enabling a collaborative approach.
When designing with Cisco ACI, selecting the right service graph mode depends on your operational needs:
Dynamic Configuration Needs?
If firewalls and load balancers must be configured dynamically through APIC, choose Service Policy Mode. If a separate administrator handles device configuration, opt for Network Policy Mode or Service Manager Mode.
Frequent Commissioning Like Cloud Services?
For environments where devices are frequently added or removed, Service Policy Mode or Service Manager Mode works best. If services remain static for long periods, Network Policy Mode or Service Manager Mode is more practical.
Complex Multi-Leg Designs?
If your design requires multiple interfaces or DMZ configurations, manual service insertion using EPGs and bridge domains may be more convenient than using a service graph.
Bottom Line:
Your choice should align with automation needs, operational flexibility, and design complexity.
