- January 30th, 2018Read 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
anyconnect image disk0:/anyconnect-win-4.3.02039-k9.pkg 1 regex "Windows NT"
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 firstname.lastname@example.org to schedule a potentially necessary ASA/Firepower upgrade.
- January 25th, 2018Read 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.
- January 23rd, 2018Read More
Earlier this month, security researcher Jann Horn from Google’s Project Zero reported the discovery of some serious vulnerabilities in most modern CPUs, most notably Intel. According to researchers, “virtually every user of a personal computer” are at risk.
The vulnerabilities, which are now collectively being referred to as Meltdown and Spectre, exploit performance enhancement features. The vulnerabilities could give hackers access to passwords, photos, and other sensitive data if exposed. Intel CPUs, which drive most computer platforms in the market today, are most heavily affected because they have a few tweaks that AMD/ARM CPUs do not. ARM CPUs are more common in mobile devices, and they are apparently not affected by the Meltdown attack, but are mostly vulnerable to the Spectre attacks.
These attacks allow one process to access data, including memory page contents, that would otherwise be restricted. According to Google’s research, this could even extend to the point of breaking the VM isolation boundary, e.g. a VM running malicious code for this attack may be able to access memory of another VM on the same host. This is detrimental for data centers and even worse for cloud platforms.
Cisco was one of the first networking vendors to come forward with comments on the situation. They assured end-users that there is no attack vector on their appliance platforms unless another vulnerability to execute arbitrary code is first exploited. In other words, these attacks require local code to run on the target machine. Since routers, switches, firewalls, and load balancers generally do not allow just anyone to run a piece of software, an attacker would need to first use another exploit to enable the attacker to run a piece of arbitrary code, and then could theoretically execute one of these new attacks. Such arbitrary code execution vulnerabilities are found from time to time, but keeping up with software updates on networking appliances should prevent most attacks. This also goes for virtual appliances (such as ASAv, CSR1000V, NGFWv, etc.). Though Cisco acknowledges that if the virtual server platform these systems are running on is compromised, the virtual appliances could be impacted.
One exception to the limited impact on routers and switches is those that can run user-specified processes in containers, such as the Open Agent container feature on some Cisco Nexus switches or Open Service containers on Cisco ASR routers. Always make sure you run software from trusted sources in containers on your network equipment.
That leads us to where the real impact is: server platforms
Attackers leveraging Spectre and Meltdown will primarily be targeting servers. Even though they are relatively difficult to execute, these attacks still have the potential to surface. Since server OS’ can, by nature, execute arbitrary code, these exploits can be run on a system that has that malicious code placed on them in some way. As of right now, no viruses/worms/malware are known which use these attacks, but it’s probably just a matter of time. These exploits cannot be run just by visiting a website, viewing an email, etc., they need code to run locally on the target machine. But, typical malware insertion methods (whether a worm or phony email attachments) could be used to get the code to a target machine when combined with other attacks.
UCS servers are vulnerable. This is because, like most servers today, they have Intel CPUs. This is not Cisco’s fault, but they use the impacted CPU components, like most every server issued since around 1995. Per the Cisco PSIRT linked above, there will be microcode updates available on February 18th for most Cisco server platforms, which, when applied in concert with applicable OS updates, should mitigate the vulnerabilities. The UCS update will be a BIOS update that updates the CPU microcode.
Mitigations and Mitigation Impacts:
For Meltdown, the easiest mitigation is an OS patch. Apple, Microsoft, and Linux all have patches available. Operating Systems derived from Linux will need to be updated once the upstream updates are incorporated into their builds. This is the case for many embedded platforms (including some Cisco routers, switches, etc.).
There is a CPU performance impact since the mitigation is to disable performance features. The extent of that performance hit is highly dependent on workload. Apparently, a single-workload system or one which does limited context switching (e.g., an end-user laptop/desktop) will not see a significant impact on the performance front. Our engineers suspect that dedicated network appliances (routers, switches) will not see much impact even when they are eventually patched at the OS level for the same reason.
Where is gets concerning is the server/data center/virtualization environment. Here, context switching is very frequent due to the multiple workloads running on each CPU. These mitigation patches require not only disabling some performance enhancements in the CPUs, but require doing MORE work to secure memory contents before switching to a different task. The numbers generally floating around for impact are 5-30% - that’s a lot. Again, it is hard to predict the impact on a specific workload.
Here is a graph showing the impact to two server instances before and after OS patching:
You can see a 10-20% jump in CPU. Ouch.
Click Here to see more examples of impacted workloads. Some have a negligible impact, and others are significant.
In the link above, Redis and PostgreSQL (both database platforms) saw the most impact.
Mitigating the Spectre attacks is more difficult and no specific mitigations have been released yet for most platforms.
So, the potential here is that everyone loses effectively CPU capacity in their compute environments. We can’t predict how much, but potentially enough to require a larger server farm to handle a workload than was previously required. Once patches are applied, end-customers will start to see the impacts to their workloads and will have to adjust future sizing appropriately – or in the worst case, they may need to backfill for “lost” CPU capacity if their workloads were already taxing their CPU resources.
Tips going forward:
- Keep an eye on the PSIRT page for Cisco details
- Conduct patch operation system procedures ASAP (despite the potential performance hit)
- Reach out to your H.A. account manager to set up any upcoming UCS updates
- January 11th, 2018Read More
“If you haven't any charity in your heart, you have the worst kind of heart trouble.”
- Bob Hope
One of the main reasons I joined the High Availability, Inc. team was because of the company culture. Having worked with High Availability, Inc. closely during my years at NetApp, I was able to see first-hand how strong that culture was. In my opinion, company culture encompasses many aspects - from positive employee morale, to the readiness to support your teammates and, ultimately just having employees who love going to work every day. However, beyond this, another important factor to me personally is a company’s willingness to give back charitably to both their community and worthy causes.
Charity is a huge part of my life outside of work. Since 1989 my family and close friends have run a charity supporting brain tumor research in memory of my brother called the JAG Fund. Because of this, I’ve always valued the charitable efforts in my professional life, and High Availability, Inc. is certainly no different. After joining the team, I quickly realized that giving back was just as important to High Availability, Inc.
Here are a few examples that prove this….
As mentioned previously, my entire family is deeply involved in the JAG Fund. Every year, we host a Black Tie-Gala to raise both support and awareness for brain tumor research. I was thrilled when my teammates at High Availability, Inc. pledged their support for the JAF Fund through a corporate sponsorship towards our Black-Tie Gala! Not only did H.A. support the JAG Fund financially, but they also attended the event. In fact, my boss, Steve Eisenhart, was rated as one of the top dancers that evening and the High Availability, Inc. table was by far the most supportive during our silent auction. They even set a record for their winning bids!
A second example was High Availability, Inc.’s partnership with Tech Impact, a non-profit organization headquartered in Philadelphia created to provide cost-effective IT support for other non-profit organizations. Tech Impact also helps help young urban adults move into a career in IT through their ITWorks Program. Having supported Tech Impact prior to coming to High Availability, Inc., I knew how worthy of an organization it was, so I was thrilled when the executive team at H.A. approved a sponsorship for the annual Tech Impact Luncheon. I was fortunate enough to attend the event with several other members of our team and even a few customers. It was amazing to see first-hand the positive impact of our contribution!
Lastly, but most impressive in my opinion, was High Availability, Inc.’s support of Hurricane Harvey relief efforts. H.A. specifically contributed to the J.J. Watt Foundation. The aftermath of Hurricane Harvey was absolutely devastating for the state of Texas. The Category 4 storm dumped over 27 trillion gallons of rain over Texas, and forced over 30,000 people to seek temporary shelter.
After the storm passed, High Availability, Inc. acted immediately. The team set up a relief fund program for those affected by Hurricane Harvey, and even matched each contribution dollar-for-dollar. Within just a few minutes, the H.A. team donated over $3,000!
“Everyone stepped up and was happy to help in any way they could,” said Greg Robertson, CFO and Founder of High Availability, Inc. “I feel very fortunate to be working with individuals who see the importance of helping those in need.”
Within three days, High Availability, Inc. had raised exactly $10,000!
High Availability, Inc. plans to double our charitable efforts in 2018. In fact, Steve Eisenhart, CEO and Founder of High Availability, Inc., has even implemented the first ever “H.A. Challenge”, which encourages employees to give back a full working day to a local charity through volunteering.
Of course, these aren’t the only examples of H.A. giving back but they are the top 4 that I’ve seen since joining the organization just over 18 months ago. Pretty impressive and a true example of the company embracing a charitable culture!
- December 29th, 2017Read More
Meraki cloud-managed network infrastructure has brought a new level of manageability to the network, and many of High Availability’s customers have found out just how easy it is to operate a Meraki-based network infrastructure. For this series of articles, I wanted to recap a few tips for making the deployment go smoothly as well. Listed below are five often-overlooked topics essential for a complete and trouble-free Meraki installation.
- AP Addressing (Static or DHCP)
- Installation Photos
We will be discussing each of these topics in the next few blog articles.
By default, Meraki access points will request an IP address through the Dynamic Host Configuration Protocol (DHCP). If you are putting your APs on a client-serving network (which can be OK in a small office environment), that’s usually all they need to get started. However, larger, more complex network designs often dictate that access points’ management interfaces live on a dedicated AP VLAN or maybe a common infrastructure management VLAN. In those cases, DHCP may not be enabled by default. There are a few options in this situation.
First, DHCP can be enabled for the VLAN. If this is done, the approach I like to take is to set that DHCP scope up on the router or layer 3 switch serving the VLAN, rather than on a Windows AD server or similar. Why? Well, the simple fact is that VLANs used for infrastructure are easy to ignore, and sometime in the future the DHCP scopes might be migrated or the server decommissioned, with little or no attention paid to the DHCP scope defined for a non-user VLAN. In this case, the stability of a layer 3 switch to provide the DHCP may be desirable. Also, unlike client workstations, there is no strong need to have reverse-DNS PTR records registered for the APs or anything like that so putting the APs’ DHCP scope on a network device keeps all the configuration needed for the APs “in the network.”
Now, there may be times when DHCP addressing for your access points is not feasible or desirable. One support issue I’ve encountered more than once occurs when the DHCP scope that supplies IP addresses to the APs is exhausted (this usually occurs when a client-facing subnet is used for the access points). Eventually the AP is unable to renew its IP address, and it stops working. If this is the only option for addressing, DHCP may not be a good choice. Perhaps security policy prohibits the management network from providing the DHCP service. Or maybe administrator simply prefers that all infrastructure devices have fixed IP addresses. In this case, there are two ways to assign static IPs to your Meraki APs.
If you can initially provide an IP address via DHCP, the AP will check into the Meraki Dashboard, and assigning a static IP is simple.
First, go into the access point details page under Wireless > Access points, and click the access point in question. To the left of the main browser pane, you will see the IP settings. Click the pencil icon to edit them:
A small box will appear, in which you can select the addressing type. Here, you can select “Static IP:”
The box will expand and you can enter the AP addressing details, like this:
After filling in the appropriate details, click the Save button. The AP will reboot, and should come up at its new, static IP address. Rinse and repeat for the other APs. Note that the “VLAN” field only needs to be populated if the AP’s management VLAN is not the untagged/native VLAN for the connected switch port.
What about an instance where you cannot bring the AP up on DHCP initially? If the AP must be statically addressed from the start, before it can even reach the Meraki Dashboard, you need to locally connect to the AP.
In this case, power up the factory-fresh AP and it should begin broadcasting an SSID of “Meraki Setup.” Connect to this SSID, and then open your browser and go to “ap.meraki.com.” You should see a status page like this:
Switch to the “Configure” tab at the top, and when prompted for a Username and Password, enter the serial number of the AP under the Username and click OK, like this:
The Configure screen will allow you to choose the Uplink addressing mode:
As before, select Static, then fill in the addressing details and click Save at the bottom of the screen. After restarting, your AP should be able to connect to the Internet and the Meraki Dashboard via the statically-programmed IP address.
Hopefully, this blog article has been helpful in getting your Meraki access points addressed and connected to the Meraki cloud in a reliable manner. As always, the networking experts at High Availability are available to assist you with your networking project.
Next time, we will cover tips for deploying your Meraki hardware using the Meraki mobile app and taking advantage of some special Meraki features!
- December 27th, 2017Read More
The placement of Voice Infrastructure devices on the network presents some challenges to voice engineers. They must satisfy the security requirements of the Enterprise while providing simple and uninterrupted access to external systems such as PSTN SIP trunks and internal systems such as VoIP phones and servers. In this article, we discuss Voice security from a Routing and Switching point of view. This article is not about internal Voice security mechanisms such as authentication and encryption.
Obviously, we do not recommend terminating external SIP trunks on Unified Communications Manager servers directly. Therefore, in this article, we will talk about the placement of Voice Gateways on the network and the interaction between the various Voice components. We consider the Voice Gateway to be a CUBE that terminates all media streams.
Placing a Voice Gateway on the internal network is a major security risk. It exposes your entire enterprise to an external entity even if that entity is your trusted voice carrier. Therefore, all our designs require placing the Voice Gateway on a DMZ behind a NextGen firewall such as Cisco ASA with Firepower services. First, the ASA does SIP inspection and can deploy security ACLs to filter inbound traffic and only allow connections from specific IPs such as your Voice Gateway SIP signaling and media IP. Second, NextGen firewalls can detect and protect against malware embedded in the data stream.
The following scenarios are based on some very common WAN designs that we have seen deployed at our customer sites of various sizes.
I. Dedicated PSTN SIP trunk via a dedicated Voice Gateway.
This is the simplest setup. A primary dedicated SIP trunk over a private T1 or Ethernet WAN connection and an optional backup SIP trunk via the Internet. Note that the backup SIP trunk can be hosted on a separate Voice Gateway too to provide hardware redundancy. The following diagram illustrates this design.
In this scenario, the Voice Gateway is on a dedicated DMZ behind the NextGen firewall. The firewall has SIP inspection turned on and only allows inbound SIP control traffic sourced from the inside IP of the Voice Gateway to the CUCM. Similarly, an outbound ACL controls SIP signaling traffic from CUCM to the Voice Gateway. SIP media traffic will be automatically allowed based on the negotiated RTP ports.
II. Voice Gateway is co-located with your MPLS router
Today’s most common WAN designs utilize MPLS as the underlay infrastructure for Enterprise WAN connectivity. It is also not uncommon for an MPLS carrier to provide PSTN SIP trunks over the same physical fiber or copper cable. Therefore, to save on hardware your Voice Gateway might be co-located with your WAN ISR router. If your MPLS/SIP provider separates the two functions and terminates each on a separate VLAN, then it is possible to use VRF (Virtual Routing and Forwarding) to virtualize your router: The Voice portion can use the Global Routing table while the MPLS portion can use a VRF. Otherwise, both technologies can use the Global routing table. The following diagram illustrates this former scenario:
In the above diagram, we go a step further by separating MPLS and Voice Routing tables. Note that we are only discussing Voice Security. You still need to configure Quality of Service (QoS) to prioritize your VoIP traffic whether you are using a VRF or not. QoS is outside the scope of this article.
As in the previous scenario, the security ACLs, firewall inspection, and Firepower services protect the Enterprise Voice Infrastructure from external attacks.
III. Dedicated Voice Gateway and a shared MPLS/SIP connection
This is a very common design in which the customer orders an MPLS and a SIP trunk from the same carrier as in the 2nd scenario above. However, the customer is using a dedicated Voice Gateway with an optional backup SIP trunk to the same carrier via the Internet.
The following diagram illustrates this solution:
In this scenario, a single Voice Gateway sits behind a NAT firewall. The VG communicates with the SIP provider via the “out_voice” interface and communicates to CUCM and the IP Phones via the “in_voice” interface. NAT is only used when communicating over the backup SIP trunk via the Internet connection. With recent firewall firmware, we see no issues in NAT’ing SIP control and media traffic. As in all previous scenarios, the Voice Gateway sits on a DMZ segment and the CUCM sits on a dedicated internal VLAN. Note that the “in_voice” interface can be connected directly to the internal LAN without going through the firewall.
While there are many ways to protect your Voice Infrastructure, we have highlighted three common scenarios and listed the advantages of having Voice control and media traffic inspected by a NextGen firewall. Other more complicated designs can be derived from the above scenarios especially if you combine your DMVPN, MPLS, or iWAN technologies into a single device.
- December 21st, 2017Read More
Last week, High Availability, Inc. welcomed customers and partners alike to the Movie Tavern in Collegeville, PA for an advanced screening of Star Wars: The Last Jedi. The annual movie premiere has been a cornerstone event for High Availability, Inc. since 2012. It’s a chance for the H.A. team to thank customers for their business during the past year and allows for everyone, even our partners, to kick back and relax.
“Our movie premier event is a great chance for our employees, customers, and partners to get together and escape the end-of-year busyness.” Said Greg Robertson, Chief Financial Officer for High Availability, Inc. “The event creates the perfect mixture of industry news, education, and fun,” Robertson added.
However, the event wasn’t as relaxing for our speakers! H.A.’s infamous “Ignite-Style” presentations took place before the film. Speakers from Cisco, NetApp, Quantum, Riverbed, Rubrik, Varonis, Veeam, and High Availability, Inc. had to present an emerging technology or solution from their organization. Although, the H.A. team set forth some abnormally strict rules! Each speaker had only 5 minutes to present and had to utilize 20 slides – no more, no less. The slides were timed to advance every 15 seconds whether the speaker was ready or not.
“The Ignite format was challenging for the speakers, but helpful for the audience.” Explained Pat Hopkins, a speaker from Quantum. “The speakers had to prepare a short, fast moving but focused message to get their point across. With this style, the audience can quickly absorb valuable information about potential solutions they could bring back to their own organizations. Great format,” Hopkins added.
The most talked about presentation of the evening, which was delivered by Bob McCouch from High Availability, Inc., discussed the most popular emerging technologies from each year a Star Wars film was released. McCouch, a Principal Technologist for High Availability, Inc., discussed everything from the rise of the modern cell phone, big data, and the internet of things.
In short, the High Availability, Inc. movie premier was an enormous success! We can’t wait for next year! Thanks to all our customers and partners for participating in the event.
- December 19th, 2017Read More
In the world of backup and recovery, deduplication appliances have always had a great purpose in keeping large amounts of data for long periods of time. From the backup software perspective, Veeam has continued to grow as the platform of choice for virtual environments.
Quantum has recently announced some new integration with Veeam, in the form of Data Mover software for DXi and also the iBlade for Scalar libraries that both integrate very nicely. For now, I would like to focus on the data mover. The Veeam Data Mover is a piece of software that runs directly on the DXi and performs some of the processing for Veeam Backup and Replication software. By running the target data mover directly on the DXi, some of the backup and restore operations within Veeam are much more efficient and happen quickly. The backup data is sent by the Veeam backup server to the data mover, which in turn writes to an NFS share on the DXi for deduplication, compression, and eventually storage.
Configuration is straightforward, and requires only a few steps. There are a few prerequisites that must be met, which are listed below:
- A Veeam License is required, and must be installed on the DXi
- The DXi system must be running at least version of 3.4 firmware
- A memory upgrade may be required on the DXi
- The DXi must have NAS support
My focus for this article is on configuration of the Veeam Data Mover integration, so any of the above listed requirements for the DXi can be addressed by your local Quantum reseller.
The first step that must be configured on the DXi is to create the NAS share. Create a new NFS NAS share with deduplication enabled. If replication is needed, the option is there to use Quantum replication, which can easily be configured on the share as well. Once the share is added, there is a new tab in the 3.4 firmware called “Application Environment”. By checking the “Enable Veeam” box and entering a new password, the DXi software will build the data mover environment. That’s it – a few simple commands and the DXi is ready for Veeam.
Now that the DXi is ready as a target for the data, we must configure Veeam to send it there. In the Backup Infrastructure tab, add a new Linux server. Use the name (or ip address) associated with a data port on the DXi and add the associated credentials that were specified during the Quantum configuration. This will add the newly created data mover as a managed Linux server within Veeam.
Next, once again go to the Backup Infrastructure tab and add a new Backup Repository. The specified type for this repository will be Linux Server. When you add the server, and the path screen is displayed, click populate and then click next to move to the Repository folder path. Click “Browse” and drill down to the newly created NFS NAS share on the DXi. Make sure to select Decompress backup data blocks and Use per-VM backup files. Default settings can be used for the rest of the wizard.
Once completed, you will have successfully created a new Veeam Repository on the Quantum DXi which resembles the diagram below:
The finished product is not only an extremely efficient way to backup and store virtual machines, but also for recovery as well. You’ve got Quantum DXI with the StorNext data management software to maximize efficiency, as well as the industry leading variable length deduplication technology. Combined with Veeam to manage the backup and recovery process as well as move the data, it doesn’t get any better. Recovery of virtual machines, whether that be instant recovery or individual files, is just as easy and efficient. Protecting your virtual machine data has never been easier.