On 2007/11/29 23:25, NetOne - Doichin Dokov wrote:
First, thanks for the prompt reply!
No problem, if I can save someone else the night I had in a
cold datacentre working it out, some good came out of it :-)
Nopes, I'm not:
# netstat -in
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls
{snip}
bge0 1500 <Link> 00:30:48:57:c3:80 44867924 39723 42574046 1 0
bge0 1500 213.137.48. 213.137.48.1 44867924 39723 42574046 1 0
bge0 1500 fe80::%bge0 fe80::230:48ff:fe 44867924 39723 42574046 1 0
bge1 1500 <Link> 00:30:48:57:c3:81 45170081 33204 42551236 1 0
bge1 1500 fe80::%bge1 fe80::230:48ff:fe 45170081 33204 42551236 1 0
Despite seeing Ierrs, I do not see any performance and connectivity
issues. What exactly does lead to having input errors on the bge(4)s?
I mean, would they be usable for what I will need the two more ports
for.
I don't know what leads to them, but it's not cable/switch, I have
tried numerous alternatives. I was running OSPF with fairly short
timers over those interfaces, and had a lot of instability until
I swapped over to em/sk cards. Most protocols are able to handle
delays/loss a lot better than OSPF though.
This machine is gonna soon have a twin to be backed up with CARP,
and i need the two additional interfaces on each of them for:
1) One interface for cross-connecting the machines to do pfsync
Beware split routing; if you only have one active set of BGP
sessions (i.e. active/passive with 'depend on carpXX') there's
no problem of that kind, but if you have live sessions on
both boxes, you'll find that pfsync isn't designed to handle
the case where inbound traffic goes one way, and outbound
traffic the other, so you run into problems with stateful
filtering (sequence number mismatch and maybe there were
wscale problems too).
mickey posted some diffs on tech@ relating to watchdog
problems with bge and em, they might be worth a look.
Are these what you're talking about, or there were any subsequent
patches I could not find:
http://article.gmane.org/gmane.os.openbsd.tech/14133
http://article.gmane.org/gmane.os.openbsd.tech/14134
Yes, those ones. Alternatively it may be a problem with
interrupt routing (the fix for that on many machines is to
enable acpi to set up interrupts according to the AML from
the BIOS - this is more likely to have correct information
than other methods of interrupt setup on newer machines,
this is a large part of the reason for the ACPI work that
has been happening in -current).
While you build, don't forget this patch if you will use pfsync:
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.2/common/004_pf.patch
Again, thank you very much for the help. I highly appreciate it. $30
will be donated to the OpenBSD foundation, plus another copy of the 4.2
CD set bought (we'll need one for the new machine, no? :D).
That's nice, thank you :-)
