Solution: Remote KVM/Console Extremely Laggy

Triage

1. Verify basic connectivity to the iLO:
2. ping -c 20 10.100.5.47 -- check for packet loss and latency variance
3. arping -D -I eth0 10.100.5.47 -- check for IP conflicts (duplicate detection)
4. iperf3 -c 10.100.5.47 -t 10 -- if iperf is available on iLO, test throughput
5. Check iLO network configuration:
6. Log into iLO web UI > Network > Network Interface tab
7. Verify dedicated NIC is in use, note the negotiated speed and duplex
8. Check the iLO shared NIC is disabled (avoid confusion)
9. Check the switch port:
10. show interface gigabitEthernet 1/0/23 -- look for speed, duplex, error counters
11. Look specifically for: late collisions, CRC errors, runts, input/output errors

Root Cause

The iLO dedicated NIC has auto-negotiated to 100Mbps half-duplex while the switch port is set to auto-negotiate. A flaky cable (damaged pin 4/5 on the Cat6) is causing link flapping that settles at a degraded speed. The half-duplex mismatch causes collisions under load, which manifests as: - Intermittent packet loss on ping - Severe lag on bandwidth-heavy KVM sessions - Java console crashes due to socket timeouts

Fix

1. Immediate workaround: Use iLO SSH CLI for text-based troubleshooting:
2. ssh administrator@10.100.5.47
3. Use textcons command for text console access
4. Replace the cable: Swap the Cat6 cable from the iLO dedicated NIC to the ToR switch.
5. Hard-set speed/duplex on both ends (if cable swap doesn't resolve):
6. iLO: Network > NIC Settings > Speed: 1Gbps, Duplex: Full
7. Switch: speed 1000 / duplex full on the port
8. Verify resolution:
9. Confirm NIC negotiates at 1Gbps full-duplex on both ends
10. Ping test should show 0% loss, <2ms latency
11. Test HTML5 remote console -- should be responsive
12. Update iLO firmware if not on the latest version for this generation.

Rollback / Safety

• If hard-setting speed/duplex causes the link to go down, revert to auto on both ends.
• The server's production traffic is unaffected (uses different NICs); only management access is impacted.
• If SSH to iLO is also unusable, physical console (crash cart) is the fallback.
• Do not reboot the iLO (iloreset) unless necessary; it takes 3-5 minutes and disrupts all management access.

Common Traps

• Blaming the KVM software: The HTML5 and Java consoles both fail because the underlying network is degraded. Don't waste time adjusting Java security settings or browser configs.
• Ignoring duplex mismatch: Auto/auto should work, but a bad cable can cause one end to fail back to half-duplex while the other stays full. This creates insidious packet loss under load.
• Not checking for IP conflicts: A duplicate IP will cause exactly this pattern of intermittent loss. Always verify with arping.
• Overlooking shared NIC mode: If the iLO is accidentally using the shared NIC (piggybacking on a production port), it competes with production traffic.
• Rebooting the server to "fix" management access: The iLO operates independently; rebooting the host OS does not reset the iLO.