Follow these step-by-step instructions to set up automated device discovery in Slurp'it. This process ensures that new and existing devices on your network are accurately inventoried and visible for management.

1. Define Discovery Schedule:
   Set a recurring schedule for automatic discovery. Use cron-style timing to fit your operational hours.
   • Example: Every day at 3:00 AM (0 3 * * *).
2. Select Discovery Methods:
   Specify which protocols Slurp'it should use while scanning the network.
   • Common options include SNMPv2c for network devices and ICMP for basic reachability.
3. Provide Device Access Strings:
   List the read communities or credentials necessary for SNMP-based discovery to proceed securely.
   • Include multiple to cover different device groups.
4. Declare Network Ranges to Scan:
   Input the subnets Slurp'it should probe during each discovery cycle.
   • Keep the scope focused to reduce unnecessary traffic (e.g., 10.0.0.0/24).
5. Exclude Specific Devices (Optional):
   Identify IP addresses or subnets that should be intentionally skipped.
   • Useful for avoiding test or out-of-scope environments.
6. Apply and Verify:
   Save the configuration, initiate a manual discovery run, and review the discovered inventory to confirm accuracy.

Example Configuration (YAML):

discovery:
  schedule: "0 3 * * *" # Every day at 3:00 AM
  methods:
    - SNMPv2c
    - ICMP
  snmp_communities:
    - public
    - secure-read
  networks:
    - 10.0.0.0/24
    - 192.168.1.0/24
  exclude_devices:
    - 192.168.1.10

Best Practices:

• Limit scan frequencies to minimize network impact.
• Store sensitive discovery information in secure files or environment variables.
• Test discovery settings in a non-production environment prior to full rollout.

Follow these steps to streamline and automate the onboarding process for new network devices using Slurp'it. Proper onboarding ensures consistent device configuration, security compliance, and accurate inventory tagging.

1. Set Default Device Attributes:
   Define standard attributes such as device type, location, and owning team to simplify the onboarding process.
   • Example: Default type could be switch and location might be SA Data Center 1.
2. Assign Access Credentials:
   Specify the read and management credentials that Slurp'it will use to connect to devices.
   • Include SNMP community strings and SSH usernames along with paths to secure authentication files.
3. Apply Compliance Policies:
   Attach baseline compliance checks and policies that the device must meet upon onboarding.
   • For example, ensuring NTP configuration and syslog forwarding are enabled.
4. Customize Per Device or Group (Optional):
   Override or extend default settings when onboarding specific device types or for particular locations.
5. Validate and Commit:
   Review the configuration template, run a test onboarding if possible, then deploy to production.

Example Configuration (YAML):

device_onboarding:
  defaults:
    type: switch
    location: "SA Data Center 1"
    owner: network_team
  credentials:
    snmp_community: secure-read
    ssh_username: netadmin
    ssh_keyfile: /etc/slurpit/keys/sa-net-key
  compliance_policies:
    - baseline_security
    - ntp_configured
    - syslog_enabled

Best Practices:

• Ensure credentials are stored securely and access limited.
• Customize policies to reflect your organization's security requirements.
• Test onboarding workflows in a staging environment before production rollout.
• Maintain documentation for device roles and assigned owners.

Follow these steps to automate the backup of your critical network device configurations using Slurp'it. Regular backups protect against configuration loss and simplify recovery processes.

1. Schedule Backup Times:
   Define when backups should run automatically using cron-style scheduling.
   • Example: Weekly backups every Sunday at 2:00 AM (0 2 * * 0).
2. Select Target Devices:
   Specify if all devices or specific groups should be included in the backup routine.
3. Choose Backup Method:
   Define the protocol or method Slurp'it should use to retrieve device configs.
   • Common option: SSH-based backup for secure file transfer.
4. Configure Backup Storage:
   Set where the backup files will be stored and how they are managed.
   • Example: Use cloud object storage (e.g., S3) with the bucket named slurpit-backups.
   • Specify data region for compliance (e.g., us-west-2).
5. Retention Policies:
   Define how long backups are kept before being deleted to manage storage and compliance.
   • Example: Retain backups for 30 days.
6. Apply and Monitor:
   Save the configuration, enable the backup schedule, and monitor logs to ensure backups are running successfully.

Example Configuration (YAML):

config_backup:
  schedule: "0 2 * * 0" # Every Sunday at 2:00 AM
  devices:
    - all
  backup_method: ssh
  backup_storage:
    type: s3
    bucket: slurpit-backups
    region: us-west-2
  retention_days: 30

Best Practices:

• Encrypt backups at rest and in transit.
• Restrict access to backup storage locations.
• Periodically test backup restoration procedures.
• Keep backup schedules outside peak network hours to reduce impact.

Use this template to set up automated compliance auditing for your network environment in Slurp'it. Regular compliance checks support security best practices and ensure that all devices remain within policy guidelines.

1. Configure Audit Frequency:
   Set the interval for automatic compliance checks using cron-style syntax.
   • Example: Run audits every 6 hours (0 */6 * * *).
2. Define Compliance Rules:
   List the policies and configuration checks to enforce. Each rule should specify what to look for and its severity level.
   • Examples include verifying NTP settings or requiring password complexity.
3. Set Notification Preferences:
   Determine who gets notified and under which conditions (e.g., on failure).
   • Provide email recipients for audit alerts and specify if notifications are triggered only by failures.
4. Test and Apply:
   Review your configuration, run a manual audit if possible, and confirm that alerts and reports are received as expected.

Example Configuration (YAML):

compliance_audit:
  audit_interval: "0 */6 * * *" # Every 6 hours
  rules:
    - name: NTP Server Configured
      type: config_check
      match_regex: "^ntp server"
      severity: warning
    - name: Password Complexity
      type: config_check
      match_regex: "password complex"
      severity: critical
  notifications:
    email:
      to: netsec-alerts@company.com
      on_failure: true

Best Practices:

• Keep rule definitions up to date with organizational policy changes.
• Limit notification frequency to reduce alert fatigue.
• Test policies in a staging environment before enforcing them in production.
• Regularly review compliance reports to address issues proactively.

This section guides you through setting up API integration with Slurp'it to synchronize network data with third-party tools. Proper API integration helps automate workflows and maintain consistent data across systems.

1. Enable API Integration:
   Turn on the API integration feature within Slurp'it to allow external communication.
2. Configure Endpoints:
   Define the external services that will receive data from Slurp'it.
   • Provide the name and full URL for each endpoint.
   • Specify how often data should be synchronized (e.g., every hour).
3. Set Authentication Tokens:
   Reference the environment variables that securely store authentication tokens for each external API.
   • This ensures credentials remain confidential and easily managed.
4. Define HTTP Methods and Headers:
   Specify the HTTP method (e.g., POST, GET) and any necessary headers like authorization or content type.
5. Test Integration:
   Run initial tests to confirm data is syncing correctly and authentication is successful.
6. Monitor and Maintain:
   Regularly check logs and alerts for any issues and update tokens or endpoints as needed.

Example Configuration (YAML):

api_integration:
  enabled: true
  endpoints:
    - name: ServiceNow CMDB
      url: https://servicenow.company.com/api/network
      token_env_var: SERVICENOW_API_TOKEN
      sync_interval: 3600 # seconds
    - name: SIEM Ingest
      url: https://siem.company.com/ingest
      method: POST
      headers:
        Authorization: "Bearer ${SIEM_TOKEN}"

Best Practices:

• Store all sensitive tokens in environment variables or secure vaults.
• Use HTTPS URLs to ensure secure data transmission.
• Limit sync intervals based on data update frequency to balance load and freshness.
• Implement retry logic and error notifications for integration failures.

This section helps you set up custom polling tasks in Slurp'it to regularly collect specific metrics or states from your network devices. Custom polling extends monitoring beyond default parameters for tailored visibility.

1. Set Polling Interval:
   Specify how often Slurp'it should poll the target devices, defined in seconds.
   • Example: Every 5 minutes (300 seconds).
2. Define Polling Targets:
   List the devices to poll, identifying them by name and IP address.
3. Choose Polling Method:
   Specify the method to collect data from each device.
   • Options include executing a custom script or using SNMP queries.
4. Configure Script or SNMP Details:
   For script-based polling, provide the script location that performs the data retrieval.
   For SNMP, list the object identifiers (OIDs) to query.
5. Apply and Validate:
   Save the polling configuration, start the polling process, and verify the collected data for accuracy.

Example Configuration (YAML):

custom_polling:
  interval: 300 # 5 minutes
  targets:
    - name: CoreRouter
      ip: 10.0.0.1
      polling_method: script
      script_path: /opt/slurpit/scripts/core_router_health.py
    - name: EdgeFirewall
      ip: 192.168.1.254
      polling_method: snmp
      oids:
        - 1.3.6.1.2.1.1.5.0 # sysName
        - 1.3.6.1.2.1.25.3.3.1.2 # CPU Load

Best Practices:

• Keep polling intervals balanced to avoid network congestion or device overload.
• Ensure scripts have proper error handling and logging.
• Use SNMP community strings or credentials with minimum necessary privileges.
• Test custom polling procedures in a controlled environment before production deployment.