November Maintenance Window – 11/17 & 11/18

On November 17th & 18th of 2017, we will be performing maintenance on DataYard’s customer infrastructure. This will include performing updates to all managed server infrastructure, including tasks that require reboots/shutdowns/service interruptions.  Maintenance will begin at 3:00AM EST and will be completed by 9:00AM EST.

Let us know if you have any questions, concerns, or just want to chat: 1.800.982.4539 or [email protected]. Remember to follow us on Twitter (@datayardtechops & @datayard)!

October Maintenance Window – 10/14/17

On Saturday October 14th 2017, we will be performing maintenance on DataYard’s infrastructure. This will include performing updates to our internal server infrastructure and all managed server infrastructure, including tasks that require reboots/shutdowns/service interruptions.  Maintenance will begin at 3:00AM EST and will be completed by 9:00AM EST.

Let us know if you have any questions, concerns, or just want to chat: 1.800.982.4539 or [email protected]. Remember to follow us on Twitter (@datayardtechops & @datayard)!

September 2017 Maintenance Window – 09/15/17 & 09/16/17

On Friday September 15 2017 and Saturday 16 2017, we will be performing maintenance on DataYard’s infrastructure. This will include performing updates to our internal server infrastructure and all managed server infrastructure, including tasks that require reboots/shutdowns/service interruptions.  Maintenance will begin at 3:00AM EST and will be completed by 9:00AM EST both days.

Let us know if you have any questions, concerns, or just want to chat: 1.800.982.4539 or [email protected]. Remember to follow us on Twitter (@datayardtechops & @datayard)!

Should I use POP or IMAP?

Should I use POP or IMAP?

POP and IMAP are just two different ways of receiving e-mails. They each have their own unique  ways of handling mail.

POP

POP or “Post Office Protocol” is the most basic way to receive email. When the POP server receives an email it stores it on the server until you hit ‘send/receive’ in your mail program. When you hit the send/receive button your mail client checks the server for new messages and then requests any new messages be downloaded off our mail server and onto your computer.  This removes your messages from our server and leaves your mail stored only on the local PC that you’ve downloaded it to.

IMAP

IMAP or “Internet Messaging Access Protocol” is just another way of receiving mail. It allows you to download your emails to your local computer and automatically leaves a copy of these messages on the server.  IMAP will allow messages from the server to be available for download from multiple devices. For example, if you delete a message from your Outlook client inbox it will then show as deleted (with a line through it) in your inbox until you permanently remove it and not be downloaded by another device after that.

The downside to IMAP is that it’s a bit slower due to messages being re-downloaded each time you access your inbox, but, you are not taking up storage space on your devices as the messages are not being downloaded only stored on the server.

 

Now, to decide which one is right for you…  A few questions you might want to ask yourself are:

  1. Do I need to sync my mail with multiple devices?
  2. Do I need to keep a backup copy of my e-mail messages?
  3. Do I always have a network connection available when I need to see my messages?
  4. Do I need redundancy for my e-mail?
  5. Am I limited by storage space because I am using a portable device, such as a smart phone, to check my mail?

If you have answered ‘yes’ to most of these questions you are likely better off using IMAP protocol.

How can I contact DataYard support staff?

How can I contact DataYard support staff?

The DataYard support staff is dedicated to your service. Please let us know how we can help you by reaching out to us. There are three ways to contact DataYard support staff:

  1. Call the DataYard support department at 937-226-6896. We are available Monday through Friday, 8 am to 5 pm Eastern US time.
  2. You can email a request 24 hours a day to [email protected].  This will automatically generate a new support ticket in our system. The DataYard team will review and complete your request as soon as possible.
  3. You can send a request through the contact page on our website, which can be found at https://www.datayard.us/contact/. This, too, will automatically generate a new support ticket in our system. The DataYard team will review and complete your request as soon as possible.

DataYard support staff

SSLv3 Man in the Middle (POODLE)

SSLv3 Man in the Middle (POODLE)

What Is It?

Padding Oracle On Downgraded Legacy Encryption (POODLE) – a security vulnerability that forces the downgrade of negotiated session protocol to SSLv3, a legacy protocol used to establish secure web communication (HTTPS). The vulnerabilities are limited in scope and several client and servers restrict the use of SSLv3 which is a 15-year-old protocol. If a server is vulnerable, a man-in-the-middle attack can be executed to compromise the encrypted session.

How Does It Work?

This is a man-in-the-middle attack that forces browsers and sites to downgrade the security protocol to SSLv3 from TLS. This is done by interrupting the handshake between the client and server. This forces the retry of the handshake to earlier protocol versions. It is important to understand that in order to successfully exploit the POODLE vulnerability, the exploiting user must either be on the same network of the client or server or be able to successfully execute malicious JavaScript.

DataYard’s Actions?

DataYard has already disabled SSLv2 and SSLv3 on all of our shared infrastructure and internet facing servers. We are in the process of contacting managed customers to disable earlier protocol versions. Currently, the only workaround is to stop using SSLv3. The only downside to disabling SSLv3 is that legacy operating systems with legacy browsers that do not support TLS (Windows XP / IE 6 and earlier) will not be able to access sites and services with SSLv3 disabled.

Ready Backup Scheduled Maintenance – October 06, 2014

The DataYard Technical Operations team will be performing an upgrade to our Ready Backup infrastructure beginning at 10:30 AM EDT on Monday October 06, 2014 with an anticipated completion time of 4:30 PM EDT.

During this maintenance, access to backup and restore capabilities will be limited or unavailable. No interruption or delay to regularly scheduled backup windows is anticipated. If you require an urgent restore operation during this maintenance or have any questions, please contact our Customer Service team at (800) 982-4539 or [email protected].

Please remember to follow us on Twitter (@datayard) for maintenance updates.

Layer 2 Networking Pseudo Redundancies

Layer 2 Networking Pseudo Redundancies

Premise

I’ve seen many production networks that rely on layer 2 pseudo-redundancies through the core, and I’m here to explain why such designs are unnecessary, often dangerous, and how they can be improved. This article assumes an understanding of the OSI model, the most common protocols at layers 2 and 3, and the common “Cisco campus” Core/Distribution/Access network model.

This article aims to cover the following:

  • Collapsed core and L2 core/distribution networks
  • Limitations of common L2 HA tools – VSS, STP
  • L3 alternatives

Layer 2 HA Scenarios

Consider the following common collapsed core environment, and the protocols at play to provide redundancy.

collapsed-core

  • Core uses Cisco VSS, StackWise or similar shared control plane redundancy mechanism
  • Some or all VLANs span all access switches through L3 switch core
  • Spanning-tree (Classic STP, Rapid-STP, or MST) handling failover between physical access-core links
  • Little or no dynamic routing use
  • “Distribution” layer may be created to support campus expansion

Let’s touch on a few points that may seem like advantages to an engineer jumping into such a network.

The single shared Layer 2 domain allows for an “any user, any subnet, anywhere” approach to provisioning new ports and access for your users and systems. A user moving between physical points, departments, or switches in your campus or network does not mean re-addressing or re-configuring access rules, software, etc.

Having minimal routing protocol usage can be attractive to some – as all of the tunable knobs of OSPF, EIGRP, and BGP can be a little overwhelming. When a new port or subnet is needed, an SVI in the Layer 3 core can easily be configured, and a new VLAN trunked where needed.

VSS and other shared control plane solutions create a single logical switch. This has the apparent benefit of reducing administrative burden by having only a “single switch” to manage, and gaining physical hardware redundancy without using more complicated (administratively, anyway) protocols such as HSRP, GLBP, and dynamic routing.

Limitations of Common Designs

When you look beyond some of the key points above, you find some serious issues with collapsed core and shared control plane technologies in the core. Consider the diagram above with a single VSS pair in the collapsed core. Although the core switch and it’s connected infrastructure can survive a single physical hardware failure (up to a full VSS chassis), assuming all connected devices are dual homed using port channels, the entire network can be interrupted by a single “logical” failure, human error, or software bug. While VSS pairs can make an excellent edge or access layer switch, you should carefully consider the risks involved before deploying them in a core setting without other redundancy mechanisms.

In addition to increasing the risk of large-scale failure, solely relying on shared control plane redundancies also reduces flexibility in routing and traffic engineering. Switches configured in VSS or StackWise pairs maintain a shared routing table, routing processes, and make the same routing decisions.

Wasted bandwidth can be another issue when relying on Layer 2 transport and Spannning Tree failover from core to distribution or access network segments. When relying on any STP protocol (Multiple Spanning Tree with properly configured instances being the exception) for link redundancy, one or more links in a bridge must operate in a blocked state by design – reducing total available bandwidth of the topology.

Finally, STP (and VTP, if you choose to run it) is often classified as a dangerous and slow protocol. By design, every STP speaking bridge in a tree participates in Root Bridge election and exchanges bridge protocol data units (BPDUs) to determine who the root bridge is, where it’s located, and what paths need to be blocked. All it takes is one misconfigured switch inserted into the network to cause wide-sweeping failures or performance issues, which are often cumbersome to troubleshoot. If you’ve never had to troubleshoot spanning tree issues during a network failure, count your blessings!

STP_block

Layer 3 Alternatives

Route everything – many networks and network engineers would benefit from abandoning the idea that any modern application actually requires layer 2 adjacency. Almost any broadcast domain spanning more than one device hop, or two network hosts total, can be eliminated and routed over without negative impact to the applications traversing the path. The most common exception to this rule is virtual machine migration traffic such as VMWare vMotion; technologies such as Cisco Overlay Transport Virtualization exist for remedying these exceptions.

l3-core

Moving to a layer 3, route-centric design, also provides more options for protocol selection in how you transport your traffic from one network segment to another. Most common small and medium size networks will be sufficiently supported with basic OSPF or EIGRP implementations while larger enterprise and service provider networks will often rely more heavily on BGP and IS-IS. Your choice of protocols should be influenced by administrative experience, networking vendors involved, and your requirements for scale.

Proper use of first hop redundancy protocols such as HSRP, VRRP, and GLBP can also provide hardware redundancy at the first hop gateway much like VSS and StackWise – without the inherent risks of putting so many eggs in one proprietary basket.

Finally, depending on your route design and configuration, relying on layer 3 protocols for redundancy and transport allows for load balancing traffic across multiple paths. Equal cost and unequal cost load balancing can allow for full utilization of all network links without sacrificing ports and hardware for failover/blocked paths.

Summary

The topologies, protocols, and designs mentioned above are all only examples of tools that should be readily available in every networkers’ toolbox. Hopefully, this article has sparked some ideas that will lead to building a more redundant, better-performing network.

Routing Around Internet Congestion

Around 9:30AM EST, we started experiencing some choppy and dropped phone calls through our own internal SIP based phone system, and shortly after began receiving customer reports of slow and limited access to internet resources. After some investigation (20-30 minutes of troubleshooting) we determined that the access problems were isolated to one of our three major internet peers, Level3 communications. We immediately disconnected from Level3 to minimize the impact to us and our and customers, and this resolved most connectivity problems over the next few minutes while other networks began to make routing changes. Fortunately, our other ample upstream paths carried our full traffic load without issue.

Despite the change we made, Level3 is one of the largest and most utilized carriers in the world. As a result, many external networks still rely on Level3 as a transit or intermediary path to reach one of our remaining peers (Cogent, TWTelecom) which results in poor performance for some users. 

At this time, Level3 is still showing signs of loss in the Midwest and we are still de-peered. We have had a ticket open with Level3 since early this morning, and we are poking our contacts for updates as they become available. We will be monitoring throughout the evening, and re-peering when we have confirmation that things are stable.

So while it’s common to have multiple paths to reaching the rest of the internet, does your IT partner really have the ability to respond quickly and efficiently to a critical failure? If you’re not confident in the answer to that question, give us a call and you will be.