That would be really useful :)
One of the things that made it hard to debug was logging. I tried all
the net.inet.carp.log levels ;)
Andy.
On Tue 23 Jul 2013 17:00:58 BST, Theo de Raadt wrote:
I agree, that's why I spent a long time trying to get all the switches
configured correctly. And wh
> I agree, that's why I spent a long time trying to get all the switches
> configured correctly. And whilst it is rare, sadly one of our providers
> in particular just outright refuses to enable port-fast as they don't
> trust all their colo members (kinda don't blame them).
>
> I also don't wa
Hi Henning,
I agree, that's why I spent a long time trying to get all the switches
configured correctly. And whilst it is rare, sadly one of our providers
in particular just outright refuses to enable port-fast as they don't
trust all their colo members (kinda don't blame them).
I also don't
Fantastic,
Thanks Stuart, That was really helpful!
Without even knowing it your thoughts (suggesting manipulating
carpdemote) has also just helped me to resolve /another/ CARP issue I
have been battling with when using a direct crossover cable between the
firewalls.
Same issue as;
http://old.
* Andy [2013-07-22 13:14]:
> None the less I'm surprised that no one else has any thoughts on
> this when it has been discussed several times before.
the solution is to fix the switch config, not to come up with stupid
("works most of the time in most cases" - that's the microsoft/apple
definitio
On 2013-07-22, Andy wrote:
> For example we are connected to a various providers in various
> locations (we have many OpenBSD firewalls and this is only a problem in
> some locations) where they wont enable port fast/configure as static
> access ports.
I would think this is the minority, and t
Hi Cam, Ah ok
Having everything stop for a few seconds (until the network is ready)
is what I'd like. I had a feeling that there must have been some reason
holding this back as it seemed so trivial! ;)
Never mind, I'll have to live with the !sleep and longer advbase values
then, rather than
On 7/22/13 1:12 PM, Andy wrote:
I messed up and added '!sleep 5' to the hostname.carp instead of the
physical interface..
None the less I'm surprised that no one else has any thoughts on this
when it has been discussed several times before.
It would be /very/ easy to resolve (by someone with ta
Hi Marko,
I agree, and that is what I have done (enabled portfast etc) but we
don't have control of the switches/routers to which OpenBSD is
connected in all cases.
For example we are connected to a various providers in various
locations (we have many OpenBSD firewalls and this is only a pro
On Mon, 22 Jul 2013 12:12:30 +0100
Andy wrote:
> >> I.e. When a firewall boots up, the connected switch port starts STP and
> >> is initially blocked, causing the newly booting firewall to think it is
> >> master, the port then starts forwarding and I have double master.
Why trying to solve prob
I messed up and added '!sleep 5' to the hostname.carp instead of the
physical interface..
None the less I'm surprised that no one else has any thoughts on this
when it has been discussed several times before.
It would be /very/ easy to resolve (by someone with talent and
experience of the co
Ok, sadly adding the !sleep 5 is not helping and made it even worse :(
E.g. the reboot of the primary with the sleep resulted in this;
.
.
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (8985ec86e22625f3.a) swap on sd0b dump on sd0b
carp0: state transition: INIT -> BACKUP
carp0
Hi,
Others have discussed our problem but I cannot see that this has been
implement (I cannot find a man page referring to this).
http://openbsd.7691.n7.nabble.com/carp-init-delay-td226187.html
I.e. When a firewall boots up, the connected switch port starts STP and
is initially blocked, causing
13 matches
Mail list logo
