----- Original Message ----- From: Stuart Henderson <[email protected]> To: Bogdan <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Wednesday, August 10, 2011 6:33 PM Subject: Re: interface trunk0
On 2011/08/10 08:01, Bogdan wrote: > > The information from ifconfig -A and maybe also netstat -rn are > pretty important in showing what is wrong. I have an idea what you > missed, but > I'm not going to guess based on incomplete information. > > This would require to > commute back to trunk setup, which I can not do it anymore > but I thank you for > the willing to help me. Maybe you could do this on a test machine or VM.. I have no machine available to me. If you want to let me know what the solution is would be greate. I forgot to mention that I also flushed the routing table and added the default gateway bounded to trunk0 rather than em0, but that also failed to work. > It seemed pretty secure to activate > trunk, although had no experience with that in the past. I had much less trouble with trunk on OpenBSD than with bonding on Linux. But personally I would try to avoid making this type of change in production without a redundant machine and out-of-band console access. I do not consider linux+bonding a solution as I would never 'trade' on OpenBSD box on otherOS. >> 4.0 is nearly 5 years old - how are your >> services critical for >> local infrastructure going to cope when the hardware >> fails? > > well, good question. > > First I took the courage to re-write from > scratch all the software > with concurrency, distribution, fault tolerance and > replication in mind, > > Many services are self-replicating on secondary machine, > so I achieve a decent level of data persistence. > > All the code I wrote is also > commited into a CVS repository which is mirrored on several machines, > including the development machine. > > I don't know how good this setup is but is > something. This is all good, and much better than many people will do. > And yes a binary image of the running OS would be great, but I am > keep telling myself that nothing wrong could happen. A binary image might not be so good; if you need to replace with new hardware, you may well find that it requires an OS with newer NIC drivers, and/or supporting ACPI for correct interrupt routing, so a direct clone of the 4.0 system might not work, forcing an upgrade. IMO it's much better to do this as planned maintenance (with a good back-out plan in case of problems) rather than wait until forced. This is better than OS imaging
