I85PREP
⌘ K
DCAT study materials
DCAT study resources

The Intermittent Link Flap

DCAT · Put your knowledge to work in context.

All case studies

The Intermittent Link Flap

A top-of-rack switch connects to a server via a 10GbE DAC cable. For three weeks, the link has flapped roughly twice a day. The switch logs show "link down/up" events with no error counters on the port. The server's NIC logs show the same. A network engineer replaced the DAC cable once; the flapping continued. The switch port is configured for auto-negotiation. The server is in a rack that also houses a large UPS and a transformer. The switch's other 47 ports are stable. The colo has had brief power sags during the same period.

1. List the plausible causes of the intermittent link flap and rank them by likelihood given the evidence.

Read the worked answer

Evidence recap: flapping ~2x/day for 3 weeks, no error counters, DAC replaced once, port set to auto-negotiation, 47 other ports stable, rack contains UPS and transformer, colo had power sags.

Ranked causes:

  1. EMI from the UPS/transformer - the rack houses a large UPS and transformer, which emit strong electromagnetic fields. A DAC cable routed near them can pick up interference. This fits the "only this port" and "no error counters" pattern (interference causes link loss, not necessarily errored frames).
  2. Power sags affecting the server or switch - brief sags can cause the NIC or switch ASIC to reset the link. The timing correlation with colo sags is a strong clue.
  3. Auto-negotiation mismatch - auto-negotiation on 10GbE DAC can cause intermittent link issues if the two ends disagree; forcing speed/duplex is a common fix.
  4. Bad switch port or NIC - less likely since the DAC was replaced and other ports are stable, but not ruled out.
  5. Physical strain on the DAC - a bent or strained cable can intermittently lose contact.

Least likely: firmware bug (would affect more ports), cable length (DAC is short by design).

2. Design a diagnostic plan to isolate the cause, including what to change and in what order.

Read the worked answer

Diagnostic plan (least invasive first):

  1. Correlate timestamps - compare switch link-flap times with the colo's power-sag log. If they align, power is the cause.
  2. Force speed/duplex on both ends (disable auto-negotiation) and monitor for 48 hours. This is a one-line config change and eliminates cause #3.
  3. Reroute the DAC cable away from the UPS/transformer, using a longer DAC or fiber if needed. Monitor. This tests the EMI hypothesis.
  4. Move the connection to a different switch port and monitor. If flapping follows the port, the port is bad; if it follows the server, the NIC is suspect.
  5. Swap the server NIC (or use a different NIC port) if the fault follows the server.
  6. Check power: put the server and switch on a UPS-backed circuit and verify the UPS is functioning. Monitor during the next sag.

Order rationale: Steps 1–2 are free and fast. Step 3 tests the strongest hypothesis without hardware replacement. Steps 4–5 isolate hardware. Step 6 addresses the power correlation.

Documentation: log each change with timestamps so you can attribute any change in flap frequency.

3. The correlation with power sags is confirmed. What is the durable fix, and what interim mitigation do you apply?

Read the worked answer

Durable fix:

  1. Put the server and ToR switch on UPS-backed power with adequate runtime, so brief sags do not reach them. Verify the UPS transfer time is within the equipment's hold-up tolerance.
  2. Separate sensitive network gear from the UPS/transformer rack if possible - move the switch or reroute cabling to reduce EMI.
  3. Force speed/duplex as a permanent config if auto-negotiation proved unstable.
  4. Add link-flap monitoring/alerting so future flaps are caught early.

Interim mitigation:

  • Move the DAC cable away from the UPS/transformer now (free, immediate).
  • Force speed/duplex now.
  • If the server has a second NIC, bond the links so a single flap does not drop connectivity (LACP or active-backup).
  • Notify the colo of the power-sag pattern and request a root-cause investigation on their side - sags twice a day suggest a recurring load or transfer issue upstream.

Verification: monitor for at least one week with no flaps before closing the incident, and confirm the UPS is actually carrying the load during a sag (test with a controlled transfer if the colo permits).