Created Started Cancelled
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.