Adjusting apinger impact
-
If a connection is down, you don't want your states to be stuck on that connection, as active connections will never fail over to your remaining available connections. So a dead connection triggers killing all states on that connection. Just set your levels appropriately so it's not triggered unless it's truly down.
-
Thank you for the reply.
What if this is a single WAN configuration (which it is)? Why set it to fail over when there is nothing to fail over to? Why not just let connections eventfully time out- or resume, if the connection returns. Is there an advantage to having an alarm trigger a reload, breaking any persistent connections, when it is a single WAN situation?
-
High latency on the line is a sign of your connection being saturated. You might want to use the Traffic shaper to limit the bandwidth of the line to the actual line capabilities. This will prevent the latencies from sky-rocketing.
Another thing I've found useful to do in pfsense 2.0 is to set floating rules to direct ICMP into the highest priority queue (qACKs in my case).
If not, ICMP will be relegated to the default queue where, if the line is under heavy usage, may drop or greatly delay the packets that aPinger uses to test your line status. Since the ICMP packets are small and we only need apinger to determine if the line is up, this works very well and doesn't adversely affect the connection on a whole. -
These are some great ideas and something I'll definitely work on in the near future, thanks for the recommendations, esp when I start tuning the connection.
I've also noticed, by monitoring my quality rrd graphs, that they can occur randomly when there is no heavy network usage. It may be that my ISP gateway occasionally throttles back on responses- or something completely different.
-
Ah yeah, that runs now regardless of whether you have multi-WAN, and that behavior isn't desirable if you have a single connection.
http://redmine.pfsense.org/issues/911 -
Thank you very much! Your responsiveness is appreciated.
-
@cmb:
Ah yeah, that runs now regardless of whether you have multi-WAN, and that behavior isn't desirable if you have a single connection.
http://redmine.pfsense.org/issues/911Hmm, I think this explains a problem I have had (it sounds related to Bug #911):
A couple of weeks ago my ISP had a failure that made my monitor IP (GW) on WAN (DHCP) unavailable for a longer period.
I thought it was extra weird that I wasn't able to connect to my other router residing outside WAN2 when the GW on my primary WAN was down.
What I remember was that I was able to get the login screen but then the login process just appeared to be hung (states got cleared?).
The monitor IP on WAN2 (DHCP) was never down. I can't trigger this again as it is not the same thing as just unplugging the cable on WAN.
-
High latency on the line is a sign of your connection being saturated. You might want to use the Traffic shaper to limit the bandwidth of the line to the actual line capabilities. This will prevent the latencies from sky-rocketing.
Another thing I've found useful to do in pfsense 2.0 is to set floating rules to direct ICMP into the highest priority queue (qACKs in my case).
If not, ICMP will be relegated to the default queue where, if the line is under heavy usage, may drop or greatly delay the packets that aPinger uses to test your line status. Since the ICMP packets are small and we only need apinger to determine if the line is up, this works very well and doesn't adversely affect the connection on a whole.This, along with the new System/Advanced/Miscellaneous/Gateway Monitoring Setting has solved all my apinger problems I was having, most especially with gaming. Thank you, I believe this should be stickied in the 2.0 Beta forum
-
Happy New Year folks!
Despite of the adjustment I have tried to make I still constantly observe this issue.
Please advice how to disable it or to stop getting this warning and dropping the connections.
It is definitely something wrong with the router, because with the spare Linksys on interruptions are observed.
Jan 1 15:43:57 check_reload_status: reloading filter
Jan 1 15:43:57 check_reload_status: reloading filter
Jan 1 15:43:47 apinger: alarm canceled: Gateway(xx.xx.xx.1) *** Gatewaydown ***
Jan 1 15:43:47 apinger: ALARM: Gateway(xx.xx.xx.1) *** Gatewaydown ***
Jan 1 15:40:36 check_reload_status: reloading filter
Jan 1 15:40:36 check_reload_status: reloading filter
Jan 1 15:40:26 apinger: alarm canceled: Gateway(xx.xx.xx.1) *** Gatewaydown ***
Jan 1 15:40:26 apinger: ALARM: Gateway(xx.xx.xx.1) *** Gatewaydown ***
Jan 1 15:37:21 check_reload_status: reloading filter
Jan 1 15:37:21 check_reload_status: reloading filter
Jan 1 15:37:11 apinger: alarm canceled: Gateway(xx.xx.xx.1) *** Gatewaydown ***
Jan 1 15:37:11 apinger: ALARM: Gateway(xx.xx.xx.1) *** Gatewaydown ***
Jan 1 15:33:33 check_reload_status: reloading filter
Jan 1 15:33:33 check_reload_status: reloading filter
Jan 1 15:33:23 apinger: alarm canceled: Gateway(xx.xx.xx.1) *** Gatewaydown ***
Jan 1 15:33:23 apinger: ALARM: Gateway(xx.xx.xx.1) *** Gatewaydown ***Some addtional information, I have one WAN, static IP.
Gateway is set to 10 seconds down time. The rest is empty (but I did test with the values mentioned above).
Gateway monitor is disabled. -
Disabling state killing will not disable notification on logs.
It just means that the states will not get killed and that's it.
