Skip to content

ciscoittech/roocode-network-engineering

Repository files navigation

RooCode Network Engineering System

Complete network engineering orchestration for RooCode with offline capability

Version: 1.0 Date: October 2025 For: Network Engineers, VoIP Engineers, Security Engineers, AWS Cloud Engineers


🎯 What This System Does

Provides four main orchestrators that coordinate specialized agents for network engineering and cloud tasks:

Network & Infrastructure

  1. 🌐 Network Engineering Orchestrator - Routing (OSPF, BGP, EIGRP), Switching (VLANs, STP), Connectivity
  2. 📞 VoIP Orchestrator - AWS Connect, CUCM, CUC, SIP, call quality
  3. 🔒 Security Orchestrator - ISE, Firewalls, NAC, authentication

AWS Cloud & DevOps

  1. ☁️ AWS Cloud Orchestrator - Lambda, DynamoDB, S3, API Gateway, Bedrock, AI Services, DevOps

Each orchestrator launches specialists for:

  • 🔍 Troubleshooting - Diagnose issues systematically
  • 🏗️ Architecture - Design solutions
  • ⚙️ Implementation - Provide configurations
  • 📄 Documentation - Generate runbooks and diagrams

🌟 Key Features

1. Online Orchestration (Automated)

Orchestrators automatically launch specialists and aggregate results:

User: "OSPF neighbors not forming"

Network Orchestrator:
  → Launches Network Troubleshooter
  → Launches Packet Analyzer (if needed)
  → Launches Network Architect (if redesign needed)
  → Launches Network Engineer (implementation)
  → Launches Runbook Generator (documentation)

Output: Complete analysis + solution + runbook

2. Offline Mode (Script Generation)

Generate diagnostic scripts with logging for offline environments:

User: "I need to troubleshoot BGP but I'll be offline"

Network Orchestrator:
  → Generates diagnostic-bgp.sh with comprehensive logging
  → Script collects: BGP neighbors, routes, config, connectivity
  → User runs script offline → Brings logs back

User: "Here are the logs: [paste]"

Network Orchestrator:
  → Analyzes logs
  → Identifies root cause
  → Provides fix

3. Context-Aware Intelligence

Orchestrators ask clarifying questions when needed:

User: "Users can't authenticate"

Security Orchestrator:
  Asks: "What system?
    A) ISE (802.1X/MAB)
    B) Firewall (VPN)
    C) Both"

  Based on answer → Launches appropriate specialists

4. Customer/Project Organization

Organize work by customer and project:

/network-projects/
├── customer-acme/
│   ├── .network-config/          # Customer-specific context
│   │   ├── customer-context.md
│   │   ├── network-topology.md
│   │   └── device-inventory.md
│   ├── voip-migration/
│   │   ├── logs/                 # Offline script outputs
│   │   ├── scripts/              # Generated scripts
│   │   └── documentation/        # Runbooks, diagrams
│   └── firewall-upgrade/
│       ├── logs/
│       ├── scripts/
│       └── documentation/

📂 Directory Structure

roocode-network-engineering/
├── README.md (this file)
├── INDEX.md (quick navigation)
├── OFFLINE_MODE_GUIDE.md (offline workflow details)
│
├── orchestrators/
│   ├── network-orchestrator-export.yaml
│   ├── voip-orchestrator-export.yaml
│   ├── security-orchestrator-export.yaml
│   └── README.md
│
├── specialists/
│   ├── troubleshooting/
│   │   ├── ise-troubleshooter-export.yaml
│   │   ├── voip-troubleshooter-export.yaml
│   │   ├── network-troubleshooter-export.yaml
│   │   ├── packet-analyzer-export.yaml
│   │   └── authentication-analyzer-export.yaml
│   │
│   ├── architects/
│   │   ├── voip-architect-export.yaml
│   │   ├── network-architect-export.yaml
│   │   └── security-architect-export.yaml
│   │
│   ├── implementation/
│   │   ├── voip-engineer-export.yaml
│   │   ├── network-engineer-export.yaml
│   │   └── security-engineer-export.yaml
│   │
│   └── documentation/
│       ├── runbook-generator-export.yaml
│       ├── diagram-generator-export.yaml
│       └── config-documenter-export.yaml
│
├── contexts/ (knowledge bases)
│   ├── cucm-complete.md
│   ├── sbc-complete.md
│   ├── ise-complete.md
│   ├── sip-complete.md
│   ├── aws-connect.md
│   ├── bgp-complete.md
│   ├── ospf-complete.md
│   └── README.md
│
└── templates/
    └── customer-project-template/
        ├── .network-config/
        │   ├── customer-context.md
        │   ├── network-topology.md
        │   └── device-inventory.md
        ├── logs/
        ├── scripts/
        └── documentation/

🚀 Quick Start

1. Import Modes into RooCode

Quick Import (All at Once):

# File already created: network-engineering-complete.yaml (300KB)
# Includes all 14 modes (3 orchestrators + 11 specialists)

# Import in RooCode:
# Settings → Custom Modes → Import → network-engineering-complete.yaml

Selective Import:

# Just orchestrators (69KB)
cat orchestrators/*.yaml > orchestrators-only.yaml

# Just troubleshooting (89KB)
cat specialists/troubleshooting/*.yaml > troubleshooting-only.yaml

# Just architects (79KB)
cat specialists/architects/*.yaml > architects-only.yaml

# Just implementation (76KB)
cat specialists/implementation/*.yaml > implementation-only.yaml

See IMPORT_GUIDE.md for:

  • Detailed import instructions
  • Switching between network engineering and development modes
  • Mode groups setup
  • Troubleshooting import issues

2. Set Up Customer/Project Structure

# Copy template for new customer
cp -r templates/customer-project-template/ ~/network-projects/customer-newco/

# Customize customer context
cd ~/network-projects/customer-newco/.network-config/
# Edit customer-context.md, network-topology.md, device-inventory.md

3. Start Using

Online Troubleshooting:

Switch to: network-orchestrator mode in RooCode

"OSPF neighbors down on core routers"

Orchestrator automatically:
→ Launches troubleshooters
→ Analyzes issue
→ Provides solution
→ Generates runbook

Offline Troubleshooting:

Switch to: network-orchestrator mode in RooCode

"BGP issues at remote site, no connectivity to generate offline script"

Orchestrator generates:
→ diagnostic-bgp.sh with logging
→ Instructions for running offline
→ What to look for in logs

Run script offline → Bring logs back → Paste to orchestrator

📖 How It Works

Online Mode Example: OSPF Troubleshooting

User: @network-orchestrator "OSPF neighbors not forming between R1 and R2"

Orchestrator: I'll help troubleshoot. Are you online or offline?

User: "Online"

Orchestrator:
  [Step 1] Launching Network Troubleshooter...

  Network Troubleshooter analyzes:
  - OSPF neighbor requirements
  - Common failure points
  - Diagnostic commands needed

  Result: "Check OSPF network statements and interface configuration"

  [Step 2] Packet capture not needed (configuration issue)

  [Step 3] Launching Network Engineer for implementation...

  Network Engineer provides:
  - Configuration commands to fix
  - Validation commands
  - Rollback procedure

  [Step 4] Launching Runbook Generator...

  Result: Complete runbook saved to documentation/

Orchestrator Final Report:
  Problem: OSPF neighbors not forming
  Root Cause: Mismatched network statements
  Solution: [Configuration fix]
  Validation: [Commands to verify]
  Runbook: [Link to generated doc]

Offline Mode Example: BGP Troubleshooting

User: @network-orchestrator "BGP peers down, I'll be offline"

Orchestrator: I'll generate an offline diagnostic script.

What protocols are affected?
  - BGP
  - Routing in general
  - Connectivity to specific IPs

User: "BGP to ISP"

Orchestrator generates script:

#!/bin/bash
# BGP Diagnostic Script
# Logs to: bgp-diagnostic-YYYYMMDD-HHMMSS.log

[Script checks:]
- show ip bgp summary
- show ip bgp neighbors
- show ip route bgp
- show run | section router bgp
- ping/traceroute to ISP
- Interface status

[User runs offline]

User returns online: "Here are the logs: [paste 500 lines]"

Orchestrator:
  [Analyzing logs...]

  Found in logs:
  - BGP neighbor state: Idle
  - TCP connection failing
  - Interface shows up/down

  Root Cause: Interface flapping due to cable issue

  Solution: Replace cable, verify BGP re-establishes

  Validation: show ip bgp summary (should show Established)

🎯 Workflow Patterns

Pattern 1: Troubleshooting → Fix

User has problem →
  Orchestrator launches troubleshooter →
    Identifies root cause →
      Launches implementation engineer →
        Provides fix →
          Generates runbook

Pattern 2: Design → Implement

User needs solution →
  Orchestrator launches architect →
    Designs solution →
      Launches implementation engineer →
        Provides step-by-step config →
          Launches documentation →
            Creates as-built docs

Pattern 3: Offline → Analyze → Fix

User going offline →
  Orchestrator generates diagnostic script →
    User runs offline →
      Brings logs back →
        Orchestrator analyzes →
          Identifies root cause →
            Provides fix

🔧 Customization

Add Customer-Specific Context

Edit .network-config/customer-context.md for each customer:

# Customer: ACME Corp

## Network Overview
- 3 data centers (DC1, DC2, DC3)
- MPLS WAN with BGP
- Cisco 9300 switches, ASR routers
- ISE for NAC

## Contact Information
- Network Team: [email protected]
- On-call: +1-555-0100

## Special Considerations
- Change window: Sunday 2-6 AM
- Always test in DC1 first
- Dual-vendor firewall (Cisco + Palo Alto)

Customize Offline Scripts

Offline scripts can be customized per customer:

# Save customer-specific script template
cp generated-script.sh ~/network-projects/customer-acme/scripts/bgp-diagnostic-template.sh

# Customize for customer environment
# Add customer-specific IPs, device names, etc.

# Reuse for future BGP issues

📊 Comparison: Online vs Offline

Feature Online Mode Offline Mode
Specialist Launching Automatic N/A (script generation)
Real-time Analysis Yes No (log analysis later)
Requires Connectivity Yes No
Output Interactive analysis + solution Script + logs + analysis later
Use Case Live troubleshooting Remote sites, no internet
Time to Resolution Faster (real-time) Slower (round-trip required)
Documentation Auto-generated Auto-generated after logs analyzed

🎓 Learning Path

For New Users:

  1. Read this README
  2. Import orchestrators only
  3. Try online troubleshooting with Network Orchestrator
  4. Try offline mode with script generation
  5. Import specialists for deeper dives

For Advanced Users:

  • Customize orchestrators for your workflows
  • Add customer/project-specific contexts
  • Create reusable offline script templates
  • Build runbook library

🐛 Troubleshooting

Issue: Orchestrator not launching specialists

  • Check that specialist modes are imported into RooCode
  • Verify specialist slug matches what orchestrator calls

Issue: Offline script not working

  • Ensure script has execute permissions: chmod +x script.sh
  • Check device CLI access (SSH, console)
  • Verify commands work manually first

Issue: Log analysis incomplete

  • Provide complete log file (don't truncate)
  • Include timestamps in logs
  • Paste logs in code blocks for proper formatting

📚 Resources

RooCode Documentation:

Network Engineering Contexts:

  • See contexts/ folder for protocol references
  • CUCM, ISE, SIP, OSPF, BGP documentation included

Related Systems:


🤝 Contributing

To add new specialists or orchestrators:

  1. Follow existing YAML structure
  2. Include offline capability where applicable
  3. Add comprehensive customInstructions
  4. Test with real scenarios
  5. Document in README

🎉 What Makes This Different

vs Manual Troubleshooting:

  • Automated specialist coordination
  • Comprehensive logging
  • Reusable runbooks
  • Offline capability

vs GitHub Copilot Chat Modes:

  • Orchestration (auto-launches specialists)
  • Parallel analysis (multiple specialists simultaneously)
  • Result aggregation
  • Offline script generation

vs Claude Code Agents:

  • Affordable (RooCode free + Copilot $10/mo)
  • Network engineering focused
  • Customer/project organization
  • Offline workflows built-in

Next: See INDEX.md for quick navigation or OFFLINE_MODE_GUIDE.md for detailed offline workflows.

Status: Phase 5 Complete ✅

  • ✅ Phase 1: Network Orchestrator + README + Templates
  • ✅ Phase 2: VoIP & Security Orchestrators + 5 Troubleshooting Specialists + Context Files
  • ✅ Phase 3: 3 Architect Specialists (Network, VoIP, Security Architecture Design)
  • ✅ Phase 4: 3 Implementation Specialists (Network, VoIP, Security Engineers)
  • ✅ Phase 5: AWS Cloud System (1 Orchestrator + 9 Specialists + AWS Context)

What's Included:

Network & Infrastructure (Phases 1-4)

  • 3 Orchestrators: Network, VoIP, Security (with offline capability)
  • 11 Specialists:
    • Troubleshooting (5): Network, VoIP, ISE, Packet Analyzer, Authentication Analyzer
    • Architects (3): Network Architect, VoIP Architect, Security Architect
    • Implementation (3): Network Engineer, VoIP Engineer, Security Engineer
  • 7 Context Files: ISE, Routing (OSPF/BGP/EIGRP), CUCM, SBC, SIP, AWS Connect, general README

AWS Cloud & DevOps (Phase 5)

  • 1 Orchestrator: AWS Cloud Orchestrator (Lambda, DynamoDB, AI services coordination)
  • 9 Specialists:
    • Troubleshooting (4): Lambda, Database (DynamoDB), Integration (API Gateway/Step Functions/EventBridge), AI Services (Bedrock/Lex)
    • Architects (3): Serverless Architect, Contact Center Architect, AI Solutions Architect
    • DevOps (2): Cloud Engineer (IaC/CI/CD), Cost Optimizer
  • 1 Context File: AWS Services Reference (Lambda, DynamoDB, S3, API Gateway, Bedrock, IAM)

Total System: 4 Orchestrators + 20 Specialists + 8 Context Files

Import Options:

Ready to use! Import for complete network engineering, cloud architecture, and DevOps workflows. 🚀

About

No description, website, or topics provided.

Resources

License

Contributing

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published