I just thought of something that bit me recently as well.
With a real IPv6 address CARP will send out advertisements via IPv4
_and_ IPv6. It's the same CARP message so if either one reaches the
backup it's ok.
Your block rule had inet so you were probably blocking IPv4 only. But
because
On 2-3-2012 9:23, Marios Makassikis wrote:
I just thought of something that bit me recently as well.
With a real IPv6 address CARP will send out advertisements via IPv4
_and_ IPv6. It's the same CARP message so if either one reaches the
backup it's ok.
Your block rule had inet so you were
On Fri, Mar 02, 2012 at 09:23:38AM +0100, Marios Makassikis wrote:
The demotion counter is decremented when you lose connectivity (ip_output
errors for instance), but shouldn't it be reincremented when you regain
connectivity?
Well, that's a chicken and egg problem there.
It won't send out
Hello,
No, I'm using hardware machines.
I tested what Imre suggested, i.e.: flushing PF states with
'pfctl -F states'.
With a freshly booted machine, CARP packets are allowed to pass.
I then disabled pf, flushed the states and reloaded pf with the
'block log' rule. At this point, CARP is
On 2012-03-01, Camiel Dobbelaar c...@sentia.nl wrote:
On 29-2-2012 23:01, Fridiric URBAN wrote:
Hello,
Confirmed on a fresh and very simple virtual environnement with 2
firewall using latest snapshot (amd64).
pf.conf containt a single line block log, nothing is logged on pflog
and the
On 1-3-2012 10:08, Marios Makassikis wrote:
Hello,
No, I'm using hardware machines.
I tested what Imre suggested, i.e.: flushing PF states with
'pfctl -F states'.
With a freshly booted machine, CARP packets are allowed to pass.
I then disabled pf, flushed the states and reloaded pf with
Hi,
Are you sure that fw1 is sending and not receiving those? The only way
to be really sure is to use tcpdump -D out.
The sender IP was the one I assigned to fw1, but I retested it anyway with
-D out and I can confirm that there is a difference between the demote count
displayed by ifconfig
On 1-3-2012 16:32, Marios Makassikis wrote:
Bumping net.inet.carp.log value only reports the demotion:
carp:carp0 demoted group carp by 1 to 2 ( snderrors)
carp:carp1 demoted group carp by 1 to 2 ( snderrors)
And then, a few state transitions later:
carp: carp0 demoted group carp by -1 to 1
Hello,
No, that's not from your manual commands. It says there are send errors
when sending out the carp packets.
My bad.
Just paste the output instead of interpreting...
Here you go:
carp:
45808 packets received (IPv4)
74835 packets received (IPv6)
0
On 1-3-2012 18:10, Marios Makassikis wrote:
Here you go:
carp:
45808 packets received (IPv4)
74835 packets received (IPv6)
0 packets discarded for bad interface
0 packets discarded for wrong TTL
0 packets shorter than header
On 1-3-2012 18:20, Camiel Dobbelaar wrote:
On 1-3-2012 18:10, Marios Makassikis wrote:
Here you go:
carp:
45808 packets received (IPv4)
74835 packets received (IPv6)
0 packets discarded for bad interface
0 packets discarded for wrong TTL
In the spirit of K.I.S.S. I use:
pass quick proto carp
Since that should match the number on 4 and 6 packets.
Your block rule had inet so you were probably blocking IPv4 only. But
because of the send errors (due to pf blocking) fw1 started to demote
itself.
Hi all,
I am in the process of setting up a lab to test a IPv6 setup, and I'm
having some issues with filtering CARP traffic.
The configuration looks like this:
+| WAN/Internet |+
||
em0||em0
+-+
Hello,
Confirmed on a fresh and very simple virtual environnement with 2
firewall using latest snapshot (amd64).
pf.conf containt a single line block log, nothing is logged on pflog
and the other firewall on the sharing the link layer still catch carp
advertisement !
Another interessting
Hi!
On 02/29/12 19:16, Marios Makassikis wrote:
A last test prior to posting got me the following results:
The pf.conf file contained this rule at the top:
block quick log inet proto carp
And CARP was effectively blocked. Changing the 'block' to 'pass' allowed
the packets to flow, as
On 29-2-2012 23:01, Fridiric URBAN wrote:
Hello,
Confirmed on a fresh and very simple virtual environnement with 2
firewall using latest snapshot (amd64).
pf.conf containt a single line block log, nothing is logged on pflog
and the other firewall on the sharing the link layer still catch
16 matches
Mail list logo
