Cases24 cases

22 to 24 of 24

1. IL-0358 Packet Public Cloud locations had high latency and unreachable paths from routing loops and blackholed traffic

   Packet2019

   Symptoms

   At about 08:49 UTC on 2 June 2019, Packet's internal network monitoring alerted on serious reachability and performance problems in several of Packet's global datacenter locations. The first investigation found routing loops and traffic being blackholed to specific internal and Internet destinations.

   Network unreachablePacket lossHigh latency

   Trigger

   A trans-continental US backbone link in the network of Packet's upstream provider Zayo had a hardware failure and blackholed IP traffic routed over it.

   Root cause

   Dependency failure

   Component

   Backbone network (WAN)BGP routingNetwork control plane (SDN)

   Contributing factor

   –

   Detection

   Packet's internal network monitoring alerted at 08:49 UTC on reachability issues in several global datacenter locations, and engineers confirmed them at 08:52.

   Remediation

   • Migrated traffic to an alternative network and removed Zayo from the provider mix
   • Applied route filters to return service to normal
   • Optimised specific routing policies to improve latency across the backbone with the new traffic mix

   Action items

   • Expand internal connectivity monitoring and alerting of on-call operations teams
   • Expand network automation and routing so traffic can be balanced across all available backbone paths and an operator can trigger automated re-routes across all Packet datacenters in a major provider incident
   • Make Packet's provisioning systems less dependent on third party network providers and inter-datacenter connectivity

   View case
2. IL-0590 F5 load balancers cached a path MTU of 296 after Rackspace reboots, and Mailgun connections failed intermittently

   Mailgun2014

   Symptoms

   On Saturday, September 27, 2014 at 6:50 p.m. UTC, Mailgun saw that all its database replicas and the internal traffic between its environments in all regions were broken and reporting timeouts. Once Rackspace began rebooting cloud instances in its Chicago data center (ORD), Mailgun customers had intermittent connection failures.

   Intermittent connection failuresIntermittent timeoutsPacket loss

   Trigger

   Rackspace, Mailgun's parent company and hosting provider, rebooted cloud instances in its Chicago data center (ORD), and the cloud maintenance triggered an error condition on Mailgun's F5 load balancers.

   Root cause

   DNS or network fault

   Component

   Cloud load balancerDatabase replication

   Contributing factor

   –

   Detection

   Mailgun noticed at 6:50 p.m. UTC on September 27 that all database replicas and the internal traffic between its environments were broken and reporting timeouts.

   Remediation

   • The Rackspace networking team cleared the cached path MTU on Mailgun's F5s and on some Rackspace dedicated customers' F5s
   • Set up a new virtual IP for Mailgun services
   • Changed Mailgun's DNS settings, which forced the remote F5s to clear their caches

   Action items

   • Finish the root cause analysis of the F5 path MTU problem with Rackspace
   • Make sure maintenance of Mailgun's cloud infrastructure has no impact on Mailgun customers

   View case
3. IL-0537 Sakura Cloud host servers repeatedly lost their storage connection, about five minutes per port switchover

   Sakura Internet2012

   Symptoms

   From mid-December 2011, after Sakura Cloud launched, traffic between the host servers and the storage device grew, and the network connection between the hosts that carry users' servers and the storage device was cut again and again. Each cut caused by a port switchover lasted about five minutes.

   Storage disconnected or stale mountsPacket loss

   Trigger

   Traffic between the host servers and the storage device grew from mid-December 2011, after the service launched on 15 November 2011.

   Root cause

   Capacity exhaustion

   Component

   Cloud block storageInfiniBand fabric

   Contributing factor

   Automation amplificationUnrepresentative stagingLimited debug access

   Remediation

   • Switched the network interface monitoring from ICMP to a LINK state check, so the device fails over only on a physical link down
   • Changed the InfiniBand Subnet Manager's check from normal mode to heavy sweep mode
   • Updated the storage device firmware on 19 March, which stopped the packet loss
   • Added a second storage device on 12 March and migrated servers to it to reduce and spread the load

   Action items

   • Replace the current storage with an entirely different new storage device
   • Test the new storage in an environment equal to its maximum capacity under real load, with a free beta before paid service
   • Use network interface drivers and similar parts equivalent to those already proven on the host servers
   • Develop the new storage with in-house engineers so Sakura Internet can manage and operate it itself

   Lessons

   Sakura Internet wrote that it could not test the storage device at its performance limit, because it could not prepare as many servers as the design capacity and used load generated from predictions, so it could not respond quickly and accurately to problems in real operation. Packet loss on the InfiniBand port kept the device below its expected performance and took three months to fix by firmware, and its engineers could not grasp the whole of the device's specification and behaviour. Sakura Internet concluded that its process for choosing and validating the storage device had serious problems.

   View case

By root cause9