mdd-base

Table of Contents

• Initial Setup
• Topology Creation
• Data Harvest
• Pipeline Deployment
• Data Validation
• Stateful Checks
  • Check File
  • Schema File
  • Configure Netflow (In Progress)
  • Run Pipeline
• Telemetry Collection

Stateful Checks

In this excercise, we will use the concept of “test driven development” to create a stateful check as part of our pipeline. Test driven development simply means you write your test before you make your change to your infrastructure. In this training we are working with Elastic to monitor our traffic flows and collect telemetry. Before we configure our network, lets write a test that will check that we have our netflow router configured correctly.

Check File

Once the validation step completes, your configuration is pushed into the test network and onto the simulated devices. After this occures, the “Check” phase of your pipeline uses PyATS to execute commands on specefic devices. The output of those commands can be compared to additional schemas.

First, we want to enable our netflow check by moving the “check-netflow.yml” file into your mdd-data directory. You can do this by opening your gitlab IDE and selecting rename on the check-netflow.yml file in the schemas/examples directory.

This file tells the pipeline to run the following command on your hq_pop router:

show flow exporter

You want to provide the destination address of your ELK stack host. If you didn’t take note of your telemetry host when setting up your environment, you can open your CML prod topology and console into the host to get the IP.

Here is an example:

mdd_tags:
  - hq_pop
mdd_checks:
  - name: Check Netflow Exporter
    command: 'show flow exporter'
    schema: 'pyats/show-flow-exporter.yml.j2'
    method: cli_parse
    check_vars:
      exporter_name: NetFlow-To-Collector
      destination_address: 192.133.185.152

Schema File

Once pyATS runs the commands on the specefied host, it will send the output back. Open up the schema files under schema/pyats to see our expected output.

show-flow-exporter.yml.j2

type: object
properties:
  flow_exporter_name:
    type: object
    properties:
      :
        type: object
        properties:
          transport_config:
            type: object
            properties:
              destination_ip_address:
                type: string
                enum: 

In this schema, the output needs to match the format with the variables defined in your check file.

Once you commit your change, the pipeline will run and you will see our hq-pop router failed the check because we haven’t actually configured our device yet.

Configure Netflow

Now that we have our test written to check for an approved netflow configuration, let’s create the config file. Navigate to your web IDE and open your mdd-data directory using the same branch created for your check file. Select “Create a new file” and title it “oc-netflow.yml”.

Copy and paste the following into the configuration file, replacing telemetry IP address with the IP address from your telemetry host:

---
mdd_tags:
  - hq_pop
mdd_data:
  mdd:openconfig:
    openconfig-system:system:
      openconfig-system-ext:services:
        openconfig-system-ext:netflow:
          openconfig-system-ext:flow-exporters:
            openconfig-system-ext:flow-exporter:
              - openconfig-system-ext:name: NetFlow-To-Collector
                openconfig-system-ext:config:
                  openconfig-system-ext:name: NetFlow-To-Collector
                  openconfig-system-ext:description: Netflow Collector
                  openconfig-system-ext:collector-address: Telemetry IP address
                  openconfig-system-ext:collector-vrf: Mgmt-intf

The “mdd_tags” field at the top of the config denotes that we only want this configuration applied to our HQ Pop router.

Run Pipeline

Once you implement your changes, commit to your existing branch. You will end up with a successful CI run because our hq-pop router now has the correct netflow configuration applied.