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

jimp

If you are using the system patches package make sure that not only you get patch 58ee84b4b2f9daba87e44abf663026c6266a7cd8 but also 793299b8f5bdc0fd167093cc5ab9f3f30f0d77ac

Both could be relevant to similar issues, but it would still only apply for interfaces that were set to an IP type of "none" (typically bridged interfaces)

jdp0418

I would like to chime in and also confirm this fix worked for me.

I am using a Soekris Net6501-50 with the Intel 82574L 4 port Gigabit Ethernet card. I experienced the same issue with an interface configured into a bridge group bouncing continuously when connecting a device and establishing link. This patch worked for me.

I applied it using the System Patch package. For anyone who is unfamiliar with it, it's pretty easy. Install the "System Patch" package, and then under the Patches screen, add the link from jimp. Fetch the patch, test it (making sure it doesn't have any issues applying), and then apply the patch. It seemed to work without rebooting, but I did anyway just for good measure.

Thanks for those who contributed to this thread and thanks to jimp for the fix!

webroy

I have a bridged setting (WAN - DMZ) on a asus server rs300-e7 with 4 NIC. i have done this patch https://github.com/pfsense/pfsense/commit/f3a4601c85c4de78caa4f12fefd64067fd83dbe8

unfortunatly i still recieve a lot of time outs on every server behind the DMZ.

the first rule in the WAN is Allow ICMP from all to all. Are there any options which i can test?

p.s. it looks like the more data is beeing processed by pfsense the more time outs it gets…. all loggings are out on the rules. pftop is showing ok status

webroy

i am almost certain that if there are more connections through the pfsense firewall the more time outs we get, the server hardware is 3 years old with 32GB of ram… states counts is now 6125 and a recieve some pings traffic in is 1MB traffic out is 3MB ..

stephenw10

Where are yoy seeing these 'timeouts'?

Steve

webroy

when i ping to servers behind the pfsense firewall. ( i have now 2 servers behind that)

the pfsense box itselfs does not give time out, when i ping to other servers (not behind the pfsense ) no time out occurs.

I have also got a server, when i put this behind the pfsense firewall ping time outs occurrs , and when i put it back behind the sonicwall firewall no ping time out occurs

Like i said, the more traffic over the pfsense the more time out occurs…. the hardware should not be a problem:

24GB memory Intel Xeon 3470 Raid 4x 1TB raid 10

When ping time outs also apache etc is connecting

stephenw10

That doesn't sound like the interface flapping problem described in this thread. Are you seeing the interface going up and down in the logs?

Steve

webroy

I had that until i did:

https://github.com/pfsense/pfsense/commit/f3a4601c85c4de78caa4f12fefd64067fd83dbe8

now i dont have that anymore but still the ping time outs when more traffic comes over the firewall

webroy

The lan cards in the asus server are Intel 82574L known issues with that type of LAN?

stephenw10

No the 82574L is well tested and widely used.

I think this is probably unrelated to the bridge issue, maybe start a new thread.

Interestingly I see that JimP has actually posted three patches for this issue:

Initially:
https://github.com/pfsense/pfsense/commit/f3a4601c85c4de78caa4f12fefd64067fd83dbe8

and then:
https://github.com/pfsense/pfsense/commit/58ee84b4b2f9daba87e44abf663026c6266a7cd8
and
https://github.com/pfsense/pfsense/commit/793299b8f5bdc0fd167093cc5ab9f3f30f0d77ac

Have you done this?:
https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Intel_igb.284.29_and_em.284.29_Cards

Steve

webroy

Thank you Stephan for youre time !

I will check those links out and will publish the result.

webroy

Unfurtantly the links you provided did not solve the problem.

When i ping my server behind the pfsense bridge it pings good and then loses sometimes 5 pings or more…. i do not understand why.. server is down for sometime.. I put the same server behind an other firewall ( Sonicwall) and no problems...

I ping from differtent locations to the server and different internet providers.. the logs of the pfsense do not show a thing..

webroy

Oke what i did;

reinstalled pfsense 2.1 now with version i386 in stead of amd64.

After install a added NO Packages.

I did a WAN -> DMZ setting and i did a LAN setting (3x NIC)

A added all 3 GitHub rules ( like mentioned before)

So Setup 1 non busy server behind DMZ looks oke , seconds one (non busy server looks oke) Then a third server with some more traffic and ping loss. more down then up. (load pfsense fw is 0.2)

If i put only the busier server behind the pfsense all is fine…

So the busier server behind the SOnicwall again and all goes smootly.

It looks like if i get over 10000 states the error occurs ... in the firewall settings is see this:

Note: Leave this blank for the default. On your system the default size is: 326000 so that should be oke...

Fact is that the more traffic over the pfsense FW the more time out and problems i have....

stephenw10

You tried the tuning options on your em NICs?

It's not surprising that once you hit, whatever your problem is, it shows more the more traffic you push through the box.

Is there anything in the logs? As you've said 10000 states show be no problem for your hardware.

Steve

webroy

Hi stephen , i made a new topic because this looks like another problem..

http://forum.pfsense.org/index.php/topic,71432.0.html

kevin067

I am having this problem currently, and I do have a bridge with the wireless and the lan adapter without an assigned ip address.

if I try to apply patch 793299b8f5bdc0fd167093cc5ab9f3f30f0d77ac

it tells me that it cannot apply it, upon inspection of the latest 2.1 code in rc.newwanip. It is quite different it seems so the reason for the patch failure.

If I apply patch 58ee84b4b2f9daba87e44abf663026c6266a7cd8
this seems to go through. But does not fix my problem.

I don't really want to assign ip address's to these adapters behind the bridge. Anybody work this out?

I am on pfsense 2.1 with two intel pro lan gbe adapters.
Here is my interfacelayout.

Wan = em0 (dhcp)
Lan = em1 (none)
WIFI= ath0 (none)
Intranet = (static) bridge0 (lan,wifi)

I have also applied the other tunables for intel lans with no improvement

The symptoms are that after a day or two of running I will find em1 cycling up and down and of course the network is offline while it is down.

stephenw10

If you're experiencing the problem described in this thread the interface will 'flap' continuously going up and down approximately every 10 seconds. Your logs will be filled. If that is what you're seeing the easiest thing to do is just try a 2.1.1 snapshot which already contains the patches listed here (any many more).

https://forum.pfsense.org/index.php/topic,71546.0.html

Steve

jomcy

Hi,

this up/down issue is happening because of the some bug in new version and the script rc.newwanip is restarting the interfere(this script will restart the WAN interface if there is no IP on it).

actualy this script for wan interface only and unfortunately all interface in bridge considering as wan interface in new version(bug). Normal we are not assigning any IPs for all member interfaces in bridge( practical not required) so script will restart the interface. for a workaround we can assign some dummy IPs to those member interfaces and that will solve the issue.

ex: Bridge x and opt1, opt 2 and opt3 are members of it, assign 127.0.0.2 to opt1, 127.0.0.3 to opt2 and 127.0.0.4 to opt3
jomcy

phil.davis

As Steven says, try 2.1.1-prerelease, there are relevant fixes in that that should help.
I have been testing the latest build of it today:

2.1.1-PRERELEASE (i386)
built on Sun Feb 2 12:42:30 EST 2014
FreeBSD 8.3-RELEASE-p14

and it is running nicely for everything I do.

kevin067

I can confirm also that 2.1.1 prerelease fixes the cycling issue after 3 days of running no issues. 2.1.1 also fixed snort clearing it's block table.

Firewall logs also seemed to stay in sync after rule changes.