Technical Whitepaper

ARUBA NETEDIT
CONFORMANCE AND
BEST PRACTICES

Aruba NetEdit Series

 Technical Whitepaper
NetEdit Conformance and Best Practicest

Contents
REVISION HISTORY ....................................................................................................................................3
Introduction ..................................................................................................................................................4
Built-in Conformance Tests .............................................................................................................................................. 4
Conformance Tests Best Practices ..............................................................................................................8
Interface description ......................................................................................................................................................... 8
SNMP ............................................................................................................................................................................... 9
Management Access restriction ..................................................................................................................................... 10
IP helper ......................................................................................................................................................................... 12
VSX ................................................................................................................................................................................ 13
Banner ............................................................................................................................................................................ 14
NTP ................................................................................................................................................................................ 15
OSPF .............................................................................................................................................................................. 16
BGP ................................................................................................................................................................................ 17
Physical Security ............................................................................................................................................................ 18
Miscellaneous ................................................................................................................................................................. 19
Other Conformance Tests ..........................................................................................................................20
Hostname ....................................................................................................................................................................... 20
L3 interface numbering ................................................................................................................................................... 21
Routed Only Port ............................................................................................................................................................ 22
Appendix....................................................................................................................................................23
Regex Numeric Range Generator .................................................................................................................................. 23
NetEdit Conformance Help ............................................................................................................................................. 23

2
 Technical Whitepaper
NetEdit Conformance and Best Practicest

REVISION HISTORY

The following table lists the revisions of this document:

Revision Date Change Description

1.0 May 2019 Initial Release

1.1 May 2019 Help text enhancement, typos correction.

1.2 Aug 2021 Updated Template

3
 Technical Whitepaper
NetEdit Conformance and Best Practicest

INTRODUCTION

This guide provides examples of Conformance test rules that can be enabled on NetEdit to check the compliance of the network
nodes against industry Best Practices or custom Best Practices.

NetEdit runs conformance test in real-time against stored configuration. As soon as the modified conformance test is enabled, the
result of the test is available through the configuration Editor or through the dashboard (Configuration Policy Violations).

Would the running configuration of the device be modified through another mechanism than the NetEdit configuration Editor, the
NetEdit user can see the compliance after a delay of 5 minutes (maximum), which corresponds to the regular NetEdit scan of the
AOS-CX nodes (during scan, NetEdit collects switch configuration among others).

All these examples have to be adjusted to match in-house best practices.

Please note:

• The filter in the Conformance rule has great importance. If no filter is used, all devices must comply with the rule defined in the
Commands section. If filter is used, only switches matching the filter condition have to comply. Devices not matching the filter are
not verified against the said rule. The filter query applies to the current state of the switch, not to the candidate configuration. For
instance, the VSX test filters on 'role', but if the 'role' keyword is removed in a candidate configuration, then the conformance test
will still be applied to the candidate until it is deployed to the switch. So, it is not recommended to use “running-configuration
filter”. Instead, filter such as custom attributes could be very useful (example: production versus engineering node).
• Severity should be selected according to operational enforcement rules.

Built-in Conformance Tests

These are the built-in conformance tests coming by default with NetEdit:

4
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

Only “Requirements” conformance test is enabled as it is used to make sure that NetEdit can properly manage the devices.

# REST must be enabled

https-server vrf .*

# SSH must be enabled with password authentication

ssh server vrf .*

no ssh password-authentication MUST NOT EXIST

# At least one admin user must exist

user MUST MATCH (.* group administrators .*|admin .*)

5
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

Common Criteria is proposed but not enabled:

6
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

Secure Remote Logging as well:

7
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

CONFORMANCE TESTS BEST PRACTICES

Here is a list of proposed Best Practice conformance rules.

Interface description

Name: interface description

Description: all physical interfaces, LAG interfaces, VSX LAG interfaces, that are active (“no shutdown”), must have a description.

Severity: WARNING

Device Filter: None (check all devices)

Commands:

WITHIN interface 1/(\d+)/(\d+) IF no shutdown THEN description MUST EXIST

WITHIN interface lag (\d+) multi-chassis IF no shutdown THEN description MUST EXIST

WITHIN interface lag (\d+)$ IF no shutdown THEN description MUST EXIST

8
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

SNMP

Name: SNMP

Description: SNMP various rules

Severity: WARNING

Severity should be selected according to operational enforcement rules. Device Filter: None (check all devices)

Commands:

snmp-server community public MUST NOT EXIST

snmp-server community private MUST NOT EXIST

snmpv3 context .* vrf .* public MUST NOT EXIST

snmpv3 context .* vrf .* private MUST NOT EXIST

snmpv3 .*

9
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

Management Access restriction

Name: MGMT ACL

Description: Restrict management access

Severity: ERROR

Device Filter: None (check all devices). A filter could be applied to select only the production devices.

Commands:

# apply access-list ip .* control-plane vrf .*

object-group ip address mgmt_sources

10 10.10.10.0/24
object-group port mgmt_ports

10 eq 22

20 eq 443

access-list ip mgmt_traffic

10 permit tcp mgmt_sources any group mgmt_ports

20 deny ip any any

apply access-list ip mgmt_traffic control-plane vrf mgmt

10
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

First line can be uncommented and following lines removed for less specific matching.

11
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

IP helper

Name: DHCP relay

Description: check DHCP servers for SVI 100-199

Severity: WARNING

Device Filter: interface vlan

Commands:

WITHIN interface vlan(1[0-8][0-9]|19[0-9]) THEN ip helper-address 10.11.12.13 MUST EXIST

# WITHIN interface vlan(1[0-8][0-9]|19[0-9]) THEN ip helper-address 10.14.15.16 MUST EXIST

12
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

VSX

Name: VSX global

Description: check system-mac, keepalive, linkup-delay-timer

Severity: WARNING

Device Filter: role

This device filter called “role” matches all devices with running configuration containing the keyword “role”. Commands:

The linkup-delay-timer should be higher than 30s and lower than 600s.

WITHIN vsx THEN system-mac MUST EXIST

WITHIN vsx THEN keepalive MUST EXIST

WITHIN vsx IF linkup-delay-timer.* THEN linkup-delay-timer MUST MATCH ([3-8][0-9]|9[0-9]|[1-

5][0-9]{2}|600)

13
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

Banner

Name: Banner

Description: Company Name or legal Statement must exist

Severity: ERROR

Device Filter: None (check all devices)

Commands:

Replace MyCompanyName|SomeLegalStatement by your own.

banner (exec|motd) MUST MATCH .*(MyCompanyName|SomeLegalStatement).*

14
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

NTP

Name: NTP

Description: NTP

Severity: ERROR

Device Filter:

Commands:

ntp authentication

ntp authentication-key 1 md5

ntp server 10.100.1.201 prefer

ntp vrf mgmt

clock timezone etc/utc

15
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

OSPF

Name: OSPF

Description: router-id, passive-default, graceful-restart

Severity: ERROR

Device Filter: router ospf

Commands:

router ospf.*

router-id.* MUST EXIST

passive-interface default MUST EXIST

graceful-restart restart-interval MUST EXIST

16
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

BGP

Name: BGP

Description: BGP operational rules

Severity: ERROR

Device Filter: router bgp

Commands:

router bgp .*

bgp fast-external-fallover

bgp always-compare-med

bgp bestpath med missing-as-worst

bgp log-neighbor-changes

bgp deterministic-med

bgp graceful-restart restart-time ([6-8][0-9]{2}|9[0-8][0-9]|99[0-9]|[12][0-9]{3}|3[0-

5][0-9]{2}|3600)

address-family ipv4 unicast

redistribute connected route-map .*

17
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

Physical Security

Name: Physical Security

Description: Disable USB port

Severity: ERROR

Device Filter: None (check all devices)

Commands:

no usb

18
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

Miscellaneous

Name: Misc

Description: various mandatory settings

Severity: ERROR

Device Filter: None (check all devices)

Commands:

session-timeout 0 MUST NOT EXIST

logging 10.1.10.100

Replace logging 10.1.10.100 with the proper syslog server IP address.

19
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

OTHER CONFORMANCE TESTS

Here is a list of conformance rules that proposed to help a network operation team building policies against internal organization practices.

Hostname

Name: hostname

Description: hostname naming convention

Severity: ERROR

Device Filter: None (check all devices). Filter could be used to apply different rules based on device location

Commands:

hostname [A-Z]{3}SW-8(320|325|400)-\d{1,}

In this example the hostname must have 3 Upper letters (ex: site code), then SW then model then id. Ex: SFOSW-8400-12

20
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

L3 interface numbering

Name: SVI numbering

Description: VLAN IP address 3rd octet much match the VLAN number

In addition, it must be a /24 subnet and default-gateway is .1 Severity: WARNING

Device Filter:

Commands:

WITHIN interface vlan(\d+) THEN ip address MUST MATCH \d+.\d+.\1.1/24

21
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

Routed Only Port

Name: ROP

Description: All interfaces must be routed.

Severity: ERROR

Device Filter: Role:Core (Only Core pure L3 devices)

Commands:

WITHIN interface 1/1/\d+ IF no shutdown THEN no routing MUST NOT EXIST

WITHIN interface lag (\d+) IF no shutdown THEN no routing MUST NOT EXIST

22
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

APPENDIX

Regex Numeric Range Generator

In order to generate regex range easily, there are some tools available on internet, like:
http://gamon.webfactional.com/regexnumericrangegenerator/

NetEdit Conformance Help

Overview

Conformance validation detects configurations that violate your corporate policies or network design by comparing switch
configurations against conformance tests. You can define policies by creating and enabling conformance tests in Settings /
Conformance. The tests are run continuously against both candidate and running configurations. Conformance test results for
running configurations are searchable on the device search page and displayed on both the dashboard and plan details page.
Conformance test results for candidate configurations are displayed in the editor and on the plan details page.

To add a new conformance test, select Settings / Conformance / New and enter the name of the test, the severity (warning or
error), optionally the subset of devices to be validated, and the conformance test statements. Each conformance test can be
enabled or disabled. A disabled conformance test is not run against any configurations. To edit a conformance test, double-
click the test name.

The test can be applied to all devices by leaving the search query empty, or a query can be used to restrict the test so that it
runs only on matching devices. Note that this query is continuously evaluated, so if a device changes to match the query then
the test will be run against that device. For example, if you write a test and restrict it to switches running version 10.02.0010,
then this test will not be run against a switch running version 10.02.0001. If you then upgrade that switch to 10.02.0010, the
test will now automatically be run against this switch.

A good way to start writing a conformance test is to paste a known compliant block of switch configuration as a set of test
statements, then genericize the matching using regular expressions (where applicable). If additional tuning is needed, the
more powerful syntax and matching is described below.

A conformance test contains a collection of statements which describe the desired state of the configuration, from a semantic
perspective. A simple conformance test is the single statement:
ntp server 192.168.0.7

This test will pass if the configuration file has this exact line, and will fail if it does not.

General Format

More sophisticated tests can be written by using the test keywords, regular expressions, and parameters described below
and constructed according to the following general rules:

Each statement occurs on a single line.

Any line that begins with '#' is a comment.

Every statement is of the form:

WITHIN context IF condition THEN parameter MUST (NOT)? (EXIST|MATCH value)

For example:

23
 Technical Whitepaper
NetEdit Conformance and Best
P ti t

WITHIN interface mgmt IF no shutdown THEN name MUST EXIST

means that 'interface mgmt' context which contains the 'no shutdown' command, must also have a 'name' within that context.
The following configuration will fail this test because the interface does not have a name:

interface mgmt no shutdown

ip static 1.1.1.1/24

If the statement does not contain any keywords (WITHIN, IF, THEN, MUST, NOT, EXIST, MATCH) then the line must exist
and must exactly match. For example:

ssh server vrf mgmt is the same as

ssh server vrf mgmt MUST EXIST

Regular Expressions and Matching

Matching for each item occurs as follows:

Context - compared to the entire line at root level. Qualifies where the remainder of the matching occurs. If not specified, the
remainder of the matches will occur at root level.

Condition - compared to other entire lines within the given context. Qualifies the condition under which the statement should
apply.

Parameter - compared to the start of the entire line within the given context. The parameter may include multiple terms.

Value - compared to the remainder of the line matched by 'Parameter'.

Any items (context, condition, parameter, value) may contain extended regular expressions, for flexible matching. For
example:

WITHIN interface vlan.* THEN ip ospf MUST EXIST

specifies that all vlan interfaces (i.e., interfaces with names matching the regular expression 'vlan.*') must have 'ip ospf'
configured.

Any regex match groups specified in the context/condition may be used as parameter values. A match group is a portion of the
regular expression which is enclosed within parenthesis. Match groups allow you to write rules that use dynamic values from
configuration. For example:

WITHIN interface 1/1/(\d+) THEN ip address MUST MATCH 10.0.0.\1

specifies that interfaces in module 1 (i.e., modules whose interfaces match 1/1/(\d+)) must have an IP address constructed
using the interface number as the last digit (i.e., 10.0.0.\1). The following configuration will pass because the interface number
is 7 and the ip address is 10.0.0.7:

interface 1/1/7 no shutdown

ip address 10.0.0.7

24
 Technical Whitepaper
NetEdit Conformance and Best Practicest

The example above illustrates that a regular expression matching an integer can capture that value in a match group using
the syntax (\d+), and the matched value can be used in subsequent matches with the syntax '\1'. Generally the first
captured value is '\1', the second '\2', and so on.
Context

Within a statement, the context is optional. It restricts the configuration contextual block in which checking is performed. If
no context is specified, the statement will match only the root (top level) context.

Context is implied based upon indenting. If a statement is indented, the context will be the previous line context. It simplifies
adding multi-line configuration items into conformance policies, and is easier to read and verify that the policy specification
is correct. For example:

access-list ip segment-vlan261

10 permit any 13.33.0.0/255.255.0.0 any

20 permit any 15.55.0.0/255.255.0.0 any count 30 deny any any any log count

is the same as:

access-list ip segment-vlan261 MUST EXIST

WITHIN access-list ip segment-vlan261 THEN 10 permit any 13.33.0.0/255.255.0.0 any MUST EXIST WITHIN access-list
ip segment-vlan261 THEN 20 permit any 15.55.0.0/255.255.0.0 any count MUST EXIST WITHIN access-list ip segment-
vlan261 THEN 30 deny any any any log count MUST EXIST
Condition

Within a statement the condition is optional. It restricts the matching to only occurring in a configuration context block where
the given condition occurs within that block. For example:

WITHIN interface .* IF no shutdown THEN description MUST EXIST

checks that any interfaces which are enabled must have a description. The statement does not apply to interfaces where no
shutdown does not appear in the configuration text.
Parameter and Value

Within a statement the match parameter is required. It specifies the keyword(s)/term(s) being validated. The value can be
specified within the parameter or separately using the 'MATCH value' syntax. For example, the following two statements are
equivalent:

WITHIN context IF condition THEN parameter value MUST EXIST WITHIN context IF condition THEN parameter MUST
MATCH value
Viewing Conformance Results

Conformance tests are run continuously against managed devices. When conformance validation detects a violation in the
current running and startup configurations of a device, that device is flagged and can be identified through:

a dashboard tile that displays the conformance violating devices

a device search query of conformance: false

viewing the device details page

The device details page shows the result of the current conformance settings against the device's current running
configuration at the top of the page. The conformance result for each plan at the time that plan was deployed is shown to
the right of the revision history.
Conformance in the Editor

When viewing a device configuration in the editor, relevant conformance failures are shown. The results are updated in

25
 Technical Whitepaper
NetEdit Conformance and Best Practicest

real- time as the configuration is edited. This feedback loop allows admins to resolve all conformance failures prior to
deploying a configuration change.

Where possible, conformance failures will be associated with the line that most closely matches the error. Line-specific
failures are marked on the line where they occur on the left side of the editing pane. The details for any line-specific
failure are only shown in the Insights panel when the cursor is on the associated line.

Failures where no line is associated (such as a missing command) are not marked on the left side of the editor, they are
shown only in the Insights panel. Such failures appear in the Insights panel when the cursor is on any line.

The summary totals for the plan are shown in the lower right corner. These totals do not change depending upon which
candidates are hidden/visible.

Each statement in a conformance test will report a failure for every line which violates the test. It means that a conformance
test with a statement:

interface MUST MATCH 1/1/1

when run against a config file which contained: interface 1/1/2

interface 1/1/3 interface 1/1/4

would report a failure for all three interfaces.

Conformance in Plans

When deploying a new configuration to a set of devices, or for plans previously deployed, the conformance validation status
is displayed on the plan details page. The conformance result for each device in the plan is shown under the list of
devices.

A summary of the failures in the entire plan is shown under "Conformance". Clicking this item will display a pop-up window
which shows all conformance tests that ran against the plan. Click the expansion arrow to view specific failures that
occurred for each test. Tests with no failures are shown, but are not expandable.

26
 Technical Whitepaper
NetEdit Conformance and Best Practicest

www.arubanetworks.com
3333 Scott Blvd. Santa Clara, CA 95054
1.844.472.2782 | T: 1.408.227.4500 | FAX: 1.408.227.4550 | [email protected]