010b1950

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Check a configuration against the router's own export

The strongest check here, and the cheapest. A RouterOS that cannot compile
a command applies none of the file, so the question that decides whether a
deployment bricks a router is whether that router knows every word in it.
An export answers with authority no vm has: the router printed those
commands itself, which is proof it accepts them, whatever version it is
running. Ask for a verbose export and it prints every parameter at its
default too, which is what tells a name the router does not know from one
it merely has no use for.

So three new problems: a menu, a command or a parameter that no export of
this router mentions. A file that means to be new says so in a comment
above the line, [untried] and why, and an annotation that excuses nothing
or gives no reason is itself a problem, since that is how annotations stop
being read.

Two more come from the chassis, which until now only the vm read: an
interface name that is neither hardware nor anything the file creates, and
an index into /port past the last serial port this chassis has.

Four examples move out of caught-by-vmtest, because the cheap check now
finds them in milliseconds rather than after booting a router: an unknown
menu, hw-offload on a chassis that cannot offload, an interface that is
not there, and a serial port that is not there. Two of those were compile
errors, which are the ones that leave a reset router with nothing at all.
What is left for the vm is a bad value: it compiles or fails on its own
terms, and no list of the words a router knows can tell.

The vm test now says which RouterOS the router runs and which one it is
itself, and refuses outright to stand in for a router of another
architecture.