1
Once or twice an hour, my Ubuntu machine's ethernet connection will drop:
$ ping google.com
(nothing happens)
After 10-20s (though sometimes longer) it will magically come back.
During the outages, I'm unable to ping google.com or an IP, so I don't think it's a DNS issue. I've tried a number of things to debug:
- Rebooted
- Updated/upgraded all packages.
- Uninstalled and re-installed
network-manager
. - Swapped ethernet cables.
My coworkers are connected to the same router as I am and they're not experiencing this issue, so it does seem to be something with my machine.
Any ideas? I'm fresh out of them and this is getting quite frustrating!
Here's a whole bunch of information about my system:
$ lspci
00:00.0 Host bridge: Intel Corporation Device 591f (rev 05)
00:02.0 VGA compatible controller: Intel Corporation Device 5912 (rev 04)
00:14.0 USB controller: Intel Corporation 200 Series PCH USB 3.0 xHCI Controller
00:14.2 Signal processing controller: Intel Corporation 200 Series PCH Thermal Subsystem
00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME HECI #1
00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller [AHCI mode]
00:1f.0 ISA bridge: Intel Corporation 200 Series PCH LPC Controller (H270)
00:1f.2 Memory controller: Intel Corporation 200 Series PCH PMC
00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio
00:1f.4 SMBus: Intel Corporation 200 Series PCH SMBus Controller
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.04
Release: 17.04
Codename: zesty
$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
inet6 fe80::42:e7ff:fe8d:d514 prefixlen 64 scopeid 0x20<link>
ether 02:42:e7:8d:d5:14 txqueuelen 0 (Ethernet)
RX packets 25739 bytes 1591975 (1.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 116624 bytes 169185651 (169.1 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.201.32.57 netmask 255.255.255.0 broadcast 10.201.32.255
inet6 fe80::7285:c2ff:fe2a:efa8 prefixlen 64 scopeid 0x20<link>
ether 70:85:c2:2a:ef:a8 txqueuelen 1000 (Ethernet)
RX packets 1938458 bytes 1438227394 (1.4 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1442649 bytes 772299655 (772.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xdf000000-df020000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 181354 bytes 50978753 (50.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 181354 bytes 50978753 (50.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
$ ethtool enp0s31f6
Settings for enp0s31f6:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Here's something I see in /var/log/syslog
around the time of a dropped connection:
Jul 7 12:44:02 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.18 for interface enp0s31f6.
Jul 7 12:44:03 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.15 for interface enp0s31f6.
Jul 7 12:44:04 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.18 for interface enp0s31f6.
Jul 7 12:44:04 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.15 for interface enp0s31f6.
Jul 7 12:44:05 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.18 for interface enp0s31f6.
Jul 7 12:44:06 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.15 for interface enp0s31f6.
Jul 7 12:44:07 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.18 for interface enp0s31f6.
Jul 7 12:44:09 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.15 for interface enp0s31f6.
Jul 7 12:44:11 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.18 for interface enp0s31f6.
Jul 7 12:44:11 dv systemd-resolved[1259]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 10.201.1.18.
Jul 7 12:44:13 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.15 for interface enp0s31f6.
Jul 7 12:44:15 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.18 for interface enp0s31f6.
Jul 7 12:44:17 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.15 for interface enp0s31f6.
Jul 7 12:44:18 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.18 for interface enp0s31f6.
Jul 7 12:44:18 dv systemd-resolved[1259]: Using degraded feature set (UDP) for DNS server 10.201.1.18.
Jul 7 12:44:18 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.15 for interface enp0s31f6.
Jul 7 12:44:20 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.18 for interface enp0s31f6.
Jul 7 12:44:22 dv systemd-resolved[1259]: Switching to DNS server 10.201.1.15 for interface enp0s31f6.
If your Ethernet switch is configurable, disable spanning tree on the port where your PC is connected. Spanning tree is only useful for ports connecting other switches. – Ben Voigt – 2017-07-07T18:00:01.950
What does your system log say at the start, during and at the end of these outages? – Nevin Williams – 2017-07-07T18:02:33.547
@NevinWilliams I added some bits of
/var/log/syslog
from around the outage. – danvk – 2017-07-07T18:12:58.977Try to ping your router IP address. Also reset route with route command. Is there any problem with DHCP and/or DNS? – Biswapriyo – 2017-07-07T18:32:28.620
Given your log, if you ping an address (say, 8.8.8.8) do you have an outage? If not, that would be a problem with the rogue DNS switch (hazy memory of seeing this problem elsewhere on StackExchange). – xenoid – 2017-07-07T20:07:41.583
@xenoid During the outages, I'm not able to ping remote IPs (I've been using 172.217.10.238, one of Google's IPs). I'm waiting for the next outage to test pinging my router's IP. – danvk – 2017-07-07T20:14:38.570
Interesting post here with a similar problem, it seems to have been caused by a rogue device on the network. Otherwise the output of
dmesg
could also be useful. – xenoid – 2017-07-07T20:55:05.353The added syslog entries suggests the resolver is struggling to do a DNS query, which is likely due to a bigger issue. Look for interface issues (enp0s31f6) just prior to
resolved
throwing fits. – Nevin Williams – 2017-07-07T21:59:05.903Are you able to reach your router/machines on your LAN during the outages? Can your docker container reach the LAN and your computer? – lungj – 2017-07-08T05:16:55.787
Somewhat mysteriously, this stopped being an issue last Friday (July 7th). The only change I know I made around the time it stopped was disabling IPv6 entirely (via Edit Connections --> Wired connection 1 --> IPv6 Settings --> Method: Ignore). So perhaps that was it? – danvk – 2017-07-11T13:30:49.380