Cases6 cases

6 to 6 of 6

1. IL-0263 GitHub was slow and erroring all day and down for 18 minutes as links between access and aggregation switches saturated

   GitHub2012

   Symptoms

   On Friday, 30 November 2012, GitHub had sporadic bursts of slow responses and intermittent errors for the whole day and was completely unavailable for 18 minutes. One fileserver pair was offline for a large part of the day, which affected a small percentage of repositories; this was a side effect of the network problems on the high-availability clustering between the fileserver nodes.

   High latencyHigh error rateService outage

   Trigger

   On the morning of 30 November GitHub moved the A switches in its server cabinets onto the new aggregation switches, the second half of a migration whose B-switch half had been done the day before.

   Root cause

   Software defect

   Component

   Network switchNIC, cable and switch port link

   Contributing factor

   Overlapping failuresUnverified assumptionHarmful manual action

   Detection

   Engineers saw the problems during the maintenance itself: connectivity to the B switch was lost as the last A switch was connected, and afterwards performance stayed low and the links between access and aggregation switches showed as completely saturated.

   Remediation

   • Fixed the bridge-loop problem and returned the affected B switch to service
   • Removed the partial link failure detection setting from the access switches
   • Escalated to the network vendor, which raised the case to its highest severity level
   • Restarted core processes on the aggregation switches in a Saturday 0600 Pacific maintenance window so they learned MAC addresses again

   Action items

   • Deploy the vendor's software update that fixes the MAC learning issue to the switches
   • Closely monitor aggregation-to-access capacity and keep a workaround process ready if the problem returns
   • Build a duplicate of the network stack, from the routers through the access switches, as a staging environment for testing such changes
   • Add automated network monitoring that alerts sooner on similar issues
   • Run scheduled incident response exercises with scenarios that counter tunnel vision
   • Contact the network vendor's support at the first sign of trouble in the network

   Lessons

   GitHub had designed the maintenance to have no impact on customers and clearly failed, so it plans to invest in a staging copy of its network to test such changes and catch bugs like this one. During the response the team fixated for a long time on a bridge loop, which kept it from considering other causes. GitHub had a very positive experience with the vendor's support staff, so it will contact that support team at the first sign of network trouble.

   View case

By root cause4