BGP Timers on a VRF in ACI Multi-Site — Why NDO Can't Do It and What Cisco TAC Confirmed

 If you've gone looking for a VRF-level BGP Timer Policy in Nexus Dashboard Orchestrator and come up empty, you're not missing a menu — it genuinely isn't there yet. Here's what we found while troubleshooting this on a live Multi-Site fabric with a mix of stretched and local VRFs, the workaround Cisco TAC confirmed as supported, and exactly how to verify the new timers actually took effect instead of just assuming they did.

• The gap: NDO does not expose a BGP Timer Policy at the VRF level for ACI Multi-Site — only at the L3Out node level (via L3Out Node Routing Policy → BGP Node Settings).
• The workaround: Create and apply the BGP Timer Policy directly on APIC, per site, against the target VRF (local or stretched). Cisco TAC confirmed this is the correct and supported method.
• The catch: BGP timers are negotiated during the initial handshake. Changing the policy alone does nothing to an already-established session — you need a hard reset of the BGP session for the new keepalive/hold values to take effect.
• Don't trust the config alone. "Configured" timers and "negotiated" (active) timers are two different things in show bgp output — always verify the negotiated value after the reset, not just the configuration.

The Problem: No VRF-Level BGP Timer Option in NDO

In a single-site APIC deployment, applying a custom BGP Timer Policy to a VRF is straightforward — it's a native object under Tenant → Networking → VRF → BGP Context Per Address Family. In Multi-Site environments managed through NDO, that granularity isn't there. NDO's L3Out configuration model lets you attach a BGP Node Routing Policy (with its own keepalive/hold timers) to a node group inside an L3Out template — but there's no equivalent construct for applying timers at the VRF level, independent of a specific L3Out's node groups.

For environments running mixed local and stretched VRFs across sites, that's a real gap: you may want consistent BGP timer behavior tied to the VRF itself, not scattered across every L3Out node group that happens to reference it.

What We Asked Cisco TAC

Rather than guess, we opened a case and asked directly. Here's the exchange, included for anyone hitting the same wall:

Our question:

We need to deploy BGP timers on a VRF within our ACI Multi-Site fabric. Our environment contains both stretched and local VRFs. We do not see an option in NDO to apply BGP timers at the VRF level. Therefore, we are planning to use the following approach: 1) Create a BGP Timer Policy on the APIC. 2) Apply the BGP Timer Policy to the target VRF (local or stretched) via APIC only. Could you please confirm whether the above procedure is the correct and supported method for configuring BGP timers in an ACI Multi-Site environment? Additionally, after applying the policy, we do not see the updated timer values reflected on the BGP neighbour sessions. Is a BGP session reset (hard reset) required for the new timer values to take effect, or are there any additional steps that need to be performed?

Cisco's response:

Configuration Method: Your proposed approach is correct. As NDO does not currently support configuring BGP Timer Policies at the VRF level, applying these policies directly via the APIC on each respective site is the standard and supported method. 

Session Reset: Yes, a BGP session reset (hard reset) is required for the new timer values to take effect. Because these timers are negotiated during the initial BGP handshake, the existing sessions must be torn down and re-established to renegotiate the new keepalive and hold-down values with the neighbor.

Two things worth underlining from that response: this is a per-site, APIC-side configuration — NDO is not the tool for VRF-level BGP timers today — and a hard reset is mandatory, not optional, for the values to actually apply.

Step-by-Step: Applying the BGP Timer Policy to a VRF via APIC

1. Log into the APIC GUI for the site containing the target VRF (do this per site for stretched VRFs — there's no single-pane push for this from NDO).
2. Navigate to Tenants → <tenant> → Networking → VRFs → <vrf-name>.
3. Under the VRF, go to the BGP Context Per Address Family (create one for each address family in use — IPv4 and/or IPv6).
4. Set the BGP Timers field to a custom BGP Timer Policy, or create a new one:
   • Go to Tenants → <tenant> → Policies → Protocol → BGP → BGP Timers, right-click and Create BGP Timers Policy.
   • Set Keepalive Interval (sec) and Hold Interval (sec) to your target values (keep the standard 1:3 ratio — e.g., 4/12 or 10/30 — most implementations expect hold time to be roughly 3x keepalive).
5. Apply the policy to the VRF's BGP Context Per Address Family and submit.
6. Repeat per site for any stretched VRF — this is not propagated automatically across the Multi-Site domain since it's an APIC-local object, not an NDO-managed one.
7. Confirm the object landed correctly:

   GET https://<apic>/api/node/mo/uni/tn-<tenant>/ctx-<vrf>/bgpCtxAfP-ipv4-ucast.json

Check for the tnBgpTimersPolName attribute pointing to your new policy.

Why the Timers Won't Show Up Until You Reset the Session

This trips people up every time: BGP keepalive and hold timers are exchanged in the OPEN message during session establishment — they're not a live, continuously-enforced parameter that updates on the fly. Changing the policy updates the configuration, but an already-established session keeps running on whatever timers it originally negotiated until it's torn down and rebuilt.

That means after step 7 above, show bgp will show your configured timers, but the negotiated/active timers on any existing session will still be the old values — until you force a reset.

Verifying the Change Actually Took Effect

Don't just trust the APIC MO or the CLI's "configured" line — verify the negotiated value, which is what's actually governing the session.

1. Check the configured value on the border leaf:

show bgp <afi> unicast neighbors <peer-ip> vrf <tenant>:<vrf-name>

Look for: Configured hold time is 12, keepalive interval is 4 seconds

2. Check the negotiated (active) value in the same output: Look for: Hold time is X, keepalive interval is Y seconds If X/Y still show the old defaults, the session hasn't renegotiated — move to step 3.

3. Force the hard reset:

clear bgp <afi> unicast <peer-ip> vrf <tenant>:<vrf-name>

A soft clear will not renegotiate timers — timers only get exchanged at session establishment, so this has to be a hard clear.

4. Re-check the negotiated value after the reset:

show bgp <afi> unicast neighbors <peer-ip> vrf <tenant>:<vrf-name>

The negotiated value will be the lower of what each side offers — if your peer's own BGP timer configuration is set higher (or lower) than yours, that governs the final negotiated result, not your configured value alone.

5. Confirm real-world keepalive cadence:

show bgp <afi> unicast neighbors <peer-ip> vrf <tenant>:<vrf-name> | include "Last read"

Run this two or three times a few seconds apart — "Last read" should reset roughly every N seconds, matching your new keepalive interval.

6. Watch for flapping after the change, especially with aggressive timers like 4/12:

show bgp <afi> unicast neighbors <peer-ip> vrf <tenant>:<vrf-name> | include "Last reset"
show logging logfile | include BGP

A Word of Caution on Aggressive Timers

Tighter timers (like 4-second keepalive / 12-second hold) improve failure-detection speed, but they raise the risk of false-positive flaps on links with variable latency, high CPU load on the peer device, or congested control-plane paths. Before rolling this out broadly across a Multi-Site fabric, test it on a single non-critical VRF/L3Out first and monitor for a few days.

FAQ

Does NDO support VRF-level BGP timers at all? Not currently. The only BGP timer construct exposed in NDO is at the L3Out node group level (L3Out Node Routing Policy → BGP Node Settings). VRF-level BGP Timer Policies must be applied directly on APIC, per Cisco TAC's confirmation.

Will this survive an NDO template push or resync? Since the VRF-level BGP Timers Policy is applied directly on APIC and not modeled in the NDO template, it should not be overwritten by a standard template redeploy — but any workflow that deletes and recreates the VRF from NDO would remove it. Treat it as an out-of-band configuration and document it clearly for your team.

Do I need to reset the session on both sides of the peering, or just my side? Just your side's session needs a hard clear to force renegotiation — BGP will tear down and rebuild the full session, which inherently re-triggers the handshake and timer exchange on both ends.

What's a safe keepalive/hold ratio to use? Cisco and most vendors expect hold time to be roughly 3x keepalive (e.g., 4/12, 10/30, 20/60). Going below that ratio, or setting a very low hold time on a link with real latency or jitter, increases false-positive flap risk.

Is this the same procedure for a stretched VRF across multiple sites? Yes, but it must be repeated per site — this is an APIC-local object, and NDO doesn't propagate it across the Multi-Site domain automatically. For a stretched VRF, log into each site's APIC and apply the same BGP Timer Policy independently.

Related Reading on Networklearner

• Why BGP Maximum-Paths Wasn't the Problem: Fixing Uneven Port-Channel Traffic on Cisco Nexus and IOS
• Complete Firewalls Port Reference for Cisco ACI, Nexus Dashboard, NDO and NDI
• BGP: Active Open Failed - No Route to Peer
• Weight Attribute - BGP
• BGP Attributes: Well Known vs Optional
• BGP Attribute - AS Prepend
• Cisco ACI Static EPG Configuration – Step-by-Step Deployment Guide
• Complete Steps to Create vPC in Cisco ACI (via APIC GUI)

---

Author note: 

Need help with Cisco ACI, Nexus, data center networking, or network automation?
I am a CCIE Data Center engineer with 18+ years of enterprise networking experience.
Contact me for consulting, troubleshooting, design reviews, and project support.

Understanding AI Agents for Network Engineers: LLMs, Prompts, Tokens and Context Explained

Artificial Intelligence is rapidly becoming part of modern network operations. From troubleshooting assistants to automated change management, AI agents are beginning to work alongside network engineers.

But what exactly powers these agents?

If you've configured routing protocols, built automation scripts, or managed network monitoring systems, understanding AI agents isn't as complicated as it might seem. This guide walks through the core building blocks of AI agents using networking analogies that any network engineer will recognize.

What Is an AI Agent?

An AI agent is a software system that can understand a goal, make decisions, and take actions to achieve that goal.

Compare it to a traditional network automation script. A Python script might be programmed to check interface status, detect a down link, and send an alert — it follows predefined instructions, nothing more.

An AI agent works differently. Instead of following a fixed set of rules, it can:

• Understand a request written in natural language
• Analyze available information
• Decide which action to perform
• Adapt when unexpected situations occur

That flexibility is what makes AI agents powerful.

Traditional Automation vs. AI Agents

Traditional automation follows rigid logic, such as IF Interface Down → Send Email. It's predictable, easy to troubleshoot, and great for repetitive tasks — but it cannot handle unknown scenarios and lacks contextual understanding.

AI-powered agents focus on outcomes rather than rigid instructions. Given a prompt like "Analyze this network outage and suggest possible root causes," an agent can review logs, analyze symptoms, identify possible issues, and recommend troubleshooting steps. It understands natural language, adapts to new situations, and can handle partially known problems.

The LLM: The Brain Behind Every AI Agent

At the center of every AI agent is a Large Language Model (LLM) — think of it as the control plane of the system. Just as a network's control plane makes routing decisions, the LLM makes reasoning decisions: understanding requests, processing information, choosing tools, and generating responses. Without the LLM, an AI agent is just a collection of disconnected tools.

Why the System Prompt Matters

The System Prompt is like a design document combined with operating procedures. It tells the AI who it is, what it should do, what to avoid, and which tools it can use — for example: "You are a Network Operations Assistant. Help engineers troubleshoot enterprise networks. Explain reasoning clearly. Use available monitoring tools when necessary." Without a solid system prompt, an AI agent can produce inconsistent or irrelevant responses.

Understanding Temperature: The Creativity Dial

Temperature controls how predictable or creative an AI's output is.

• Temperature = 0 — the model always picks the most likely answer. Best for troubleshooting, configuration validation, and change management, where consistency and accuracy matter most.
• Higher temperature — more creative and exploratory output, useful for brainstorming and content generation, but with a higher risk of inconsistent answers and hallucinations.

For network operations, a range of 0 to 0.3 is generally preferred.

What Are Tokens?

A token is a small unit of text processed by an LLM. As a rough rule of thumb, one token is about 4 English characters, and 100 words is roughly 130 tokens. Tokens directly affect processing cost, response speed, and context limits.

The Context Window: AI's Working Memory

The context window is effectively the RAM of an AI agent — it holds the system prompt, tool definitions, conversation history, and the current request. The larger the window, the more the AI can "remember" during a session.

Just as troubleshooting gets harder if a monitoring system forgets earlier alerts mid-investigation, an AI agent's performance can degrade once its context window fills up: older details get dropped, and accuracy can suffer. Efficient context management is essential for enterprise AI solutions.

Other Important AI Agent Parameters

• Max Tokens — the output limit for a single response, like a bandwidth cap.
• Stop Sequences — signals that tell the model when to stop generating, often used when calling external tools or handing control back to a user or system.
• Top-P — controls how many candidate next-words the model considers; lower values are more focused, higher values more diverse.
• Frequency Penalty — reduces repetitive language, useful when generating reports, documentation, and troubleshooting guides.

Real-World Network Engineering Use Cases

• Network troubleshooting — log analysis, root cause identification, incident summaries
• Configuration assistance — config review, error detection, best-practice recommendations
• Documentation generation — design docs, change records, runbooks
• Knowledge management — searching engineering documentation, answering technical questions, step-by-step procedures

Key Takeaways

• LLMs act as the reasoning engine of AI agents
• System prompts define behavior and scope
• Temperature controls creativity and consistency
• Tokens are the building blocks of AI processing
• Context windows determine what the agent can remember
• Proper configuration leads to more reliable AI agents

Final Thoughts

Just as networking evolved from manual CLI configuration to automation, the industry is now entering an era of intelligent, AI-assisted operations. Understanding LLMs, prompts, temperature, and context windows gives network engineers the foundation to work with this next generation of tools — and you don't need to become a data scientist to get there. If you already understand how networks make decisions, you're closer to understanding AI than you might think.

FAQ

What is an AI agent?

A software system that uses an LLM to understand goals, make decisions, and perform tasks — adapting to new situations rather than following fixed rules.

How is it different from traditional network automation?

Traditional automation follows fixed rules ("if interface down, alert"). An AI agent can handle open-ended requests ("investigate why Branch A is slow") by analyzing logs and configs and reasoning about likely causes.

Can AI agents replace network engineers? 

No. They're force multipliers for troubleshooting, documentation, and automation — but engineers remain responsible for design, security, governance, and business decisions.

What is hallucination? 

When an AI generates plausible-sounding but inaccurate or fabricated information (e.g., a command or error message that doesn't exist). Always verify AI output before acting on it.

Which AI skills should network engineers learn first? 

Prompt engineering, AI agents, generative AI fundamentals, basic Python, REST APIs, network automation, retrieval-augmented generation (RAG), and agentic AI workflows.

Related Reading on Networklearner

• Agentic AI for Network Engineers: What It Actually Means
• Reactive Automation vs Generative AI vs Agentic AI in Networking
• AI Brainstorming Framework & CROSS Prompting Explained
• AI Leadership Frameworks Explained: TQC, Power/Interest, and More
• Complete Firewall Ports Reference for Cisco ACI, NDO, and NDI

Need help with Cisco ACI, Nexus, data center networking, or network automation?
I am a CCIE Data Center engineer with 18+ years of enterprise networking experience.
Contact me for consulting, troubleshooting, design reviews, and project support.

Why BGP Maximum-Paths Wasn't the Problem: Fixing Uneven Port-Channel Traffic on Cisco Nexus and IOS

 If you've ever pulled up interface counters and seen one port-channel member carrying 70–80% of the traffic while its bundle-mate sits nearly idle, your first instinct is probably the same one we had: "BGP load balancing must be broken."

It usually isn't. Here's the case we worked through, why BGP was innocent from the start, and the actual fix.

TL;DR

• Symptom: One port-channel member interface was carrying the majority of traffic; the other was underutilized.
• First suspect: BGP maximum-paths — already configured correctly, and confirmed working via ECMP.
• Real cause: The port-channel load-balancing algorithm (src-dst-ip enhanced) was hashing large, persistent flows onto the same physical link every time.
• Fix: Move to src-dst-mixed-ip-port (or the NX-OS equivalent src-dst ip-l4port) to add Layer 4 entropy to the hash.
• Caveat: If the imbalance is caused by a single "elephant flow," even L4 hashing won't split it — that needs a different tool entirely.

The Symptom

The environment was already running router bgp with maximum-paths 8 configured, so multiple equal-cost paths were expected to be installed and used. But interface counters told a different story — one member of the port-channel was consistently running hot while the other stayed quiet, day after day, regardless of overall traffic volume.

Router# show interface port-channel 10 | include rate
  5 minute input rate 812000000 bits/sec, 95000 packets/sec
  5 minute output rate 790000000 bits/sec, 92000 packets/sec

Router# show interface gigabitethernet 1/1 | include rate
  5 minute input rate 780000000 bits/sec, 91000 packets/sec

Router# show interface gigabitethernet 1/2 | include rate
  5 minute input rate 32000000 bits/sec, 4000 packets/sec

That's roughly a 96/4 split across two members of the same bundle — not something you'd expect from a healthy port-channel.

Ruling Out BGP First

Before touching anything on the switching side, we confirmed the routing layer was actually doing its job.

Router# show ip bgp summary
Router# show ip route 10.20.30.0
Routing entry for 10.20.30.0/24
  Known via "bgp 65001", distance 20, metric 0
  Routing Descriptor Blocks:
  * 192.168.1.1, from 192.168.1.1
      192.168.1.2, from 192.168.1.2

Two next-hops installed for the same prefix, exactly as maximum-paths 8 should produce when the paths are equal-cost. BGP ECMP was functioning correctly — routing decisions were being made across multiple paths, so it made no sense to keep chasing BGP config as the root cause.

That's the key thing to internalize: BGP ECMP and port-channel load balancing are two completely separate mechanisms operating at two different layers.

Layer	Mechanism	Decides
Layer 3 (Routing)	BGP maximum-paths / ECMP	Which path (next-hop) traffic takes
Layer 2 (Switching)	Port-channel hash algorithm	Which physical member link within a bundle carries a given flow

Even with BGP perfectly distributing traffic across paths, each of those paths might egress through a port-channel — and it's entirely possible for the hashing algorithm on that port-channel to funnel most flows onto one member link regardless of what BGP is doing upstream.

Checking the Current Hashing Algorithm

Next step: find out what hash algorithm the port-channel was actually using.

On IOS / IOS-XE:

Router# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
        src-dst-ip

On Nexus (NX-OS):

Switch# show port-channel load-balance
Port Channel Load-Balancing Configuration:
System: src-dst ip

Both confirmed the same thing: the algorithm was using only Layer 3 information — source and destination IP address — to compute the hash and select a member link.

Why src-dst-ip Pins Big Flows to One Link

The hash is deterministic. Given the same source IP and destination IP, the algorithm produces the same result every single time, which means every packet in that flow is sent down the same physical link.

That's fine when you have many different flows between many different IP pairs — the hash spreads them out reasonably well. It falls apart when a small number of flows dominate the traffic, which is exactly what a database replication stream, a backup job, or a storage sync between two fixed IPs looks like: same source, same destination, forever — one hash result, one link, permanently.

This isn't a bug. Cisco's port-channel load balancing is intentionally flow-based, not packet-based, specifically to avoid packet reordering within a TCP session. The trade-off is that a big, long-lived flow can dominate a single member link even when the bundle as a whole has spare capacity.

The Fix: Add Layer 4 to the Hash

Switching from src-dst-ip to src-dst-mixed-ip-port pulls TCP/UDP source and destination port numbers into the hash calculation alongside the IP addresses.

IOS / IOS-XE:

Router(config)# port-channel load-balance src-dst-mixed-ip-port

NX-OS (Nexus):

Switch(config)# port-channel load-balance src-dst ip-l4port

Some Nexus platforms go a step further and support VLAN as an additional hash input for even more entropy:

Switch(config)# port-channel load-balance src-dst ip-l4port-vlan

With source/destination ports added, two different application sessions between the same pair of servers (say, a web server and a database server running several concurrent connections) will now very likely produce different hash results — and land on different physical links — instead of all piling onto whichever link the IP-only hash happened to pick.

In environments with many concurrent sessions between the same endpoints (application servers, load balancers, hypervisor clusters), this alone often meaningfully improves the balance.

Before You Make the Change

A few things worth knowing before you touch a production bundle:

• It's generally non-disruptive on most Cisco platforms — you don't need to shut the port-channel.
• Every existing flow gets re-hashed immediately. Expect a brief window of packet reordering as flows redistribute across members. It's usually transparent to TCP, but schedule the change for a maintenance window or low-traffic period if the environment is sensitive (VoIP, storage replication, etc.).
• This is still flow-based hashing, just with more inputs. A single elephant flow — one enormous, sustained stream between one IP:port pair — will still be pinned to one physical link even after adding L4 information. Layer 4 hashing splits up multiple flows between the same hosts; it does not split a single flow.

If It's an Elephant Flow, Hashing Alone Won't Fix It

If, after the change, one link is still running noticeably hotter than the others, don't keep tweaking the hash algorithm — look for a dominant flow instead:

Router# show interface port-channel 10 | include rate
Switch# show flow monitor <name> cache

or pull top talkers from NetFlow/sFlow/telemetry. If you find one flow consuming most of the bandwidth, your real options are traffic engineering (splitting the application across multiple sessions/IPs if possible), platform-specific dynamic load balancing features (several Nexus platforms support Dynamic Load Balancing, which rebalances flows based on real-time link utilization rather than a static hash), or simply accepting that a single-flow workload isn't a great fit for port-channel-based scaling in the first place.

Verification Checklist

After changing the algorithm, give it a few hours under real traffic and check:

• Port-channel member interface utilization (show interface … | include rate on each member)
• Top bandwidth-consuming flows (NetFlow/sFlow/telemetry)
• Interface error/discard counters (rule out anything unrelated masquerading as imbalance)
• Application-level traffic distribution if you have flow visibility tools

If the split moves from something like 96/4 toward 55/45 or 60/40, the change did its job. If it barely moves, you're very likely looking at an elephant-flow scenario rather than a hashing-algorithm problem.

FAQ

Does changing the port-channel load-balancing algorithm cause an outage? No — on most Cisco IOS, IOS-XE, and NX-OS platforms this is a non-disruptive change. Existing flows get re-hashed and may briefly reorder, but the port-channel itself stays up.

Will src-dst-mixed-ip-port always produce perfectly even traffic distribution? No. It improves distribution when multiple flows exist between the same endpoints, but a single very large flow will still be pinned to one member link, since hashing is flow-based, not packet-based.

How do I check the current load-balancing algorithm on a Nexus switch? show port-channel load-balance on NX-OS. On IOS/IOS-XE, use show etherchannel load-balance.

Is BGP maximum-paths related to port-channel hashing at all? No — they operate at different layers. maximum-paths controls how many equal-cost paths BGP installs at Layer 3. Port-channel hashing controls which physical member link, at Layer 2, carries a given flow once it's already been routed onto that path.

What's the best load-balancing algorithm for Cisco port-channels in general? There isn't a universal "best" — it depends on traffic patterns. src-dst-mixed-ip-port (or NX-OS's ip-l4port) is a strong general-purpose default for environments with many concurrent sessions between the same hosts, since it adds the most useful entropy without added complexity.

Conclusion

BGP maximum-paths was never the issue in this case — it was correctly installing and using multiple equal-cost paths exactly as designed. The imbalance lived one layer down, in the port-channel's src-dst-ip hashing algorithm, which pins any given source/destination IP pair to a single physical link. Moving to src-dst-mixed-ip-port added Layer 4 awareness to the hash and meaningfully improved distribution — with the caveat that a genuine elephant flow needs a different fix entirely.

The broader lesson: when you see uneven link utilization on a bundle, don't assume the routing protocol is at fault. Check where the imbalance actually lives — Layer 3 path selection or Layer 2 hash distribution — before you start changing BGP configuration that may already be working exactly as intended.

---

Related Articles

If this was useful, these go deeper on the BGP and Cisco fundamentals that sit underneath this issue:

• Weight Attribute - BGP
• BGP Attributes: Well Known vs Optional
• BGP Attribute - AS Prepend
• MTU in EIGRP Metric
• Forward Error Correction (FEC) in Cisco ACI
• BGP: Active Open Failed - No Route to Peer

Why BGP Maximum-Paths Wasn't the Problem: Understanding Port-Channel Load Balancing and Traffic Imbalance

Recently, we investigated a case where traffic utilization across port-channel member interfaces was significantly unbalanced. One of the links was carrying the majority of the traffic while the other link remained underutilized. Since the environment was already configured with BGP maximum-paths 8, the initial assumption was that BGP load balancing might not be functioning correctly.

After reviewing the configuration, we confirmed that BGP ECMP was operating as expected and that multiple equal-cost paths were available. This shifted our focus from the routing layer to the port-channel load-balancing mechanism.

Why BGP Was Not the Problem

The configuration already included BGP maximum-paths 8, which allows the router to install and use multiple equal-cost paths. This means the network was capable of leveraging several routes simultaneously, eliminating BGP as the primary suspect.

It is important to understand that BGP ECMP and port-channel load balancing serve different purposes. BGP decides which routing path should be used, while the port-channel hashing algorithm determines which physical member link will carry the traffic.

Even when ECMP is working perfectly, traffic can still become concentrated on a single port-channel member if the hashing algorithm maps large flows to the same interface.

Current Hashing Algorithm Analysis

The port-channel was configured with the src-dst-ip enhanced load-balancing algorithm.

This algorithm uses only the source and destination IP addresses to calculate the hash. If a traffic flow continuously uses the same source and destination IP addresses, all packets belonging to that flow will be forwarded through the same member interface.

For example, a database replication stream between two servers will always generate the same hash result. As a result, the entire flow remains pinned to a single physical link regardless of how much unused bandwidth exists on other members of the port-channel.

This behavior is normal because Cisco port-channel load balancing is flow-based rather than packet-based. The objective is to avoid packet reordering and maintain application performance.

Considering src-dst-mixed-ip-port

To improve traffic distribution, we evaluated changing the load-balancing algorithm from src-dst-ip enhanced to src-dst-mixed-ip-port.

Unlike the current configuration, this method includes both Layer 3 and Layer 4 information in the hash calculation. In addition to source and destination IP addresses, it also considers source and destination TCP or UDP port numbers.

This creates a larger number of unique hash combinations and increases the likelihood that different application sessions between the same endpoints will be distributed across multiple member links.

In environments where users, applications, or servers establish numerous simultaneous connections, this approach often results in significantly improved bandwidth utilization across the port-channel.

Important Considerations Before Making the Change

Changing the load-balancing algorithm is generally considered a non-disruptive operation on most Cisco platforms. However, all existing traffic flows will be immediately re-hashed.

As traffic gets redistributed across available links, there may be a brief period of packet reordering. While this is typically minor and transparent to most applications, implementing the change during a maintenance window or low-utilization period is recommended.

Another important consideration is that even with Layer 4 information included, the load-balancing mechanism remains flow-based. If the imbalance is caused by a single high-bandwidth elephant flow, the entire flow will still be assigned to one member link.

In such cases, changing the hashing algorithm may provide only limited improvement.

Recommended Validation After the Change

After implementing the new load-balancing method, monitor interface utilization and traffic patterns for several hours.

Review the following:

Port-channel member utilization

Top bandwidth-consuming flows

NetFlow or telemetry statistics

Application traffic distribution

Interface counters

If traffic becomes more evenly balanced across the member interfaces, the change has achieved its objective. If the imbalance continues, further investigation should focus on identifying large elephant flows or application-specific traffic patterns.

Conclusion

Based on our analysis, BGP maximum-paths was not contributing to the bandwidth imbalance. The routing layer was functioning correctly and supporting multiple equal-cost paths as designed.

The more likely cause was the src-dst-ip enhanced hashing algorithm, which uses only Layer 3 information and can result in traffic concentration when a small number of large flows dominate bandwidth consumption.

Moving to src-dst-mixed-ip-port is a logical and widely adopted optimization because it introduces Layer 4 awareness into the hashing calculation and generally improves traffic distribution when multiple flows exist between the same source and destination hosts.

While it may not solve scenarios involving a single elephant flow, it represents the most appropriate next step before exploring more advanced traffic-engineering options

Complete Firewalls Port Reference for Cisco ACI, Nexus Dashboard, NDO and NDI

 

If you've ever tried to onboard an APIC site into Nexus Dashboard Orchestrator (NDO) or Nexus Dashboard Insights (NDI) only to watch the connection sit at "Not Reachable," the cause is almost always the same: a firewall or ACL between Nexus Dashboard and the ACI fabric is blocking a port nobody told you about.

This guide consolidates every port you need — APIC to leaf/spine, APIC to Nexus Dashboard, NDO-specific ports, NDI-specific ports, and the internal ports a multi-node ND cluster needs between its own nodes — into one reference you can hand straight to your firewall team.

Quick jump:

• Why this trips people up
• Management vs. data network — pick correctly
• Port table: ND cluster ↔ outside world
• Port table: NDO ↔ APIC
• Port table: NDI ↔ APIC / fabric
• Port table: APIC ↔ Leaf/Spine (fabric internal)
• Troubleshooting checklist
• FAQ

---

Why this trips people up

Nexus Dashboard isn't one service — it's a platform that runs NDO, NDI, and NDFC as apps on top of a shared cluster. Each app has its own port requirements on top of the base cluster ports, and each app can reach the fabric through a different interface (management network vs. data network, in-band vs. out-of-band APIC). Miss that distinction and you'll open the right port on the wrong interface — the connection still fails, and it looks identical to a wrong-port problem.

---

Management vs. data network — pick correctly {#management-vs-data-network}

Nexus Dashboard interface	What it's for	Reaches APIC via
Management (mgmt) network	UI access, NTP, DNS, firmware upgrades, Intersight, DC proxy	Can reach APIC OOB or in-band, if routed
Data network	Node-to-node cluster traffic, and all app traffic — NDO, NDI, NDFC	APIC in-band or OOB for NDO; in-band only for NDI

Rule of thumb: if you're only running NDI, or NDI alongside other services, the ND data interface must have IP reachability to the in-band management network of the APIC and every switch in the fabric — NDI pulls switch-level telemetry that OOB simply doesn't carry. NDO is more flexible and can use either OOB or in-band APIC reachability.

---

Port table: ND cluster ↔ outside world {#nd-cluster-ports}

These are baseline ports every Nexus Dashboard cluster needs, regardless of which app (NDO/NDI/NDFC) you run on top.

Also allow outbound to your NTP, DNS, and (if used) TACACS+/LDAP/RADIUS servers, plus internet/proxy access if the cluster needs firmware downloads or Intersight connectivity.

---

Port table: NDO ↔ APIC {#ndo-apic-ports}

NDO's actual data-plane traffic to sites is just the APIC REST API over TCP 443. If you're only building day-0/day-1 policy through NDO (no NDI), this is the shortest port list of the three.

---

Port table: NDI ↔ APIC / fabric {#ndi-apic-ports}

NDI is the most sensitive to the in-band requirement — before onboarding a fabric, confirm the in-band management EPG, bridge domain, and subnet are already built and that every leaf, spine, and APIC has a reachable in-band address. This is the step people skip and then spend hours troubleshooting "site unreachable" errors that are actually EPG/BD issues, not firewall issues.

---

Port table: APIC ↔ Leaf/Spine (fabric internal) {#apic-fabric-ports}

This traffic stays inside the ACI infra VRF and normally isn't firewalled, but it's worth documenting for anyone running APIC connectivity through an external device (e.g., a device sitting between APIC and a remote-leaf pair):

If you're extending remote leaf switches over a routed IPN, also confirm OSPF, DHCP relay, and multicast (PIM Bidir) are permitted, with a minimum MTU of 9150 bytes end to end.

---

Troubleshooting checklist {#troubleshooting}

Work through these in order before opening a TAC case:

1. Ping test first. Confirm basic IP reachability from the ND data interface to the APIC in-band (for NDI) or in-band/OOB (for NDO) address. No ping = no point checking ports yet.
2. Confirm which interface ND is actually using. Nexus Dashboard > Infrastructure > Cluster Configuration shows whether the data or management network is used for fabric connectivity.
3. Verify APIC in-band is actually built (mgmt tenant, in-band BD, in-band EPG, node management addresses) — this is the single most common NDI onboarding blocker, not the firewall itself.
4. Test port 443 directly from an ND node to the APIC IP with curl -vk https://<apic-ip> or openssl s_client -connect <apic-ip>:443.
5. Check for SSL inspection/proxy devices sitting in the path — APIC's certificate handling doesn't play well with transparent SSL interception.
6. Re-check site status after any firewall change — NDO/NDI cache connectivity state and may need a manual "Refresh" or re-registration, not just a rule change.

---

FAQ {#faq}

Does NDO need port 80, or just 443? In current releases, TCP 443 alone is sufficient for APIC REST API communication. Port 80 was referenced in older MSO documentation and is generally not required if 443 is reachable.

Can NDI use the APIC out-of-band address? No. NDI depends on in-band reachability to both APIC and the switches for telemetry collection; OOB-only connectivity will not work for NDI.

Do NDO and NDI need different firewall rules if both run on the same ND cluster? Yes — treat them as separate rule sets. NDO needs 443 to APIC. NDI additionally needs 443 (and sometimes 22) to every switch in the fabric over the in-band network.

What's the minimum MTU I need between Nexus Dashboard and the fabric? 1500 bytes minimum on the ND data interface; higher MTU is supported if your infrastructure already runs jumbo frames.

My rules look correct but the site still shows "Not Reachable." What next? Check for SSL-inspecting firewalls/proxies in the path, confirm the APIC certificate hasn't expired, and verify NTP is in sync across APIC and ND — clock skew alone can break TLS session establishment.

---

Related reading on Networklearner

• ThousandEyes Firewall Requirements: Agent to Dashboard Ports and Rules — same port-table format, useful cross-link since readers researching ACI firewall rules often also manage ThousandEyes agents
• Recovering and Reinitializing a Standby APIC to Active APIC in Cisco ACI
• How to Safely Decommission a Leaf Switch in Cisco ACI — Step-by-Step Guide with Checklist
• Cisco ACI Decommission Only vs Remove vs Secure Remove — Complete Guide with Management IP Behavior
• ACI Leaf Switch Replacement
• Complete Steps to Create vPC in Cisco ACI (via APIC GUI)
• Cisco ACI Static EPG Configuration – Step-by-Step Deployment Guide
• What is a Contract Preferred Group in ACI?
• COOP: Council of Oracle Protocol - Cisco ACI
• Configuring Port Profiles in Cisco ACI (NX-OS Style CLI)
• Cisco ACI Mis-Cabling Protocol (MCP) – Loop Detection Simplified