network configuration failed on reboot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Bionic |
Won't Fix
|
Undecided
|
Unassigned | ||
Focal |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
[impact]
number of statically defined addresses for an interface in systemd-networkd is limited
[test case]
Note: this only occurs in a container; this is not reproducable in a VM or bare metal.
Configure netplan with the attached yaml file (10-test.yaml)
enable debug for systemd-networkd
reboot the system and check the journalctl output to see if any errors were reported for systemd-networkd, e.g.:
$ journalctl -b -u systemd-networkd | grep 'could not set'
Jul 23 13:16:52 lp1930738-b systemd-
...
Note that systemd may be able to actually correctly set all addresses, but fails to communicate with netlink to determine the addresses are set, so just checking the output of 'ip a' is not enough, the systemd-networkd debug log should be checked
[regression potential]
possible failure to correctly apply all statically defined interfaces
[scope]
TBD, not fully fixed upstream
this is needed in f and b
this is fixed upstream with commits 628f08b66d43d19
[other info]
I elided upstream commit d31f33e3c9f6ea3
Additionally this requires the typo fix from commit 4934ba2121d7622
[original description]
This issue was reported at https:/
**Used distribution**
> Ubuntu 20.04.1 LTS
**systemd version the issue has been seen with**
> 245.4-4ubuntu3.2
**Issue details**
I configured 255 IPv4 address (including primary IP) using netplan but when the server restart, it time out on configuring the interface. If I limit total IPv4 addresses to 181 or less, it works. But anything larger than 181 fails.
Below are my configurations and error logs.
**/etc/
```
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: no
addresses:
- 140.XX.XX.XX/23
- 103.XXX.XX.1/24
- 103.XXX.XX.2/24
- CONTINUED IP ADDRESS UPTO BELOW ...
- 103.XXX.XX.254/24
gateway4: 140.XX.XX.X
nameservers:
addresses: [1.1.1.1, 1.0.0.1]
routes:
- to: 169.254.0.0/16
via: 140.XX.XX.X
metric: 100
```
The above config works if I run `netplan apply` but when I reboot, it does not work.
**networkctl**
```
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 ens3 ether routable failed
2 links listed.
```
**/etc/
```
[Service]
Environment=
```
**systemctl status systemd-
```
● systemd-
Loaded: loaded (/lib/systemd/
Drop-In: /etc/systemd/
Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago
Docs: man:systemd-
Main PID: 346 (systemd-network)
Status: "Processing requests..."
Tasks: 1 (limit: 1074)
Memory: 3.8M
CGroup: /system.
└─346 /lib/systemd/
Sep 10 19:47:03 test-server systemd-
Sep 10 19:47:11 test-server systemd-
Sep 10 19:47:11 test-server systemd-
Sep 10 19:47:11 test-server systemd-
Sep 10 19:47:23 test-server systemd-
Sep 10 19:47:23 test-server systemd-
Sep 10 19:47:23 test-server systemd-
Sep 10 19:47:23 test-server systemd-
Sep 10 19:47:23 test-server systemd-
Sep 10 19:47:23 test-server systemd-
```
information type: | Public → Public Security |
information type: | Public Security → Public |
description: | updated |
Changed in systemd (Ubuntu Bionic): | |
status: | New → In Progress |
Changed in systemd (Ubuntu Focal): | |
status: | New → In Progress |
Changed in systemd (Ubuntu): | |
status: | Incomplete → Fix Released |
Changed in systemd (Ubuntu Focal): | |
importance: | Undecided → Low |
Changed in systemd (Ubuntu Bionic): | |
importance: | Undecided → Low |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in systemd (Ubuntu Focal): | |
assignee: | nobody → Dan Streetman (ddstreet) |
description: | updated |
Changed in systemd (Ubuntu Bionic): | |
status: | In Progress → New |
assignee: | Dan Streetman (ddstreet) → nobody |
description: | updated |
Changed in systemd (Ubuntu Focal): | |
assignee: | Dan Streetman (ddstreet) → nobody |
importance: | Low → Undecided |
Changed in systemd (Ubuntu Bionic): | |
importance: | Low → Undecided |
i can't reproduce this, and your log output looks like you have are having problems with your ipv6 configuration, not ipv4. you'll need to attach the full journal log if you still have this problem