100Base-TX teaming/trunking support question

QNX Newsgroups (Archives) qdn.public.ddk.network
1

Hello all,

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
solutions…

Your help would be appreciated.

SY,
Boris Hassanov

2

Boris Hassanov <hasanov@nnz.ru> wrote:

Hello all,

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
solutions…

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
done already.

–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net

3

Bill Caroselli <qtps@earthlink.net> wrote in message
news:b1rjro$jhg$1@inn.qnx.com…

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
done already.

In theory. The only thing TCP concerned is the IP address. Local/remote IP,
Local/remote port, these 4 numbers identified a “connection”.
So if one MAC out, you moved SAME ip to another, the upper layer,
user application won’t aware of that.

But you would have problem like settled down the ARP cache, remeber, other
guys on network will have your old MAC cached; and implementations might
have pointers to internal structures point to old interface …

-xtang

4

Xiaodan Tang <xtang@qnx.com> wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote in message
news:b1rjro$jhg$> 1@inn.qnx.com> …

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
done already.

In theory. The only thing TCP concerned is the IP address. Local/remote IP,
Local/remote port, these 4 numbers identified a “connection”.
So if one MAC out, you moved SAME ip to another, the upper layer,
user application won’t aware of that.

But you would have problem like settled down the ARP cache, remeber, other
guys on network will have your old MAC cached; and implementations might
have pointers to internal structures point to old interface …

Hi Xiaodan

We did what I described on my post on an all QNX4 TCP/IP network.
The other hosts seamed to accept the new MAC very willingly.
I.E. it all worked for us.

In an all QNX6 network, would you expect it to just accept the new
MAC addresses and start using them?

Or would you expect some delay before they were accepted? How long?

–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net

5

Bill Caroselli <qtps@earthlink.net> wrote in message
news:b1rm0k$jhg$4@inn.qnx.com…

Xiaodan Tang <> xtang@qnx.com> > wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote in message
news:b1rjro$jhg$> 1@inn.qnx.com> …

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
done already.

In theory. The only thing TCP concerned is the IP address. Local/remote
IP,
Local/remote port, these 4 numbers identified a “connection”.
So if one MAC out, you moved SAME ip to another, the upper layer,
user application won’t aware of that.

But you would have problem like settled down the ARP cache, remeber,
other
guys on network will have your old MAC cached; and implementations might
have pointers to internal structures point to old interface …

Hi Xiaodan

We did what I described on my post on an all QNX4 TCP/IP network.
The other hosts seamed to accept the new MAC very willingly.
I.E. it all worked for us.

Bill, in your sample, you are safe. Cause the “ifconfig” (or whenever a
interface get configured), will cause stack send a ARP request with the
new address. This request would refesh all other guys ARP cache.
I guess that’s why you don’t see a glitch on your system.

Now, your sample actually switching the machine (stack), so tcp/udp
connection to orignal box would be dropped. Applications like NFS
client/server, have enough logic to re-establish if a connection is dropped,
but others may not.

(you can’t switching and have a on-going ftp downloading not fail :slight_smile:

In an all QNX6 network, would you expect it to just accept the new
MAC addresses and start using them?

Or would you expect some delay before they were accepted? How long?

I believe QNX6 stack did the same thing. Unless you config the interface
without plug it in first, and connect to network, you should all safe.
Now if somebody DOES missed to update their cache, it would take
as long as 20 minutes untile arp cache timeout. Of cause, you can
“arp -d” to manuly delete the entry on those bad nodes.

-xtang

6

qtps@earthlink.net sed in <b1rjro$jhg$1@inn.qnx.com>:

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.
Some others may not be familliar with Intel’s “Adapter teaming” so

here’s exerpt from the Intel PROset manual…


Adaptive Fault Tolerance
If primary adapter fails, the secondary takes over.
(me: This should assume the secondary is normally silent)

Adaptive Load Balancing
creates team of 2-8 adapters to increase throughput.
Works with most switches.
(me: switch is mandatory; no point plugging both in dumb hub)
(me: Docs below says it only works for Layer-3 protocols)

Fast EtherChannel (FEC)
team of 2-8 to increase throughput. Include Fault Tolerance.
Requires a switch with FEC capability.

Gigabit EtherChannel (GEC)
2-8 teams of gigabit adapters. Include Fault Tolerance.
Requires a switch with GEC capability.

Link Aggregation (LA)
2-8 teams to increase throughput. Include Fault Tolerance.
Requires a switch with Link Aggregation.

For overview info on Intel adapter teaming, visit
URL:http://www.intel.com/network/connectivity/
(me: www.intel.com/support/network/adapter/ans/teaming.htm should be better)

Redundancy is redundancy so you’ll always lose some $$$.
That’s how it should be.

kabe

7

What about running two NIC’s in promiscuous mode? Then, on top of this
build a “pseudo ethernet driver” that emulates a single ethernet card.
You would need to register the NIC’s as something other than ENx but
that’s not difficult if you can get the source code.

Having done this, you would have to then bridge between the promiscuous
NIC’s and the ethernet driver. You would also need to write a driver
that could switch between the NIC’s (possibly using something like
spaning tree?)

We have a solution that bridges between a Wireless and Wired NIC device
and also provides a port to the local device. The arrangement is shown
below. All of this presents the system as having 1 ethernet device and 1
IP address, however each of the individual elements can be interrogated
using nicinfo.


[LOCAL IP]
||
[IP-EN]
||
[PSEUDO EN(en0)]
||
[ MAC BRIDGE (BR0)]
// || || \
[LAN0][LAN1] [WLAN0][WLAN1]



You could take a similar approach, but have the bridge module use a
suitable protocol to determine which of the interfaces is active. This
would give you the system with the characteristics you desire.


As to performance, this approach does not significantly detract from the
baseline QNX, our LANx/WLANx are down by around 500kBit/sec although
we’ve done no optimisation with the pseudo ethernet interface.


I guess that the final question here is: Do you want to build yourself a
solution or do you want something out of the box?

Hope this helps

Dave




Bill Caroselli wrote:

Boris Hassanov <> hasanov@nnz.ru> > wrote:

Hello all,


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
solutions…


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
done already.

8

Dave,

Thanks for reply. Answering your question I may say that out of the box
solution is preffered by many reasons, The main is that it will be more
simply for customer - just buy ready to implement solution. Therefore I told
about some QNX analoguos of Intel’s teaming…

SY,
Boris


“Dave Edwards” <Dave.edwards@abicom-international.com> wrote in message
news:3E42F9A9.7090801@abicom-international.com…

What about running two NIC’s in promiscuous mode? Then, on top of this
build a “pseudo ethernet driver” that emulates a single ethernet card.
You would need to register the NIC’s as something other than ENx but
that’s not difficult if you can get the source code.

Having done this, you would have to then bridge between the promiscuous
NIC’s and the ethernet driver. You would also need to write a driver
that could switch between the NIC’s (possibly using something like
spaning tree?)

We have a solution that bridges between a Wireless and Wired NIC device
and also provides a port to the local device. The arrangement is shown
below. All of this presents the system as having 1 ethernet device and 1
IP address, however each of the individual elements can be interrogated
using nicinfo.


[LOCAL IP]
||
[IP-EN]
||
[PSEUDO EN(en0)]
||
[ MAC BRIDGE (BR0)]
// || || \
[LAN0][LAN1] [WLAN0][WLAN1]



You could take a similar approach, but have the bridge module use a
suitable protocol to determine which of the interfaces is active. This
would give you the system with the characteristics you desire.


As to performance, this approach does not significantly detract from the
baseline QNX, our LANx/WLANx are down by around 500kBit/sec although
we’ve done no optimisation with the pseudo ethernet interface.


I guess that the final question here is: Do you want to build yourself a
solution or do you want something out of the box?

Hope this helps

Dave




Bill Caroselli wrote:
Boris Hassanov <> hasanov@nnz.ru> > wrote:

Hello all,


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
solutions…


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
done already.