• Accessing Virtual Machine Consoles from the High Availability Inc. Customer Portal

    Accessing Virtual Machine Consoles from the High Availability Inc. Customer Portal

    March 15th, 2018
    Read More

    The High Availability Inc. Customer Portal gives users the ability to access a virtual machine's console using our web interface. The Portal features two different ways to open a console.
    The first way to access the Virtual Machine console is through the Device Management section of the portal. From the home page, click the ‘Devices Management’ link on the left-hand sidebar, then click ‘Devices’.

    The first icon in the row of ‘Shortcuts’ will open the console in a separate window for that corresponding device. The console button may be opened if the icon is green. The icon will appear as disabled, with a gray background, if console access to that device is unavailable. The button may also be red, which indicates that the device is powered off.
    Virtual Machine Consoles may also be accessed by clicking on a device name on the ‘Device Management’ page. The portal will then open the management page for the selected device. The individual device page features device information, data graphs, alert and ticket history. The console can be opened by clicking on the ‘Open Console’ tab in the top menu, to the right of the device name.

    For questions regarding the customer portal, or to request a user account, please contact us at

  • VXLAN EVPN Multihoming

    VXLAN EVPN Multihoming

    March 9th, 2018
    Read More


    Cisco Nexus platforms support a feature called VPC (virtual port channel) which a pair of switches act as a single switch for redundancy and both of switches will function as an active switch.

    For Cisco Nexus 9000 in VXLAN EVPN environments, two solutions are supported:

    • Traditional VPC

    • BGP EVPN 

    Traditional VPC use consistency checking, which is a mechanism used by both switches as VPC pair to exchange configuration information and verify compatibility. BGP EVPN lacks this consistency check. BGP EVPN relies on LACP protocol to detect any miss-configuration.

    This approach eliminates the MCT link used by traditional VPC and offers more flexibility.

    BGP EVPN Multihoming:


    • EVI: The EVPN instance (EVI) is represented by the virtual network identifier (VNI).

    • MAC-VRF: The MAC Virtual Routing and Forwarding (MAC-VRF) instance is a container for housing the virtual forwarding table for MAC addresses.

    • ES: The Ethernet segment (ES) is a set of bundled links.

    • ESI: The Ethernet segment identifier (ESI) represents each Ethernet segment uniquely across the network.

    Guidelines and limitations

    • EVPN multihoming is supported on the Cisco Nexus 9300 Series switches only and it is not supported on the Cisco Nexus 9300-EX and 9500 Series switches. The Cisco Nexus 9500 Series switches can be used as Spine switches but they cannot be used as VTEPs.

    • EVPN multihoming is not supported on FEX.

    • EVPN multihoming is supported with multihoming to two switches only.

    • Cisco recommends enabling LACP on ES PO.

    EVPN Multihoming redundancy group

    The following figure shows a dual-homed topology in which VTEPs Leaf1 and Leaf 2 are distributed anycast VXLAN gateways performing IRB (integrated Routing and Bridging). Host 2 is connected to a switch which is dual-homed to both Leaf1 and Leaf2.

    EVPN Multihoming

    The switch is not aware of that the bundle is configured on two different switches. But the Leaf 1 and Leaf 2 must be aware of that they are part of the same bundle.

    To make the VTEPs aware that they belong to the same bundle link, Cisco NXOS uses the ESI and system MAC address configured on the port-channel interface.

    Ethernet Segment Identifier 

    It is a 10-byte value for bundled link that they share with multihomed neighbor. 

    LACP Bundling

    LCAP can detect ESI misconfiguration and the port-channel bundle. The LACP on the leaf switches will send the ESI configured MAC address in the hello message sent to the access switch. LACP is not mandatory with ESI. A given ESI interface shares the same ESI across the VTEPs in the group.

    EVPN Multihoming with LACP

    It is recommended to run LACP between VTEPs and access devices because LCAP BPDs have a mechanism to detect and act on the ESI misconfiguration.

    Layer 2 Gateway STP

    L2G-STP builds a loop-free topology. The STP root always must be the VXLAN Fabric. A bridge ID for STP consists of a MAC and bridge priority. For VXLAN fabric the system automatically assigns the VTEPs with a MAC address from the reserved range (c84c.75fa.6000), so each switch uses the same MAC address for the bridge ID emulating a single logical pseudo root. The L2G-STP is disabled by default.

    All L2G-STP vlans should be set to a lower priority than the fabric edge switches. Or you can set the leaf switches L2G-STP priority to 0.

    BGP EVPN Multihoming Configuration steps:
    • Enable multihoming globally: evpn esi multihoming
    • Enable BGP maximum paths. This setting enables equal-cost multipath (ECMP) for host routes. Otherwise, host routes will have only 1 VTEP as the next hop. 
      • maximum-paths ibgp x
      • maximum-paths x
    • Enable core links. This setting tracks uplink interfaces to the core. If all uplinks are down, local Ethernet segment–based ports will be shut down or suspended. This setting is used mainly to avoid black-holing south-to-north traffic when no uplinks are available.
      • evpn multihoming core-tracking
    • Configure the Ethernet segment.
      • interface port-channel x
      • ethernet-segment <es-id>
      • system-mac <es-system-mac>
    • Configure TCAM.
      • hardware access-list tcam region vpc-convergence 256
      • hardware access-list tcam region arp-ether 256 


    Sample Configuration


    Leaf 1 configuration:

    evpn esi multihoming ⇒enable the feature

    Interface X/Y ⇒  leaf switch connection to core 

    evpn multihoming core-tracking ⇒ enable core link tracking

    interface port-channel XXX  ⇒ port channel link to downstream switch

    ethernet-segment 2011 ⇒ ESI

        system-mac 0000.0000.2011 ⇒ system MAC

    Leaf 2 configuration:

    evpn esi multihoming ⇒ enable the feature

    Interface X/Y ⇒  leaf switch connection to core 

    evpn multihoming core-tracking ⇒ enable core link tracking

    interface port-channel XXX  ⇒ port channel link to downstream switch

    ethernet-segment 2011 ⇒ ESI

        system-mac 0000.0000.2011 ⇒ system MAC


    • Cisco VXLAN EVPN Multihoming white paper

    • Cisco Nexus 9000 series NX-OS VXLAN Configuration

  • Replacing a Defective UCS 6324 Fabric Interconnect

    Replacing a Defective UCS 6324 Fabric Interconnect

    February 28th, 2018
    Read More

    Occasionally, UCS hardware does go bad and recently I had the opportunity to replace a defective UCS 6324 Fabric Interconnect.

    First, some background on the hardware…

    The UCS 6324 Fabric Interconnect (FI) is a core component of Cisco's UCS mini system and extends the UCS architecture into smaller domains while providing the same unified server and networking capability as in the full-scale UCS solution.  The UCS 6324 Fabric-Interconnect provides embedded connectivity in a small UCS domain for up to 20 servers.

    Unlike the traditional Fabric Interconnects, the UCS 6324 Fabric Interconnects are installed directly into the UCS 5108 chassis, where the IO modules are installed.  (see diagram below)

    Because the 6324 Fabric Interconnects are installed directly into the chassis as part of the UCS mini design, and there are no IO modules required, there is no need for FEX cabling or L1/L2 cables between FIs.

    Before we begin to remove the defective hardware (in our case Fabric-Interconnect A), if there are QSFP licenses installed on the defective FI, we should contact TAC to have them transfer the port-licenses to the replacement Fabric Interconnect.  Since our 6324 Fabric Interconnect was not purchased with additional port-licenses, we're good here.

    Other considerations before we begin:

    • Cabling connected to the ports on the 6324 Fabric Interconnects should be labeled.

    • Obtain a full-state and configurational backup of the 6324 Fabric interconnects.

    • Verify the cluster state of the Fabric Interconnects


    To verify the cluster state of the existing Fabric Interconnects, SSH to UCS Manager (UCSM) and run the command "show cluster extended-state".  We're looking for the "HA Ready" message between the 2 Fabric Interconnects.


    PA-UCS-6324-A# show cluster extended-state 

    Cluster Id: 0xe144f0c272fc11e7-0x9678002a6a88c401

    Start time: Tue Nov 21 22:08:26 2017

    Last election time: Tue Nov 21 22:29:48 2017




    A: memb state UP, lead state PRIMARY, mgmt services state: UP

    B: memb state UP, lead state SUBORDINATE, mgmt services state: UP

       heartbeat state PRIMARY_OK


    eth1, UP

    eth2, UP


    Detailed state of the device selected for HA storage:

    Chassis 1, serial: FOX1743H1ZN, state: active



    Once we have verified and performed the tasks listed above, we are ready to start the replacement of the defective Fabric Interconnect.

    Step #1:  

    The next task is to perform a fabric evacuation on the defective Fabric Interconnect.  The caveat here is that the fabric evacuation can ONLY be performed on the subordinate Fabric Interconnect, so if the defective Fabric Interconnect is currently the primary Fabric Interconnect, we will need to change the cluster lead over to the secondary Fabric Interconnect.  This can be accomplished by switching to local management and running the command, "cluster lead b".  Be sure to run the "show cluster state" command to verify the cluster state as "HA Ready" before proceeding.


    PA-UCS-6324-A# sh cluster state

    Cluster Id: 0xe144f0c272fc11e7-0x9678002a6a88c401





    PA-UCS-6324-A# connect local

    Cisco Nexus Operating System (NX-OS) Software

    TAC support:

    Copyright (c) 2009, Cisco Systems, Inc. All rights reserved.

    The copyrights to certain works contained in this software are

    owned by other third parties and used and distributed under

    license. Certain components of this software are licensed under

    the GNU General Public License (GPL) version 2.0 or the GNU

    Lesser General Public License (LGPL) Version 2.1. A copy of each

    such license is available at and


    PA-UCS-6324-A(local-mgmt)# cluster lead b

    If the system is at 'infrastructure firmware' auto-install 'pending user Ack' stage,this action will result in upgrading and rebooting current primary. Please check the outstanding faults (scope monitoring <enter> show new-faults) and make sure the data-paths on FI-B are established properly before making it primary to ensure there is no data outage.

    Do you want to continue? (yes/no):yes

    Cluster Id: 0xe144f0c272fc11e7-0x9678002a6a88c401

    PA-UCS-6324-A(local-mgmt)# sh cluster state

    Cluster Id: 0xe144f0c272fc11e7-0x9678002a6a88c401






    To evacuate the vEths and vHBAs from the defective Fabric Interconnect, navigate to Equipment tab -> Fabric Interconnects/Fabric-Interconnect A.  

    Note that "Admin Evac Mode" can be enabled, even if the subordinate FI is to be replaced/removed because the UCSM configuration is kept on both FIs as a cluster.  

    Once the Fabric-Interconnect A has been evacuated, and the vEths and vHBAs have been moved over to Fabric-Interconnect B, we can now safely remove the defective Fabric-Interconnect.

    Step #2:

    The next step is to physically swap the defective Fabric Interconnect with the replacement FI.  Once the replacement FI has been inserted into the slot, it takes roughly 2 minutes for the FI to power-up.

    Step #3:

    After the replacement Fabric Interconnect has been powered up, the FI will boot and run POST.  Once this is completed, the Fabric Interconnect will run through a series configurational dialog messages.

    The FI should then detect the presence of a peer Fabric-Interconnect and will prompt us to add the replacement FI to the cluster.  This process also copies the configuration details over to the replacement FI.  The setup process then compares the firmware version of the replacement FI to the active Fabric-Interconnect.  If the firmware versions are not identical, the configurational dialog will prompt for an upgrade to match the peer FI version.  This process takes around 5-10 minutes.


    Enter the configuration method. (console/gui) ? 

      Enter the configuration method. (console/gui) ? console

      Installer has detected the presence of a peer Fabric interconnect. This Fabric interconnect will be added to the cluster. Continue (y/n) ? yes

      Enter the admin password of the peer Fabric interconnect: 

        Connecting to peer Fabric interconnect... done

        Retrieving config from peer Fabric interconnect... done

        Installer has determined that the peer Fabric Interconnect is running a different firmware version than the local Fabric. Cannot join cluster.

        Local Fabric Interconnect

          UCSM version     : 3.0(2c)

          Kernel version   : 5.0(3)N2(3.02c)

          System version   : 5.0(3)N2(3.02c)

          local_model_no   : Mini

        Peer Fabric Interconnect

          UCSM version     : 3.2(2b)

          Kernel version   : 5.0(3)N2(3.22a)

          System version   : 5.0(3)N2(3.22a)

          peer_model_no    : Mini

      Do you wish to update firmware on this Fabric Interconnect to the Peer's version? (y/n): y

    Updating firmware of Fabric Interconnect....... [ Please don't press Ctrl+c while updating firmware ]

     Updating images 

     Please wait for firmware update to complete.... 

     Checking the Compatibility of new Firmware..... [ Please don't Press ctrl+c ]. 

    Verifying image bootflash:/installables/switch/ucs-mini-k9-kickstart.5.0.3.N2.3.22a.bin for boot variable "kickstart".

    [####################] 100% -- SUCCESS

    Verifying image bootflash:/installables/switch/ucs-mini-k9-system.5.0.3.N2.3.22a.bin for boot variable "system".

    [####################] 100% -- SUCCESS

    Verifying image type.

    [####################] 100% -- SUCCESS

    Extracting "system" version from image bootflash:/installables/switch/ucs-mini-k9-system.5.0.3.N2.3.22a.bin.

    [####################] 100% -- SUCCESS

    Extracting "kickstart" version from image bootflash:/installables/switch/ucs-mini-k9-kickstart.5.0.3.N2.3.22a.bin.

    [####################] 100% -- SUCCESS

    Extracting "bios" version from image bootflash:/installables/switch/ucs-mini-k9-system.5.0.3.N2.3.22a.bin.

    [####################] 100% -- SUCCESS

    Performing module support checks.

    [####################] 100% -- SUCCESS

    Notifying services about system upgrade.

    [####################] 100% -- SUCCESS

    Compatibility check is done:

    Module  bootable          Impact  Install-type  Reason

    ------  --------  --------------  ------------  ------

         1       yes      disruptive         reset  Incompatible image

    Images will be upgraded according to following table:

    Module             Image         Running-Version             New-Version  Upg-Required

    ------  ----------------  ----------------------  ----------------------  ------------

         1            system         5.0(3)N2(3.02c)         5.0(3)N2(3.22a)           yes

         1         kickstart         5.0(3)N2(3.02c)         5.0(3)N2(3.22a)           yes

         1              bios                v1.022.0                v1.022.0            no

         1         power-seq                    v1.0                    v1.0            no

    Switch will be reloaded for disruptive upgrade.

    Install is in progress, please wait.

    Performing runtime checks.

    [####################] 100% -- SUCCESS

    Setting boot variables.

    [####################] 100% -- SUCCESS

    Performing configuration copy.

    [####################] 100% -- SUCCESS

    Install has been successful.



    Step #4:

    Once the replacement FI has been upgraded, it will now prompt us to enter the management IP information.  After the management IP information has been configured on the replacement FI, the Fabric Interconnect will reboot two more times and will come online in approximately 10 minutes.



     Firmware Updation Successfully Completed. Please wait to enter the IP address 

        Peer Fabric interconnect Mgmt0 IPv4 Address:

        Peer Fabric interconnect Mgmt0 IPv4 Netmask:

        Cluster IPv4 address          :

        Peer FI is IPv4 Cluster enabled. Please Provide Local Fabric Interconnect Mgmt0 IPv4 Address  

      Physical Switch Mgmt0 IP address :

      Apply and save the configuration (select 'no' if you want to re-enter)? (yes/no): yes

      Applying configuration. Please wait.

      Configuration file - Ok

     FI will now reboot after which you can access the switch.

    WARNING: There is unsaved configuration!!!

    WARNING: This command will reboot the system


    After the reboots have been completed, the replacement FI should be good to go.  To verify IP reachability, console into the replacement FI and verify that it can reach the peer Fabric-Interconnect and its gateway.


    PA-UCS-6324-A(local-mgmt)# ping

    PING ( from : 56(84) bytes of data.

    64 bytes from icmp_seq=1 ttl=64 time=5.94 ms

    64 bytes from icmp_seq=2 ttl=64 time=0.108 ms

    64 bytes from icmp_seq=3 ttl=64 time=0.109 ms

    64 bytes from icmp_seq=4 ttl=64 time=0.105 ms

    64 bytes from icmp_seq=5 ttl=64 time=0.111 ms

    64 bytes from icmp_seq=6 ttl=64 time=0.103 ms


    --- ping statistics ---

    6 packets transmitted, 6 received, 0% packet loss, time 5015ms

    rtt min/avg/max/mdev = 0.103/1.079/5.942/2.174 ms

    PA-UCS-6324-A(local-mgmt)# ping

    PING ( from : 56(84) bytes of data.

    64 bytes from icmp_seq=1 ttl=255 time=0.541 ms

    64 bytes from icmp_seq=2 ttl=255 time=0.581 ms

    64 bytes from icmp_seq=3 ttl=255 time=0.569 ms

    64 bytes from icmp_seq=4 ttl=255 time=0.648 ms

    64 bytes from icmp_seq=5 ttl=255 time=0.578 ms

    64 bytes from icmp_seq=6 ttl=255 time=0.567 ms


    --- ping statistics ---

    6 packets transmitted, 6 received, 0% packet loss, time 4996ms

    rtt min/avg/max/mdev = 0.541/0.580/0.648/0.042 ms



    Step #5:

    Once the UCS Manager is up, http into UCSM and set the "Admin Evac Mode" to "off".  This can be configured under to Equipment tab -> Fabric Interconnects/Fabric-Interconnect A.


    Step #6:

    As a final step, switch the cluster lead to Fabric-Interconnect A by running the following commands:


    connect local-mgmt b

    show cluster state

    cluster lead a


    PA-UCS-6324-A# connect local-mgmt b

    Cisco Nexus Operating System (NX-OS) Software

    TAC support:

    Copyright (c) 2009, Cisco Systems, Inc. All rights reserved.

    The copyrights to certain works contained in this software are

    owned by other third parties and used and distributed under

    license. Certain components of this software are licensed under

    the GNU General Public License (GPL) version 2.0 or the GNU

    Lesser General Public License (LGPL) Version 2.1. A copy of each

    such license is available at and

    PA-UCS-6324-B(local-mgmt)# show cluster state

    Cluster Id: 0xe144f0c272fc11e7-0x9678002a6a88c401




    PA-UCS-6324-B(local-mgmt)# cluster lead a

    If the system is at 'infrastructure firmware' auto-install 'pending user Ack' stage,this action will result in upgrading and rebooting current primary. Please check the outstanding faults (scope monitoring <enter> show new-faults) and make sure the data-paths on FI-A are established properly before making it primary to ensure there is no data outage.

    Do you want to continue? (yes/no):yes

    Cluster Id: 0xe144f0c272fc11e7-0x9678002a6a88c401


    PA-UCS-6324-B(local-mgmt)# sh cluster state

    Cluster Id: 0xe144f0c272fc11e7-0x9678002a6a88c401






    Congratulations!  You have successfully replaced a defective UCS 6324 Fabric Interconnect.

  • Tips for Meraki WLAN Deployment Part 3: Working with Floor Plans

    Tips for Meraki WLAN Deployment Part 3: Working with Floor Plans

    February 15th, 2018
    Read More

    This is the 3rd part in our series on Meraki WLAN deployment tips. The first article covered some helpful hints for assigning IP addressing to your Meraki access points. The second post had tips for AP naming, tagging, and the important of installation photos.


    In this final part in the series, we will discuss adding a floor plan to your Meraki WLAN deployment. Why do we need to do this? What value does it provide? What cool things can we do once we have a floor plan in our deployment? Read on to find out!


    To start with, let’s cover a basic fact: Adding floor plans to your Meraki WLAN deployment is completely optional. And there are at least a few cases where they are unnecessary. For example, if your deployment is covering a large outdoor space, the default Google Maps satellite view will work fine. Or if you have a small remote office with a single access point, there’s not a ton of value in having a floor plan imported. However, if your deployment involves multiple access points in the interior of a building, then adding a floor plan gives you some nice benefits.


    First, a populated floor plan lets you easily see AP locations and some quick stats of those APs. Take, for example, this floor plan display from the H.A. office in Audubon, PA:



    This screen is found at the Wireless > Map & floor plan menu item. As you can see, we can easily identify where our APs are physically located. Each AP also has a number overlaid on it. This is the current number of wireless clients associated with that access point. This can be useful for gauging client density, although there is a better tool for that which we will explore later.


    Mousing over one of the APs brings up a link to that AP’s Dashboard page, like this:


    Clicking the PA-AP07 link will take me to the details page for that AP.


    Likewise, if I want to see where a specific AP is physically deployed, I can go to that AP’s details page in Dashboard, and then go to the Location tab. The AP will be displayed on the supplied floor plan. In this example, we can easily find that PA-AP03 is the one in our reception area. If notes or tags were not added when APs were deployed, this can be very helpful!



    OK, so we can locate an AP on the map. That’s handy. What else? Well, what if we want to locate a client device within our environment? That’s easy too, once floor plans are deployed. Simply navigate to a client’s details page by going to Network wide > Clients, and then clicking on a wireless client in the list. The client detail page will be displayed, and the users most-likely location will be indicated on the floor plan:



    In this case, the user’s iPhone is believed to most likely be at the location of the blue dot. The light blue circle is the circle of uncertainty, this is the total area that the client could be in, but the system thinks the location of the blue spot is most likely. If the system can get a tighter triangulation on the user, the circle of uncertainty will get smaller to indicate higher confidence. In this eample, I know the location the device is indicated as being is exactly where this user’s cubicle is, so the system has located this user’s phone with a high degree of accuracy. This can be convenient if you need to hunt down a device/user/guest that isn’t behaving well, or if you’re asked to help locate a missing device.


    Locating a device in this way isn’t always perfect, but it gives you a good place to start if you’re trying to locate someone/something.


    Another useful thing you can do with the floor plan is see your wireless channel settings visually. If you navigate to Wireless > Radio settings, you will see a list of all access points and their assigned channels for the current network. If you hit the “Map” toggle, you will see the APs on the floor plan with their assigned channels as labels, like this:




    This can be helpful for manual channel planning to ensure you’ve got the maximum possible separation between APs on the same channel or adjacent channels, or even to review automatic channel assignments to ensure the system is not making a bad choice in assigning APs to certain channels.


    Now, one of my favorite uses of the floor plan: the location heatmap. This feature, which is found at Wireless > Location heatmap in the Dashboard, shows you a color-coded heatmap of where wireless clients are physically located in your environment.



    What can we use this for? It’s a nice real-time display of how many devices are in certain areas of your environment. It can be used to see where high-density regions might be, or if an unusual congregation of devices (and thus people) has popped up. And notice the “Play” button and timeline slider in the upper-left corner of the screen? That lets you play back an hour-by-hour view of the heatmap to see how client density has changed over time. For an office setting, that’s nifty. In a retail or industrial setting, this can be highly valuable business intelligence, letting you see where customers tend to spend time in a retail store, or by seeing patterns in movement of fork trucks in a warehouse during shifts.


    As you can see, taking advantage of the Dashboard features that can utilize floor plans can give you some nice perks in your Meraki deployment.


    Now that you have some idea of why you want floor plans configured in your Meraki WLAN networks, how do you set them up? Fortunately Meraki has already documented that procedure better than I could (with animated GIFs and everything!), so head on over to their site for the how-to.


    If you’re interested in a Meraki-based WLAN deployment, or need help tuning an existing deployment to get the most out of it, reach out to your High Availability Account Manager today. We’d be happy to help you!


  • Big Data – A Need for Speed – Hello Pure Storage FlashBlade!

    Big Data – A Need for Speed – Hello Pure Storage FlashBlade!

    February 9th, 2018
    Read More

    Fast does not always mean high IOPs. Sometimes hundreds of thousands of IOPs just is not enough. Big data applications such as machine learning, real time data processing, and backups of big data workloads needs high throughput and massive scaleout. Enter PureStorage’s FlashBlade!

    Start from 7x8TB to 75x 52TB blades!

    Have you ever asked yourself any of these questions?

    • How do you backup databases which are hundreds of TB in a timely manner?
    • How to you ingest and index Splunk, Spark or ELK logs from thousands of sources?
    • How do you ingest and process video from hundreds of video cameras?
    • How do you train machine learning systems like TensorFlow or Caffe with petabytes of source data?
    • How do you easily provide a scalable NFS, SMB, or S3-compatible storage solution to your researchers?

    If so, PureStorage FlashBlade just may be for you!


    PureStorage FlashBlade is winning and clever design on what others only hope to achieve: Multi-protocol, high-thoughput, scale-out storage.

    Using Intel System-on-a-chip, mixed with FPGAs and Flash chips to store data, PureStorage has taken a step away from the old-fashioned controller-based architecture, to provide a solution which can scale from 7 to 75 Storage Blades.

    Flashblade Chassis

    Flashblade Blade

    • Each 4u Chassis provides:
      •  8x 40gb, or 32x 10gb network ports
      • Space for up to 15 blades (7-blade minimum)
      • ~17GB/sec Throughput on a fully populated chassis.
      • Under 1500 watts


    With the latest FlashBlade PurityOS, up to 75 blades can be tied together in one fabric.  That is over 75GB/sec of read & 25GB/sec of write throughput, at just 6500 watts! 


    Rise of the Machines [Learning]…

    You may not have heard of machine learning, but you use it every day.

    • Yelp’s restaurant images are all sorted and categorized automatically
    • GMail’s “Smart Replies”, 12% of all replies, are all created by machine learning from all user’s past responses.
    • “Machine Vision” in self-driving cars
    • Email malware and virus detection
    • Automatic Translation on websites
    • Targeted advertising and geolocation

    Machine Learning is all about turning Unstructured Data into Actionable Information

    Machine Learning is exactly that.  You “train” the system with data, to make it learn patterns of recognition.  On many systems, these are massive data lakes or feeds.  Hundreds of thousands of images or documents.  Real time video from many sources. Millions of emails. This needs high throughput.    The ability to utilize NFS and S3 to store and feed your data, and ease of use PureStorage’s FlashBlade is the best solution to support your machine learning needs.

    If you are not integrating one of the machine learning tools such as TensorFlow, Caffe, aiWare, and the many others available into your architecture and design, you may be missing out on utilizing all the data you have to the fullest. Your competitors may just be getting the edge on this.



    Let’s talk databases and backups… 

    I have had the {mis}pleasure  of dealing with Oracle, in one way or another, for over 20 years.  It was a great joy when I came across Oracle ACE Ron Ekins’s blog about his performance using Oracle, DirectNFS, and FlashBlade.  His testing showed 4GB/sec of single node performance, and 8.8GB/sec of two-node RAC performance on over Direct NFS with PureStorage FlashBlade.  With this much available throughput, not only is processing and table scans amazingly fast, but backups are as well.  How fast are your Oracle dataloads and backups?

    RAC + FladeBlade – 8.8GB/sec


    Another story:

    A few months ago, we deployed a pair of PureStorage FlashBlade appliances for an enterprise customer for Splunk archive and replication tiers.  Their Hot Data and Indexers were running on

    PureStorage FlashArrays.  Within a few hours, we had hundreds of TB of scalable storage, ready to be used.   The customer was trained on the new hardware in minutes, since it is intuitive and works much like Pure1, and their FlashArray.  PureStorage has continued the ease of use that they are known for.  The customer was so happy with the performance and ease, they are filling out their chassis with blades, with many more on the horizon!

    Other customers are utilizing PureStorage FlashBlade for Veeam and Rubrik archive with great success!  Flashblade’s insanely fast throughput makes for insanely fast restore speed!


    If you want to hear success stories for everything from medical imaging, to genomics research, to drone data collection, let your account manager know or email

  • Which Cloud Strategy is Best?

    Which Cloud Strategy is Best?

    February 1st, 2018
    Read More

    Every organization has a cloud initiative.  Advertisements for the cloud can be found everywhere; during the Super Bowl, on KYW, on the banner of your Google news feed.  You cannot escape this onslaught and neither can your CEO, CFO, or the board.  The cloud initiative is poised to eliminate all your IT woes, offering 0 downtime with money leftover in your pockets.

    As a member of our regional cloud team (more on this later) I typically find myself at the table discussing cloud initiatives.  The three most popular questions at the beginning of these conversations are:

    • What can be moved?
    • What should be moved?
    • How long will this take?

    Without failure at the end of our conversation I am asked off the record which cloud is my favorite, or which cloud is best?  Before I answer these questions, I would like to walk through why you should consider moving your applications to the cloud.  Back in 2002 with the dot-com bubble burst, many IT budgets were slashed.  Since the recovery process has skipped over the IT budget, we are asked to do more with less people and a more condensed timeline. 

    The dilemma facing IT staffs today is; do you complete the afterhours upgrades this month, deploy the new financial application, merge the latest business acquisition, or check on last week’s backups and review performance statistics of the ESX hosts.  All too often the tasks that cannot be assigned a monetary value by the business, until there is a problem, is thrown to the cutting room floor to be picked up next week. 

    So how does the cloud help make my life easier? First, you gain a standardized way of operating, risk is transferred to the cloud, you never have to upgrade your hardware again, and finally you are working in a flexible operational budget. 

    The arguments against moving to the cloud is the loss of configuration flexibility across the infrastructure for your applications, No longer able to the ability to “borrow from Peter to pay Paul”, cost (the cloud can cost more), and your CFO’s favorite is capital expense depreciation. 

    When I look at the clouds available, I break them down into 4 classes.

    1. Private Clouds – Your Data Center
      • You and only you have access to the resources in a private cloud.  You will pay for resources if they are in use or not.  You still work with vendors to spec., build, document, manage, and maintain all aspects of the infrastructure or multiple infrastructures if you require any type of redundancy.
    2. Metro or Regional Clouds – This is High Availability, Inc.
      • You determine the amount of resources your organization needs for your applications and the service provider builds a pool of resources you can carve up and manage as needed.  They are an extension of your IT staff to maintain the infrastructure, network, monitoring and backups while you perfect the applications to meet business needs.
    3. Public/Hyper Clouds – Think Azure or AWS
      • They maintain massive data centers for resource allocations and you pay by the drink and the drink and the drink.   Every component, and every aspect of your infrastructure is billed by the minute it’s turned on.   These are great for variable workloads and business to consumer applications.   If you are looking to experiment with Docker or containers, this is a great way to step into the mix without a large capital expense.   If you require CDN functionality, this is the right platform.   And keep in mind that you are still responsible for all the infrastructure upgrades and backups.  They just take care of the hardware. (by the minute)
    4. SaaS Clouds – Think O365 or
      • These applications that are hosted by the software developers are great solutions for IT organizations that are already taxed with internal projects, M&A and working with the business to drive functionality to the end users.  

    Every cloud (albeit I am a bias) will not work for all applications.  So, to answer one of my early questions "Which one is my favorite"?  The answer is simple, the cloud that runs my application the best.  All too often we get caught up in the “religious wars of I.T.”  I’m an “insert OS/Cloud/Product line” fan boy or girl. 

    I challenge you to take a step back and ask the question: Which platform is best for my application?  It could be Google, private cloud, or a regional cloud like High Availability, Inc.

    Understanding the options, and making an informed decision for your business is the end goal.  Find the right cloud for you by making sure you understand what will work best for you.

    Need to discuss your options more? Reach out to your account manager or contact us at 

  • Critical Cisco ASA Security Vulnerability

    Critical Cisco ASA Security Vulnerability

    January 30th, 2018
    Read More

    On January 29th, 2018 Cisco made public a security vulnerability disclosure for the ASA and Firepower security appliances. This is a pretty severe vulnerability. This blog provides some basic information about the vulnerability and details on how to determine if your environment is at risk.

    What is the vulnerability?

    In short, it potentially allows a remote attacker to execute arbitrary code on an ASA and/or create a denial of service (DoS) condition by rebooting the firewall at their whim. It requires an attacker to send a series of crafted XML packets to the firewall, but the attacker does not need to know any authentication credentials for the firewall to be able to run the attack. Also, if the affected feature, AnyConnect VPN, is configured the attacker can’t easily be blocked from executing the attack.

    How severe is it?

    The vulnerability is pervasive in ASA code, affecting basically any release that is more than a few days to a few weeks old. It affects AnyConnect VPN, a very common feature that many customers rely on. Additionally, this vulnerability allows a remote, unauthenticated attacker to take complete control of and/or run arbitrary software code on the firewall. This combination of elements makes this a pretty severe threat. Cisco has rated this as a 10 on the CVSS scale, which is the maximum severity rating for a security vulnerability, industry-wide.

    Is this attack in the wild yet?

    It doesn’t appear to be. This disclosure was done based on the normal responsible disclosure process. The researcher that identified the vulnerability informed Cisco some time ago, and Cisco has created and published fixed software releases. On February 2 (that’s this Friday!), the researcher will present his findings at an information security conference in Europe. After that presentation, enough detail will be available that attacks in the wild will likely be possible. This gives administrators a couple days to patch their systems if they are behind on software. If you act now, you should be able to close this exposure before it is likely to hit you.

    Am I at risk?

    There are two factors that determine if your firewalls are at risk:

    1) If you are running software versions prior to the versions named in the “First Fixed Release” column of the table below.

    To find your software version, you can SSH to your firewall and run the “show version | include Version” command as shown in the example below:

    ciscoasa# show version | include Version
    Cisco Adaptive Security Appliance Software Version 9.2(1)

    The firewall in the above example would be vulnerable.

    Alternately, you can log into the ASDM GUI and look in the upper-left pane of the Device Dashboard Home tab. You’ll see your device version like this:

    In the example shown above, this firewall is running 9.6(4), which is not vulnerable.

    If you are running the Firepower Threat Defense (FTD) software on your ASA or Firepower appliance, this table shows the version info.

    You can check the version by running the “show version” command:

    > show version
    ---------------------[ ftd ]---------------------
    Model : Cisco ASA5525-X Threat Defense (75) Version 6.2.2 (Build 362)
    UUID : 2849ba3c-ecb8-11e6-98ca-b9fc2975893c
    Rules update version : 2017-03-15-001-vrt
    VDB version : 279

    2) If you are running an affected software version (as described above), and the Cisco AnyConnect SSLVPN is configured, then you are vulnerable. To determine if AnyConnect is configured, you can run the “show run webvpn” command from the command line.

    This is an example of a firewall that does not have AnyConnect enabled, and thus is not vulnerable:

    FW-5512-1# show run webvpn


    This is an example of a firewall that does have AnyConnect enabled, and thus is vulnerable:

    PA-FW-5512-1# show run webvpn

    enable OUTSIDE

    anyconnect image disk0:/anyconnect-win-4.3.02039-k9.pkg 1 regex "Windows NT"

    anyconnect enable

    tunnel-group-list enable


    If any output is shown under the “webvpn” configuration stanza, AnyConnect is configured and the firewall is exposed if running a vulnerable version of software.

    How can I mitigate this vulnerability?

    The best way to mitigate this vulnerability is to upgrade your ASA software (or patch your FTD software) to a fixed version. ASA code upgrades are straight-forward as long as you are already on a code train that has a fixed release. If you are running a very old ASA version (like 8.x or 9.0), some analysis to determine the impact of an upgrade may be necessary and H.A. can assist with that.

    If you are running FTD, can apply the hotfix patches listed in the FTD software table above.

    Alternately, if your firewall is vulnerable and has AnyConnect (the “webvpn” command) configured, but you are absolutely sure you are not using AnyConnect VPN, you can simply disable AnyConnect by entering the “no webvpn” configuration command from configuration mode. This is only an option if you are not using AnyConnect VPN (either client-based or clientless) on your firewall. If you rely on AnyConnect VPN for your business functions and you execute the “no webvpn” command, you will probably have a bad day. If you’re unsure, please let me know and we can have an H.A. engineer help assess your situation.

    There are no other known workarounds to secure a vulnerable software release that is running the AnyConnect feature.

    Where can I find more information?

    Here is the link to Cisco’s public PSIRT alert:

    Here is the link to Cisco’s BugDB report (you need a Cisco login to view this):

    This is a link to the upcoming researcher’s presentation session disclosing the hack:

    Need more assistance? Reach out to your H.A. account manager or to schedule a potentially necessary ASA/Firepower upgrade.

  • Tips For Meraki WLAN Deployment Part 2: Naming, Tagging, and Installation Photos

    Tips For Meraki WLAN Deployment Part 2: Naming, Tagging, and Installation Photos

    January 25th, 2018
    Read More

    In our last installment, we covered IP addressing for Meraki access points. In this article, we will discuss a few of the finer details of AP deployment, specifically: AP naming, AP tagging, and installation photos. Taking these elements into consideration during deployment can really help make management of the network easier down the road.

    Before deploying APs, you should have already added the access points to your Dashboard Inventory and then deployed them to a Network in your Meraki Dashboard. Now, we’re ready to go hang access points. If you just go around, hang up your APs and power them on you’re going to have an AP list that looks like this (visible in Wireless > Access points):

    While this network will work fine once SSIDs and other configuration settings are defined, it’s very challenging to live with a network where the APs have no identifiers other than their MAC address. Some of you reading this may think no one leaves their APs unnamed, but I encounter it all the time in Meraki and other vendors’ wireless environments at customers.

    Now, one way to deal with this is to take note of the Serial number or MAC address of each AP at the time of installation and then later, go through the Dashboard and re-name each AP. That works, but it requires additional tracking and paperwork. It’s far easier to take care of the name and other configuration details at install time. And the easiest way to do that is with the Meraki Mobile App.

    To use the Mobile App for deployment, download it from your respective mobile App store. It is available for both Apple and Android devices.

    Once logged into the app, you’ll see a list of your APs. What I like to do is find each AP in the list as we’re installing it. Just take a look at the last 2 bytes of the MAC address for the AP you’re hanging, like 0c:f0 in the example above.

    Now, in the app, tap that AP and look at the AP details. It will look like this (note these are iPhone screenshots, the Android flavor might look slightly different):

    As you are putting up the AP and powering it up, go ahead and click the pencil icon in the upper right corner of the screen:

    Name the access point however you’d like. In general, I recommend at least a unique identifier for the AP, like “AP04” or “AP-11” and some sort of text location key like “Reception.” In other WLAN platforms, I’ll usually recommend a big string of identifiers like a site code and floor designation, like “PHL-FL4-AP04-Reception” or something, but due to some unique features in the Meraki Dashboard you don’t have to do this if you don’t want to. Once you’ve entered the name, it will be reflected in the app (and the Dashboard):

    Why don’t we need site codes and floor designators and everything in the AP name? Well, see the next few fields in the AP details? Like Tags and Location? These help us out a ton. The location field is easy. Key in the street address of the AP (or use the “Use my Current Location” button which attempts to resolve your address via the phone’s GPS).

    When it comes to tags, clicking that field will enter a screen to search for and define tags:

    We might assign several tags, such as:

    Why apply tags this way? Well, we can use tags for multiple uses in the Meraki Dashboard. For one thing, we can search the AP list based on the tags. So perhaps we want to find all the APs on the main floor of our office in the AP list? We can just search for that tag:

    So, these tags can take the place of trying to encode floor into the device name, keeping the device names more concise and shorter. Why tag the mounting type? Well, perhaps we want to send a tech over to take some action on the AP. It might be nice to be able to easily see whether it’s mounted to the wall or ceiling. Tagging the AP to indicate it’s in an area guests may be present can be used in the Wireless > SSID Availability menu to limit the visibility of certain SSIDs to certain areas of the building, like this:

    We might choose to tag APs as being in a VIP area, or in a high-density region, or visible vs. hidden, etc. There is no limit (that I know of) to the number of tags you can assign, so go crazy! Generally, I say if more than one AP will share some attribute, it’s worth assigning a tag for it.

    Finally, while we are still at the installation point of the AP, it’s a great time to use another handy feature of the mobile app. In the AP details page is a “Photo” box. If you click that, it will open your phone’s camera so you can take a picture of the AP. Here’s a tip: Take the photo from a wide enough vantage point that you can see some detail to clue you in to where the AP is mounted. A picture of an AP on a single 2x2’ ceiling tile isn’t very helpful. One that shows that the AP is behind the reception desk or at an intersection of hallways if very helpful. The key is that getting a close-up of the AP helps nothing, but getting a picture of the area the AP is in is very helpful. Once the photo is taken, it will appear in the AP details page of the App:

    More importantly, it’s also visible in the Location tab of the AP details page in the Meraki Dashboard:

    Again, this is exceptionally helpful for easily finding the AP when doing any maintenance in the future, especially when managing remote sites where the administrator may not frequently visit. Imagine being able to send an on-site tech resource a photo of the AP you need replaced to help them identify the right one!

    Once these details have been collected, you can move on to the next AP. Of course, a team of installers can be doing this at multiple locations at once to speed installation.

    As you can see, taking advantage of Meraki’s built-in tools for installation and AP management can be very helpful in future operations. A little legwork up front when deploying can pay big dividends down the road a bit.

    Next time, we will cover the importance of adding floorplans to your Meraki WLAN configuration, and the value you can derive by doing so.

Join the High Availability, Inc. Mailing List