Basic Networking Questions - Interview

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.

BGP

Difference between soft-reconfiguration inbound and soft-reconfiguration inbound always.

Feature	soft-reconfiguration inbound	soft-reconfiguration inbound always
Purpose	Enables reprocessing of inbound policies without resetting the BGP session.	Same as above, but ensures routes are always stored for reprocessing.
Storage	Stores routes only when explicitly triggered.	Always stores all received routes in adj-RIB-in.
Memory Impact	Lower memory usage.	Higher memory usage (routes duplicated in memory).
Dependency	Relies on neighbor supporting Route Refresh capability.	Works even if neighbor does not support Route Refresh.
Use Case	Modern networks where Route Refresh is supported.	Legacy peers or environments where Route Refresh is unavailable.

Cisco ACI - MoQuery command

Understanding moquery in Cisco ACI: Safe, Powerful & Zero Impact

When 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.

Why Engineers Love moquery

• Fetches deep fabric details instantly
• Helps troubleshoot contracts, mappings, scopes, and endpoints
• Works directly on the APIC without touching data-plane devices
• Safe to use even on busy production fabrics

Popular Examples

moquery -c fvBD # Bridge Domains

moquery -c fvCtx # VRFs

moquery -c fvAEPg # EPGs

moquery -c fvCEp # Endpoints

moquery -c fvRsProv # Provided contracts

Bottom Line If you need to inspect anything inside the ACI fabric, moquery 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.

VRF Enforced Mode - Cisco ACI

 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.

Why VRF Enforced Mode Matters

• Secure by default: All inter‑EPG traffic is denied until permitted by a contract.
• Controlled micro-segmentation: Only required communication paths are opened.
• Intra‑EPG traffic allowed: Endpoints inside the same EPG can talk freely unless isolation is configured.

Other Policy Modes

• Unenforced Mode:
  All traffic inside the VRF is allowed without contracts. Used rarely—mainly for testing or troubleshooting.
• Preferred Group:
  A flexible option where selected EPGs can communicate freely, while others still require contracts. Useful during migrations or gradual policy tightening.

How to Configure VRF Enforced Mode

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.

Switching from Unenforced to Enforced

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.

A Beginner’s Guide to Ansible Roles for Network Automation

 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:

• Variables
• Tasks
• Templates
• Files
• Handlers
• Custom modules

This modular approach not only keeps your work tidy but also makes it effortless to reuse and maintain automation across multiple projects.

Creating an Ansible Role

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.

Key Directories You’ll Use Most in Network Automation

While a role contains multiple folders, a few are especially important for network engineers:

1. defaults/

This folder holds baseline default values for your variables. If your playbook does not pass a variable, Ansible uses the value defined here.

2. tasks/

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.

3. templates/

Used to store Jinja2 templates that your tasks render dynamically during execution.

4. vars/

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.

Why Use Roles?

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.

Why Service Graphs Matter in Cisco ACI

Service graphs in Cisco ACI simplify network and security integration by offering several key benefits:

• Traffic Redirection Made Easy: Direct traffic to L4-L7 devices without complex designs.
• Automated VLAN Management: No manual VLAN assignments needed.
• Seamless vNIC Connectivity: Virtual NICs are automatically connected.
• Reusable Templates: Configure once, reuse multiple times.
• Logical & Application-Centric View: Gain clarity and better visibility of services.
• Shared Device Model: Efficiently share devices across departments.
• Health & Performance Insights: Collect health scores and statistics from devices.
• Dynamic Updates: ACLs and pools update automatically with endpoint discovery.

However, in Service Policy Mode:

• The model leans heavily on automation.
• Managing numerous configuration parameters can be overwhelming for frequent changes.

Bottom Line:
Service graphs offer a streamlined, application-focused approach compared to traditional designs—but choose wisely based on your operational needs.

Cisco ACI Service Graph Management Models Explained

Cisco ACI provides three distinct approaches to manage service graphs, each offering different levels of control and integration:

1. 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.

2. 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.

3. 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.

Choosing the Right Cisco ACI Service Graph Mode

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.

Nexus Dashboard Roles and Permissions