Hello,

I have a similar error (seems it is connected with the ones above
mentioned) using bridge-utils but not bonding support. My configuration is

+Debian streetch
# uname -a
Linux server2 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13)
x86_64 GNU/Linux
# cat /etc/debian_version
9.5
# dpkg -l | grep -e ifupdown -e vlan -e bridge-utils | awk '{print $1, $2,
$3}'
ii bridge-utils 1.5-13+deb9u1
ii ifupdown 0.8.19

I have a Realtek 8139 based network card for teaching purposes on system
administration:
# dmesg | grep 8139
[    0.137837] pci 0000:01:0e.0: [10ec:8139] type 00 class 0x020000
[    0.704364] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22,
2004)
[    0.704370] 8139cp 0000:01:0e.0: This (id 10ec:8139 rev 10) is not an
8139C+ compatible chip, use 8139too
[    0.704858] 8139too: 8139too Fast Ethernet driver 0.9.28
[    0.705537] 8139too 0000:01:0e.0 eth0: RealTek RTL8139 at
0xffffa9a8c0339c00, 00:08:54:53:8c:01, IRQ 17
[    0.736030] 8139too 0000:01:0e.0 enp1s14: renamed from eth0
[    1.503524] 8139too 0000:01:0e.0 enp1s14: link up, 100Mbps, full-duplex,
lpa 0xC1E1
[  846.953912] 8139too 0000:01:0e.0 enp1s14: link up, 100Mbps, full-duplex,
lpa 0xC1E1


My network configuration is the following
auto lo
iface lo inet loopback
iface enp1s14 inet manual

auto xenbr0
iface xenbr0 inet dhcp
     bridge_ports enp1s14
     bridge_hw 00:08:54:53:8c:02
     bridge_stp off
     bridge_fd 0
     bridge_maxwait 0

This configuration (that works fine in Jessie even without the specifiying
the manual configuration of enp1s14 interface) on reboot and startup
results in enp1s14 and xenbr0 (both) makes a DHCP request and get
autocongured with the IP address (see below). I changed the mac address of
xenbr0 to see better the problem. If i do not do it, both dhcp requests are
made resulting in the same IP configuration for the two devices. Due to
this inconsistent state if bridge_maxwait option is not used the operations
with networking service are lagged for a lot of time.

# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master xenbr0 state UNKNOWN group default qlen 1000
    link/ether 00:08:54:53:8c:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.112.239/24 brd 192.168.112.255 scope global enp1s14
       valid_lft forever preferred_lft forever
3: xenbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
    link/ether 00:08:54:53:8c:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.112.135/24 brd 192.168.112.255 scope global xenbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::208:54ff:fe53:8c02/64 scope link
       valid_lft forever preferred_lft forever


In order to solve the problem every time the system starts i have to:
+ stop networking service: service networking stop or systemctl stop
networking.service. After this IP address of enp1s14 is not removed.
+ Manually delete the erroneous configuration for ethernet interface
(enp1s14): ip a d 192.168.xxx.yyy dev enp1s14
+ relaunch networking service: service networking start
After that everything works fine (service relaunching and all). So the
problem seems to be at startup.

Also, feel free to ask me for additional information. However, my technical
skills are not enough to suggest a solution for the  problem.

Best regards.

-- 
J. Ramón Méndez
University of Vigo (Spain)

Reply via email to