Manual:SimTest

Configuration Syntax Explained

Version definition

Version always should be defined at the beginning of the file.

Syntax:

version 1;

Description

Description is used to show detailed description of what this simulation do.

Syntax:

desc {
 ...
}

Include

Allows to include parts of configuration located in another files. For example include common host information or common network configuration.

Syntax:

#include "host.cfg"

include works only from 'tests' directory. So, for example, if file test.cfg is in 'tests/lala/ and 'host.cfg' is in the same dir, then include should be #include "lala/host.cfg"

Note: './' and '../' does not work

Host

Defines host login information, where tester application should log in and add virtual network.

Host should always be at the same broadcast network as tester, since ipv6 link-local addresses are used to connect to virtual guests from the tester.

Syntax:

host <name> {
    <param> <value>;
}

Host configuration allows following parameters:

Param	Description
desc (string)	Simple description, can be left blank
addr (ipv4 | ipv6)	IP/IPv6 address of the host
port (integer | string)	API port on the host
user (string)	Username used to login
pass (string)	Password used to login
bridge (string)	Name of the bridge where management interfaces of guests are added. This is needed for tester to be able to connect to the guest routers and apply configuration.

Network

Define all routers and links between routers in virtual network.

network <name> {
  <param> <value>;
  
  router <ref_name> {
    META {
        <api_commands>
    }
  }
}

Network configuration allows following parameters:

Param	Description
desc (string)	Simple description, can be left blank
host (string)	Which of the defined hosts to use
vlans (integer [0..1])	Whether to use vlans for link simulations instead of virtual interfaces. Vlans should be used in MetaROUTER mode, since metarouters has limited amount of available virtual ethernets
routers (list of router names separated by comma (R1, R2;))	Define all routers in virtual network. All routers are separated by comma
link (list of routers (R1 R2;))	Define links between routers. It is possible to define point to point and broadcast links. Link definition will also make an interface name for the guest interface. For example link R1 R2 will make point to point link between router with name R1 and router with name R2: on router R1 interface will be called R1_R2 on router R2 interface will be called R2_R1 Another example, link R1 R2 R3 will make broadcast network between three routers. Interfaces on routers will be named as follows: on R1 interface will be called R1_R2_R3 on R2 interface will be called R2_R1 on R3 interface will be called 'R3_R2

router scope allows to define two sub-scopes:

* META - this scope should contain configuration in API syntax which will be applied to the router.

* KVM - this scope should contain configuration in RouterOS CLI syntax which will be applied during KVM image creation process.

Simulation

Defines actual simulation process.

sim <name> {
  <param> <value>;

  events {
    ...
  }
}

Sim configuration allows following parameters:

Param	Description
desc (string)	Simple description, can be left blank
network (string)	Which network to use from all defined networks.

Simulation Events

Event scope defines all events during simulation in actual order.

Possible events:

print

Output to the screen;

 print "Hello World\n";

delay

Delay in seconds before moving to the next event.

 delay 4; 

wait

Pause simulation and timer until manually continued.

reboot

Reboot the router

reboot <router_name> ;

reconnect

Reconnect to the router, necessary after virtual router reboot

reconnect <router_name> ;

ping

Run the ping command and check the result. If received packet count < configured count, event returns failure.

ping <router_name> {
  <param> <value>;
  ...
}

Currently ping allows following parameters:

Param	Description
src (IP)	Used Source address of the ICMP packet
dst (IP)	Destination where to send ping.
count (integer)	Number of ping packets to send. NOTE: if count is not specified infinite loop will occur.
size (integer [64..1500])	Size of the packet
table (string)	Name of the routing table which will be used for nexthop lookup.
status (string)	Status returned at least on one response. If specified status is not found then event exits with failure.

For example:

ping "R1" {
	dst	10.5.101.1;
	src	10.5.101.21;
	count	1;
	size	64;
	table	main;
}

trace

Run the traceroute command and check the result. If recorded path is not the same as specified path, event returns failure.

trace <router_name> {
  <param> <value>;
  ...
}

Currently trace allows following parameters:

Param	Description
src (IP)	Used Source address of the ICMP packet
dst (IP)	Destination where to send ping.
size (integer [64..1500])	Size of the packet
table (string)	Name of the routing table which will be used for nexthop lookup.
path (string)	List of the hops in the path. Hops should be separated by comma (e.g. "1.1.1.1,2.2.2.2")

For example:

trace "R1" {
	dst	10.5.101.1;
	src	10.1.101.21;
	path	"1.1.1.1,2.2.2.10,10.5.101.1";
	size	64;
	table	main;
}

config_set

Add or modify configuration of the specified virtual router

config_set <router_name> {
  id {
    <API CMD>
  }
  cmd {
    <API CMD>
  }
}

Sometimes it is needed to get ID of the item which should be modify. In this case use id scope to get ID, which will be automatically set in cmd scope. If multiple IDs are returned then config is applied to all of them.

For example:

config_set "R2" {
	id {
		/ip/route/print
		?dst-address=0.0.0.0/0
		=.proplist=.id
	}
	cmd {
		/ip/route/set
 		=disabled=yes
	}
}

config_check

Check parameters on the specified virtual router. Scope can have multiple 'cmd' sections, if any of those fails event will return failure.

config_check <router_name> {
  cmd {
    <API CMD>
  }
  <param> <value>
}

Config check allows following parameters:

Param	Description
data (yes | no)	What to do if API command returns data. If not set then it is considered as data no; If set to 'yes', event will return failure if API command returns non empty data. If set to 'no', event will return failure if API command returns empty data.
status (inconclusive | failed | completed)	What status to set if event returns failure. inconclusive - something failed before actual test is possible. For example, BGP failed to establish connection in the test which should test routing filters. failed - actual test failed completed - test completed. If nothing failed, then 'completed' is always returned at the end of simulation.

Sample Configuration

host.cfg

version 1;

// host login information
host "default" {
	desc "Default host";
	addr "10.5.101.14";
	port "8728";
	user "admin";
	pass "";

	bridge "bypass";
} 

network_2_routers.cfg

/* Configuration template for two interconnected routers
*
*              R1 ---- R2 
*
*/

version 1;

#include "host.cfg"

network "2_router_network" {
	desc		"";
	host 		"default";
	
	vlans		0;

	routers 	R1, R2;

	link 		R1 R2;

	router "R1" {
		META {
			/ip/address/add
			=address=1.1.1.1/30
			=interface=R1_R2
		}
	}

	router "R2" {
		META {
			/ip/address/add
			=address=1.1.1.2/30
			=interface=R2_R1
		}
	}

}

bgp/001-auth.cfg

version 1;

desc {
+===================================================================
| BGP connection establishment with authentication
| 
+===================================================================
.
.Test setup creates a simple link between 2 routers
.
.                   
.              R1------R2
.
.  Simulator actions:
.	* Check if BGP connection is established
.	* Change to incorrect MD5 key
.	* Check if BGP connection is NOT established
.	* Change back to correct MD5 key
.	* Check if BGP connection is established
}

#include "network_2_routers.cfg"


sim "simple"{
	desc		"MD5 authentication test";
	network 	"2_router_network";

	events {
		print "Set initial config...\n";
		config_set "R1" {
			cmd {
				/routing/bgp/peer/add
				=name=R2
				=remote-address=1.1.1.2
				=remote-as=65530
				=tcp-md5-key=helloworld
			}
		}
		config_set "R2" {
			cmd {
				/routing/bgp/peer/add
				=name=R1
				=remote-address=1.1.1.1
				=remote-as=65530
				=tcp-md5-key=helloworld
			}
		}
		delay 7;

		print "Check if BGP session is established..\n";
		config_check "R1" {
			cmd {
				/routing/bgp/peer/print
				?state=established
				=.proplist=.id
			}
			status	inconclusive; 
		}

		print "Change MD5 key..\n";
		config_set "R1" {
			// id can be only one and should contain only one command
			id {
				/routing/bgp/peer/print
				?name=R2
				=.proplist=.id
			}
			cmd {
				/routing/bgp/peer/set
				=tcp-md5-key=lalala
			}
		}

		print "Waiting...\n";
		delay 3;

		print "Check if BGP session is NOT established..\n";
		config_check "R1" {
			cmd {
				/routing/bgp/peer/print
				?state=established
				=.proplist=.id
			}
			data	yes; // failure if returns any entries
			status	failed; 
		}


		print "Change MD5 key..\n";
		config_set "R1" {
			// id can be only one and should contain only one command
			id {
				/routing/bgp/peer/print
				?name=R2
				=.proplist=.id
			}
			cmd {
				/routing/bgp/peer/set
				=tcp-md5-key=helloworld
			}
		}

		print "Waiting...\n";
		delay 3;

		print "Check if BGP session is established..\n";
		config_check "R1" {
			cmd {
				/routing/bgp/peer/print
				?state=established
				=.proplist=.id
			}
			data	no;
			status	failed; 
		}

	}
}