Chapter 9. Configuration Management
In addition to the normal operations such as write memory, copy run start, and the like, the running configuration in Arista’s Extensible Operating System (EOS) can be managed in a variety of interesting ways. To understand the majority of them, I’d like to begin with the command configure replace.
Configure Replace
Remember that Arista EOS, much like the industry standard CLI, is additive. In other words, if you want to remove a command from the running configuration, you must add a command to negate the existing command. For example, if I have a switch that has the following configuration
Arista(config-if-Et1)#sho active interface Ethernet1 no switchport ip address 10.10.10.1/24
to remove the IP address, I must add a command to do so:
Arista(config-if-Et1)#no ip address Arista(config-if-Et1)#sho active interface Ethernet1 no switchport
Given this model, for decades the only way to load a completely new configuration on a device was either to carefully negate every existing command (a practical impossibility in most cases, not to mention a recipe for network disruption) or to overwrite the startup-config with something else and reload the device. This is a massively disruptive process that can take a large amount of time depending on the device and configuration in play.
In EOS 4.14, Arista added a new option to the configure command that allows you to replace the running configuration on a live switch. This is a very big deal that doesn’t seem to be obvious to most of the people I show it to, and I think it’s because the concept of wanting to replace the running configuration on a switch has never occurred to them, likely as a result of it simply not having been possible before now. As someone who maintains hundreds of switches in a lab and/or training environment, I can tell you that it’s a tremendously powerful feature, especially when coupled with automation tools such as eAPI or CloudVision. In fact, if you are using CloudVision, every change to a switch done via CloudVision is being done through the use of configure replace (it’s a touch more complicated than that, and I explain why later in this chapter). Consider this, though: during my classes I often change the entire behavior of a 24-switch lab using config replace automated through eAPI (Chapter 30). I can overwrite the running-configs of 24 switches in about 30 seconds, converting the entire thing from a Layer 2 (L2) Multi-Chassis Link Aggregation Group (MLAG) design to a Layer 3 (L3) Equal-Cost MultiPathing (ECMP) design without rebooting a single device and without disrupting connectivity to the switches. That’s the power of config replace.
I must point out that config replace does not do a merge operation. I had a heated discussion with someone in one of my classes in which the student insisted that what was happening was a merge operation, my guess being because she was used to other vendors’ devices for which a real replace was not possible.
Configuration merging is the process by which any new commands are added but no commands will be removed. Let me illustrate the difference between merging and replacing with a simple configuration snippet:
Arista#sho run int e1 interface Ethernet1 no switchport ip address 10.10.10.1/24
Here, I add a text file to flash: called GAD.txt that has the following contents:
Arista#more flash:GAD.txt interface ethernet1 description I Like Pie!
In EOS, copying a file into the running-config will merge the file into the running-config. Let’s see what happens:
Arista#copy flash:GAD.txt running-config ! Missing final 'end' command, adding automatically. Copy completed successfully. Arista#sho run int e1 interface Ethernet1 description I Like Pie! no switchport ip address 10.10.10.1/24
Sure enough, the contents of the GAD.txt file have been added to the running-config in a merge operation. Now let’s take a look at why config replace is not the same thing. In this example, I reset the Ethernet configuration to be the same as it was when we started:
Arista#sho run int e1 interface Ethernet1 no switchport ip address 10.10.10.1/24
Now, I do a configure replace using the same GAD.txt file:
Arista#configure replace flash:GAD.txt ! Missing final 'end' command, adding automatically.
Looks the same, but what you can’t easily see reading a book is that my Secure Shell (SSH) connection died and the switch is completely offline. Why? Let’s go into the console and find out:
localhost#sho run ! Command: show running-config ! device: localhost (DCS-7280SR-48C6-M, EOS-4.20.5F) ! ! boot system flash:/EOS-4.20.5F.swi ! transceiver qsfp default-mode 4x10G ! spanning-tree mode mstp ! no aaa root ! interface Ethernet1 description I Like Pie! ! interface Ethernet2 ! interface Ethernet3 ! interface Ethernet4 [-- output truncated--]
The hostname is no longer Arista and has changed to localhost, which is the default hostname for an Arista switch. If you look at the configuration for Ethernet1, you can see that it contains the contents of the GAD.txt file but not the original configuration. So why did this happen? Because config replace does not do a merge operation. Instead, config replace does what the name implies—it replaces the running configuration with the contents of the source, which in this case was flash:GAD.txt.
By the way, check out how simple it is to fix my catastrophic blunder using config replace again to literally replace the running-config with the contents of the startup-config.
localhost#configure replace flash:startup-config localhost#<cr> Arista#
After the replace is finished, I need to press Return, but then I’m right back where I started. Understand that at no time did I reboot this switch! I completely replaced the running configuration on a live switch. Sure, I caused a network outage with the original config replace, but that’s not important right now.
Now, if you’re wondering whether that could be bad (and you weren’t convinced when I wiped out the entire configuration of a live switch), take heart in that there’s more to config replace than wiping out the running-config. What’s especially nice about this feature is that if a section remains unchanged, there is no disruption to that process. In other words, if I do a config replace and both the existing running-config and the new one have the exact same 30 lines of Border Gateway Protocol (BGP) configuration, there will be no interruption to BGP on the switch (assuming IPs and such also remain unchanged). And the same is true for any configuration section: spanning-tree, mlag, eapi, vxlan—it doesn’t matter.
So why then, did my previous example result in the switch being wiped out? Because I replaced the entire running-config with a file containing only these lines:
Arista#more flash:GAD.txt interface ethernet1 description I Like Pie!
I can’t say this often enough: config replace replaces the running-config! Because I replaced the entire file with only two lines, everything else that had been configured previously reverted to the default, and that’s why I lost connectivity and the hostname defaulted to localhost. So what’s the solution?
Don’t do that.
When using config replace, you should always think about replacing the entire configuration, because that’s what it’s for. If what you want is a merge, use copy source running-config. I know I’ve harped on that point, but what I’m going to cover next builds on the assumption that you understand config replace.
Configuration Checkpoints
EOS also has the ability to save configuration checkpoints. This feature allows you to save the running configuration as it exists at a point in time so that you can return to it at some point in the future. To save a checkpoint use the configure checkpoint save checkpoint-name command:
Arista(config)#config checkpoint save GAD-Pre-Change
With one or more checkpoints saved you can view a brief report of them using the show config checkpoints command:
Arista(config)#sho config checkpoints Maximum number of checkpoints: 20 Filename Date User --------------- ------------------------- ----- GAD-Pre-Change 2019-01-02 22:30:43 admin
With a checkpoint saved, it can now be restored using the checkpoint restore checkpoint-name command, but before we do that, I need to show you a limitation of how this all works that might not be immediately obvious. Actually, it’s not a limitation at all, but in my experience, people seem to want to believe that it works differently, so I want to prevent problems. You see, configuration checkpoints work through the ability of EOS to do a config replace. That means that the checkpoint, when restored, replaces the current running-config. This is not a merge operation! Allow me to prove my point.
Remember that we just saved a configuration checkpoint named GAD-Pre-Change. After that save, I’m going to go in and change the running-config through good old-fashioned CLI commands:
Arista(config)#conf Arista(config)#int e5 Arista(config-if-Et5)#sho active interface Ethernet5
At this point we can see that’s there is no configuration on Ethernet5, so let’s add a description:
Arista(config-if-Et5)#desc I Like Pie! Arista(config-if-Et5)#sho active interface Ethernet5 description I Like Pie!
Now Ethernet5 has a description configured on it. I know, this is not exactly a BGP configuration for a major internet peering point, but stay with me. I’m now going to restore the checkpoint that I saved earlier:
Arista(config-if-Et5)#configure checkpoint restore GAD-Pre-Change
Now that I’ve done that, let’s see what the configuration on E5 looks like:
Arista(config-if-Et5)#sho active interface Ethernet5
And just like that, my interface description went away. Why? Because the configuration checkpoint feature uses config replace to restore a checkpoint, and (can you guess what’s coming?) config replace does not do a merge.
You might have noticed before when I listed the checkpoints that there was a maximum number of checkpoints listed:
Arista(config)#sho config checkpoints Maximum number of checkpoints: 20 Filename Date User --------------- ------------------------- ----- GAD-Pre-Change 2019-01-02 22:30:43 admin
You can configure this number via the service configuration checkpoint max saved number command:
Arista(config)#service configuration checkpoint max saved ? <0-100> Maximum number of saved checkpoints Arista(config)#service configuration checkpoint max saved 50
Let’s save another and then see what the report looks like:
Arista(config)#sho configuration checkpoints Maximum number of checkpoints: 50 Filename Date User --------------- ------------------------- ----- GAD-Post-Change 2019-01-02 22:30:43 admin GAD-Pre-Change 2019-01-02 22:30:34 admin
If you’re wondering where these checkpoints are stored, it’s in a hidden directory on flash: named .checkpoints:
[admin@Arista ~]$ ls -al /mnt/flash/.checkpoints total 16 drwxrwx--- 2 root eosadmin 4096 Jan 2 22:30 . drwxrwx--- 7 root eosadmin 4096 Jan 2 22:09 .. -rwxrwx--- 1 root eosadmin 2928 Jan 2 22:30 GAD-Post-Change -rwxrwx--- 1 root eosadmin 2928 Jan 2 22:30 GAD-Pre-Change
That means that checkpoints will survive a reboot. It also means that they take up space on flash. The fact that flash drive space is at a premium on many switches is likely why the default is to store only 20 checkpoints. Because each of these files is clear text (they are not zipped) and some devices have very large configurations, be cognizant of the fact that your checkpoints are consuming space on flash:—space that is not reported in the output of the show config checkpoints CLI command.
As a fun aside (I think it’s fun, but then I’ve been told that I’m not exactly normal), you can do a config replace directly from a checkpoint file if the mood strikes you because there is now a device in CLI called checkpoint:. This makes perfect sense because the checkpoint files are nothing more than text files.
Arista(config)#configure replace checkpoint:GAD-Pre-Change
I should point out that there’s really no reason to do this because you can accomplish the same thing using config checkpoint restore, but I like the fact that this works because it shows how the Arista developers work to make things behave the way they should. Actually, I’d be willing to bet that this is just a logical by-product of building it the right way from the ground up.
Configuration Sessions
We’ve looked at config replace and configuration checkpoints, so the last thing we’re going to cover in this chapter is configuration sessions. Configuration sessions allow for a couple of interesting options that more or less come down to the idea that a group of commands can be saved and applied at a point in time instead of interactively through the CLI. Again, though, this ability derives from the root idea of config replace, so this might not work the way you expect if you’re used to merging. It certainly caught me by surprise, and I’m the guy who’s been ranting and gesticulating about these features not doing a merge. Guess what? Configuration sessions do not do a merge, either. Let’s take a look.
The principal idea of config session is that you enter a bunch of CLI commands but those commands are not applied when you enter them. Instead, they are saved for later use. Actually, that’s not strictly true, which is what leads to the confusion. Let’s see why.
First, let’s begin with an empty interface configuration:
Arista(config)#sho run int e5 interface Ethernet5
I then start a new config session named GAD and put in the configuration commands that I would use to save the configuration:
Arista#conf session GAD Arista(config-s-GAD)#int e5 Arista(config-s-GAD-if-Et5)#desc I Like Pie! Arista(config-s-GAD-if-Et5)#^z Arista#
This string of commands has not changed the running-config, but instead has saved a new config session named GAD. With a session saved, I can view a report of all sessions using the show config sessions command:
Arista#show config session Maximum number of completed sessions: 1 Maximum number of pending sessions: 5 Name State User Terminal ---- ------------- ---------- -------- GAD pending
What tends to get people is that they think that the session is nothing more than the couple of commands typed to create the session, but that is not the case. Using the command show session-config named session-name shows the contents of a session. Here’s the output for my GAD session:
Arista#show session-config named GAD
! Command: show session-configuration named GAD
! device: Arista (DCS-7280SR-48C6-M, EOS-4.21.1F)
!
! boot system flash:/EOS-4.21.1F.swi
!
alias conint sh interface | i connected
alias senz show interface counter error | nz
alias shmc show int | awk '/^[A-Z]/ {intf = $1}/, address is/{print intf, $6}'
alias snz show interface counter | nz
alias spd show port-channel %1 detail all
alias sqnz show interface counter queue | nz
alias srnz show interface counter rate | nz
[--output truncated--]
Holy moly—that’s a running-config! Why? Because that’s how configuration sessions work. They don’t save the commands you entered; rather, they make a copy of the running-config and apply those commands to that, thus forming a new configuration with your changes added, which is then saved as a session.
Warning
Let me reiterate that. A configuration session is not a set of commands you entered. It is the running-config at the time you entered them, merged with your commands. The result is a whole new configuration—not just a list of the commands you entered.
To prove this further, you can use the show session-config named session-name diff command:
Arista#sho session-config named GAD diff --- system:/running-config +++ session:/GAD-session-config @@ -43,6 +43,7 @@ interface Ethernet4 ! interface Ethernet5 + description I Like Pie! ! interface Ethernet6 !
Without getting deep into how diff works, this output is showing that the only difference between the running-config and the session named GAD is the one line, description I Like Pie!
Now, without applying that session, I’m going to change the running-config for Ethernet 6:
Arista#conf Arista(config)#int e6 Arista(config-if-Et6)#desc I hate cake Arista(config-if-Et6)#^z
At this point I have changed the running-config (specifically for E6), but I did not alter the config-session (which changed E5). Now when I do a show session-config named GAD diff to show the differences between the running-config and the session named GAD, notice that the GAD session does not include a description on int e6:
Arista# Arista#sho session-config named GAD diff --- system:/running-config +++ session:/GAD-session-config @@ -43,9 +43,9 @@ interface Ethernet4 ! interface Ethernet5 + description I Like Pie! ! interface Ethernet6 - description I hate cake ! interface Ethernet7 !
If the diff output is confusing, how about I just commit the session and show what happens? Here is the current running-config for Ethernet 5 and 6:
Arista#sho run int e5-6 interface Ethernet5 interface Ethernet6 description I hate cake
Now I commit the session named GAD that has the description for E5. Configuration sessions are applied by using the commit command from within configuration mode for the session that you want to commit:
Arista#config session GAD Arista(config-s-GAD)#commit
Let’s see what happened to our configurations for E5–6:
Arista#sho run int e5-6 interface Ethernet5 description I Like Pie! interface Ethernet6
While the configuration for Ethernet5 was added, note that the configuration for Ethernet6 was removed. Why? Because the session replaced the running-config with what was contained in the session.
Warning
Configuration sessions do not contain just the commands you entered; they contain a running-config from the time the session was created with those commands applied. If you make changes to the running-config and then apply the session, you will lose the changes you made to the running-config.
I should point out that there are a couple of cool things about configuration sessions that I haven’t covered yet. First, you can commit a session with a timer.
Arista#configure session GAD2 Arista(config-s-GAD2)#int e7 Arista(config-s-GAD2-if-Et7)#description I like pudding Arista(config-s-GAD2-if-Et7)#^z
This time, I commit the change, but with a timer:
Arista#configure session GAD2 Arista(config-s-GAD2)#commit timer 00:03:00
What this does is commit the change, but the change will stay only for the duration of the timer unless someone goes in and commits without a timer. Why would you do this? To prevent you from being locked out of the switch when issuing remote commands. I once shut down all of Australia for a global financial firm by applying an empty Access Control List (ACL) to a router (whoops!), which is when I learned about the reload in time command. Using a commit timer is much more powerful than the reload in command because there’s no reboot involved. Note that the command I entered does not commit the change in three minutes: it commits the change for three minutes. Here is the running-config for E7 after I issued the command:
Arista#sho run int e7 interface Ethernet7 description I like pudding
While the session is committed and the timer is active, you can see the time remaining by using the show config session detail command:
Arista#sho configuration sessions detail Maximum number of completed sessions: 1 Maximum number of pending sessions: 5 Name State User Terminal PID Commit Time Left ---- ----------------------- --------- ------------- --------- ---------------- GAD completed GAD2 pendingCommitTimer 1m30s
When the timer expires and the session has not been permanently committed, the system reverts to a checkpoint that the system made automatically at the time of the timed commit:
Arista#sho configuration sessions detail Maximum number of completed sessions: 1 Maximum number of pending sessions: 5 Name State User Terminal PID Commit Time Left ---- ----------------------- --------- ------------- --------- ---------------- cfg-2625--896533696-0 completed Name Description --------------------- --------------------------------------------- cfg-2625--896533696-0 config replace of commitTimerCheckPointConfig
Unlike with configuration checkpoints, configuration sessions are not saved to flash: and will not survive a reboot, so don’t expect to be able to make a bunch and use them post-upgrade.
Note
Technically, configure replace exists as a result of the structure built for config sessions, but I explain them in a different order because it seems easier to explain the idea as building on the idea of replacing a configuration.
As a quick final note, if you’ve wondered why the output of show config session doesn’t show a user and terminal in my examples, it’s because those fields are populated only when a user is actively in a session.
Arista#configure session GAD Arista(config-s-GAD)#sho configuration sessions Maximum number of completed sessions: 1 Maximum number of pending sessions: 5 Name State User Terminal ---- ------------- ----------- -------- * GAD pending admin vty3
As a last bit of interesting information regarding config session, you can actually make a default config session using the rollback clean-config command from within a session:
Arista#configure session GAD Arista(config-s-GAD)#rollback clean-config Arista(config-s-GAD)#exi
Doing this will create a configuration that has only default commands, which will give the same results as doing a write erase and then a reload.
Arista#sho session-config named GAD ! Command: show session-configuration named GAD ! device: Arista (DCS-7280SR-48C6-M, EOS-4.21.2F) ! ! boot system flash:/EOS-4.21.2F.swi ! transceiver qsfp default-mode 4x10G ! spanning-tree mode mstp ! no aaa root ! interface Ethernet1 ! interface Ethernet2 ! [-- snip--] ! interface Ethernet47 ! interface Ethernet48 ! interface Ethernet49/1 ! interface Ethernet50/1 ! interface Ethernet51/1 ! interface Ethernet52/1 ! interface Ethernet53/1 ! interface Ethernet54/1 ! interface Management1 ! no ip routing ! end
I’m not sure how useful this is in a production environment, but in a lab environment, where you might need to have a “blank” or default switch, this is a pretty powerful capability and is actually part of how CloudVision uses config session to configure switches on live networks.
EOS limits the number of sessions to five by default, but you can change this by using the service configuration session max command:
Arista(config)#service configuration session max ? completed maximum number of completed sessions kept in memory pending maximum number of pending sessions Arista(config)#service configuration session max completed ? <0-20> Maximum number of saved sessions Arista(config)#service configuration session max pending ? <1-20> Maximum number of pending sessions
Because it would appear that the configuration sessions reside in memory and are not compressed and because some switches have some large configurations, I probably wouldn’t change these values unless I really needed to.
Conclusion
Configuration management in EOS is very powerful, but remember that it might not work the way you expect it to if you’re familiar with the way that other networking vendors deal with the same topic. When in doubt, remember that it’s not a merge unless you use the copy command. Also, testing this out for yourself in a lab environment would probably be a good idea before you go replacing the running configuration on a production device. Or not. I suppose there are some people who actually enjoy job hunting.