Routing testing scenarious

Since v4.2 MikroTik RouterOS has a automated routing testing system. The system uses plain text files in a specific format as test scenario description files. These files describe configuration to be tested, and they can be useful as router configuration examples, even if you don't have access to a testing system.

These scenarios can be accessed here.

All these configuration examples are automatically verified and known to be working with latest RouterOS version.

Here is an example test script with comments to help you to understand the format:

// Every test file starts with a short description of the test (this is a comment, by the way)
desc "This test does this and that";

// Enumerate the routers participating in test.
// (any names can be given, but in others tests usually only simple letters A, B, C, etc., are used).
router Router1, Router2;
router Router3;

// Enumerate links between routers. The links are bidirectional.
link Router1 Router2;
link Router2 Router3;

//
// The next section is more interesting.
// It describes what configuration to put on the routers in the simulated network. That is the only configuration
// the routers under test will have. Also, commands in this configuration use the same syntax as real RouterOS
// console commands, so this configuration can be simply copy-pasted in console on a real RouterOS system,
// provided the interface names are correct.
//
router Router1 {
    ip address add address=1.1.1.1/24 interface=Router1_Router2;
    ip route add dst-address=9.9.9.1/32 gateway=1.1.1.2;
}

router Router2 {
    ip address add address=1.1.1.2/24 interface=Router2_Router1;
    ip address add address=2.2.2.2/24 interface=Router2_Router3;
    ip route add dst-address=9.9.9.1/32 gateway=2.2.2.3;
}

router Router3 {
    ip address add address=2.2.2.3/24 interface=Router3_Router2;
    interface bridge add name=lobridge;
    ip address add address=9.9.9.1/32 interface=lobridge;
}

//
// The last section describe so-called events.
// Event description format:
// * starts with "at";
// * time value follows - specifies when the even will "happen"
// * event type follows;
// * optional and mandatory parameters follow.
// The parameters are:
// * desc - description (optional)
// * router - on which router to run the event (mandatory)
// * link - on which interface  to run the event (for packet-sniff and packet-send events)
// * other parameters.
//

// this is configuration checking event.
at 1.0 config-check desc="check that route is active on router 1" router=Router1
   where="ip route print dst-address=9.9.9.1/32 active=yes";

// this is configuration changing event.
at 1.5 config-change desc="adding a new route on router 1" router=Router1
   set="ip route add dst-address=0.0.0.0/0 type=unreachable";

// this is packet sniffing event. it waits for a packet that matches the optional parameters specified.
at 2.0 packet-sniff desc="checking that router 3 is receiving packets from router 1" router=Router3
   duration=1.0 link=Router3_Router2 ip.srcaddr=1.1.1.1 ip.dstaddr=9.9.9.1 ip.dstport=10000;

// this is packet sending event. it send an UDP packet with specified parameters
at 2.5 packet-send router=Router1 dst-address=9.9.9.1 dst-port=10000;

// this is link changing event. it allows to e.g. change "Running" status on a particular interface.
at 3.0 link-change desc="simulating interface from router 1 to router 2 losing running bit"
   router=Router1 link=Router1_Router2 status=up;