Introduction to Managing EOS Devices – Setting up Management

Note: This article is part of the Introduction to Managing EOS Devices series:

https://eos.arista.com/introduction-to-managing-eos-devices/ 

 

 

1) Setting Up Management

The following management tools are available on Arista EOS for all platforms:

  • VRF-aware management
  • Telnet and SSH
  • Syslog and Console Logging
  • SNMP Versions 1 and 3
  • NTP
  • DNS
  • Local and remote user control (AAA)
    • TACACS+, RADIUS
  • sFlow
  • XMPP
  • eAPI

 

Note: in the following configuration examples, the commands in square brackets are optional: [optional]

 

1.1) VRF Aware Management

As of release 4.10.1, EOS supports the ability to constrain management functions to a VRF. This enables the user to separate management based functions from the data plane. This feature does not change the capability for the device to be managed either via inband front panel interfaces or the out-of-band Management 1 interface.

The inclusion of this management VRF has several configuration implications for most management features, such as SNMP, SSH, TACACS+, syslog, etc.

In order to use the management VRF:

  • the management VRF must be created
  • a route distinguisher (rd) must be assigned to it
switch(config)#vrf definition MGMT 
switch(config)#rd 100:100

For more details on understanding and configuring VRF, please refer to the manual.

Note: The name of the management VRF is configurable; we use MGMT as an example. Both front-panel ports and management interfaces can then be assigned into this VRF.

switch(config)#interface management1 
switch(config)#vrf forwarding MGMT 

Note: When moving interfaces between VRFs the IP addresses will be removed. It is therefore not recommended to move an interface between VRFs if that is the interface used to access the device. However, such dynamic change is possible with a multi-line alias with arguments. Example:

alias changevrf
!! Syntax : changevrf <int> <vrf> <IP>
!! Example: changevrf ma1 MGMT 172.22.30.166/23
1 conf
2 int %1
3 vrf forwarding %2
4 ip address %3
5 end

Once the management interface has been moved into the appropriate VRF the various management services must be notified of this change. Most of the management services have vrf <vrf-name> command syntax for that purpose.

In all of the following sections the [vrf MGMT] configuration is optional and is only provided as an example; however, this is recommended as a best practice in security-conscious environments.

 

1.2) Telnet and SSH

SSH is the default protocol for establishing a terminal session to the Arista switches. By default telnet is disabled. To enable telnet, execute the following:

switch(config)#management telnet
switch(config-mgmt-telnet)#vrf MGMT
switch(config-mgmt-telnet)#no shutdown

 

By default the connection timeout period is disabled (default is “idle-timeout 0”, infinity). This can be changed by executing the following command. In the example a timeout of 3 hours is configured:

switch(config-mgmt-telnet)#idle-timeout 180

 

1.3)  Logging

 

1.3.1) Configuring System Logging

For common system logging, EOS follows industry standard configuration semantics:

switch(config)#logging ?
buffered            Set buffered logging parameters
console             Set console logging parameters
event               Global events
facility            Set logging facility
format              Set logging format parameters
host                Set syslog server IP address and parameters
level               Configure logging severity
on                  Enable logging to all supported destinations
relogging-interval  Configure relogging-interval for critical log messages
source-interface    Use IP Address of interface as source IP of log messages
synchronous         Set synchronizing unsolicited with solicited messages
trap                Set syslog server logging level
vrf                 configure VRFs

 

The size of the log buffer and the severity of incidents logged can be configured via:

switch(config)#logging buffered
<0-7>            Severity level value
<10-2147483647>  Logging buffer size (in number of messages)

 

Logging is not persistent and does not survive reboots. Therefore logging to an external syslog server is recommended. The following command configures logging to external syslog servers:

switch(config)#logging [vrf MGMT] host 10.0.0.1
switch(config)#logging [vrf MGMT] host 10.0.0.2

 

The default severity level of the messages that are sent to the syslog servers is 6 (informational). This can be changed using the following command:

switch(config)#logging trap
<0-7>            Severity level value

 

1.3.2) Configuring Console Logging

Console logging is enabled by default. The following logging options are available:

switch(config)#logging console ?
alerts         Immediate action needed           (severity=1)
critical       Critical conditions               (severity=2)
[...]

 

If no specific severity level is specified then console logging will default to error conditions only:

switch(config)#show logging
Syslog logging: enabled
Buffer logging: level debugging
Console logging: level errors
Synchronous logging: disabled
Trap logging: level informational
Sequence numbers: disabled
Syslog facility: local4
Hostname format: Hostname only
Repeat logging interval: disabled

 

Changing the default console logging level can be done via the following command. In this example everything will be sent to the console:

switch(config)#logging console debugging

 

By default, logging will not be printed to the remote terminal sessions (SSH/Telnet), but this can be enabled using the following command in enable mode:

switch#terminal monitor

 

1.4) SNMP Configuration

EOS supports a growing number of both Arista-specific and standards-based MIBs, providing the ability to quickly integrate devices into 3rd party monitoring solutions. The current list of supported MIBs can be found at:

http://www.arista.com/en/support/arista-snmp-mibs

Configuring SNMP  follows the industry standard. For example, for SNMP v2, the SNMP agent is not enabled until the first community is created.

switch(config)#snmp-server community public

 

The switch can be configured to send SNMP traps or informs to an external host. The last variable (‘arista’ in the example below) changes depending on the version of SNMP. For SNMP v1/v2 it would be the community string, for SNMP v3 it would be the username.

switch(config)#snmp-server host 10.0.0.1 [vrf MGMT] traps arista

If you choose SNMP v3, you need to configure group(s) and user(s), as per the configuration example below:

switch(config)#snmp-server group tech-group v3 priv read all-items
switch(config)#snmp-server user tech-user-1 tech-group v3

 

You can enable all types of SNMP notifications (traps or informs) with the following command:

switch(config)#snmp-server enable traps

And You can granularly select/deselect some MIBs as follows:

switch(config)#[no] snmp-server enable traps ospf if-state-change

 

Like other management features, SNMP is VRF aware, such assignment can be per host (see previous snmp-server host example), or global to all SNMP servers:

switch(config)#[snmp-server vrf MGMT]

 

The status of SNMP can be shown via:

switch(config)#show snmp
0 SNMP packets input
0 Bad SNMP version errors
0 Unknown community name
0 Illegal operation for community name supplied
0 Encoding errors
0 Number of requested variables
0 Number of altered variables
0 Get-request PDUs
0 Get-next PDUs
0 Set-request PDUs
0 SNMP packets output
0 Too big errors
0 No such name errors
0 Bad value errors
0 General errors
0 Response PDUs
0 Trap PDUs
Access Control
0 Users
0 Groups
0 Views
SNMP logging: enabled
Logging to 10.0.0.3.162
SNMP agent enabled in VRFs: default

 

 

1.5) NTP Configuration

NTP allow network-wide time synchronization.

switch(config)#ntp server [vrf MGMT] 192.168.1.1

High precision time distribution can be achieved by PTP with a precision oscillator. This is a platform specific feature detailed in “Platform Specific Configuration – 7150” under “PTP”.

 

1.6) DNS Configuration

The Domain Name Server (DNS) maps FQDN labels to IP addresses and provides addresses for network devices. Each network requires at least one server to resolve addresses. The system supports up to three servers:

switch(config)#ip name-server [vrf MGMT] 192.168.1.1 [server2_IP] [server3_IP]

 

 

1.7) Local and remote Authentication, Authorization, and Accounting (AAA)

 

1.7.1) Local Authentication

Local authentication is achieved with local username/passwords:

switch(config)#username ops-user role ops secret <password>

 

Activate the local user authentication with the following AAA configuration:

Switch(config)#aaa authentication login default local
Switch(config)#aaa authentication enable default local

 

By default, AAA provides local user login authentication.

 

1.7.2) Local Authorization – Role Based Access Control (RBAC)

Local authorization is achieved with a role-base model that gives explicit and implicit command access.

switch(config)#role ops
switch(config-role-ops)#10 deny command delete|rmdir|bash
switch(config-role-ops)#20 deny mode config command(no|default)?(interface|username|role|aaa)
switch(config-role-ops)#30 permit command .*

 

Explicit vs implicit syntax – following regular expressions:

  • permit command .*includes “show” implicitly
  • permit command showincludes “show” explicitly

 

Note: Like for any regexp, placing the character “?” (question mark) rather than calling for contextual help, is realised by typing “Ctrl + V”, then “?”.

The role “ops” prevents access to the linux shell, deleting files and directories from the flash, changing interfaces, and deleting certain AAA commands. All the other commands are allowed.

The newly defined role can be assigned to a user with the username <user> role command.

User command authorization against the local roles can be enabled with:

switch(config)#aaa authorization commands all default local

 

Individual user privilege level grant access to different exec levels, this is a form of simple command authorization. RBAC supersedes these privilege levels.

switch(config)#aaa authorization exec default <local|group>

 

Users that are not explicitly assigned a role are assigned the default role. The network-operator built-in role is the default role. This role can be shown using the command:

switch(config)#show role
The default role is network-operator
role: network-operator
10 deny mode exec command configure|bash|python-shell|\|
20 permit mode exec command .*

 

vEOS1(config)#show user-account
user: ops-user
role: ops
privilege level: 1

 

1.7.3) AAA with a remote server

Remote AAA allows centralized management of credentials and access rules. TACACS+ and RADIUS are supported. A simple configuration example with TACACS+ would include the tacacs-server host definition, and the addition of tacacs+ group as a AAA method. The following example uses TACACS+ for user login authentication and authorization, with local fallback.

switch(config)#tacacs-server host 192.168.1.1 [vrf MGMT]
switch(config)#tacacs-server key MyTacacsServerKey
switch(config)#aaa authentication login default group tacacs+ local
switch(config)#aaa authentication enable default group tacacs+ local
switch(config)#aaa authorization exec default group tacacs+ local

 

1.8) Sflow traffic sampling

sFlow is an open standard line rate traffic sampling technology. The following example shows how the feature can be enabled and configured – the traffic samples can be streamed to an external receiver:

switch(config)#sflow run
switch(config)#sflow [vrf MGMT] destination 192.168.1.2

 

1.9) XMPP

XMPP is an open standard messaging protocol, which allow flexible and scalable communication with Arista switches that run an XMPP client natively (EOS 4.12 onwards). Previous versions can also run the client as an extension.

 

The switches can be accessed individually or in groups (using chat rooms). The XMPP server configuration is beyond scope of this document, but several open platforms exists for your needs (ejabberd, OpenFire, etc). The XMPP client is activated and configured as follows:

switch(config)#management xmpp
switch(config-mgmt-xmpp)#no shutdown
switch(config-mgmt-xmpp)#[vrf MGMT]
switch(config-mgmt-xmpp)#server 192.168.1.3
switch(config-mgmt-xmpp)#domain mydomain
switch(config-mgmt-xmpp)#username Arista@mydomain password MyPass
switch(config-mgmt-xmpp)#switch-group all@conference.mydomain password MyPass

 

Only users that are authorized using local or remote AAA can execute commands on the switch via XMPP chat sessions. In order to authorize commands sent via conference rooms, the switch-group itself needs to configured as a user.

For the XMPP group “all”:

switch(config-mgmt-xmpp)#switch-group all@conference.mydomain password <pwd>

 

Create a user “all” allowing the group to execute commands onto the switch:

switch(config)#username all secret <pwd>

 

1.10) eAPI

Arista EOS provides multiple APIs, of which Extensible API (eAPI) is a RESTFUL programmatic interface based on the JSON structured format via HTTP or HTTPS, to simplify interactions with any Arista EOS. It can be enabled using:

switch(config)#management api http-commands
switch(config-mgmt-api-http-cmds)#no shutdown
switch(config-mgmt-api-http-cmds)#[vrf MGMT]

 

You can change the default protocol  from HTTPS to HTTP as follows:

switch(config-mgmt-api-http-cmds)#no protocol https
switch(config-mgmt-api-http-cmds)#protocol http

 

Using a web browser, the eAPI Explorer can be used to explore the syntax of the eAPI requests and responses. In order to access it, simply point your browser to:

http[s]://<ip_address_switch>/command-api

 

For more details you can refer to the eAPI guide that can be downloaded in the software download section, the EOS extensibility manual and EOS Central.

 

Access rights for eAPI

For correct access via eAPI, ensure you have correctly set the relevant AAA parameters, including Authentication, privilege levels, and Authorization. Remember that by default a user does not have privileged access, but only unprivileged access (level 1). Note that many CLI or eAPI commands require the user to enter the “enable” command in order to access privileged exec mode.

 

Alternatively, you may set the user privilege level to 15 using:

username eapi privilege 15 secret <password>

This would only be effective once authorization is also configured:

aaa authorization exec default local

 

The result would be a user named “eapi” that has directly access to privileged exec mode, such user would not require entering the “enable” command before executing privileged commands such as “config”, “show running-config”, etc.

 

See the previous  “Local Authentication” section for more details.

 

1.11) Understanding Port Numbering

 

Arista switches might be of fixed form factor or modular. Interface numbering follows an [A/]B[/C] numbering pattern, where:

  1. A = slot number of the line card (nil in case of fixed switch)
  2. B = port number in order of its physical presentation, such as SFP+, QSFP, MXP, etc.
  3. C = if a port sub-divides (e.g. 40G QSFP → 4x10G), then “C” represents the logical port (e.g. 10G) within the mechanical interface (e.g. QSFP)

 

Examples:

  1. The Arista 7150S-24 fixed switch has 24xSFP+ ports. All the ports follow the B numbering pattern:
    • Eth1, Eth2, Eth3, […]  Eth22, Eth23, Eth24
  2. The Arista 7050QX-32 fixed switch has 32xQSFP ports:
    • Ports follow the B/C numbering pattern (there are no slots, but port sub-division is present)
    • Each QSFP port can be individually configured as 4x10G ports, e.g.:
      1. QSFP1    Eth1/1                                          ← Eth1/1 is a 40G port, the Eth1/2-4 are inactive
      2. QSFP2    Eth2/1, Eth2/2, Eth2/3, Eth2/4     ← Eth 2/1-4 are 10G ports
  3. The Arista 7500E-36Q-LC line card has got 36xQSFP ports
    • Ports follows the A/B/C numbering pattern, where slot number, and port sub-division are present
    • Example with 1st line card (slot 3), 1st QSFP as native 40G, 2nd QSFP as 4x10G:
      1. QSFP1    Eth3/1/1   ← Eth3/1/1 is a 40G port. The Eth3/1/2-4 are either shown inactive (pre  4.14.3F), or hidden (post 4.14.3F)
      2. QSFP2    Eth3/2/1, Eth3/2/2, Eth3/2/3, Eth3/2/4← Eth 3/2/1-4 are 10G ports

Output matching the previous example:

switch# show interfaces status
Port       Name              Status       Vlan        Duplex  Speed Type
Et3/1/1    I am a 40G port   connected    trunk       a-full  a-40G 40GBASE-CR4
Et3/1/2                      inactive     1           unconf unconf 40GBASE-CR4
Et3/1/3                      inactive     1           unconf unconf 40GBASE-CR4
Et3/1/4                      inactive     1           unconf unconf 40GBASE-CR4
Et3/2/1    I am a 10G port   connected    trunk       a-full  a-10G 40GBASE-SR
Et3/2/2    I am a 10G port   connected    10          a-full  a-10G 40GBASE-SR
Et3/2/3    I am a 10G port   connected    routed      a-full  a-10G 40GBASE-SR
Et3/2/4    I am a 10G port   connected    123         a-full  a-10G 40GBASE-SR
[...]