> On 4. Dec 2023, at 10:59, Stuart Henderson wrote:
>
> On 2023-12-01, Christian Gut wrote:
>> Hi List,
>>
>> I just updated two carp/pfsync firewalls from 7.3 to 7.4. After updating the
>> second box I see a massive increase in traffic on the syn
On 2023-12-01, Christian Gut wrote:
> Hi List,
>
> I just updated two carp/pfsync firewalls from 7.3 to 7.4. After updating the
> second box I see a massive increase in traffic on the sync interface. I now
> reproduced this with another pair of firewalls - same thing.
>
&g
Hi List,
I just updated two carp/pfsync firewalls from 7.3 to 7.4. After updating the
second box I see a massive increase in traffic on the sync interface. I now
reproduced this with another pair of firewalls - same thing.
Both firewall have three physical interfaces: external, internal
On 9/18/23 8:59 PM, Stuart Henderson wrote:
On 2023-09-18, Mark Patruck wrote:
i've already wrote to dlg@, but also want to know if others see
the same behavior or at least inform about it.
pfsync(4) in combination with rdomain(4) doesn't work anymore on
a fresh -current. I see packets
On 2023-09-18, Mark Patruck wrote:
> i've already wrote to dlg@, but also want to know if others see
> the same behavior or at least inform about it.
>
> pfsync(4) in combination with rdomain(4) doesn't work anymore on
> a fresh -current. I see packets on pfsync0, but nothing leave
Hi,
i've already wrote to dlg@, but also want to know if others see
the same behavior or at least inform about it.
pfsync(4) in combination with rdomain(4) doesn't work anymore on
a fresh -current. I see packets on pfsync0, but nothing leaves
the machine, so no states are synchronised
On Thu, May 19, 2022 at 09:35:53AM -, Stuart Henderson wrote:
> On 2022-05-19, Jordan Geoghegan wrote:
> > I've run pfsync + CARP for a number of years now. One interesting
> > "gotcha" I discovered when building an IPv6-only test network was that
> > pfsyn
On 2022-05-19, Jordan Geoghegan wrote:
> I've run pfsync + CARP for a number of years now. One interesting
> "gotcha" I discovered when building an IPv6-only test network was that
> pfsync does not work in an IPv6-only environment. I tried both unicast
> and mu
On 5/11/22 12:32, Tom Smyth wrote:
Hello Folks,
We are updating some course material for an upcoming PF firewall course,
and I would like to put a call out to those who use PFsync in a
redundant firewall cluster
about your user experience, have you come across any edge cases?
have you any
2022 at 11:20, Stuart Henderson
wrote:
>
> On 2022-05-13, Marko Cupać wrote:
> > The only problem I currently have with pfsync is the fact that it does
> > not synchronise queue membership of states.
>
> IIRC this is meant to work but only if you have identical rulesets,
>
On 2022-05-13, Marko Cupać wrote:
> The only problem I currently have with pfsync is the fact that it does
> not synchronise queue membership of states.
IIRC this is meant to work but only if you have identical rulesets,
after expanding interface addresses etc. This will require som
Nick Holland writes:
> Wrote a little script which, when run:
Good grief, man! Just put the pf.conf in CVS and push it with
rdist. We do that for all our carped firewall pairs and it
works a treat. The following 'special' command in the Distfile
will give you a failsafe reload of the pf rules:
Hi Tom
On 5/11/22 21:32, Tom Smyth wrote:
We are updating some course material for an upcoming PF firewall course,
and I would like to put a call out to those who use PFsync in a
redundant firewall cluster
The one thing that immediately comes to mind is to NOT use a crossover
cable
On 5/11/22 3:32 PM, Tom Smyth wrote:
Hello Folks,
We are updating some course material for an upcoming PF firewall course,
and I would like to put a call out to those who use PFsync in a
redundant firewall cluster
about your user experience, have you come across any edge cases?
have you any
Hello Folks,
We are updating some course material for an upcoming PF firewall course,
and I would like to put a call out to those who use PFsync in a
redundant firewall cluster
about your user experience, have you come across any edge cases?
have you any tips or tricks about PFSync.
have you come
On 2/1/21 8:20 PM, Kapetanakis Giannis wrote:
> On 02/02/2021 05:18, Jordan Geoghegan wrote:
>> Hello,
>>
>> I had a question about using relayd with pfsync.
>>
>> I have a small gateway/load-balancer set up with relayd, carp and pfsync
>> plus BGPd for
On 02/02/2021 05:18, Jordan Geoghegan wrote:
Hello,
I had a question about using relayd with pfsync.
I have a small gateway/load-balancer set up with relayd, carp and pfsync plus
BGPd for IP failover, and everything is working great. I was pleasantly
surprised at how easy it was to get
Hello,
I had a question about using relayd with pfsync.
I have a small gateway/load-balancer set up with relayd, carp and pfsync plus
BGPd for IP failover, and everything is working great. I was pleasantly
surprised at how easy it was to get pfsync tunnelled over wireguard. Things
failover
an still be used with an identical ruleset.
>
> >2) Both of the firewall IP addresses can be in a rule if egress is
> >not suitable for your topology, something like this will sync over
> >cleanly with pfsync: pass in quick log on $ext_if inet proto tcp to {
> >$fw1_ext $f
On 6/9/2020 1:42 PM, Markus Wernig wrote:
Neither jumbo frames nor multicast will prevent group demotion when the
other side of a crosslink cable goes physically down. Only not having
the sync interface in the carp group will.
True. But I think he was just discussing general best practices,
On 6/9/20 9:25 PM, Paul B. Henson wrote:
> Hmm, I had never considered using jumbo frames.
...
> I guess multicast would work too
Neither jumbo frames nor multicast will prevent group demotion when the
other side of a crosslink cable goes physically down. Only not having
the sync interface in
On 6/9/2020 7:36 AM, Stuart Henderson wrote:
IME the best setup for pfsync between 2 machines is to use a dedicated
cross-connect (preferably configured for jumbo frames). Obviously that's
not possible with >2 machines though.
Hmm, I had never considered using jumbo frames. It looks l
; But I have found it problematic, because taking down one firewall, or
> even only its sync interface, will automatically demote the sync
> interface on the other one, which then will affect the whole carp group,
> if the interface is part of that group.
That is exactly what Paul's suggestion
On 6/9/20 12:27 AM, Paul B. Henson wrote:
> Yes, I am using a direct link between the two physical firewalls.
[...]
> Is this no longer a best practice?
If it's in the documentation, I suppose it still is.
But I have found it problematic, because taking down one firewall, or
even only its sync
tion "Combining CARP and pfsync for Failover" it says:
! enable preemption and group interface failover
# sysctl net.inet.carp.preempt=1
# echo 'net.inet.carp.preempt=1' >> /etc/sysctl.conf
As well as in the example in 'man pfsync':
The following must also be added to /etc/sysctl.conf:
by the documentation?
https://www.openbsd.org/faq/pf/carp.html
"The firewalls are connected back-to-back using a crossover cable on em1."
As well as in 'man pfsync':
"Only run the pfsync protocol on a trusted network - ideally a network
dedicated to pfsync messages such
Am 08.06.2020 00:29 schrieb Paul B. Henson:
However, for only two firewalls, when you're using the syncpeer
directive for the pfsync interface, it seems it would be better not to
default to belonging to the carp group? With only two firewalls, if
one of them has broken synchronization, so does
On 6/8/20 12:29 AM, Paul B. Henson wrote:
> whenever I rebooted the secondary firewall, the
> carp interfaces on the primary would flip to backup and then back to
> master as the secondary one rebooted
I don't see that behaviour on my carp pair. Are you using a cross-link
cable between the two
I've had a pair of redundant firewalls using pfsync for years. I've
noticed in the past that whenever I rebooted the secondary firewall, the
carp interfaces on the primary would flip to backup and then back to
master as the secondary one rebooted. I never really noticed any issues
with it, so
this will sync over
cleanly with pfsync: pass in quick log on $ext_if inet proto tcp to {
$fw1_ext $fw2_ext } port 22
I thought about doing that, but I ended up just making a table with a
single IP address in it, each router having the appropriate IP address
in the table, and the rule referencing
mething like this will sync over cleanly with
pfsync:
pass in quick log on $ext_if inet proto tcp to { $fw1_ext $fw2_ext } port 22
Where is it documented that in order for pfsync to properly synchronize
rule specific state timeouts that the rule sets on the systems being
synchronized must be *exactly* the same?
I have a pair of redundant firewalls synchronizing state, and recently
added a couple rules that increase
I've been trying to diagnose a mysterious issue where a UDP state
disappears before it's supposed to expire. I finally tracked it down to
pfsync. On the primary server, the state entries look like:
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:02:21, expi
Hi all,
After upgrade my two OpenBSD carp’ed fws to 6.7, I am seeing a lot of “failed
state lookup/inserts” statistics.
On firewall A:
pfsync:
5487 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for bad interface
0
in relation to the syncdev parameter.
>>
>> Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan
>> interface for pfsync ?
>>
>
> It's as secure as your ethernet network is. There is no privacy or
> authentication with pfsync. I don't think
14 Nov 2019, 11:21 by liste...@wernig.net:
> On 14.11.2019 11:30, Rachel Roch wrote:
>
>>>> Does this mean Bad Things (TM) will happen if I try to use a dedicated
>>>> vlan interface for pfsync ?
>>>>
> I have had pfsync running happily over
On 14.11.2019 11:30, Rachel Roch wrote:
>>> Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan
>>> interface for pfsync ?
I have had pfsync running happily over a vlan interface for years, never
a problem.
> Regarding the extra port, in my case I'
quot;
>> in relation to the syncdev parameter.
>>
>> Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan
>> interface for pfsync ?
>>
>
> It's as secure as your ethernet network is. There is no privacy or
> authentication with pfsync. I do
Bad Things (TM) will happen if I try to use a dedicated vlan
> interface for pfsync ?
>
It's as secure as your ethernet network is. There is no privacy or
authentication with pfsync. I don't think that using a vlan is
considered a big problem these days. I'm absolutely amazed at the
volume o
Hi,
Both the man page and FAQ (https://www.openbsd.org/faq/pf/carp.html)
<https://www.openbsd.org/faq/pf/carp.html> talk about "physical interface" in
relation to the syncdev parameter.
Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan
interface for
> On 2019/02/22 20:45, Charles Amstutz wrote:
> > > Not sure if it will give any additional clues but can you show dmesg
> please?
> >
> > Sure, however, they are quite lengthy, are you wanting the whole thing? I
> apologize not sure of protocol here.
>
> Yes please, the whole thing is fine (and
On 2019/02/22 20:45, Charles Amstutz wrote:
> > Not sure if it will give any additional clues but can you show dmesg please?
>
> Sure, however, they are quite lengthy, are you wanting the whole thing? I
> apologize not sure of protocol here.
Yes please, the whole thing is fine (and preferable
> Not sure if it will give any additional clues but can you show dmesg please?
Sure, however, they are quite lengthy, are you wanting the whole thing? I
apologize not sure of protocol here.
Not sure if it will give any additional clues but can you show
dmesg please?
On 2019-02-21, Charles Amstutz wrote:
>> congestion 1777154 11.1/s
>>
> The actual problem that we are seeing is that OpenBSD is
> Charles Amstutz(charl...@binary.net) on 2019.01.30 23:16:17 +:
> > Hello
> >
> > We are running into an issue with a lot of dropped packets where states
> are failing to be created. We have noticed that it coincides with a fair
> amount
> of congestion, around 10-15/s according to 'pfctl
Charles Amstutz(charl...@binary.net) on 2019.01.30 23:16:17 +:
> Hello
>
> We are running into an issue with a lot of dropped packets where states are
> failing to be created. We have noticed that it coincides with a fair amount
> of congestion, around 10-15/s according to 'pfctl -si'.
>
it will not try
to take over even if it has lower advskew than the other, until the sync is
complete.
depending on the setting of sysctl net.inet.carp.log,
carp(4) will log what it (and pfsync) does.
I highly appreciate your response.
Regards
Harri
Charles Amstutz(charl...@binary.net) on 2019.01.30 23:16:17 +:
> Hello
>
> We are running into an issue with a lot of dropped packets where states are
> failing to be created. We have noticed that it coincides with a fair amount
> of congestion, around 10-15/s according to 'pfctl -si'.
>
>
Janne Johansson(icepic...@gmail.com) on 2019.02.01 12:49:53 +0100:
> Den fre 1 feb. 2019 kl 07:17 skrev Harald Dunkel :
>
> > Hi folks,
> > I have a question about pfsync protocol in a master-backup firewall
> > configuration (OpenBSD 6.3 and 6.4):
> > If I rebo
Den fre 1 feb. 2019 kl 07:17 skrev Harald Dunkel :
> Hi folks,
> I have a question about pfsync protocol in a master-backup firewall
> configuration (OpenBSD 6.3 and 6.4):
> If I reboot (let's say) the backup host, will it receive the whole
> set of state information again, wh
Hi folks,
I have a question about pfsync protocol in a master-backup firewall
configuration (OpenBSD 6.3 and 6.4):
If I reboot (let's say) the backup host, will it receive the whole
set of state information again, when it gets back online?
Hopefully I am not too blind to see, but pfsync(4
Charles Amstutz(charl...@binary.net) on 2019.01.30 23:16:17 +:
> Hello
>
> We are running into an issue with a lot of dropped packets where states are
> failing to be created. We have noticed that it coincides with a fair amount
> of congestion, around 10-15/s according to 'pfctl -si'.
>
>
Hello
We are running into an issue with a lot of dropped packets where states are
failing to be created. We have noticed that it coincides with a fair amount of
congestion, around 10-15/s according to 'pfctl -si'.
We finally tried disabling our Carp Interfaces (we are using carp for failover)
Just a plus
After performed a ton of test's I bring up debian linux freebsd and
Windows .
freebsd : with fetch tool no issue using ftp causes the stalled
OpenBSD: wget and ftp tool causes connection stalled
linux debian: wget works
Windows: works
I tested the retrieve with
Hello Misc,
I kindly would like to ask if anyone already faced something like this:
I have the follow setup
VMware 6 ( one physical interface )
2x OpenBSD 6 ( cloned machine) ( using E1000 ) ( was using vmxnet3 )
OpenBSD Router running 3 carps ( ext / dmz / lan )
Physical Carp interfaces has
Hello All, Sunday is Valentine day
I know pfsync will sync the state between two routers, sasync and other
tools will help syncing other daemon,
Are pf table synced as well ? is it possible to ignore one table ?
Best
pfsync does not sync any rules, nor tables. It only syncs states.
You'll need to sync rules and tables on your own.
On 2016 Feb 12 (Fri) at 14:21:44 -0500 (-0500), sven falempin wrote:
:Hello All, Sunday is Valentine day
:
:I know pfsync will sync the state between two routers, sasync
micro-board machines with four network interfaces each (em0 ..
em3).
Networks:
LAN A : 172.16.210/24 via em0
LAN B : 172.16.0/24 via em1
direct connect for pfsync: 1.1.1.0/30 via em3
Gateway A setup --- (master) ---
hostname.em0:
"inet 172.16.210.2 255.255.255.0"
hostname.em1:
&
Hello @list,
perhaps I'm stupid but I've got a problem with two CARPed gateways
running 5.7-amd64 stable.
Hardware:
two supermicro-board machines with four network interfaces each (em0 ..
em3).
Networks:
LAN A : 172.16.210/24 via em0
LAN B : 172.16.0/24 via em1
direct connect for pfsync
Hi,
Pfsync + ipsec setup IS broken.
Links:
http://marc.info/?l=openbsd-miscm=143463803906528w=2
Patch to manual page has been applied:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/man/man4/pfsync.4.diff?r1=1.32r2=1.33
Please remove example of this setup:
2. Use the ifconfig(8) syncpeer
below, though i
commented out text rather than removing it.
thanks for the diff,
jmc
Thank you.
Please also remove this line:
2. Use the ifconfig(8) syncpeer option (see below) so that updates are
unicast directly to the peer, then configure ipsec(4) between the hosts
to secure the pfsync(4
. The peer already has IPsec state
in memory (created by pfsync replication) which matches incoming IPsec
packets directed at it. So the peer's IPsec stack ends up believing it's
seen the incoming packet already (while it actually hasn't seen the packet,
it just copied the IPsec state from
W dniu 2015-06-18 o 17:30, Łukasz Czarniecki pisze:
It's still broken because as mentioned at the end of the thread you
linked IPsec state gets replicated to the peer and this is causing
the replayed packets you're seeing. The peer already has IPsec state
in memory (created by pfsync
It's still broken because as mentioned at the end of the thread you
linked IPsec state gets replicated to the peer and this is causing
the replayed packets you're seeing. The peer already has IPsec state
in memory (created by pfsync replication) which matches incoming IPsec
packets directed
On Thu, Jun 18, 2015 at 03:44:24PM +0200, Łukasz Czarniecki wrote:
Hi,
I have the same problem described here:
http://openbsd-archive.7691.n7.nabble.com/pfsync-over-ipsec-is-broken-td257496.html#a257681
My system is 5.7 i386
I have keep state (no-sync) on all local terminated traffic
On 2015-02-13, Adam Thompson athom...@athompso.net wrote:
I've got two OpenBSD 5.6-STABLE (courtesy of M:Tier packages, thanks
guys!) BGP routers running carp pfsync between them for some of the
internal interfaces. Yes, I probably should have done this using two
routers, two firewalls
Firstly: this problem never occurred even once in ~6 months of operation
with pf(4) disabled; it never occurred in ~2 months of operation with
pf(4) enabled, an accept-all ruleset and no pfsync, and now with pfsync
configured it's happening about once a week.
My setup is complex enough that I
Spotted a missing n in pfsync(4):
Index: share/man/man4/pfsync.4
===
RCS file: /cvs/src/share/man/man4/pfsync.4,v
retrieving revision 1.31
diff -u -p -r1.31 pfsync.4
--- share/man/man4/pfsync.4 29 Apr 2010 08:45:44 -
1.31
Hi,
I've just changed my pair of of firewalls (master/backup) from
carp/pfsync to ospf/pfsync (both external/internal interfaces).
Primary has metric 1 and backup has metric 10 in interfaces in ospfd.conf.
I'm looking for success stories for the initial bulk transfer/sync of
states
On 10/10/14 23:34, Stuart Henderson wrote:
oops, missed your sysctl -a output (I wasn't expecting to see it,
well done ;-)
net.inet.ip.ifq.drops=140720
You would probably benefit from increasing net.inet.ip.ifq.maxlen,
maybe double it once or twice and see if net.inet.ip.ifq.drops stops
, but they
didn't disappear.
Pfsync is configured to use unicast, the defer option is present:
# cat /etc/hostname.pfsync0
up syncif vlan123 defer syncpeer xx.xx.xx.xx
You are correct, the routing can be asymmetric in our case.
What does the output of sysctl kern.netlivelocks net.inet.ip.ifq
look like
Hi
First, thank you Paul and Andy for your input! I'm very thankful for
your effort!
On Thu, 2014-10-09 at 16:08 +0100, Andy wrote:
I have seen this when the allowed number or states is too low and PF
clears the idle states too early..
See http://www.openbsd.org/faq/pf/options.html;
set
On 2014-10-09, Nicolas Christener li...@0x17.ch wrote:
Besides those steps we also disabled one of the boxes by stopping ospf
and removing the carp interfaces - however, the disconnects didn't go
away.
I was going to suggest that you might have asymmetric routing causing
split states i.e. one
oops, missed your sysctl -a output (I wasn't expecting to see it,
well done ;-)
net.inet.ip.ifq.drops=140720
You would probably benefit from increasing net.inet.ip.ifq.maxlen,
maybe double it once or twice and see if net.inet.ip.ifq.drops stops
increasing.
- OpenBSD 5.5
- trunk between the two NICs
- 13 VLANs interfaces with carp failover
- one VLAN for pfsync
- ospfd and ospf6d
- approx. 200Mbit/s of traffic
- the initial pfysnc takes quite long (~1h)
The setup looks like this (not sure if relevant):
- both servers have a failover trunk with two
, 2GB RAM,
Intel Xeon E5335@2.0GHz
- OpenBSD 5.5
- trunk between the two NICs
- 13 VLANs interfaces with carp failover
- one VLAN for pfsync
- ospfd and ospf6d
- approx. 200Mbit/s of traffic
- the initial pfysnc takes quite long (~1h)
The setup looks like this (not sure if relevant):
- both
- trunk between the two NICs
- 13 VLANs interfaces with carp failover
- one VLAN for pfsync
- ospfd and ospf6d
- approx. 200Mbit/s of traffic
- the initial pfysnc takes quite long (~1h)
The setup looks like this (not sure if relevant):
- both servers have a failover trunk with two
* Tony Sarendal t...@polarcap.org [2014-09-03 06:48]:
The initial request disappearing and the firewalls staying demoted
forever are independent issues.
sure about that? the demotion counter for the interface group pfsyncX
is part of (usually carp) is kept raised until the bulk transfer
group pfsyncX
is part of (usually carp) is kept raised until the bulk transfer
finishes.
Looks like separate issues.
I have done more testing since, using 5.5. In all cases the demote
counter restores after the bulk transfer completes, or after pfsync
gives up after 12 retries. I have a few 5.4
he's clearly indicating currently supported OpenBSD versions 5.4
and 5.5 near the bottom...)
On 30 Aug 2014 at 14:22, Chuck Burns wrote:
On Saturday, August 30, 2014 8:27:24 AM Tony Sarendal wrote:
Good morning,
I'm having issues with pfsync on trunk interfaces, although I suspect
Final email in this thread, for correctness.
The initial request disappearing and the firewalls staying demoted
forever are independent issues.
A new request for bulk transfer is sent after 2h+. Due to bulk transfer
performance the transfers
never finish. I see on average 3kpps of pfsync
Good morning,
I'm having issues with pfsync on trunk interfaces, although I suspect it to
be
any interface that is slow to start. When I run pfsync on a vlan interface
on a trunk(4),
the pfsync bulk transfer never completes.
Running pfsync on an interface that starts quickly I see:
07:41
On Saturday, August 30, 2014 8:27:24 AM Tony Sarendal wrote:
Good morning,
I'm having issues with pfsync on trunk interfaces, although I suspect it to
snip
Running on pfsync on trunk(4) that initial request never shows up, and the
bulk update never starts/finishes. I would like to run pfsync
,
I'm having issues with pfsync on trunk interfaces, although I suspect
it to
snip
Running on pfsync on trunk(4) that initial request never shows up, and
the bulk update never starts/finishes. I would like to run pfsync on
trunk(4) lacp link, but as it looks now I have firewalls with carp
On 01/04/14 21:21, Kapetanakis Giannis wrote:
After updating my primary firewall to current, the pfsync initial sync
does not end.
Primary firewall is
OpenBSD 5.5-current (GENERIC.MP) #0: Tue Apr 1 19:26:27 EEST 2014
with latest 5.5 errata applied,
secondary firewall is a bit older but I'm
After updating my primary firewall to current, the pfsync initial sync
does not end.
Primary firewall is
OpenBSD 5.5-current (GENERIC.MP) #0: Tue Apr 1 19:26:27 EEST 2014
with latest 5.5 errata applied,
secondary firewall is a bit older but I'm afraid to update cause this
might be the only
to put a production system with
carp+pfsync+relayd on production.
The point is that im facing some trouble setting more than one ip
alias
address with different vhid and different passwd.
So, this is the scenario.
Im trying to relayd more or less 15 sites so i have conceptual
Output for
'pfctl -si', 'pfctl -sm' and 'sysctl -a|grep net.inet.ip.ifq would be hie to
see.
//mxb
On 18 nov 2013, at 04:20, Leonardo Santagostini lsantagost...@gmail.com
wrote:
Sorry, looking more detailed at the logs i found this:
/var/log/daemon
Nov 17 18:36:12 v-arcbabalancer01
Ok, thanks for all the replies. Im waiting to this situation appears to
send to you the output of those commands.
Thanks and regards
Saludos.-
Leonardo Santagostini
http://ar.linkedin.com/in/santagostini
2013/11/18 mxb m...@alumni.chalmers.se
Output for
'pfctl -si', 'pfctl -sm' and
Hello list, i found something strange.
By one side, cpu idle is at 0%
[root@v-arcbabalancer01 ~]# vmstat 2 20
procsmemory pagediskstraps cpu
r b wavm fre flt re pi po fr sr wd0 cd0 int sys cs us
sy id
5 0 0 86576 1450072 845 0
Santagostini
http://ar.linkedin.com/in/santagostini
2013/11/14 Andy a...@brandwatch.com
On 14/11/13 15:21, Leonardo Santagostini wrote:
Hello misc,
Im doing my final approach to put a production system with
carp+pfsync+relayd on production.
The point is that im facing some
a production system with
carp+pfsync+relayd on production.
The point is that im facing some trouble setting more than one ip alias
address with different vhid and different passwd.
So, this is the scenario.
Im trying to relayd more or less 15 sites so i have conceptual doubts.
1
/in/santagostini
2013/11/14 Andy a...@brandwatch.com
On 14/11/13 15:21, Leonardo Santagostini wrote:
Hello misc,
Im doing my final approach to put a production system with
carp+pfsync+relayd on production.
The point is that im facing some trouble setting more than
Hello everybody, i still having some issues whit relayd.
Nov 17 21:01:56 v-arcbabalancer01 relayd[4252]: relay relay4, session 75 (1
active), 0, 190.51.90.22 - :0, buffer event timeout
Nov 17 21:01:57 v-arcbabalancer01 relayd[12715]: relay relay4, session 97
(4 active), 0, 190.49.60.30 - :0,
Sorry, looking more detailed at the logs i found this:
/var/log/daemon
Nov 17 18:36:12 v-arcbabalancer01 relayd[13984]: fatal: relay_connect: no
connection in flight
Nov 17 18:36:12 v-arcbabalancer01 relayd[22615]: pfe exiting, pid 22615
Nov 17 18:36:12 v-arcbabalancer01 relayd[31674]: hce
Hello misc,
Im doing my final approach to put a production system with
carp+pfsync+relayd on production.
The point is that im facing some trouble setting more than one ip alias
address with different vhid and different passwd.
So, this is the scenario.
Im trying to relayd more or less 15 sites
15 sites and only 9?
Id put around 50 (and have). You might need even more.
On 14 nov 2013, at 16:21, Leonardo Santagostini lsantagost...@gmail.com
wrote:
set limit states 9
Put all of those into the same relay { } as they are going to the same
forward table.
relay {
listen on addr1 port 80
listen on addr2 port 80
etc
.
}
or youll end up doing check http several times.
and Id do just simple check tcp - faster.
On 14 nov 2013, at
Ok, i will modify the config. But i really want to know about the carp
configuration.
I forget to mention that im doing DSR.
Saludos.-
Leonardo Santagostini
http://ar.linkedin.com/in/santagostini
2013/11/14 mxb m...@alumni.chalmers.se
15 sites and only 9?
Iâd put around 50
On 14/11/13 15:21, Leonardo Santagostini wrote:
Hello misc,
Im doing my final approach to put a production system with
carp+pfsync+relayd on production.
The point is that im facing some trouble setting more than one ip alias
address with different vhid and different passwd.
So
1 - 100 of 423 matches
Mail list logo
