When building a topology within Cisco VIRL it is a good idea to familiarise yourself with the file structure. If you’ve been exposed to XML and Cisco config files before (I would hope ALL of you would have) then nothing will look too scary.

I am going to take my INE v5 topology I’ve made for this post and look at the file format.

node name="R1" type="SIMPLE" subtype="IOSv" location="393,166"
 entry key="Auto-generate config" type="Boolean"false/entry
 entry key="config" type="String"

Here we see a node description for R1. Denoting a Simple connection with a subtype of IOSv this routed will not auto-generate a configuration from AutoNetKit and its configuration is a String (Oooh Yeah, I know what that is. My python programming is paying off!). Immediately below this item there is the output of a Cisco Router configuration file. One that we all know and are familiar with.

! Last configuration change at 10:37:23 UTC Sun Jul 6 2014
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
hostname R1

This is then repeated for each device within the topology. Whilst this loads and populates items on our canvas and associates a configuration with the node we still need to define our connections. After our string there is some additional information.

interface id="0" name="GigabitEthernet0/1"
 interface id="1" name="GigabitEthernet0/2"
 interface id="2" name="GigabitEthernet0/3"

We can see there is an interface ID mapping to a named interface. A named interface is familiar to the Cisco administrators whilst VIRL has no concept. This mapping is now an object which can be referenced. It is referenced here.

dst="/virl:topology/virl:node[1]/virl:interface[1]" src="/virl:topology/virl:node[3]/virl:interface[1]"
 dst="/virl:topology/virl:node[2]/virl:interface[1]" src="/virl:topology/virl:node[3]/virl:interface[2]"

If you look at the connection destinations you can see a basic structure in how everything is addressed. The VIRL topology references a node and the node has a number associated to it. This node number highlights which instance of IOS/NX-OS running within VIRL then denotes an interface number. Node 1 interface 1 to Node 3 Interface 1. The interface ID then corresponds with the named interface and you have a topology.

For reference – a multi-point connection network – or a dumb L2 segment simply appears like this:

node name="DMVPN" type="SEGMENT" location="653,296"
 node name="Network 1-4-6" type="SEGMENT" location="573,84"

With that you have been able to break down the basic anatomy of a .VIRL file. It is nice and neat and keeps everything together. There is GitHub integration into VIRL as well as sharing folders. Creating a topology and sharing with co-workers for peer-review or validation just got very easy!

One thought on “Breaking down a VIRL file

Leave a Reply

Your email address will not be published. Required fields are marked *