Some quirks in our Interface Classification settings screen made it more tedious than it should be to create and test rules. For example, a new interface classification rule being created was automatically sent to the bottom of the stack. Therefore, when testing the rule at creation time, it was evaluated before all the already-present rules.
The only way to test the effects of a rule being created was to save it, re-locate it within the stack, open it again, and see if the rule placement change fixed it.

We are adding new capabilities that alleviate this inconvenience, read on !

---

Interface Classification Refresher

First off, let's go back to how Interface Classification works: upon SNMP polling (frequency varies based on your device settings), the classification engine goes through your updated interfaces and runs them through the Rules stack. To do so, it runs every interface one by one through the stack of rules. Each interface is run consecutively through the stack of rules in the order which they are defined in the Interface Classification screen – starting with Kentik-managed rules first, and then on to each rule from top to bottom.
Each interface exits the evaluation loop of the stack upon first match of the IF clause, and applies the THEN action defined by the rule to classify: Connectivity Type, Network Boundary (inherited from Connectivity Type) and Provider if defined. Once the THEN action is applied, the algorithm moves on to the next interface... and so on.
An interface that goes through the list without match stays categorized as "unclassified".

When creating a rule, users are able to test it from the creation modal to make sure the resulting classification is as expected, allowing the user to see the number of interface matches per device and zero-in on a specific device to inspect the results of the classification action.

The main usability issue came when users were creating a new rule: the rule gets automatically created at the bottom of the stack and hitting the "[Test Rule]" button doesn't offer any choice of locating the rule elsewhere in the stack – the only way to do so was until now to save the rule, go back to the stack, move it, open it and test again in with the new position. This is the part that we just improved.

Adding Rules Mid-Stack

When hovering on any of the rules in the stack, users will now see + signs above and below it. These icons allow the user to create a rule Before or After the one currently hovered. Additionally the Rule creation and test context will honor this desired position.

Upon clicking any of these + icons the rule editor will now be aware which position the rule is being created at in the stack
Users will also be able to select other standard positions in this new drop-down, such as "Move to Top" and "Move to Bottom"

Hitting [Test Rule] will now proceed with testing this new rule given the position it now has in the stack, instead of the default "Bottom" position it used to have.

But wait, there's more

While we're at it, we added a few more niceties:

• When clicking the top right "Add Rule" button, the editor modal will also contain the same previously shown drop-down to select where in the stack to create and test the rule
• The kebab menu at the right of every rule now contains two new options to directly relocate a rule at the Top or Bottom – we all know how frustrating it can be to drag elements on a web page after or below the fold.