Issue #2960 has been updated by sepherosa.
On Wed, Oct 26, 2016 at 9:02 PM, <bugtracker-ad...@leaf.dragonflybsd.org> wrote: > Issue #2960 has been reported by fgudin. > > ---------------------------------------- > Submit #2960: net.inet.carp.setroute sysctl > http://bugs.dragonflybsd.org/issues/2960 > > * Author: fgudin > * Status: New > * Priority: Normal > * Assignee: > * Category: Networking > * Target version: > ---------------------------------------- > Hello, > > CARP adds and deletes routes as interfaces state change. I wanted to prevent > it from messing with routes on my hosts, and thus introduced a new sysctl > under net.inet.carp (default behaviour kept obviously). Diff was done against > v4.6.1. > > My use case was a dual squid proxy setting, where their processes couldn't > even resolve names, as the local resolvers were themselves subject to ARP > load-balancing. AFAIU, the default route being set to CARP's IP address > implied that their outgoing connections had their source address set to the > virtual IP. This may be ok for routing, etc. but as soon as the CARP-enabled > host has to initiate sessions, it breaks. Of course, I could be plain wrong > and willingly accepting advice if there's a better solution. > I believe the routes are only changed (points to the CARP's address) instead of deleted then re-added. Can you be more specific about your breakage? Thanks. sephe -- Tomorrow Will Never Die ---------------------------------------- Submit #2960: net.inet.carp.setroute sysctl http://bugs.dragonflybsd.org/issues/2960#change-13020 * Author: fgudin * Status: New * Priority: Normal * Assignee: * Category: Networking * Target version: ---------------------------------------- Hello, CARP adds and deletes routes as interfaces state change. I wanted to prevent it from messing with routes on my hosts, and thus introduced a new sysctl under net.inet.carp (default behaviour kept obviously). Diff was done against v4.6.1. My use case was a dual squid proxy setting, where their processes couldn't even resolve names, as the local resolvers were themselves subject to ARP load-balancing. AFAIU, the default route being set to CARP's IP address implied that their outgoing connections had their source address set to the virtual IP. This may be ok for routing, etc. but as soon as the CARP-enabled host has to initiate sessions, it breaks. Of course, I could be plain wrong and willingly accepting advice if there's a better solution. Thanks in advance, -- Francis GUDIN ---Files-------------------------------- carp.diff (3.36 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
