Cisco Product Setup

Cisco Product Setup

Prerequisites

Workflow Overview

┌───────────┐   ┌───────────────┐   ┌───────────────┐   ┌─────────────────┐
│ Preflight │ → │ Render/review │ → │ Apply/handoff │ → │ Validate evidence │
└───────────┘   └───────────────┘   └───────────────┘   └─────────────────┘

When to Activate

• Set up Splunk for a Cisco product such as ACI, Nexus 9000, Duo, Meraki, ThousandEyes, ASA, or FTD, including choosing the dedicated ASA syslog TA versus Cisco Security Cloud API or eStreamer collection.
• Preview and review the cisco product setup workflow before any live apply phase.
• Diagnose failed prerequisites, generated assets, configuration, or validation evidence.

Scope

Follow the documented read-only or render-first path whenever it is available. This skill does not imply permission to mutate live systems. Require explicit apply flags, protected credentials, and operator review for state changes.

Examples

Inspect the supported setup modes before selecting one:

bash skills/cisco-product-setup/scripts/setup.sh --help

Expected output: usage, supported modes, and required arguments are displayed without changing the target environment.

Inspect validation modes before running completion checks:

bash skills/cisco-product-setup/scripts/validate.sh --help

Expected output: offline, live, and completion options are displayed when the skill supports them; help exits without mutation.

Troubleshooting

Shared add-on completion gate

When the selected product resolves to a Splunk TA, add-on, or dashboard companion, the delegated child must satisfy the shared completion gate. Package delivery alone is never successful product onboarding.

Provides one product-aware entrypoint for Cisco setup requests.

What It Does

• Resolves a product name, alias, or keyword against the pinned normalized SCAN public-catalog fixture.
• Classifies the product as automated, partial, manual_gap, no_plans_available, unsupported_legacy, or unsupported_roadmap.
• For automated products, delegates to the existing family skill already in this repo.
• For partial products, returns a concrete collector or app-install handoff path without claiming full product automation.
• For CUCM, Expressway, Meeting Server, and Meeting Management, delegates only render/validate planning to cisco-collaboration-setup; all four remain partial. BroadWorks and RoomOS collaboration hardware retain unsupported_roadmap through a non-executable gap_handoff to the same evidence router.
• For ASA and FTD, treats the collection path as part of product identity: syslog or Splunk_TA_cisco-asa intent routes to cisco-asa-ta-setup, while API and eStreamer intent routes to cisco-security-cloud-setup. Bare ASA/FTD requests return both choices instead of selecting an owner silently.
• Uses the relevant family template.example file to show which non-secret values are required before configuration.

Primary Commands

List products:

bash skills/cisco-product-setup/scripts/resolve_product.sh --list-products

Preview a product route:

bash skills/cisco-product-setup/scripts/setup.sh \
  --product "Cisco ACI" \
  --dry-run

Run the default workflow:

bash skills/cisco-product-setup/scripts/setup.sh \
  --product "Cisco ACI" \
  --set name ACI_PROD \
  --set hostname apic1.example.local,apic2.example.local \
  --set username splunk-api \
  --secret-file password /tmp/aci_password

Agent Behavior

The agent must never ask for secrets in chat. Use the routed family skill's secret-file pattern instead.

For non-secret intake, prefer the family template.example that the dry-run output lists for the resolved product.

Product Coverage

• Automated products use the existing Cisco family skills already in this repo.
• Partial products list the backed collector or handoff workflow and succeed in --dry-run previews, but do not perform live configuration through this router.
• Active products without a local route return manual_gap.
• Products with no verified local route return no_plans_available.
• Deprecated and retired products return unsupported_legacy.
• Roadmap products return unsupported_roadmap.

Catalog Files

• catalog_overrides.json defines local routing overrides.
• scan_source.json records the public SCAN catalog timestamp, minimum app version, raw source SHA-256, and normalized fixture SHA-256.
• scan_products.fixture.json is the sanitized, package-free source fixture consumed by clean-clone builds.
• scan_sourcetype_reconciliation.json binds the current SCAN version to every reviewed sourcetype delta, the previous and current complete-set hashes, a snapshot of every unchanged product, canonical owner skills, and downstream evidence. This makes omitted product changes and incomplete per-product deltas fail closed.
• catalog.json is the generated runtime catalog.
• scripts/build_catalog.py --check verifies that catalog.json matches the pinned fixture and overrides, including both provenance checksums and the sourcetype reconciliation contract.
• scripts/build_catalog.py --write regenerates catalog.json after editing catalog_overrides.json.
• scripts/build_catalog.py --refresh-source --write fetches the public SCAN products.conf and refreshes the fixture and manifest. When the source version changes, catalog generation intentionally stops until scan_sourcetype_reconciliation.json and its downstream evidence are reviewed; rerun --write after that review.
• scripts/build_catalog.py --check-live-source is the networked drift check; it is scheduled separately from pull-request gating.
• --scan-package PATH produces one-off comparison output from a reviewed vendor package but cannot overwrite the pinned generated catalog. Without a mode flag the script prints the catalog to stdout.

Completion Validation

The router's validation phase, including --validate-only, invokes actionable Cisco child validators with --completion. Consequently the full router does not report onboarding complete when account/input, event-flow, or shipped dashboard evidence is missing. Run a child validate.sh without that flag when only a warning-oriented diagnostic inventory is desired.