Now that the XMPP server and switches have been configured, commands can now be issued from an XMPP client either on the switch or a client running in Linux, Windows, etc.
This post will demonstrate the issuing of commands from the IM client Gajim and the Arista switches themselves using XMPP. By default, when configuring the Arista switches the privilege level was left as the default of 1
0 1 2 3 4 5 6 7 8 9 |
spine1(config-mgmt-xmpp)#show xmpp status XMPP Server: 172.17.3.253 port 5222 Client username: spine1@securitydemo.lab Default domain: securitydemo.lab Default privilege level for received commands: 1 Connection status: not connected spine1(config-mgmt-xmpp)#no shut spine1(config-mgmt-xmpp)#show xmpp status |
Privilege 1 Commands
Commands can be sent to the switch in a couple of ways. Sending commands from switch to switch or to a group of switches.
As XMPP is a protocol that is designed for chat and instant messaging to send messages to a group of switches, they are part of a chat group.
I have installed Gajim on the Ubuntu server. Below are the screenshots of the configuration and sending commands from an IM client to a single switch.
0 1 2 |
sudo apt install gajim-omemo |
Manually set the hostname for the server
Commands can be sent from switchX to switchY, in a similar way to SSHing from switchX to SwitchY. Another feature is the ability for commands to be sent to multiple switches that are in a group.
Each switch will need to be configured with the switch-group command in XMPP management for both of these features. Once the switches are in the same switch group, they will recognise each other as neighbours.
0 1 2 3 |
management xmpp switch-group all@conference.securitydemo.lab password Stefan2020 |
The admin user is present because this is a known contact due to the integration with the IM client.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
spine1#sho xmpp neighbors Neighbor State Time Since Last Change ------------------------------ --------------- ------------------------- admin@securitydemo.lab present 5:56:16 ago leaf1@securitydemo.lab present 6:06:11 ago leaf2@securitydemo.lab present 6:06:15 ago leaf3@securitydemo.lab present 6:06:19 ago leaf4@securitydemo.lab present 6:06:24 ago spine2@securitydemo.lab present 6:05:32 ago Neighbor Status Message ------------------------------ ---------------------------------------- admin@securitydemo.lab leaf1@securitydemo.lab Arista Networks vEOS-lab leaf2@securitydemo.lab Arista Networks vEOS-lab leaf3@securitydemo.lab Arista Networks vEOS-lab leaf4@securitydemo.lab Arista Networks vEOS-lab spine2@securitydemo.lab Arista Networks vEOS-lab |
Now that the switches are all neighbours, commands can be issued on leaf2 from spine1 as if they are run from leaf2.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
spine1#xmpp send leaf2@securitydemo.lab command show version message from user: leaf2@securitydemo.lab -------------------------------------------------- Arista vEOS-lab Hardware version: Serial number: C9734140FB699094F8456139251A7C2C Hardware MAC address: 0cb0.c91e.eddd System MAC address: 0cb0.c91e.eddd Software image version: 4.26.8M Architecture: x86_64 Internal build version: 4.26.8M-28525459.4268M Internal build ID: fdcab683-0578-4f67-80c6-9f00b3358777 Image format version: 1.0 Uptime: 3 hours and 16 minutes Total memory: 2006808 kB Free memory: 941600 kB |
Another method is to issue commands in a way that looks like you are directly on the neighbour switch.
So from spine1 I can interact with another switch, leaf2 in this case, as if I am on that switch directly.
0 1 2 3 4 5 6 7 8 9 10 |
spine1#xmpp session leaf2@securitydemo.lab CliInputWrapper: CliInput: CliInput cannot be used if the readline module is loaded xmpp-leaf2-spine1#show ip int br response from: leaf2@securitydemo.lab -------------------------------------------------- Address Interface IP Address Status Protocol MTU Owner ---------------- ------------------ ----------- ------------- --------- ------- Management1 172.17.3.2/24 up up 1500 |
It is possible to issue a command to all the switches in the switch group, again can be done from the Arista CLI like commands to single switches can. This issues commands to the switch that sent the command. So I have 6 switches in the group, and 6 responses despite issuing the command from one of those 6 switches in the group.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
spine1#xmpp send all@conference.securitydemo.lab command show ip int br message from user: leaf1@securitydemo.lab -------------------------------------------------- Address Interface IP Address Status Protocol MTU Owner ---------------- ------------------ ----------- ------------- --------- ------- Management1 172.17.3.1/24 up up 1500 message from user: leaf2@securitydemo.lab -------------------------------------------------- Address Interface IP Address Status Protocol MTU Owner ---------------- ------------------ ----------- ------------- --------- ------- Management1 172.17.3.2/24 up up 1500 message from user: leaf3@securitydemo.lab -------------------------------------------------- Address Interface IP Address Status Protocol MTU Owner ---------------- ------------------ ----------- ------------- --------- ------- Management1 172.17.3.3/24 up up 1500 message from user: leaf4@securitydemo.lab -------------------------------------------------- Address Interface IP Address Status Protocol MTU Owner ---------------- ------------------ ----------- ------------- --------- ------- Management1 172.17.3.4/24 up up 1500 message from user: spine1@securitydemo.lab -------------------------------------------------- Address Interface IP Address Status Protocol MTU Owner --------------- ------------------- ----------- ------------- --------- ------- Management1 172.17.3.101/24 up up 1500 message from user: spine2@securitydemo.lab -------------------------------------------------- Address Interface IP Address Status Protocol MTU Owner --------------- ------------------- ----------- ------------- --------- ------- Management1 172.17.3.102/24 up up 1500 |
This switch group (group chat) can be joined from the IM client.
Commands issued in the switch group are all saved in the group chat.
Privilege 15 Commands
As all the commands so far have been issued by a user that can only perform privilege level 1 commands. Meaning, no show running
or configuration commands.
There are a couple of ways to issue commands for privilege 15, for this I have taken the easy route to modify the XMPP config of each switch to default privilege 15 instead of 1. Another way is to use a AAA TACACS server and check the username against a set of permitted commands or user checks. This is in the next Arista post.
0 1 2 3 |
management xmpp session privilege 15 |
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
spine1#show xmpp status XMPP Server: 172.17.3.253 port 5222 Client username: spine1@securitydemo.lab Default domain: securitydemo.lab Default privilege level for received commands: 15 Connection status: connected spine1#show xmpp neighbors Neighbor State Time Since Last Change ------------------------------ --------------- ------------------------- admin@securitydemo.lab present 0:02:02 ago leaf1@securitydemo.lab present 0:02:02 ago leaf2@securitydemo.lab present 0:02:02 ago leaf3@securitydemo.lab present 0:02:02 ago leaf4@securitydemo.lab present 0:02:02 ago spine2@securitydemo.lab present 0:02:02 ago Neighbor Status Message ------------------------------ ---------------------------------------- admin@securitydemo.lab leaf1@securitydemo.lab Arista Networks vEOS-lab leaf2@securitydemo.lab Arista Networks vEOS-lab leaf3@securitydemo.lab Arista Networks vEOS-lab leaf4@securitydemo.lab Arista Networks vEOS-lab spine2@securitydemo.lab Arista Networks vEOS-lab |
Working as expected. Although I did reload all the switches, shut
no shut
of XMPP may have worked just as good.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
spine1#xmpp session leaf2@securitydemo.lab CliInputWrapper: CliInput: CliInput cannot be used if the readline module is loaded xmpp-leaf2-spine1#conf t xmpp-leaf2-spine1#show run response from: leaf2@securitydemo.lab -------------------------------------------------- > show run ! Command: show running-config at line 1 ! device: leaf2 (vEOS-lab, EOS-4.26.8M) ! ! boot system flash:/vEOS-lab.swi |
Sending configuration commands from one switch to another using the session or send options is not supported according to the Arista documentation. Below is an excerpt of the config restrictions
- Only enable-mode commands are allowed within the multi-switch CLI.
- Changing into a different CLI mode and running several commands in that mode is not supported (e.g., into configuration mode).
- An external XMPP client (for example Adium) can be used to send multiple lines within a single message. By sending multiple lines, it is possible to change into another CLI mode. After the message is processed, the switch automatically return to the enable mode.
- Commands that prompt for a response (like reload) are not supported.
- Long commands, such as image file copies, may cause the switch XMPP client to momentarily stop responding and disconnect. The switch should reconnect and the long command should complete.
- Many command outputs display in a specific table format. To achieve the same visual feel as through a terminal, use a monospaced font, such as Courier, for the incoming messages.
Issuing commands from the chat client requires everything as a single command. The commands are written line by line in a text editor and then pasted into the chat client as a single message, shift+enter
will probably also work for a new line, depending on the client. There is no response from the switch unless there is output back to the user. So issuing configuration commands only returns something if the CLI returns something for that command, most do not.
Using AEM To Send Messages
AEM is the event manager. It works as an event, trigger and action sequence. More details about AEM can be found on the Arista website.
This example will show a switch that reports a message when an interface status is changed.
All the config is applied to the switch spine1 in the AEM config.
0 1 2 3 4 |
event-handler Eth2IntTest trigger on-intf ethernet 2 operstatus action bash FastCli -p 15 -c "xmpp send admin@securitydemo.lab message 'Ethernet2 has changed state'" |
Shutting down the interface eth2
should trigger the event and send a message to the admin in the chat client. A no shut
will also trigger the same message. This is due to the trigger being a change in interface state.
I did try to modify this to get the switch to send the message to the chat group. The command runs, but I do not get any output in the chat or any other switches. I cannot see anywhere in the documentation that states this is not possible. It would be nice for the switches to use the switch group to send the message. Running show commands works, it is just the messages that seem to fail.