The link state of an interface (bridge member) goes up/down continuously

CS · Sep 21, 2013, 5:47 PM

Exactly! That's the same problem I have. Before creating the bridge there was no issue. Do you have problems with specific bridge members or all of them?

Mavy · Sep 21, 2013, 6:03 PM

There has been a simial case in the past here.

In it SMB mentions:

Ah yeah I didn't see that. The problem at one point in the past was the Intel drivers cycle link when you add an interface to a bridge, which then causes the interface to be added back to the bridge, which cycles link, which causes the interface to be added to the bridge, and repeats the process over and over endlessly. Though the OP makes no mention of which version, 2.0 and 2.0.1 release versions shouldn't exhibit this behavior. We ran into that scenario on a customer's system pre-2.0 release and fixed it prior to release.

I guess it was solved but for some reason got introduced again in the latest version?

frizouille · Sep 21, 2013, 8:11 PM

I tried creating only one bridge with two ports and the problem appears

stephenw10 · Sep 21, 2013, 8:45 PM

The linked problem is similar but not exactly the same. The symptoms are the same but the cause appears to be adding the NIC to a bridge rather than forcing the mtu or speed/duplex. Setting the speed made no difference to my box.

Steve

CS · Sep 22, 2013, 11:54 AM

I left only one bridge interface plugged in and still every morning I get the same error and I need to reboot pfsense. This never happened with 2.0.3 and now it seems to be a serious problem…

stephenw10 · Sep 22, 2013, 12:48 PM

With similar problems I've experienced it made a different which order the links were powered up in. if you have the two machines connected to OPT1 and OPT2 already up when pfSense boots do the link still flap?
I agree this seems like a problem. It's not a show stopper for me, I don't sue those links regularly, but I can see it will be for others. The more useful information we can gather here for the developers the easier/quicker it will be for them to resolve.

Steve

CS · Sep 22, 2013, 1:16 PM

Let's provide some feedback to help developers find a solution:

Bridge0 (LAN) has 2 members: OPT1 and OPT2

1st scenario:
OPT1 is up and I see no errors, OPT2 is down/unplugged.
Problem: Without doing any changes, suddenly (random time) OPT1 starts going down/up continuously.
Resolution: Reboot pfsense.

2nd scenario:
OPT1 is up and I see no errors, OPT2 is down/unplugged.
Problem: I plug in OPT2 and it starts going down/up continuously.
Resolution: Unplug OPT2.

3rd scenario:
OPT1 and OPT2 are down/unplugged.
Problem: I plug in OPT2 and it starts going down/up continuously. I unplug OPT2 and then I plug in OPT1. It also starts going down/up continuously.
Resolution: Reboot pfsense.

4th scenario:
I boot pfsense with OPT1 and OPT2 plugged in.
Problem: N/A. No errors in the system logs, no errors in the interface statistics, OPT1 and OPT2 seem to be up and both devices connected to them have access to the network. I will keep an eye and update this post if I see anything abnormal.
Resolution: N/A.

stephenw10 · Sep 22, 2013, 5:50 PM

Yes, I'm seeing the same behaviour. If I boot the box with the bridge connected NICs already up everything seems fine. I'll leave it up for a while and monitor things.

Steve

CS · Sep 25, 2013, 6:25 PM

So far when the box boots with all the NICs up it works fine. The problem is that I don't have all the NICs up and running 24x7…which means I need to reboot pfsense every time a NIC goes up. :(

chpalmer · Sep 26, 2013, 12:57 AM

@/CS:

Let's provide some feedback to help developers find a solution:

Bridge0 (LAN) has 2 members: OPT1 and OPT2

2.1 release on a Watchguard X550e with Marvell interfaces.

Ive got a similar setup as you. Ive renamed the interfaces V1 and V2 and the bridge Voipbridge.

I can duplicate your findings exactly.

One thing thats interesting to note is that Siproxd still sees the OPT interfaces as OPT (n) and not the renamed names. I had no problems with this setup under 2.0.3.

jimp · Sep 27, 2013, 7:20 PM

Try this fix:
https://github.com/pfsense/pfsense/commit/f3a4601c85c4de78caa4f12fefd64067fd83dbe8

It seems to only affect certain NICs that bounce their link on some configuration operations.

CS · Sep 27, 2013, 8:05 PM

@jimp:

Try this fix:
https://github.com/pfsense/pfsense/commit/f3a4601c85c4de78caa4f12fefd64067fd83dbe8

It seems to only affect certain NICs that bounce their link on some configuration operations.

Many thanks jimp! It works fine for me. ;D

stephenw10 · Sep 27, 2013, 10:28 PM

Nice. :)
I'll have to give this a try when I get home.
Thanks Jim.

Steve

chpalmer · Sep 28, 2013, 7:26 AM

@/CS:

Many thanks jimp! It works fine for me. ;D

Ditto! 8)

Mavy · Sep 28, 2013, 9:29 AM

Fixed it for me aswell :)

stephenw10 · Oct 5, 2013, 11:11 AM

Thought I'd report back that this worked for me too.
I have another bridge of fxp(4) NICs that didn't have that problem so as you say it's not all NICs that are affected.

First chance I've had to try the System Patches package. Nice. :)

Steve

ESPNSTI · Oct 18, 2013, 12:51 AM

@jimp:

Try this fix:
https://github.com/pfsense/pfsense/commit/f3a4601c85c4de78caa4f12fefd64067fd83dbe8

It seems to only affect certain NICs that bounce their link on some configuration operations.

This worked on some interfaces for me, but not others.
Looking at the system logs and the patch code, I could see that it was still going through the same path, and the IP address was empty:

Oct 17 16:59:32 	php: rc.newwanip: rc.newwanip: Informational is starting em1.
Oct 17 16:59:32 	php: rc.newwanip: rc.newwanip: on (IP address: ) (interface: opt1) (real interface: em1).
Oct 17 16:59:32 	php: rc.newwanip: rc.newwanip: Failed to update opt1 IP, restarting...

I then looked at /cf/conf/config.xml and found that there were empty <ipaddr>xml tags on the interfaces that still had problems.
The IP address was set at some point on those in the process of creating the bridge.
I removed the empty tags from the config.xml file, rebooted, and the problem went away:

Oct 17 19:09:16 	php: rc.newwanip: rc.newwanip: Informational is starting em1.
Oct 17 19:09:16 	php: rc.newwanip: Interface does not have an IP address, nothing to do.

I'm not familiar with php at all, but I assume the isset function perhaps doesn't account for empty tags and returns true:

  if (($curwanip == "") && !(isset($config['interfaces'][$interface]['ipaddr']))) {
    log_error("Interface does not have an IP address, nothing to do.");
    return;
  }

FYI, I'm running the same configuration as the OP:
pfSense 2.1 on a Soekris net6501-50 (Intel 82574L Gigabit Ethernet ports)
I have WAN assigned to em0, OPT1-7 assigned to em1-7 with IPv4 and IPv6 set to none, and LAN is assigned to Bridge0, consisting of OPT1-7.

Anyway, thanks for the patch, that made things work a lot better. ;D

Also, the way that system patches process works is rather impressive.</ipaddr>

stephenw10 · Oct 18, 2013, 9:53 AM

Interesting, thanks for the heads up. :)

No spurious tags left in my config file. I don't think I ever had them set as anything but bridged on that box though.

Steve

ceama · Nov 7, 2013, 6:57 PM

Thanks Steve.
I'll try it. Some others tried the system patches feature. I guess that's the way to do it. There I go re-inventing the wheel again.

ceama · Nov 7, 2013, 11:20 PM

The official fix works for the msk driver. I like the system patch tool. It lets you use your own patches or official github links.