Interfaces don't come back online when WAN lost
-
I'm running pfsense 2.3.3-release on an intel c1037u based mini pc platform that has dual intel gigabit nics.
Whenever there is a power outage and my cable modem reboots, pfsense begins flapping the LAN and WAN interfaces up and down and never stops and returns them to service. I am able to quickly log in and reboot the system when this happens and it will return to service. I normally do this after the cable modem has sync again but have not tried it with WAN disconnected.
Can anyone think of any reason this might be happening or steps I can take to narrow it down?
-
Do you have any special settings on WAN or LAN such as a spoofed MAC address, speed/duplex setting, etc?
I haven't seen anything like that happen in quite some time, but the last time it did happen, it was because a network card chipset wanted to take the link down/up when certain settings were applied to the NIC, and it got stuck in a loop because applying the setting caused the NIC link to bounce, which generated another link event which caused the settings to be reapplied, which caused the link to go down and back up, and so on, and so on. I haven't seen that in a while though.
Seeing the system log from the time it happened might help track it down.
-
I just had a client visit yesterday that this appears to be very similar:
Default WAN port flaps (Flapping) every 1min or less
- resulting in a state of constant resets that it cannot stabilize to the second WAN interface and the network is Internet dead.
Hardware is a Supermicro - X10SDV-TLN4F – D-1541 2.1-2.7 Ghz 12MB L3 - 8 cores / 16 threads
WAN0 - is igb0 - DHCP - Comcast Business class gateway/router in Router mode - 10.1.10.1/30
WAN2 - is igb1
LAN1 - ix0
LAN2 -ix1 (empty port)Steps to Resolve:
1. pulled down pfSense 2.3.4-Release box - Tested with laptop direct on same cable and port to Comcast modem - no problems - stable.
2. Repowered Comcast modem and put pfSense box back into the mix per above and flapping started immediately on WAN0 - igb0
3. Decided to test another port on Comcast - no change in status
4. Changed pfSense WAN0 port from DHCP to Static 10.1.10.2/30 and it stabilized and forced set the gateway IP to 10.1.10.1. - rest i believe were unchanged default settings.
Here is the key part of the log IMHO:
Jun 27 11:55:52 php-fpm 88701 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.1.10.2 -> 10.1.10.2 - Restarting packages.
Jun 27 11:55:51 kernel igb0: link state changed to UP
Jun 27 11:55:51 check_reload_status Linkup starting igb0Gateway Log entries that repeat over and over seconds back to back:
Jun 26 12:18:26 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:25 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:25 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:24 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:24 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: Alarm latency 22427us stddev 5835us loss 50%
Jun 26 12:18:24 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:23 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:22 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:22 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:21 dpinger WANIGB0COMCAST_DHCP 73.211.120.1: sendto error: 65
Jun 26 12:18:20 dpinger send_interval 2000ms loss_interval 8000ms time_period 240000ms report_interval 0ms data_len 0 alert_interval 4000ms latency_alarm 500ms loss_alarm 40% dest_addr 10.5.0.1 bind_addr 10.5.22.1 identifier "LAN3igb1GW "
Jun 26 12:18:20 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 73.211.120.1 bind_addr 73.211.120.82 identifier "WANIGB0COMCAST_DHCP "Doing searches on 11:55:52 line item - /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection:
A. Bug #4474 - OpenVPN client connection causing - this was not the case for me at this time of the error - though OpenVPN is set and actively listening. I am remote OpenVPN now getting this log message and the logs are not showing this bug error.
B. Bug #6656 - similar?
My thought is that "rc.newwanip" code does not run once the interface is set for static ip versus DHCP?
