Project

General

Profile

Actions
Copy link

Bug #846

closed

if_bridge triggers link state cycling on em(4)

Added by Chris Buechler over 13 years ago. Updated almost 13 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
2.0
Start date:
08/25/2010
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0
Affected Architecture:

Description

This is primarily a reminder to figure out more about this and report it upstream. Another question arises here - should check_reload_status do anything when IP is "none"? It skips the process when it's static IP, and hence this is not a problem with static.

To replicate, bridge two em(4) interfaces with at least one set to IP "none", and the link state will go up and down every 30 seconds roughly. The ifconfig output, the NIC's link light, and the NIC link of the connected device all show the link going down and up repeatedly.

em0: <Intel(R) PRO/1000 Network Connection 7.0.5> port 0xdc00-0xdc1f mem 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 16 at device 0.0 on pci4
em0: Using MSIX interrupts with 5 vectors

# ifconfig em0
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=2098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
    ether 00:90:0b:12:01:66
    inet6 fe80::290:bff:fe12:166%em0 prefixlen 64 scopeid 0x1 
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
    media: Ethernet autoselect
    status: no carrier
# ifconfig em0
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=2098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
    ether 00:90:0b:12:01:66
    inet6 fe80::290:bff:fe12:166%em0 prefixlen 64 scopeid 0x1 
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active

Aug 25 01:48:27 hamakua kernel: em0: link state changed to DOWN
Aug 25 01:48:29 hamakua kernel: em0: link state changed to UP
Aug 25 01:48:58 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' 
Aug 25 01:48:58 hamakua kernel: em0: link state changed to DOWN
Aug 25 01:49:00 hamakua kernel: em0: link state changed to UP
Aug 25 01:49:29 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' 
Aug 25 01:49:29 hamakua kernel: em0: link state changed to DOWN
Aug 25 01:49:31 hamakua kernel: em0: link state changed to UP
Aug 25 01:50:00 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' 
Aug 25 01:50:00 hamakua kernel: em0: link state changed to DOWN
Aug 25 01:50:02 hamakua kernel: em0: link state changed to UP
Aug 25 01:50:31 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' 
Aug 25 01:50:31 hamakua kernel: em0: link state changed to DOWN
Aug 25 01:50:33 hamakua kernel: em0: link state changed to UP
Aug 25 01:51:02 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' 
Aug 25 01:51:02 hamakua kernel: em0: link state changed to DOWN
Aug 25 01:51:04 hamakua kernel: em0: link state changed to UP

This appears to be the issue described by Andrew Thompson here:
http://www.mail-archive.com/freebsd-stable@freebsd.org/msg87816.html
though back on 6.2. Seems to have regressed back to that in 8.1.

It appears disabling hardware checksum offloading fixes this problem, or works around it at least.

Actions
Copy link

Also available in: Atom PDF