Disclaimer: Some of the individuals posting to this site, including the moderators, work for Cisco Systems, Inc. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not those of Cisco.
- Thursday, October 10 2013
- Saturday, August 25 2012
I thought, that the ability of running Python scripts on Nexus Switches is broadly know. BUT when talking to customers about this, you figure out that it’s more or less unknow.This is a pity because this gives you huge possibilities, e.g. Collecting data for statistics or trouble shooting. Python is supported on Nexus 3000, Nexus 5500, Nexus 6000, Nexus 7000.
When you call python, please do not forget to import cisco library!
Python 2.7.2 (default, Nov 27 2012, 17:50:33)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Loaded cisco NxOS lib!
>>> import cisco
['BGPSession', 'BufferDepthMonitor', 'CLI', 'CheckPortDiscards', 'CiscoSecret', 'CiscoSocket', 'Feature', 'History', 'IPv4ACL', 'IPv6ACL', 'Interface', 'Key', 'LineParser', 'MacAddressTable', 'OSPFSession', 'Routes', 'SectionParser', 'VRF', 'Vlan', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__', 'acl', 'bfd', 'bgp', 'buffer_depth_monitor', 'check_port_discards', 'cisco_secret', 'cisco_socket', 'cli', 'dhcp', 'eigrp', 'feature', 'get_global_vrf', 'get_valid_port', 'history', 'hsrp', 'interface', 'interface-vlan', 'key', 'lacp', 'line_parser', 'mac_address_table', 'md5sum', 'msdp', 'ospf', 'ospfv3', 'pim', 'private-vlan', 'ptp', 'rip', 'routes', 'scheduler', 'section_parser', 'set_global_vrf', 'show_queues', 'show_run', 'ssh', 'tacacs', 'telnet', 'transfer', 'udld', 'vlan', 'vpc', 'vrf', 'vrrp', 'vtp']
>>> print help(cisco.get_valid_port)
Help on function get_valid_port in module cisco.interface:
Validate and return correct port here
As you see there are a lot of builtin functions, also there is a nice possibility to execute CLI command and work with the output. Here you see an example how to ping an IP and parse the output.
oCli=CLI('ping ' + ip + ' vrf ' + VRF,False)
pingStatus = oCli.get_output().split()
if pingStatus == "0.00%":
pingStatus = mac + " (" + ip + ") is reachable"
elif pingStatus == "100.00%":
pingStatus = mac + " (" + ip + ") is unreachable"
pingStatus = mac + " (" + ip + ") is not stable"
Many times I end up discussing HA and DR with customers and colleagues. Hence I decided that defining this and sharing my view on it is a good way to start this blog:
Today most IT folks mix up DR and HA, due to the possibilities the industry gave them with technologies like stretched clusters, synchronous storage mirroring etc.
High Availability (HA) is about Local Availability, Downtime Avoidance and Disaster Avoidance. Disaster Recovery (DR) on the other hand is all about Site Availability and Recovery, for example on how and where to recover from a disaster that has wiped out the entire datacenter.
Downtime avoidance and disaster avoidance is mainly driven by Operation Level Agreements (OLA) and Service Level Agreements (SLA). Whereas disaster recovery is driven by Recovery Time Objective (RTO: how long does it take to bring the application back online) and Recovery Point Objective (RPO: how long is the time between two backups, so to say how much data am I allowed to loose)
But let’s have a deeper look into this: Enhancing local availability is used for improving the uptime of an application in failure or maintenance situations. This can be achieved with technologies like clustering, vMotion and Livemigration for local sites. So this is HA and typical HA is site local, because with HA I do not react on complete outages of a site.
For situation where your complete site fails, e.g. a plane crashing on your site or a complete power blackout, DR is used to protect your data against this. You cannot achieve this with HA and stretched clusters (a cluster across two sites), because when your data is gone on the primary site there is nothing left to migrate over to the other site. Backup strategies are also part of DR. Stretched clusters (storage, compute, etc.) do not protect you against configuration failures or accidentally deleted data, because the information is immediately synchronized to the remote site.
Stretched cluster (for example an ESXi Cluster across two sites) require one to have L2 extension between both sites. As a result you end up with one virtual Datacenter spread across two physical sites. This is more or less an Active/Active datacenter, with all its benefits and drawbacks (this is a definitely another discussion for a future blog entry).
As conclusion on this HA and DR discussion:
Use HA for improving local downtime & disaster avoidance and DR for cross site disaster recovery and backup/restore strategies.
Stop mixing both strategies, because it will never give you a real DR solution. As somebody once said “ No, DropBox is not a Backup”!