Score:0

Static IP with Netplan causes slow internet speed (Ubuntu Server 20.04)

nl flag

I'm having an issue with internet speed when I set up a Static IP with Netplan in Ubuntu Server 20.04.

I'm using a Dell PowerEdge R710, with no wifi card, so all solutions that I found in the forum that involves wifi, doensn't really work. I also tried serveral others configurations in Netplan and others sugestions that I found in the forum, but it really didn't work.

If I disable the Static IP and let it Dynamic, the internet speed works just fine. Does anyone have an idea on how to solve this?

Here is my 50-cloud-init.yaml

aiec@camera02:/etc/netplan$ sudo nano 50-cloud-init.yaml
network:
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      addresses: [192.168.253.188/24]
      gateway4: 192.168.253.1
      optional: true
      nameservers:
        addresses: [8.8.8.8,8.8.4.4]
  version: 2

The speedtest result (if I'm with Dynamic IP, the speed goes to 40~45 Mbits/s)

aiec@camera02:/etc/netplan$ speedtest
Retrieving speedtest.net configuration...
Testing from Live Telecom (177.66.74.126)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by StarFibra Telecomunicações (Foz do Iguaçu) [4.05 km]: 58.244 ms
Testing download speed................................................................................
Download: 2.12 Mbit/s
Testing upload speed......................................................................................................
Upload: 1.37 Mbit/s

And the ifconfig -a

aiec@camera02:/etc/netplan$ ifconfig -a
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.253.188  netmask 255.255.255.0  broadcast 192.168.253.255
        inet6 fe80::be30:5bff:fefe:671  prefixlen 64  scopeid 0x20<link>
        ether bc:30:5b:fe:06:71  txqueuelen 1000  (Ethernet)
        RX packets 162999  bytes 174965858 (174.9 MB)
        RX errors 0  dropped 6421  overruns 0  frame 0
        TX packets 78785  bytes 42246324 (42.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno2: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether bc:30:5b:fe:06:73  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno3: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether bc:30:5b:fe:06:75  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno4: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether bc:30:5b:fe:06:77  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

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 1084  bytes 96330 (96.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1084  bytes 96330 (96.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Artur Meinild avatar
vn flag
Your `50-cloud-init.yaml` looks good from what I can see.
Ricardo MacCord avatar
nl flag
Yep, for what I've searched, it is... That's what's bothering me....
Score:0
us flag

There are various other settings you may be receiving via DHCP that would affect throughput. If the IP address and the gateway address are the same, the next thing to look at would be MTU. If your default MTU is too large, your throughput may be low due to packet fragmentation.

Ricardo MacCord avatar
nl flag
My default MTU was 1500, so searched about it and tested a few values that I found in other sites (1492, 1485, 1472, 1400, 1200, 1000, 800), but still didn't work. Any other idea?
us flag
Are the IP and gateway addresses identical between your static and DHCP configs? It may be helpful if you set the device to configure via DHCP and paste the full resolutions interface config for comparison.
us flag
It is also possible but unlikely that your router has qos controls in place that prioritize traffic from dhcp-configured devices and slows down statically configured devices.
Score:0
nl flag

Ok, so, after a few talks with some friends, we found out the problem. It was quite simple actually.

The problem was with the gateway. when I used the command netstat -rn, it returned:

aiec@camera02:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.253.1   0.0.0.0         UG        0 0          0 eno1
0.0.0.0         192.168.253.254 0.0.0.0         UG        0 0          0 eno1
192.168.253.0   0.0.0.0         255.255.255.0   U         0 0          0 eno1
192.168.253.254 0.0.0.0         255.255.255.255 UH        0 0          0 eno1

The gateway had to finish with .254, insted of .1.

So, the correct way to use the netplan for me was to type gateway4: 192.168.253.254.

  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      addresses: [192.168.253.188/24]
      gateway4: 192.168.253.254
      optional: false
      nameservers:
        addresses: [8.8.8.8,8.8.4.4]
  version: 2

Now, my netstat -rn, return:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.253.254 0.0.0.0         UG        0 0          0 eno1
192.168.253.0   0.0.0.0         255.255.255.0   U         0 0          0 eno1

And that's it. Thanks for those who tried to help me.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.