Note: This article is part of the Introduction to Managing EOS Devices series:
- 1) Setting Up Management
- 1.1) VRF Aware Management
- 1.2) Telnet and SSH
- 1.3) Logging
- 1.4) SNMP Configuration
- 1.5) NTP Configuration
- 1.6) DNS Configuration
- 1.7) Local and remote Authentication, Authorization, and Accounting (AAA)
- 1.8) Sflow traffic sampling
- 1.9) XMPP
- 1.10) eAPI
- 1.11) Understanding Port Numbering
1) Setting Up Management
The following management tools are available on Arista EOS for all platforms:
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:
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:
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:
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
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 firstname.lastname@example.org 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 email@example.com password <pwd>
Create a user “all” allowing the group to execute commands onto the switch:
switch(config)#username all secret <pwd>
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:
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:
- A = slot number of the line card (nil in case of fixed switch)
- B = port number in order of its physical presentation, such as SFP+, QSFP, MXP, etc.
- 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)
- The Arista 7150S-24 fixed switch has 24xSFP+ ports. All the ports follow the B numbering pattern:
- Eth1, Eth2, Eth3, […] Eth22, Eth23, Eth24
- 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.:
- QSFP1 Eth1/1 ← Eth1/1 is a 40G port, the Eth1/2-4 are inactive
- QSFP2 Eth2/1, Eth2/2, Eth2/3, Eth2/4 ← Eth 2/1-4 are 10G ports
- 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:
- 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)
- 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 [...]