Boris Hassanov <firstname.lastname@example.org> wrote:
Gentlemen, could anyone help me with the following question:
Customer has QNX Photon PC with one network adapeter (100Base-TX), we need
to offer redundancy for the network connection. The easiest way is to
install the second network apater into this PC, but software taht are
running there required only ONE IP-address for both adapters. Some
adapeter’s vendors ( like Intel ) provide such feature as teaming, when we
can join both adapters together into the single logical one (team). Then we
can assign one IP for it, also after joining both adapters use single MAC.
Unfortunately Intel doesn’t make drivers for QNX. Does anyone know solution
for this case ? I’m dilettante in QNX,. perhaps there are some other
Your help would be appreciated.
This sounds interesting. So basically they are putting two pieces of
hardward into the same box, giving them both the same MAC address and
assigning them both the same IP address. AND I assume pluging them
both into the same ethernet.
It sounds like a true hardwaer redundancy solution. On receive, both
cards can receive the same packets and let the software drivers pick
one to use. On transmit, you just have to make sure that only one
tries to transmit at a time (or you have a real problem with collisions!)
BUT, it seems to me tghat you also give up a lot of the benefits of
having two NIC cards in one box. You can’t load balance on two networks,
you can’t gateway between two networks.
So you’ve paid for twice the hardware (and I’m sure paid a software
performance penilty as well) and only have the benefit of redundant
hardware (which in certain applications may well be worth it!)
I actually do like the QNX approach better, 2 NIC cards with 2 MAC
addresses and 2 IP addresses yields much more versitility. You just
have to make some software somewhere aware of it.
In a past life (former employer) we had redundant server hosts. One was
a primary and assumed a certain IP address. The other was a backup and
assumed a different IP address, primarily just for listening to broadcast
packets. The primary server would broadcast a heartbeat packet every
second. If the seconday missed 2 heartbeats in a row it would assume the
roll of the primary server and assume the IP address of the server as
well (by issuing ifconfig commands to reconfigure it’s own IP address).
If/when the original server came back up it would wait for 2
seconds to listen for a heartbeat before it came back on line. If it was
heard it would silently wait for the current primary to fail.
You could implement a similar scheam where you reconfigure which NIC
card assumed what IP address. I think you would just need one new
process that was multi-NIC aware and did all of the real work.
Just a thought. Does an established TCP connection need to be
re-established if the IP address is moved to a new NIC card? I really
don’t know (never tried it), but I assume so. So your other software
would have to handle errors gracefully. but this should be being
Bill Caroselli – Q-TPS Consulting