Repeating link state UP/DOWN atleast 5 times an hour (log entries inside)
Aug 21 09:14:33 dnsmasq: using nameserver 67.xx.xx.xx#53 Aug 21 09:14:33 dnsmasq: using nameserver 67.xx.xx.xx#53 Aug 21 09:14:33 dnsmasq: using nameserver 22.214.171.124#53 Aug 21 09:14:33 dnsmasq: using nameserver 126.96.36.199#53 Aug 21 09:14:33 dnsmasq: reading /etc/resolv.conf Aug 21 09:14:26 apinger: Starting Alarm Pinger, apinger(24867) Aug 21 09:14:26 check_reload_status: Reloading filter Aug 21 09:14:25 apinger: Exiting on signal 15. Aug 21 09:14:25 php: : Removing static route for monitor 67.xx.xx.xx and adding a new route through 71.xx.xx.xx Aug 21 09:14:25 php: : rc.newwanip: on (IP address: 192.168.1.1) (interface: lan) (real interface: sk0). Aug 21 09:14:25 php: : rc.newwanip: Informational is starting sk0. Aug 21 09:14:23 check_reload_status: rc.newwanip starting sk0 Aug 21 09:14:23 php: : Hotplug event detected for lan but ignoring since interface is configured with static IP (192.168.1.1) Aug 21 09:14:23 php: : Hotplug event detected for lan but ignoring since interface is configured with static IP (192.168.1.1) Aug 21 09:14:20 check_reload_status: Linkup starting sk0 Aug 21 09:14:20 kernel: sk0: link state changed to UP Aug 21 09:14:20 kernel: sk0: link state changed to DOWN Aug 21 09:14:20 check_reload_status: Linkup starting sk0
the following above will fire and repeat atleast 5 times an hour. very rarely will it happen less. …i never loose internet connectivity or lan connectivity. i have run several monitors over several days and i never lost connectivity on ANY of the monitors.
…so…this makes me wonder why a hotplug event would be fired off when the switch (which sk0 is plugged into) has zero problems, and the WAN link has never given me a problem since the day i had it installed (FIOS business 150mbps). just to be sure i tried a different switch. same problems.
i dont get it. i have the timer for ‘down time’ to fire off after 36 seconds of packet loss from my monitoring IP, but i wouldnt think that would affect the sk0 interface.
the build i am running is: 2.0-RC3 (i386) built on Tue Jun 21 16:50:25 EDT 2011
thoughts? im tired of seeing this in my system logs.
the same message appears for sk3 (my DMZ) with the same consistency. sk3 is ofcourse on a completely different switch, and a completely different NIC card brand.
…just a little more information for those who might need it. so it is not limited to my sk0 interface. it also happens on sk3.
(sk1 & 2 and disabled at the time being. they will be used for a different segment later)
From the “Hotplug event” I’d wonder if power management on the switch is coming into play or along those lines. IOW why does pfsense think that happened & what could cause it.
the power management was the first thing i looked at. its not a managed switch, and does have power management. i do have powerD enabled on pfSense.
i have also tried four other switches (managed & non-managed & different brands) …all still have the same problem.
OK bummer. I have an asus switch that people complain about issues with certain nics/equipment due to power management so fig’d worth asking.
Perhaps try without powerd or different type nic or different cables perhaps. Otherwise if you don’t lose connection it might not be a big deal.
fyi….all ports show ZERO up/down states when connected to different tools.
…so i dont think its the switch. i am wondering if powerD is powering down the NIC and causing for the up/down state. powerD shouldnt do that should it?
i have also turned off all ‘off-loading’ on the cards. ….ill monitor it over the next 24 hours to see…but all the NIC’s are the exact same model of netgear 1gbps NIC (i dont know the model number off the top).
more info on this topic…
i have tried TEN different switches …
the only thing i can think of is the NICs that might be causing this problem. i have zero problems with em0 (onboard gbic), but the other four NICs i have the problem with. Those NICs are ALL the same model/brand - d-link dge-530t
just your simple PCI gbic NIC from frys bought at 40$ a pop. i have never had a problem with these NIC’s before, and on the switches i have ZERO errors…etc.
I’m not sure about the sk driver but some of the Marvel NICs supported by the msk driver suffer from a fault in which it stops reveiving packets. The driver had a work around for such a condition that might cause the logs you are seeing as it resets the NIC.
This is some what speculative but both the sk and msk drivers are derived from the same source.
is there a perm work around? ……or should i got with different NICs? if so…which NICs would be recommended? tks in advance
Guess I’d figure if it isn’t hurting anything might be safe to ignore… Otherwise try different NIC’s, research more to see if there is a fix (like replacing drivers, tweaking settings etc) or wait for an update that might fix it. Think I’d pick option #1 or #2 myself.
ResIpsa last edited by
I was experiencing something similar, but the frequency was 5-10 up/down cycles per minute. I’m running a Jetway daughterboard with 3 Intel Gigabit NICs. Only the center NIC was experiencing the behavior. Reboots did not help, but leaving the machine unplugged for 15 minutes did.
I’m using jetway mb & 3 port intel gbit nic daughterboard & haven’t seen that. Maybe I need to look closer… Odd unplugging it for 15 minutes made a difference but maybe one of life’s mysteries. Imagine there is some logical explanation though.
i upgraded to the latest snapshot from flat RC3 and it seems to have fixed it. however, it did screw my snort all up.
ResIpsa last edited by
Mine is back - it looks like it is doing it every couple of minutes:
Sep 5 09:12:00 kernel: em1: link state changed to DOWN
Sep 5 09:12:01 check_reload_status: Linkup starting em1
Sep 5 09:12:03 check_reload_status: Linkup starting em1
Sep 5 09:12:03 kernel: em1: link state changed to UP
Sep 5 09:12:06 php: : Hotplug event detected for opt2 but ignoring since interface is configured with static IP (172.30.1.1)
Sep 5 09:12:09 php: : Hotplug event detected for opt2 but ignoring since interface is configured with static IP (172.30.1.1)
I’m running 2.0-RC3 (i386), built on Fri Sep 2 14:17:09 EDT 2011.
yes…i noticed mine doing it again. i switched out NICs to make sure that wasnt it.
i am going to update this weekend after i do a switch over