Project

General

Profile

Bug #18

Link loss can cause multi-WAN difficulties

Added by Chris Buechler almost 10 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
06/23/2009
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

When you lose link on a NIC assigned as an OPT WAN, the static route that directs the monitor IP out the correct WAN may get dropped from the routing table, causing the monitor pings to follow the default gateway. Generally not an issue as a WAN failure rarely results in link failure, but something we need to address in 2.0.

Associated revisions

Revision f353ebeb (diff)
Added by Sjon Hortensius about 4 years ago

converted usermanager_settings and setting_test

refs #18

Revision 4ee51131 (diff)
Added by Sjon Hortensius about 4 years ago

Convert main Usermanager

refs #18

Revision a0165602 (diff)
Added by Sjon Hortensius about 4 years ago

Convert System > Auth servers

refs #18

Revision 64600f94 (diff)
Added by Sjon Hortensius about 4 years ago

Some bugfixes, converted addPrivs

refs #18

Revision e6acc2ee (diff)
Added by Sjon Hortensius about 4 years ago

apply r/o state to name of system-groups

refs #18

History

#1 Updated by Ermal Lu├ži almost 10 years ago

Maybe the source address should be used for the icmp packets to make sure that it tries to go the correct interface!
For 2.0 that means that apinger sources might need modification(usually just try to bind to the source ip).

#2 Updated by Chris Buechler almost 10 years ago

Source address alone isn't adequate, as that traffic will still follow the system routing table even when sourced with an OPT WAN's IP. A route-to rule is a possible solution I think, haven't had a chance to try.

#3 Updated by Scott Ullrich over 9 years ago

  • Affected Version set to 2.0

Patch added to prevent the removal of static routes upon interface link loss. This is also similar to #72 ?

#4 Updated by Scott Ullrich over 9 years ago

  • Status changed from New to Resolved

This has been resolved with my recent change. I just tested by pulling my Wimax network interface and the static route remains in the routing table and works as it should.

#5 Updated by Chris Buechler over 9 years ago

  • Status changed from Resolved to Feedback

This needs more testing, and possibly a different solution, depending on how the routing functions in FreeBSD 8 and what unknown fallout there may be.

The code in filter.inc needs to be updated to never add a gateway on an interface that doesn't have link to help with this scenario.

#6 Updated by Chris Buechler about 9 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF