The Antidote network emulator, part of the Network Reliability Engineering project, offers a web interface that presents network emulation scenarios to users as documented lessons. Each lesson is presented in a window running Jupyter Notebooks and contains commands that the user can click on to run them on the virtual nodes in the network emulation scenario.
The NRE Labs developers intend for Antidote to be used as an educational tool. Its lesson-focused user interface supports students’ learning progress. This post is a tutorial showing how to create and test two simple, but different, Antidote lessons.
Lab documentation
At the time I wrote this post, the Antidote documentation does not provide enough practical information about how to create new Antidote labs. However, useful information is spread around in a few different locations, which I list below:
- Read the documentation about Lesson Endpoints
- The NRE Labs blog and videos on the NRE Labs Community Resources page provide some useful information about building labs for Antidote
- The Tips and FAQs Page that includes useful information about building lessons
- Read the post on the NRE Labs blog about how NRE Labs implements curriculum as code
- You can also reverse-engineer existing lab lessons
- Look at the source code to see the allowable values for attributes in the lesson files
Warning: Fast moving project!
Antidote is under active development. Its configuration procedures and operation may change significantly from one week to the next. If the procedures in this post don’t work, it is likely that the developers have changed some functionality.
For example, as I write this post, the developers are working on a change to the way nodes are defined in the lesson definition file. A longer-term view of the development plan is available in the Antidote development roadmap, as presented at Interop 2019.
Resume Antidote
I assume you previously installed and started Antidote, as described in my previous blog post about installing the Network Reliability Engineering Labs Antidote network emulator. Resume Antidote with the command shown below:
$ cd ~/antidote-selfmedicate
$ ./selfmedicate.sh resume
Open a web browser and go to the URL http://antidote-local:30001. You will see the Antidote web interface. Click on the Find Lesson Content button, as shown below:
If you followed the procedure from my previous post and also downloaded the nrelabs-curriculum files from the NRE Labs GitHub repository, you should see three categories in the lessons catalog, with lessons listed under each one.
Clicking on a lesson starts it. I showed an example of running an existing lesson in my previous post.
Explore the curriculum directory
NRE Labs creates network emulation scenarios — called lessons — based on text files and images published in a lesson directory. Each lesson is in its own directory.
Have a look at how the NRE Labs lessons are organized in the nrelabs-curriculum/lessons directory. List its contents. See there are three more subdirectories.
$ cd ~/nrelabs-curriculum/lessons
$ ls
fundamentals tools workflows
As you can see, the NRE Labs authors have categorized the lessons as fundamentals, tools, or workflows. These match the categories displayed on the Antidote web interface. When creating new lessons, you’ll have to use one of these directories. For now, explore an existing lesson.
Go to the fundamentals directory and explore the file structure of the lesson directories.
$ cd fundamentals
$ ls
lesson-14-yaml lesson-17-git lesson-22-python
lesson-16-jinja lesson-19-restapis lesson-23-linux
$ cd lesson-17-git
$ ls
lesson.meta.yaml stage1
See that the file that defines the lab topology for each lesson is named lesson.meta.yaml. You should also see one or more stage subdirectories, each of which contains a Markdown file named guide.md and may also include other subdirectories and files, such as node configuration files. Each stage changes the configuration of devices in the lab and builds a new web page that helps students learn about and interact with those devices.
For example, you can see the file structure of the YAML lab in the directory lesson-17-git:
$ tree lesson-17-git/
lesson-17-git/
├── lesson.meta.yaml
└── stage1
└── guide.md
1 directory, 2 files
Create a simple lesson
We’ll start by creating a very simple lesson that starts just one node — a container running Linux — and helps the student to run a few commands on it.
Choose the category directory in which you will create the lesson and navigate to it. In my case, I will create a new lesson directory in the fundamentals directory.
$ cd ~/nrelabs-curriculum/lessons/fundamentals
$ mkdir lesson-100-frr
$ cd lesson-100-frr
Remember that every lesson has, at a minimimum, a lesson definition file named lesson.meta.yaml and one or more lesson stage directories, each containing a Markdown file named guide.md.
Lesson definition file
Create and edit a lesson.meta.yaml file for the lesson.
$ nano lesson.meta.yaml
In this file, specify the network topology and the stages that compose the lesson. Use the YAML format when editing this file. The simplest lesson file you could create is something like below:
---
lessonName: Introduction to Lessons
lessonId: 100
category: fundamentals
tier: local
description: Demonstrate how to build a lesson in Network Reliability Labs Antidote Selfmedicate
slug: FRR
utilities:
- name: server1
image: antidotelabs/utility
stages:
- id: 1
description: Create sample lab definition file
Pay attention to the indentation of the YAML file text. Information relating to a node must be indented further than its parent node.
The Antidote documentation lists some of the data elements that make up a lesson definition. The mandatory information that must be included in a lesson definition file is:
- Lesson name
- Lesson number (ID)
- Tier. Must be one of three values:
- local, ptr, or prod
- Catergory. Must be one of three values:
- fundamentals, tools, or workflows
- Description
- Slug
- At least one node. May be one or more of the following types, with name and image (in Docker Hub format):
- utilities, devices, or blackboxes
- At least one stage, with a stage number and description
More elements may be added, such as tags, connections, lesson diagrams, videos, prerequisites, and more. I will cover some of these additional elements in the second lesson example, further below.
Save the lesson definition file and close the editor.
Lesson stages
Next, create one, or more, stages for the lab. Create a subdirectory for the each stage of the lab:
$ mkdir stage1
$ cd stage1
Then, create a guide.md file in the stage directory that will display some instructions for the lab.
$ nano guide.md
The file is in Markdown format, with some embedded HTML tags for the run buttons. In this case, I’ll keep the lesson definition very simple, as shown below.
# Introduction to Lessons
## Part 1 - The basic lessons file
Welcome to "Introduction to Lessons". This is a Markdown file so it is easy to create and edit.
## Part 2 - Running commands in devices
You can run commands the devices you set up in the lab. Set up the commands (separated by line feeds) in between the code tics, as shown below. The HTML below the code runs it in the specified lab node.
```
hostname
ls
pwd
```
<button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('server1', this)">Run this snippet</button>
### Part 2.1
We can have subsections in each part. See in the code above where we run it in the node named "server1"?
As you can see above, the Antidote lesson allows you to run code listed in the guide.md file on the network nodes running in the lab. The file includes snippets of HTML that create run buttons that, when pushed, tell Antidote to run the commands (or code) on a specified node in the lab..
You can see how Antidote makes it easy to create lessons and to separate the lessons into multiple stages. If you want to re-use the images that already come bundled with Antidote, such as the Utility image and the VQFX image, you can create lessons just by creating new directories and editing a few text files.
Lesson validation
Run the syrctl validate command to validate the lesson definition and report any errors. See the Antidote Syringe documentation for more details about syrctl.
Currently, the NRE Labs developers developers suggest you pull the latest Syringe container from the antidotelabs repository on Docker Hub and run the syrctl validate command in that container. ((When NRE Labs development activity stabilizes, you would install the syrctl binary on your Linux system. You would just download the syringe-darwin-amd64.tar.gz archive from the NRE Labs Syringe repository on GitHub, extract the syrctl binary from the archive, make it executable, and copy it to a folder on your path, such as /usr/local/bin/. However, currently, the NRE Labs development team is actively updating the Antidote project, curriculum files, and the Syringe software. They do not re-compile a Syringe binary until they prepare an official release. Because we are cloning the Antidote and curriculum files from the NRE Lab projects master branch, we need to get the latest syrctl version, to be compatible. The latest version is available in the Syringe container.)) I installed the nrelabs-curriculum directory in my home directory so I will use the path ~/nrelabs-curriculum in the command below.
$ docker run \
-v ~/nrelabs-curriculum:/antidote \
antidotelabs/syringe \
syrctl validate /antidote
You will see a line of output for every lesson in the nrelabs-curriculum directory. The line corresponding with the lesson we created looks like below:
time="2019-05-16T23:40:18Z" level=info msg="Successfully imported lesson 100: Introduction to Lessons --- BLACKBOX: 0, IFR: 0, UTILITY: 1, DEVICE: 0, CONNECTIONS: 0"
You can see the lesson passed. Is has lesson ID 100 and it has one Utility node. If you see an error, the message should provide enough information for you to fix it.
Reload the curriculum
Run the reload command to copy the contents of the nrelabs-curriculum directory into the appropriate directory on the Minikube VM, as shown below:
$ cd ~/antidote-selfmedicate
$ ./selfmedicate.sh reload
Go back to the Antidote web interface at http://antidote-local:30001/advisor/index.html and refresh the page. You should see a new lesson named Introduction to Lessons in the Fundamentals section, as shown below:
Add more stages
If you plan to submit lessons to NRE Labs, the developers recommend you split lessons up into stages so each stage takes less than five minutes to complete. To create another stage for our simple lesson, update the lesson definition file, lesson.meta.yaml, to add another stage. Then create a directory named stage2 and add a new guide.md file in it.
For example, I update the Introduction to Lessons lesson definition file to add a new stage:
$ cd ~/nrelabs-curriculum/lessons/fundamentals/lesson-100-intro
$ nano lesson.meta.yaml
Add a second stage so the stages section of the file looks like below:
stages:
- id: 1
description: Create sample lab definition file
- id: 2
description: Get the IP address of the node's interfaces
Save the file. Then, create a new stage directory:
$ mkdir stage2
$ cd stage2
Then, create a guide.md file in the stage directory that will display some instructions for the lab.
$ nano guide.md
The file is in Markdown format, with some embedded HTML tags for the run buttons. In this case, I’ll keep the lesson definition very simple, as shown below.
# Adding another stage
## Part 3 - Get the IP addresses
Get the IP addresses of the management interface on *server1*:
```
ip addr show eth0
```
<button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('server1', this)">Run this snippet</button>
You should see text that looks like the following:
```
23: eth0@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UP group default
link/ether 2e:5a:4a:a3:15:80 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.32.0.7/12 brd 10.47.255.255 scope global eth0
valid_lft forever preferred_lft forever
```
Save the file. Then, validate and reload the curriculum into the Antidote VM:
$ docker run \
-v ~/nrelabs-curriculum:/antidote \
antidotelabs/syringe \
syrctl validate /antidote
Go back to the lesson catalog in the web interface and refresh the page. Click on Introduction to Lessons and then select the second stage from the drop-down menu at the top left of the page.
You can see the menu uses the stage description you entered in the lesson definition file. You now have two stages.
You may continue to add new stages. You can see how you can build lessons one piece at a time. You may continue to add stages until you have a complete lesson.
Create a complex network lab lesson
Previously, I showed how to create the lesson definition file and the student guide for each stage of a simple lab that uses one node. Next, I will show how use the connections and devices lab endpoints to build a more complex lab topology consisting of three nodes connected together.
Currently, Antidote checks to see if we have a Device lab endpoint defined in the lab definition file. Antidote will only make connections from Device endpoint to other endpoints. For example: At the time I wrote this post, Antidote can connect a Device endpoint to another Device endpoint or to other endpoints like the Utility endpoint, but it cannot connect two Utility endpoints together.
The Device enpoint requires a valid configuration file and, currently, Antidote only supports NAPALM for configuration. Until this is changed, device endpoints can only be Cisco, Arista, or Juniper VMs because other routers, including open-source routers, do not support NAPALM.
The Antidote developers intend to change this is a future release to give more flexibilty to lesson developers. For now, to give you an example of how you can create a lab with multiple interconnected nodes, I will use the built-in VQFX container that comes with Antidote.
Create a lesson directory
As we did in the simple example, above, create a new directory for the lesson. In this case, I will create the new lesson in the fundamentals folder.
$ cd ~/nrelabs-curriculum/lessons/fundamentals/
$ mkir lesson-200-cons
Plan the lab topology
First, decide on the lab topology. The only limit you have is the amount of CPU power and memory on the system running Antidote. In my case, I have a low-powered laptop so, I will create a topology with just one VQFX node and two Utility nodes. It will look like the diagram below.
This is a good opportunity to test how the Lab Diagram feature works in Antidote. Create a lab diagram using your favorite image tool and save it as a PNG file in the lesson directory.
Antidote will not read the lesson diagram from a local directory on your PC. You must place your lesson diagram image on a web server. I chose to store the lesson diagram as a GitHub Gist at the following URL:
https://gist.githubusercontent.com/blinklet/85611bf2b2ce09699f08848924c56b4e/raw/56f621885d018b8e29f954e337cf855f458a8396/lessondiagram.png
If you are planning to contribute a lesson to NRE Labs, then you probably are working from a fork of the nrelabs-curriculum repo so you can store your image in the lesson folder in the repo and use its raw GitHub URL.
Reusing existing labs
Since lesson files are just text files, it’s easy to “repurpose” the content from an existing lesson to build a new lesson. In this case, since I don’t know Juniper VQFX switches or NAPALM, I am just going to take the configurations from the already-existing ToDD lesson, which has a similar network topology as my planned lesson. I will change the router’s interface names and IP addresses to make the lab work.
Create the lab definition file
Create a new lesson definition file in the lesson directory:
$ cd lesson-200-cons
$ nano lesson.meta.yaml
Enter the file contents as shown below. You can see we define the VQFX router node under the devices endpoint and we show how the nodes are connected under the connections endpoint.
---
lessonName: Lab connections
lessonId: 200
category: fundamentals
lessonDiagram: https://gist.githubusercontent.com/blinklet/85611bf2b2ce09699f08848924c56b4e/raw/56f621885d018b8e29f954e337cf855f458a8396/lessondiagram.png
tier: local
description: Connect three endpoints together.
slug: Networking
utilities:
- name: user1
image: antidotelabs/utility
- name: server1
image: antidotelabs/utility
devices:
- name: vqfx1
image: antidotelabs/vqfx:snap1
connections:
- a: user1
b: vqfx1
- a: vqfx1
b: server1
stages:
- id: 1
description: Test the link
When each connection is created, it uses the next available interface on the connected node and it uses them in the order listed in the lesson definition file. For example, in this example, we know that the first available interface on the VQFX router, em3, will connect to the net1 interface on node user1. The VQFX’s second interface, em4, connects to the net1 interface on server1.
You should also see we added the lesson diagram URL to the lesson definition file.
Create the first stage of the lesson
Create the first stage directory, stage1. In that directory, create the guide.md file:
$ mkdir stage1
$ cd stage1
$ nano guide.md
Edit the guide.md file and add the following contents:
# Three nodes connected together
## Test network links
The interfaces on the *vqfx1* node are configured according to the config file you created. The interfaces on *user1* and *server1* are configured by Antidote, and Antidote seems to choose addresses from the `10.10.0.0/16` subnet for each interface.
Test that we have an actual connection between *user1* and *vqfx1* by running the ping command:
```
ping -c 1 10.10.0.100
```
<button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('user1', this)">Run on user1</button>
## Check ARP caches
Did we really ping along the connection we created between *user1* and *vqfx1*? Check the ARP cache on *user1* to be sure:
```
ip neigh
```
<button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('user1', this)">Run on user1</button>
you should see that the IP address 10.10.0.100 is reachable from interface *net1*.
## Test the other link
Now, test the connection between *server1* and *vqfx1*. Use the ping command, again:
```
ping -c 1 10.10.0.101
```
<button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('server1', this)">Run on server1</button>
## Check the router's ARP chache
It should also succeed. If it fails, it is probably because Antidote assigned the *same* IP address to the *net1* interface on both *user1* and *server1*. You can check for that by checking the ARP chace on the *vqfx1* router
```
show arp
```
<button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('vqfx1', this)">Run on vqfx1</button>
Hopefully, you will not see duplicate IP addesses but, if you do, you know why the ping command failed from *server1*.
The Device configuration files
The device configurations are stored in a folder named configs in each stage directory. In this case, we have one device so, we’ll create only one configuration file.
The configuration file should have the same name as the device it configures and end with the .txt extension. In this example, the device is named vqfx1 so the file name will be vqfx1.txt.
Create the configs directory and the vqfx1.txt NAPALM configuration file:
$ mkdir configs
$ cd configs
$ nano vqfx1.txt
Enter in the XML data for the router configuration into the file. I list the entire contents of the file, copied from the ToDD lesson configuration file, with some modifications, in Appendix A, at the end of this post.
Files and scripts in nodes
If you want to make some scripts or other files available on the nodes in your lesson lab, just put the files in your lesson directory. The entire curriculum is mapped via volume to every container that runs in a lesson, so just by having those files in that directory, you’ll have access to them from any node.
To test this, we’ll add a file named test.txt to the lesson directory and see if we can access it when we run the lesson:
$ cd ~/nrelabs-curriculum/lessons/fundamentals/lesson-200-cons
$ echo "this is a test" > test.txt
When you reload the curriculum, the files in the lesson folder are copied to the /antidote folder on each Utility endpoint in the lab.
Validate the lesson
Verify that the lesson is correctly defined. Run the syrctl validate command:
$ docker run \
-v ~/nrelabs-curriculum:/antidote \
antidotelabs/syringe \
syrctl validate /antidote
In the output, the line for Lesson 200 looks like:
time="2019-05-28T01:25:53Z" level=info msg="Successfully imported lesson 200: Lab connections --- BLACKBOX: 0, IFR: 0, UTILITY: 2, DEVICE: 1, CONNECTIONS: 2"
Test the lesson
Run the lesson on Antidote. First, reload Antidote-selfmedicate:
$ cd ~/antidote-selfmedicate
$ ./selfmedicate.sh reload
Start the Antidote web interface at https://antidote-local:3000 and navigate to the lessons page. You should see the lesson named Lab connections at the bottom of the fundamentals section.
Click on the Lab connections lesson and wait about a minute for it to start up. You should see three nodes (tabs) in the terminal.
Click on the Lesson Diagram button and see if it displays the lesson diagram image correctly.
Click the Close diagram button to get back to the lesson lab.
Execute each of the code snippets in the lab’s Stage 1 and test that the lab can actually pass test traffic from user1 to vqfx1, along the connection you created between them.
You may encounter a problem if Antidote assigned the same IP address to the network interface on both user1 and server1. It seems to do that, sometimes. Also, Antidote assigns IP addresses on the Utility nodes from the same subnet, which means we cannot test end-to-end connectivity from user1 to server1. Unfortunately, we cannot manually configure the Utility node IP addresses because the Utility node’s antidote user does not have the privileges to configure IP interfaces.
Finally, see that the file we added to the lesson is available. On any lab node, go to the /antidote directory and list the contents. You should see the test.txt file there. For example:
antidote@server1:~$ cd /antidote
antidote@server1:/antidote$ ls
labdiagram.png lesson.meta.yaml stage1 test.txt
Observations about the complex lab
The lab example above is very limited because of the way Antidote handles lab endpoints. As I mentioned before, the Antidote developers plan to change the way labs work in Antidote to give lab developers more flexibility, so this situations should improve.
I observed the following things about the lab setup above:
- I confirmed that, if you allocate only 4096 GB of RAM to the AntidoteVM, the VQFX nodes will not work
- I tried the same setup on a larger machine and then discovered that the Utility nodes do not allow users to configure the IP addresses. You cannot configure the user as a sudo user.
- The interfaces created on user1 and server1 already have IP addresses configured – probably by Antidote, and sometimes, they get the same IP address which causes a problem.
For now, if you want to create a complex lab in Antidote, it looks like you’ll need to use the standard three-node VQFX topology used in lab lessons like Network Unit Testing with JSNAPY, and then just create labs stages that run commands on the Linux utility node.
Creating device images
Antidote allows you to create your own Docker images for lab endpoints such as devices and utilities. However, as mentioned above, Antidote currently will not support open-source devices. I cannot create open-source routers to test in Antidote until the developers change the way Antidote endpoints work.
In addition, no documentation is available for creating images, yet. ((If you find a docker image in a public repository that you want to try (and if it is compatible with Antidote), then you can create a new Dockerfile and start it with a FROM statement and use the Docker image you want to build off of. The main change you need to make is to set the userid and password. Any Docker image you create must have a userid of antidote and the password must be antidotepassword. These credentials are hard-coded into Antidote. See the Utility image dockerfile for an example of setting userid and password.)) To learn how to build new images for Antidote, I found some useful information about making Docker images for Antidote at the OpenJNPR-Container-vMX project and you can try to reverse-engineer the NRE Labs VQFX container.
Conclusion
I’ve gone as far as I can in using Antidote, until the developers add in support for configuring open-source devices and until I can create my own containers that enable sudo users. I also need to learn more about Docker before I can attempt to reverse-engineer how images are created for NRE Labs and Antidote.
I showed how to install Antidote on your own PC in my previous post, and I showed how to create simple labs using Antidote. I hope you see that is is fairly easy to build lessons in Antidote, especially if you use its built-in images.
I did not cover how to contribute labs to the Antidote project and to NRE Labs. You can see the Antidote documentation for information about contributing lessons to Antidote.
Appendix A: VQFX NAPALM config file
The full contents of the vqfx1.txt file for the lab we create in our second example, above. This is a copy of the VQFX config in the ToDD lab. Actually, vqfx1 in any NRE Lab lesson seems to be configured the same way.
I modified the interface names and the IP addresses to match what Antidote automatically configures on the Utility nodes.
<configuration operation="replace">
<version>15.1X53-D60.4</version>
<system>
<host-name>vqfx1</host-name>
<root-authentication>
<encrypted-password>$1$mlo32jo6$BOMVhmtORai2Kr24wRCCv1</encrypted-password>
<ssh-rsa>
<name>ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQ== vagrant insecure public key</name>
</ssh-rsa>
</root-authentication>
<login>
<user>
<name>antidote</name>
<class>super-user</class>
<authentication>
<encrypted-password>$1$iH4TNedH$3RKJbtDRO.N4Ua8B6LL/v/</encrypted-password>
</authentication>
</user>
<password>
<change-type>set-transitions</change-type>
<minimum-changes>0</minimum-changes>
</password>
</login>
<services>
<ssh>
<root-login>allow</root-login>
</ssh>
<netconf>
<ssh>
</ssh>
<rfc-compliant/>
</netconf>
<rest>
<http>
<port>8080</port>
</http>
<enable-explorer/>
</rest>
</services>
<syslog>
<user>
<name>*</name>
<contents>
<name>any</name>
<emergency/>
</contents>
</user>
<file>
<name>messages</name>
<contents>
<name>any</name>
<notice/>
</contents>
<contents>
<name>authorization</name>
<info/>
</contents>
</file>
<file>
<name>interactive-commands</name>
<contents>
<name>interactive-commands</name>
<any/>
</contents>
</file>
</syslog>
<extensions>
<providers>
<name>juniper</name>
<license-type>
<name>juniper</name>
<deployment-scope>commercial</deployment-scope>
</license-type>
</providers>
<providers>
<name>chef</name>
<license-type>
<name>juniper</name>
<deployment-scope>commercial</deployment-scope>
</license-type>
</providers>
</extensions>
</system>
<interfaces operation="replace">
<interface>
<name>em0</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>{{ mgmt_addr }}</name>
</address>
</inet>
</family>
</unit>
</interface>
<interface>
<name>em3</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>10.10.0.100/16</name>
</address>
</inet>
</family>
</unit>
</interface>
<interface>
<name>em4</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>10.10.0.101/16</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
<forwarding-options>
<storm-control-profiles>
<name>default</name>
<all>
</all>
</storm-control-profiles>
</forwarding-options>
<routing-options>
<autonomous-system>
<as-number>64001</as-number>
</autonomous-system>
</routing-options>
<protocols>
<igmp-snooping>
<vlan>
<name>default</name>
</vlan>
</igmp-snooping>
</protocols>
<vlans>
<vlan>
<name>default</name>
<vlan-id>1</vlan-id>
</vlan>
</vlans>
</configuration>