Mocking your devices

What are mock devices and what are the use cases?

Mock devices in the context of pyATS are not real nodes but a recording of commands which emulate a real device. Clearly, a mock device doesn’t carry traffic or any stateful information. What you’re looking at is a frozen set of CLI output from a recording.

However, the folks at Cisco have done a really fantastic job because you could be almost fooled into thinking it’s a real device. This gives plenty of opportunity to prank your work colleagues by pretending they are real devices but of course that is not the intended use case 🙂

The real use case is help with your testing as you could record a failure scenario and the associated CLI commands and then play that back against your script. You could create recordings of your entire network and then use a pyATS script to login and retrieve information/run commands. It’s going to be far easier to do that then continually run tests against the live platforms. Also you can give a junior engineer the mock device instead of the real device since it’s completely safe to use. I think mock devices will become very important going forward as part of your testing regime. You can also use this for demos where you don’t want to rely on access to a real device.

What has really impressed me though is mock device module in pyATS. I’ve successfully mocked a Nokia 7750 as well as the usual Cisco platforms. I believe this works for any CLI based device since you can change the prompts to reflect the type of device. What you have is awesome tool at your disposal.

Tutorial on how to create a mocked device

Thankfully, this is a relatively easy process and the documentation on pyATS was sufficient but I will run through it and some of the quirks which I found.

Step 1:

• We need to create a recording from a real device

This is very easy to do, all you need is to add –record to your pyATS script or pyATS job file. You also need to specify the directory where the recording will take place. You may want to grab a long list of commands so make sure your script executes all the commands which you’re looking to capture.

python3 genie_script.py --record ./my_record_dir

Example script to run a few commands for the recording (change to suit):

# Import our libraries
from genie.conf import Genie




list_of_cmds=["show int", 
              "show run", 
              "show ip int brief", 
              "show ip interface",
              "show ip ospf interface"]

# Create a testbed object for the network
testbed = Genie.init("testbed_iosxe.yaml")




for device in testbed.devices:
    # Connect to the device
    testbed.devices[device].connect()
    for command in list_of_cmds:
        testbed.devices[device].execute(command)

Once the script has run the commands observe the directory which has now been created my_record_dir and this contains a pickle file or binary file which cannot be natively opened.

Step 2:

• Create a YAML file which will be our mocked device from the pickle file

The command below will create the YAML file which is used for the mocked device. Don’t worry this is easy trust me 🙂

–recorded-data This is the path to the recording file and note the filename is R1

–output This is the path to where you want the YAML file to be created

python3 -m unicon.playback.mock --recorded-data ./my_record_dir/R1 --output ./mock/R1.yaml

You should now have a R1.yaml created in the appropriate directory.

Step 3:

• Change the command prompt in the YAML file

There is a good reason for this as otherwise your device will end up with a generic prompt like router or switch. If you want it to look like the real prompt then all we have to do is open up the YAML file using an editor and scroll to the very bottom of the file and change it. Re-Save the YAML file afterwards.

You will find a line like this in the YAML file:

  prompt: switch#

Change it to the device hostname of your choice. It has to look the real deal of course and that generic switch prompt doesn’t cut it 🙂

  prompt: R1#

That’s it and now we can start using our mock device and we can do that in two ways:

mock_device_cli --os iosxe --mock_data_dir mock --state connect 

The first approach is directly from the command line where –mock_data_dir is the path to the YAML file with the recorded output. Note you specify the directory only and not the YAML file itself. use CTRL + D to exit the device but you will get the following when you run this:

Trying mock_device ...
Connected to mock_device.
Escape character is '^]'.

R1#show ?
% Invalid command 'show ?'
Valid commands:
 config term
 show int
 show ip int brief
 show ip interface
 show ip ospf interface
 show run
 show version
 term length 0
 term width 0
R1#

You can run all those commands obviously change the list of commands in the script to grab more of these. Note the syntax must match i.e. show ver will not work but show version should be just fine.

The second way is to use a testbed.yaml file and call the mock device like a regular device. Example testbed.yaml extract below:

testbed:
    name: My Fake Testbed

devices:
    R1:
        type: 'router'
        os: 'iosxe'
        alias: 'uut'
        connections:
            console:
                command: mock_device_cli --os ios --mock_data_dir my_record_dir/R1  --state execute
                protocol: mock

You can call it just like a regular Testbed.yaml entry but of course the device is your fake one and not the real one. When I tried this for the first time it bought a smile as you now have a device which you can play around with to your hearts content.