NetStacksNetStacks
Contact SalesGet Started

Vendor Knowledge Packs

Built-in vendor and domain knowledge packs ground the assistant for Cisco, Juniper, Arista, routing, data center, MPLS, security, and wireless — loaded by profile weight within a budget.

Overview

Knowledge packs are curated, vendor- and domain-specific expertise compiled into NetStacks. They sharpen the assistant's answers for real network platforms without you pasting reference material or building a knowledge base first. A pack is a block of condensed, high-signal facts — LSA types, BGP path selection order, VXLAN UDP ports, Junos commit semantics — that gets injected into the system prompt so the model reasons from accurate platform knowledge.

Note

Knowledge packs are built in and local — nothing to download or enable. They are distinct from the Controller's retrieval knowledge base. See Knowledge Base for indexing your own org-specific documents with RAG.

What's Included

There are nine packs: one always-on core pack, five domain packs, and three vendor packs.

CategoryPackCovers (examples)
corecoreOSI/TCP-IP layering, subnet/CIDR math, interface naming, exec vs config mode, show-before-change discipline
domainroutingOSPF LSAs & states, BGP path selection & FSM, EIGRP DUAL, IS-IS levels
domaindatacenterVXLAN/EVPN route types, spine-leaf CLOS, VLAN/STP, oversubscription
domainsecurityACL placement, zone-based firewall, AAA (TACACS+/RADIUS) order
domainwireless802.11 standards, RF/RSSI/SNR thresholds, WLC/CAPWAP, roaming
domainmplsLabel operations, LDP/RSVP-TE, L3VPN (VRF/RD/RT), FRR, PHP
vendorciscoIOS/IOS-XE vs NX-OS config models, feature-gating, common gotchas
vendorjuniperJunos candidate/commit, hierarchy & set syntax, routing policy
vendoraristaEOS config sessions, MLAG, EVPN/VXLAN, CloudVision

How Packs Load

Pack selection is driven by your AI Engineer Profile. The profile holds two weighted maps — vendor_weights and domain_focus — where each entry is a name and a numeric weight. At prompt-compile time the loader:

  1. Always injects the core pack first — it is non-negotiable and never dropped.
  2. Sorts your domain and vendor entries by weight, highest first.
  3. Adds each pack in that order only if it fits the remaining character budget. Packs that would overflow the budget are skipped, so the highest-weighted topics win when space is tight.

The budget is derived from the model's context window: roughly the configured context size minus a fixed reserve (about 3,000 characters) held back for safety rules and the rest of your profile. Script generation uses a leaner cap so generated configs stay focused. Packs apply to AI Chat, NOC Agents, and script generation.

A profile that emphasizes routing and Cisco might look like this conceptually (weights are relative — higher means higher-priority loading):

{
  "domain_focus":   { "routing": 0.8, "datacenter": 0.5, "mpls": 0.3 },
  "vendor_weights": { "cisco": 0.7, "juniper": 0.3 }
}

With a generous budget the assistant would load: core (always) + routing + datacenter + mpls + cisco + juniper. Under a tight budget it would keep core, then routing and cisco (the highest-weighted in each map), dropping the rest until they fit.

Tip

An empty profile still gets the core pack. Set vendor and domain weights to pull in the platforms you actually run so the assistant's syntax and caveats match your fleet.

Example: A Pack in Action

Suppose your profile weights routing and cisco. The compiled system prompt includes condensed blocks like these (excerpted from the actual packs):

injected system prompt (excerpt)text
## Routing Protocol Expertise
### BGP
- Path selection (in order): highest weight, highest local-pref, locally
  originated, shortest AS-path, lowest origin (IGP < EGP < incomplete),
  lowest MED (when from same AS), eBGP over iBGP, lowest IGP metric to
  next-hop, oldest route, lowest RID, lowest neighbor IP
- FSM states: Idle -> Connect -> Active -> OpenSent -> OpenConfirm -> Established

## Cisco Platform Expertise
### NX-OS
- Feature-gated: 'feature <name>' required before using protocols (feature ospf)
- 'no shutdown' needed on most interfaces (admin-down by default on NX-OS)

Because that context is present, the assistant answers with the correct ordering and platform caveats instead of generic guesses:

You:  My eBGP neighbor on a Nexus is stuck in Idle and the
      interface looks down. What should I check?

AI:   On NX-OS the interface is likely admin-down by default — run
      'no shutdown'. Also confirm 'feature bgp' is enabled, then check
      next-hop reachability. BGP walks Idle -> Connect -> Active before
      Established, so a stuck Idle usually means the TCP session never
      opened (interface/route/ACL), not a policy problem yet.

Pair packs with live device output for grounded results. When your session context detects a platform (for example a device identified as Cisco IOS-XE), the assistant has both the pack knowledge and your real show output to reason over.

Q&A

Q: Do I need to enable or download knowledge packs?
A: No. All packs are compiled into NetStacks. The core pack always loads; domain and vendor packs load automatically based on your AI Engineer Profile weights.
Q: Which packs exist?
A: core (always), domain packs routing, datacenter, security, wireless, mpls, and vendor packs cisco, juniper, arista.
Q: How does NetStacks decide which packs to include?
A: It sorts your domain_focus and vendor_weights by weight, then adds packs highest-first until the character budget is exhausted. Core is always included first and never dropped.
Q: What happens if my context window is small?
A: Lower-weighted packs are skipped to stay within budget. Your top-weighted domain and vendor still load, so the most relevant knowledge is preserved.
Q: Is this the same as the Knowledge Base?
A: No. Packs are built-in, general vendor/domain expertise. The Knowledge Base is your own organization's document corpus retrieved via RAG in the Controller.
Q: Do packs send my data anywhere?
A: No. Packs are static local text injected into the prompt sent to your configured model. They add no telemetry of their own.