4-DC/Nexus Files and configuration Rollback.

In this post i will talk about some information about how the NX-OS deal with the different files and the different locations where we can store the different files, as well how to check the differences between the current running configuration and startup configuration, and how to define rollback configuration in case we need to roll back to old configuration file.

Directories and Memories:

There are different locations on the Nexus switch where we can store the different files, each location represents a memory, and each memory is located at different module. We can create different directories on the different memories we have, either internal memories such as bootflash, RAM, NVRAM, … or external memories such as usb, external flash memory,…, as well we can access the files stored at the different directories inside the different memories. The system image files can be downloaded from different locations either from one directory to another, this means that we can copy file located at Directory X located at volatile memory to another Directory Y located at bootflash memory, or we can download file from external source to internal memory, this means that we can download file located at external FTP/TFTP server to Directory Z located at bootflash memory. The following shows example of the different memories and directories defined to be used by NX-OS inside the Nexus devices:

  1. Bootflash: It is an internal compact flash memory located at both Supervisors (Active and Standby) and is used to store different types of files: system image files, configuration files or other user-defined files. If we need to access file stored at the Bootflash memory located at the Active supervisor we can use one of the following syntax:
    bootflash://module-1/
    bootflash://sup-1/
    bootflash://sup-active/
    bootflash://sup-local/While if we need to access file stored at the Bootflash memory located at the Standby supervisor we can use one of the following syntax:
    bootflash://module-2/
    bootflash://sup-2/
    bootflash://sup-standby/
    bootflash://sup-remote/
  2. Slot0: It is an external compact flash memory that is installed at both Supervisors (Active and Standby), but it is available only on Sup 1  and is used to store different types of files: system image files, configuration files or other user-defined files. If we need to access file stored at the External compact flash “Slot0” memory located at the Active supervisor we can use one of the following syntax:
    slot0://module-1/
    slot0://sup-1/
    slot0://sup-active/
    slot0://sup-local/While if we need to access file stored at the External compact flash “Slot0” memory located at the Standby supervisor we can use one of the following syntax:
    slot0://module-2/
    slot0://sup-2/
    slot0://sup-standby/
    slot0://sup-remote/
  3. Volatile: It is an Volatile Random Access memory or VRAM or simply we can call it RAM, that is located at both Supervisors and is used to store the temp files. If we need to access temp file stored at this VRAM located at the Active supervisor we can use one of the following syntax:
    volatile://module-1/
    volatile://sup-1/
    volatile://sup-active/
    volatile://sup-local/While If we need to access temp file stored at this VRAM located at the Standby supervisor we can use one of the following syntax:
    volatile://module-2/
    volatile://sup-2/
    volatile://sup-standby/
    volatile://sup-remote/
  4. NVRAM: It is an Non-Volatile Random Access Memory or NVRAM, that is located at both Supervisors and is used to store startup-configuration file.
  5. USB1 and USB2: They are two External USB Flash memories that are installed at both Supervisors (Active and Standby), and are used to store different types of files: system image files, configuration files or other user-defined files.

We can check the directories defined for the Bootflash memory as the following

N7K-1# dir bootflash:?
 bootflash:/// 
 bootflash://module-1/ 
 bootflash://sup-1/ 
 bootflash://sup-active/ 
 bootflash://sup-local/

N7K-1#

We can find here that there are 4 directories (module-1, sup-1, sup-active and sup-local), but in reality all of them have the same meaning, as mentioned before, if we need to display files stored at the bootflash located at the Active Supervisor, we can use one of the syntax (bootflash://module-1/, bootflash://sup-1/, bootflash://sup-active/, bootflash://sup-local/) as the following:

N7K-1# dir bootflash://module-1/
 16565 Jun 17 12:42:08 2014 20140617_123941_poap_4132_init.log
 1715 Jun 17 22:30:02 2014 20140617_222839_poap_4443_init.log
 16384 Jun 17 12:37:15 2014 lost+found/
 4733 Aug 16 01:00:02 2017 mts.log
 54 Aug 16 05:25:06 2017 reload_replay.cfg
 4096 Jun 17 12:39:29 2014 scripts/
 32557568 Jun 14 10:09:05 2014 titanium-d1-kickstart.7.0.1.ZD.0.216.bin
 103565618 Jun 14 10:09:06 2014 titanium-d1.7.0.1.ZD.0.216.bin
 1804 Aug 17 01:01:04 2017 vlan.dat

Usage for bootflash://module-1
 332378112 bytes used
 2865561600 bytes free
 3197939712 bytes total
N7K-1#
N7K-1# dir bootflash://sup-1/
 16565 Jun 17 12:42:08 2014 20140617_123941_poap_4132_init.log
 1715 Jun 17 22:30:02 2014 20140617_222839_poap_4443_init.log
 16384 Jun 17 12:37:15 2014 lost+found/
 4733 Aug 16 01:00:02 2017 mts.log
 54 Aug 16 05:25:06 2017 reload_replay.cfg
 4096 Jun 17 12:39:29 2014 scripts/
 32557568 Jun 14 10:09:05 2014 titanium-d1-kickstart.7.0.1.ZD.0.216.bin
 103565618 Jun 14 10:09:06 2014 titanium-d1.7.0.1.ZD.0.216.bin
 1804 Aug 17 01:01:04 2017 vlan.dat

Usage for bootflash://sup-1
 332378112 bytes used
 2865561600 bytes free
 3197939712 bytes total
N7K-1#
N7K-1# dir bootflash://sup-active/
 16565 Jun 17 12:42:08 2014 20140617_123941_poap_4132_init.log
 1715 Jun 17 22:30:02 2014 20140617_222839_poap_4443_init.log
 16384 Jun 17 12:37:15 2014 lost+found/
 4733 Aug 16 01:00:02 2017 mts.log
 54 Aug 16 05:25:06 2017 reload_replay.cfg
 4096 Jun 17 12:39:29 2014 scripts/
 32557568 Jun 14 10:09:05 2014 titanium-d1-kickstart.7.0.1.ZD.0.216.bin
 103565618 Jun 14 10:09:06 2014 titanium-d1.7.0.1.ZD.0.216.bin
 1804 Aug 17 01:01:04 2017 vlan.dat

Usage for bootflash://sup-active
 332378112 bytes used
 2865561600 bytes free
 3197939712 bytes total
N7K-1#
N7K-1# dir bootflash://sup-local/
 16565 Jun 17 12:42:08 2014 20140617_123941_poap_4132_init.log
 1715 Jun 17 22:30:02 2014 20140617_222839_poap_4443_init.log
 16384 Jun 17 12:37:15 2014 lost+found/
 4733 Aug 16 01:00:02 2017 mts.log
 54 Aug 16 05:25:06 2017 reload_replay.cfg
 4096 Jun 17 12:39:29 2014 scripts/
 32557568 Jun 14 10:09:05 2014 titanium-d1-kickstart.7.0.1.ZD.0.216.bin
 103565618 Jun 14 10:09:06 2014 titanium-d1.7.0.1.ZD.0.216.bin
 1804 Aug 17 01:01:04 2017 vlan.dat

Usage for bootflash://sup-local
 332378112 bytes used
 2865561600 bytes free
 3197939712 bytes total
N7K-1#

From the previous figures we can deduce that all of them having the same output, as in reality all of them having the same meaning but with different directories.

Create directory:

We can create a directory on the bootflash memory using the following command:

N7K-1# mkdir bootflash://module-1/TES_DIRECTORY

We can verify that the directory “TEST_DIRECTORY” is created successfully at the bootfllash memory using the following command:

N7K-1# dir bootflash://module-1/ | include TEST
 4096 Aug 16 21:20:54 2017 TEST_DIRECTORY/
N7K-1# dir bootflash://sup-1/ | include TEST
 4096 Aug 16 21:20:54 2017 TEST_DIRECTORY/
N7K-1# dir bootflash://sup-active/ | include TEST
 4096 Aug 16 21:20:54 2017 TEST_DIRECTORY/
N7K-1# dir bootflash://sup-local/ | include TEST
 4096 Aug 16 21:20:54 2017 TEST_DIRECTORY/
N7K-1#

Form the previous figure we can deduce that the newly created directory “TEST_DIRECTORY” is successfully created and can be accessible using the four syntax mentioned before, at which the directory is created 16 August 2017 at 21:20:54 and is 4096 bytes as mentioned in the output.

Copy file from local memory to another local memory:

We can copy file from bootflash memory to Volatile memory using the following command:

N7K-1# copy bootflash://module-1/mts.log volatile://module-1/
Copy progress 100% 4KB
Copy complete.
N7K-1#

From the previous figure we can deduce that we copy the file “mts.log” that is stored at the bootflash memory to the volatile memory.

We can verify that the file “mts.log” is copied successfully to the volatile memory using the following command:

N7K-1# dir volatile://module-1/
 4733 Aug 17 14:59:20 2017 mts.log

Usage for volatile://module-1
 8192 bytes used
 209707008 bytes free
 209715200 bytes total
N7K-1#

Form the previous figure we can deduce that the file “mts.log” is successfully copied to the volatile memory, at which the file is copied 17 August 2017 at 14:59:20 and is 7238 bytes as mentioned in the output.

Copy file from TFTP server to local memory:

We can copy file from TFTP server to Volatile memory using the following command:

N7K-1# copy tftp://192.168.10.1/test.txt bootflash://module-1/
Enter vrf (If no input, current vrf 'default' is considered): 
Trying to connect to tftp server......
Connection to Server Established.
TFTP get operation was successful 
Copy complete, now saving to disk (please wait)...
N7K-1#

In the previous figure we make the copy operation using one line at which we specified the full TFTP URL “tftp://192.168.10.1/test.txt”, and this command means that we need to copy the file “test.txt” that is located at the TFTP server with the IP address “192.168.10.1” to the bootflash memory.

or we can use the following syntax:

N7K-1# copy tftp: bootflash://module-1/
Enter source filename: test.txt
Enter vrf (If no input, current vrf 'default' is considered): 
Enter hostname for the tftp server: 192.168.10.1
Trying to connect to tftp server......
Connection to Server Established.
TFTP get operation was successful 
Copy complete, now saving to disk (please wait)...
N7K-1#

Here we make the copy operation using multiple lines at which we specified the source location of the file “TFTP server” and the destination location “bootflash memory”, then we specified the file name “test.txt”, then the IP address of the TFTP server “192.168.10.1”. Finally we found that the connection to the server established, TFTP operation was successful, the copy process complete and the file is saved to the disk.

We can verify that the file “test.txt” is copied successfully to the bootflash memory using the following command:

N7K-1# dir bootflash://module-1/test.txt
 650 Aug 17 15:22:50 2017 test.txt

Usage for bootflash://module-1
 332390400 bytes used
 2865549312 bytes free
 3197939712 bytes total
N7K-1#

Form the previous figure we can deduce that the file “test.txt” is successfully copied to the bootflash memory, at which the file is copied 17 August 2017 at 15:22:50 and is 44 bytes as mentioned in the output.

As well we can see the contents of the file “test.txt” using the following command:

N7K-1# show file bootflash://module-1/test.txt
### This file is used for TFTP copy test ###
N7K-1#

Save the output of show command to local memory:

We can save the output of  “show ip interface brief” command to bootflash memory using the following command:

N7K-1# show ip interface brief > bootflash://module-1/SHOW_IP_INT.txt

In the previous figure we redirect the output of “show ip interface brief” command to the file “SHOW_IP_INT.txt” that will be created and stored at the bootflash memory, at which the symbol “>” is used to redirect the output of the issued command to the mentioned location.

We can verify that the output of “show ip interface brief” is redirected to the newly created file “SHOW_IP_INT.txt” and stored at the bootflash memory and display its contents as well using the following commands:

N7K-1# dir bootflash://module-1/SHOW_IP_INT.txt
 241 Aug 16 15:22:50 2017 SHOW_IP_INT.txt

Usage for bootflash://module-1
 332390400 bytes used
 2865549312 bytes free
 3197939712 bytes total
N7K-1#
N7K-1# show file bootflash://module-1/SHOW_IP_INT.txt
IP Interface Status for VRF "default"(1)
Interface IP Address Interface Status
Vlan7 7.7.7.1 protocol-up/link-up/admin-up 
Eth2/10 192.168.10.10 protocol-down/link-down/admin-down

N7K-1#

Form the previous figure we can deduce that the file “SHOW_IP_INT.txt” is successfully created at the bootflash memory at 17 August 2017 15:22:50 and is 241 bytes as mentioned in the output, as well the output of “show ip interface brief” is successfully redirected to the file.

Move file or directory from local memory to another local memory:

We can move the previously created file “SHOW_IP_INT.txt” from the bootflash memory to the volatile memory using the following command:

N7K-1# move bootflash://module-1/SHOW_IP_INT.txt volatile://module-1/

We can verify that the file “SHOW_IP_INT.txt” is moved ans stored now at the volatile memory and no longer exists at the bootflash memory using the following commands:

N7K-1# dir volatile://module-1/SHOW_IP_INT.txt
 241 Aug 17 15:39:27 2017 SHOW_IP_INT.txt

Usage for volatile://module-1
 12288 bytes used
 209702912 bytes free
 209715200 bytes total
N7K-1#
N7K-1# dir bootflash://module-1/SHOW_IP_INT.txt
No such file or directory
N7K-1#

Form the previous figure we can deduce that the file “SHOW_IP_INT.txt” is successfully moved and stored at the volatile memory at 17 August 2017 15:39:27 and is 241 bytes as mentioned in the output, as well it no longer exists at the bootflash memory.

Configuration Rollback:

The configuration rollback feature is too important as it allows the NX-OS administrator to save the current running configuration for rollback purpose, this means that it allows the NX-OS administrator to take multiple snapshots of the running configuration in case we need to rollback the configuration to an old date/time, this means that before we make changes in the current running configuration we can take snapshot for this current running configuration and give it name and description, so that we can apply this checkpoint configuration at the future or after the changes we made in case this change caused network outage or any issue that affect the network operation. When we need to rollback the running configuration to previously saved checkpoint, we have four types of rollback we can use during the rollback process:

  1. atomic: This type of rollback tell the NX-OS to implement this checkpoint configuration only if no errors found, this means that the NX-OS will implement this checkpoint configuration to be the new running configuration if no errors occur, and it is the default rollback type.
  2. best-effort: This type of rollback tell the NX-OS to implement this checkpoint configuration normally and skip any errors that can occur.
  3. stop-at-first-failure: This type of rollback tell the NX-OS to implement this checkpoint configuration to be the running configuration normally and stop once an error occurs, this means that it will not implement the remaining configurations found after that first occurred error.
  4. verbose: This type of rollback tell the NX-OS to implement this checkpoint configuration to be the running configuration normally and at the same time give the execution logs to allow the administrator to see what the switch does during this configuration rollback.

 

Create Configuration Checkpoint:

Before creating configuration checkpoint, i enabled the EIGRP feature so that i can configure EIGRP on the NX-OS, then i can create two configuration checkpoints, one with EIGRP and the other without EIGRP configuration as the following:

N7K-1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
N7K-1(config)# feature eigrp
N7K-1(config)# router eigrp 100
N7K-1(config-router)#

We can create configuration checkpoint with name and description so that we can know the purpose or summary of that configuration checkpoint, at which i configured configuration checkpoint with name “EIGRP_CONFIG” and has description “This configuration checkpoint has EIGRP configuration” based on the following command:

N7K-1# checkpoint EIGRP_CONFIG description --- This configuration checkpoint has EIGRP configuration ---
..Done
N7K-1#

We can check the differences between the running configuration and certain configuration checkpoint using the following command:

N7K-1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
N7K-1(config)# no feature eigrp
N7K-1(config)# show diff rollback-patch running-config checkpoint EIGRP_CONFIG 
Collecting Running-Config
#Generating Rollback Patch

!! 
!
feature eigrp
!
router eigrp 100
N7K-1(config)#

Form the previous figure we can deduce that i disabled the EIGRP feature so that all the EIGRP configuration will be removed, then i use the command “show diff rollback-patch running-config checkpoint EIGRP_CONFIG” that is used to tell what are the differences between the current running configuration and the configuration checkpoint “EIGRP_CONFIG”, and based on the previous output, NX-OS tell you which commands needed to be added to the running configuration to make it the same as the configuration checkpoint “EIGRP_CONFIG” and the commands are “feature eigrp” and “router eigrp 100”.

We added the two commands “feature eigrp” and “router eigrp 100” to the running configuration and checked again the differences between the running configuration and the configuration checkpoint “EIGRP_CONFIG” and found that no differences exist as the following:

N7K-1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
N7K-1(config)# feature eigrp 
N7K-1(config)# router eigrp 100
N7K-1(config-router)# show diff rollback-patch running-config checkpoint EIGRP_CONFIG 
Collecting Running-Config
#Generating Rollback Patch
Rollback Patch is Empty
N7K-1(config-router)#

We can check the differences between the running configuration and startup configuration exactly as with the classic IOS, at which we use the command “show archive config difference”, while at the case of NX-OS we know the differences using the following command:

N7K-1# show diff rollback-patch startup-config running-config 
Collecting Running-Config
Collecting Startup-Config
#Generating Rollback Patch

!! 
!
feature ospf
feature bgp
feature eigrp
!
--More--

Form the previous figure we can deduce that i use the command “show diff rollback-patch startup-config running-config” that is used to tell what are the differences between the startup configuration and the current running configuration, and based on the previous output, NX-OS tell you which commands needed to be added to the startup configuration to make it the same as the running configuration, and the differences are “feature ospf”, “feature bgp”, “feature eigrp”, ….

Rollback running configuration using Configuration Checkpoint:

we can rollback the running configuration using previously defined configuration checkpoint using the following command:

N7K-1# rollback running-config checkpoint EIGRP_CONFIG verbose 
Note: Applying config parallelly may fail Rollback verification
Collecting Running-Config
#Generating Rollback Patch
Executing Rollback Patch
========================================================
`conf t`
`feature eigrp`
`router eigrp 100`
========================================================
Generating Running-config for verification
Generating Patch for verification
Verification is Sucessful.

Rollback completed successfully.

N7K-1#

Form the previous figure we can deduce that i rollback the running configuration using the configuration checkpoint “EIGRP_CONFIG” using the rollback type “verbose” to give the execution logs to see what the switch have done during this configuration rollback, so we found that the switch added three commands “conf t”, “feature eigrp” and “router eigrp 100”, finally the rollback completed successfully without any issues.

 

Hope that the post is helpful.

Regards

Mostafa Hamza

2 thoughts on “4-DC/Nexus Files and configuration Rollback.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s