Author: Michael Lucas

I needed to mass-configure MikroTik Routerboards. Each needed a very similar but not identical configuration: they would have a unique management IP, and a unique username and password for their VPN connection back to my employer’s headquarters. I don’t have time or desire to do this routine configuration myself, so I needed a method that would let a less technical person do the work.

You can back up and restore RouterOS configurations, but then I’d need to have the user do all sorts of pointy-clicky things to configure the device. Pointy-clicky is difficult to reliably reproduce. RouterOS also supports exporting the configuration as a script, but they warn that this script is not suitable for duplicating a system. I wound up using the export function, but modifying the resulting script to create a new configuration that could be loaded onto the new device.

All of this was tested with Routerboard 750s, running RouterOS 5.6. I used one device as a master, and a second to test loading the new configuration. I also created a list of hostnames, IP addresses, and VPN usernames and passwords. (My team will manage these devices remotely, so the user will never see the username and password. If I deployed more than a couple dozen boxes, I’d need a different auth scheme.)

First, make sure your Routerboard is in the default configuration. Reset to the factory defaults if necessary. Load the same version of RouterOS onto the new device as exists on your master device.

Log onto your master device. Configure it the way you want, and export the configuration.

admin@master> export file=cleanconfig
admin@master> file print
...
0 cleanconfig.rsc script 16 507 jan/02/1970 19:26:39
...


This file is the seed of my configuration script. copy it to your desktop. (The detail-oriented among you will note that my configuration should include “Set the system clock.” Feel free to stay after class and clean the blackboards as a reward.)

Unlike Cisco and its imitators, RouterOS isn’t modal. You don’t need to enter a configure mode to change the router. Instead, it has a hierarchical configuration method from the command line. For example, there’s an interface command, with an Ethernet subcommand. To work on the Ethernet interfaces, you would enter interface Ethernet. Starting a command with a leading slash tells RouterOS to go back to the root. Most of the actual commands within this level are fairly self-explanatory to anyone experienced with routers.

/interface ethernet
set 0 arp=enabled auto-negotiation=yes disabled=no full-duplex=yes l2mtu=1526 \
mac-address=00:0C:42:5A:D9:50 mtu=1500 name=ether1-gateway speed=100Mbps


The set command tells RouterOS to change a setting for an existing item. The Ethernet interface already exists, you just need to give it a configuration. Alternately, the add command tells RouterOS to add something new to a configuration, such as an IP address.

/ip address
add address=192.168.88.1/24 comment="default configuration" disabled=no \
interface=ether2-master-local network=192.168.88.0


The system has no IP address, so you must add one.

If your script tries to add something that already exists, it will fail. For example, if your configuration already has a DHCP client setting, adding a new, identical one will terminate your script early. For my application, I had to remove the following from my master configuration.

/interface ethernet switch
/interface wireless security-profiles
/ip hotspot profile
/ip hotspot user profile
/ip ipsec proposal
/queue type
/routing bgp instance
/routing ospf instance
/routing ospf area
/system routerboard settings
/user group
/interface ethernet switch port
/interface l2tp-server server
/interface ovpn-server server
/interface sstp-server server
/interface wireless align
/interface wireless sniffer
/interface wireless snooper
/ip accounting
/ip accounting web-access
/ip dhcp-client
/ip dhcp-server config
/ip firewall connection-tracking
/ip firewall nat
/ip firewall service
/ip hotspot service-port
/ip neighbor discovery
/ip proxy
/ip socks
/ip ssh
/ip traffic-flow
/ip upnp
/mpls
/mpls interface
/mpls ldp
/port firmware
/ppp aaa
/queue interface
/radius incoming
/routing bfd interface
/routing mme
/routing ospf network
/routing rip
/store
/system console
/system health
/system resource irq
/system upgrade mirror
/system watchdog
/tool bandwidth-server
/tool email
/tool graphing
/tool mac-server
/tool mac-server ping
/tool sms

I then had some items that were different in my desired configuration and the default configuration. For example, the default 750 configuration has a firewall. I needed a firewall configuration that had no overlap with the default configuration. I added entries at the beginning of my script to remove that configuration. Similarly, I didn’t want the default IP address on this device.

/ip pool remove 0
/ip dhcp-server network remove 0
/ip dns static remove 0
/ip firewall filter remove 3
/ip firewall filter remove 2
/ip firewall filter remove 1
/ip firewall filter remove 0
/system logging remove 3
/system logging remove 2
/system logging remove 1
/system logging remove 0
/ip address remove 0

Other parts were more tricky. I wanted to configure the Ethernet interfaces, but I didn’t want to change the MAC address of the interfaces. I removed the mac-addr statements from the Ethernet interface configuration.

Now that I have a clean master script, I copy it to a separate file for the slave configuration script. In the copy, I change the IP address, hostname, username, and passwords as necessary.

I could then copy the script to my target machine and run

admin@target> import configscript.rsc
admin@target>

If the script doesn’t exit silently, it failed. Compare the target platform’s new configuration to your script to see where it failed, or run your script piecemeal to see where it crashes.

This was a good day’s work to learn how to do, but now I can hand my script to a junior tech and tell him to set up a couple dozen of these without bothering me. It’ll save me days of my time in the long run.

We have a network at the office without a firewall. Several of our technical folks run a whole mess of oddball network protocols, and maintaining a network firewall would take more manpower than it’s worth. We hand these techs a network cable and tell them to not let their gear get broken into, and then heckle them mercilessly when their server becomes a haven for Eastern European porn.

But the boss just got back from ClueCon, where he learned about a whole bunch of nasty exploits for older Cisco phones. These techs have VoIP phones on their desks. The decision was made to give the VoIP phones private addresses, overlaid on the public addresses. Yes, a firewall would be much better, but the maintenance overhead was too high in this situation.

Our VoIP phones have have MAC addresses in particular ranges. For example, a certain model of phone has MAC addresses beginning with 00:03:e3, others begin with 00:03:6b, and the third begin with 00:07:eb. If a device’s MAC address begins with one of these, it should get an address in 172.19.22.0/24. Otherwise, it should get an address in the public pool of 192.0.2.0/24. I’m using ISC dhcpd 3.1.

Start by breaking the devices into classes. Each class will have its own IP configuration. dhcpd has a pattern-matching feature that lets you match MAC addresses like this dhcpd.conf snippet.

class "sip-phone" {
match if (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:3:e3")
or (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:3:6b")
or (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:7:eb");
log (info, (binary-to-ascii (16,8,":",substring(hardware, 0, 4))));
}

class "other" {
match if not (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:3:e3")
and not (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:3:6b")
and not (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:7:eb");
log (info, (binary-to-ascii (16,8,":",substring(hardware, 0, 4))));
}

So, if a host has a hardware (MAC) address matching one of the patterns in the “sip-phone” class, it’ll be classified as a sip phone. If the hardware address doesn’t match anything in the sip-phone class, it’ll be classified as other.

What does that horrible string mean? Read dhcp-eval for details, but here’s the short and nasty version. Inside dhcpd, hardware addresses are binary. The binary-to-ascii function transforms a binary field into characters. The 16,8,: tells binary-to-ascii how to parse the binary data and where to separate the characters. The substring function takes a small portion of the ASCII string, specifically places 0 through 4. The characters are a hardware label (a 1 means Ethernet) followed by a colon, followed by the MAC address. So, to match all Ethernet MAC addresses starting with 00:03:e3, we must search for 01:00:03:e3, shown without the leading zeroes as 1:0:3:e3.

The Boolean logic around these comparisons groups the MAC addresses into classes by MAC.

The interesting bit here is the “log” statement. I wanted to see how the binary-to-string and the substring functions mauled the original MAC address. This LAN has a sufficiently small DHCP request rate that I was able to log the first sixteen bytes of each hardware identifier (including the leading 01: for Ethernet). This helped me figure out what the heck I was finding as I struggled through dhcp-eval(5). These logs were written to the DHCP server log. Remove them when you’re done testing.

In this dhcpd.conf snippet we assign the two classes separate address ranges.

shared-network techs {
subnet 172.19.22.0 netmask 255.255.255.0 {
option routers 172.19.22.1;
pool {
allow members of "sip-phone";
range 172.19.22.10 172.19.22.100;
next-server 192.0.2.130;
}
}

subnet 192.0.2.0 netmask 255.255.255.0 {
option routers 192.0.2.1;
pool {
allow members of "other";
range 192.0.2.100 192.0.2.200;
}
}
}

The DHCP server has an interface on this subnet. I added a private IP to the interface, so that it has both 192.0.2.0/24 and a 172.19.22.0/24 addresses. The shared-network statement tells the DHCP server to not be shocked when it sees both subnets on the local interface.

So far, this works.

UPDATE: To all the folks who say that this network could certainly be VLAN’d and firewalled. There is no technical reason this couldn’t happen. The problems are political. Political problems are just as real as technical problems.