How to backup brocade switch config

Brocade switches have become one of the most widely deployed components in most Storage Area Networks (SANs). One thing that has led to Brocade’s success is their robust CLI, which allow you to view and modify almost every aspect of their switch. This includes zoning configurations, SNMP attributes, domain ids, switch names and network addresses, etc. All of this configuration information is necessary for the switch to function properly, and should be periodically backed up to allow speedy recovery when disaster hits. Each Brocade switch comes with the “config Upload” and “config Download” commands to back up a switch configuration to a remote system or to restore a configuration from a remote system. Config Uploads has two modes of operation: interactive mode and automatic mode. To use the interactive mode to upload a config from a switch named switch1 to an ftp server with the IP address 1.2.3.4, config Upload can be run to walk you through backing up the configuration:

switch1:admin> **configupload**

Server Name or IP Address [host]: **1.2.3.4**

User Name [user]: **matty**

File Name [config.txt]: **switch1_config.txt**

Protocol (RSHD or FTP) [rshd]: **ftp**

Password:

Upload complete

After the configuration is uploaded, you will have a text file with you switches configuration on the remove server:

$ ls -l sw

-rw-r--r-- 1 matty other 7342 Jul 7 09:15 switch1_config.txt

To restore a configuration, you can use the config Download command. Both of these commands allow the parameters to be passed as arguments to the script, so they are ideal for automation (there is a backup script on the Brocade support site that can be used to automate configuration backups).

At exit () stage right. Or how my Python program leaked file descriptors.

A year and a half ago I started using Prometheus and grafana to graph metric data. This combination is incredibly powerful and I have been absolutely blown away by the amount of actionable intelligence I’ve been able to convey in our dashboards. Prometheus has a number of exporters which can be used to retrieve metric data from remote endpoints and stash it in its highly optimized time series database. There are exporters for Mongo DB, Postgres, v Sphere, Nginx, HAProxy, JMX as well as numerous other applications. If it’s a popular application there is most likely an exporter for it. If an exporter isn’t available the Prometheus developers have made it crazy easy to develop new ones with Python and Go.

I recently started playing with pyvmomi which is a Python SDK for the VMware v Sphere API. The SDK allows you to view and manipulate all aspects of v Sphere programmatically. This allows you to automate things like collecting and graphing host and VM performance data, adding disks, putting hosts into maintenance mode or generating common reports. It’s powerful stuff! Being super curious I decided to write a Prometheus VM performance metrics exporter so I could overlay business metrics on top of HTTP responses which could then be laid on top of VM and host performance metrics. After a couple hours of hacking my Flask-based exporter was spitting out VM performance metrics. Or at least that’s what I thought. Periodically the exporter would die and the following stack trace would be written to the console:

1.2.3.4 - - [18/Mar/2018 01:10:48] "GET /metrics HTTP/1.1" 200 -

Traceback (most recent call last):

  File "/usr/lib64/python2.7/SocketServer.py", line 295, in _handle_request_noblock

    self.process_request(request, client_address)

  File "/usr/lib64/python2.7/SocketServer.py", line 321, in process_request

    self.finish_request(request, client_address)

  File "/usr/lib64/python2.7/SocketServer.py", line 334, in finish_request

    self.RequestHandlerClass(request, client_address, self)

  File "/usr/lib64/python2.7/SocketServer.py", line 651, in __init__

    self.finish()

  File "/usr/lib64/python2.7/SocketServer.py", line 710, in finish

    self.wfile.close()

  File "/usr/lib64/python2.7/socket.py", line 279, in close

    self.flush()

  File "/usr/lib64/python2.7/socket.py", line 303, in flush

    self._sock.sendall(view[write_offset:write_offset+buffer_size])

 My code was leaking file descriptors because at exit () was leaving around references to the object that encapsulated the file descriptor associated with the socket. Commenting out at exit () fixed my issue and the code is now working splendidly. These types of issues pop up during development and it’s incredibly fun debugging them! I learned a ton about the Python debugger during this debugging session and became much more familiar with the code for various Python modules. I also got to read the vast majority of the PyVim and pyVmomi source code which made developing this a snap! At exit (), stage right.

Some Services: shutdown unix command, brocade zoning commands, types of zoning in san, cisco zoning commands, vmax3 provisioning steps, snapvx, san zoning, unix flavors, timefinder snapvx, san storage explained, storage provisioning steps, emc snapvx, san zoning, symsg commands, how to backup brocade switch config, snapvx step by step, vmax snapvx, san zoning steps, gatekeeper device, zoning explained, emc vmax3, vsan vs zoning, dell emc vmax3, difference between vmax and vmax3, thin provisioning explained, data sovereignty requirements

Contact Us:

Email Us: contact@sajidiqubal.com

Website: https://sajidiqubal.com/