Foundry NIC teaming

well do they support it fully??
Any switch can use basic NIC teaming with no configuration at all. IT can all be set up on the server. However with a duel link this will only give you 2X bandwith out of the server and keep the single speed in.
for things like web servers this is fine as generaly they are asycrious in there transfers with small get requests to the server and larger pages being serverd up.
All you need for this is to enable NIC teaming on the server. and for this you will need the full drivers and utilities form the NIC manafactures.
If you want to set up full teaming with duel speed in and out you will need to run something like Eather channels (CISCO Switchs) where you simple need to enable the function on the switchs (single line of code) and enable it in the server drivers. then when you plug in two network leads between them, they talk to eachother and set up the channel automaticaly.
however as to foundry switchs I dont know what model you have, or if they do or do not have this function?
Hope that helps a bit!

I am not sure why someone would enable NIC teaming on the server side without configuring the network side, doesn't make much sense. Also, typically NIC teaming on the server side will use a virtual MAC or one of the physical layer MACS, the switch will see the same MAC on two ports without the network NIC TEAMING configured, I cannot imagine this would work effectively, the switch would be constantly refreshing it's CAM tables, very inefficient.

harbor235 ;}

No it wont
It works very simpley, the server simple floods its data to one of the ports on the switch, but does not adevertis a IP addrss it simple sends a packet with the source mac address of the other NIC and a destination mac of where ever. the switch will simple forward the data when it arives at the port to where it needs to go. however when data comes back to the switch it only sees the server on one port (all return to same mac address) so only deals with conversations on that one port. As far as the switch is aware the two strams of data are comming from seperate sources.
the reson for it is that its a legecy function, before switchs had port grouping/teaming funcationality it was the only way to do teaming. Its mainly used as i said for redundency (if one NIC in the server goes down it can enable the other as the primary card).
Like you say now if your switch has teaming funcanality then I would deffently suggest enabeling it. As it is much more efficent and switchs more cleanily in the event of a failed link. However if you simple want redundeny and not incress in bandwith then there is actuly no need to configure the switch.

Switches do not flood traffic to ports with the exception of broadcast or multicast

An HA configuration for a server does not work that way, one interface is active one passive, if a NIC goes down or a switch port goes down  the other interface assumes control of the virtual MAC and becomes active, they never work simualtaneously.

I appreciate your input, however, its not what I am looking for

thanx

harbor235 ;}

;)
OK but if you look at a HP prolient way of doing things you will see
Transmit Load Balancing (TLB) - balances the transmit traffic among the team members, but does not require any special switch intelligence or switch configuration. In addition, TLB teams can be split across switches as long as all members are in the same layer 2 network. In TLB teams, receive traffic is not load balanced, but is received on a single team member. TLB is a standard feature of ProLiant Teaming. (ALL SERVER NICS CAN SEND DATA TO THE NETWORK ONLY ONE RECIVES IT) This means in effect the other NICS are Flooding data to the network. it does not mean the flood in the sence of to all or mutiple devices on the network. But simple they do not include there own MAC address in the source address of the packet and the data flow is all one way.

Network fault tolerance (NFT) - prevents network downtime by transferring the workload from a failed port to a working port. Clients on the network see no disruption of service, and the network can remain in use while the failed component is repaired. NFT teaming functions at any speed, on any media. It is switch-independent and can be split across Layer 2 switches but must be in the same Layer 2 domain. NFT is a standard feature of ProLiant Teaming, and is available in all team configurations.
However you still havent mentiond if you model of switch supports 802.3ad. if so then you simple enable this on the switch and on the server team, and as long as they NIC's are plugged in to the same switch/stack then they will configure the aggrated linked port them selves.
But when you say you want a method of implementing this feature, what exactly do you mean?
 

ok, I see and was not familar with the HP solution. It makes sense now because only one can receive it or only one mac can be associated with the system on the same network.

You are correct in what you said, however, I still need to know how to do NIC teaming from the foundry switch perspective.

I learned something, thank you.

harbor235 ;}