Thanks, Howard.
(at least this means that my posts *are* being seen on the list :)
>Loadsharing and failover aren't always the same problem, although
>they often are related.
Right. Originally, I was just looking for a failover solution and found
that Intel supported *both* "Automatic Load Balancing" *and* failover
-- out of the box, so to speak (note the term "Balancing" vs. "sharing"
:)
HP supports failover, but not sharing (except with aggregation, like
FEC), so this was an unexpected bonus.
-------------------------------------------------
Tks��� ��� | <mailto:[EMAIL PROTECTED]>
BV��� ���� | <mailto:[EMAIL PROTECTED]>
Sr. Technical�Consultant,� SBM, A Gates/Arrow Co.
Vox 770-623-3430�����������11455 Lakefield Dr.
Fax 770-623-3429���������� Duluth, GA 30097-1511
=================================================
-----Original Message-----
From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 11, 2001 9:27 AM
To: [EMAIL PROTECTED]
Subject: RE: loadbalancing with NIC's
>Howard,
>Did you see either of my posts on this issue.
>I think that they hit the list, but I heard nary a peep. In fact, this
>has happened on my last few posts to the list -- I see them, but *no*
>one responds. I'm starting to get paranoid :)
My fault. I was just somewhat swamped and wanted time to think about
your reply.
Credit where credit is due -- feel free to post this directly to the
list.
>----
>
>> Otherwise, the 802.1D spanning tree algorithm will block more
>>than one card;
>
>I don't think that this is correct (yikes !! :)
>If the server is not acting as a bridge how could the two connections
>matter, vis-a-vis STP.
I suppose I was thinking more of the server acting as a bridge. If
it does so, it has the potential to autodetect a spanning tree
failure.
Other than a vague suspicion that somewhere, somehow, some servers
will screw up their ARP tables this way, I can't see any objection.
Not being a server person, I don't have detailed familiarity with the
Intel teaming approach, but your description doesn't cause me to
relax about the possibility of ARP problems.
It's funny, but in many of my internal discussions with primarily
optical networking folks, "Ethernet" and "bridging" get ignored a lot
with the hype of "Ethernet everywhere." Questions about broadcast
propagation, ARP, etc., get blank looks.
>.
>
>This relates to a scenario I described a short while back,
> [which I never got a response to]
>the only
>difference being that the 2 ports on the (NT) server were connected
>to different switches (which addresses your concern about the single
>point of failure at the switch).
>
>I had raised a question as to why both NICs couldn't answer and get
some
>kind of load balancing on the input, as well. I got no response from
>the list. But, upon reflection, I'm thinking that devices seeing the
>ARP reply are supposed to clear or update their cache if they have a
>different MAC cached (I'm too lazy to go look at the RFC). Thus there
>could be a wholotta ARPing going on.
There's a grand question: when does load balancing actually buy you
anything and where should it be applied? My intuition tells me that
for the ordinary sorts of servers, it is unlikely to buy much in
performance. If you are concerned with throughput on the server
interface(s), going to faster connectivity -- FastEtherchannel,
Gigabit Ethernet, etc., may help more than independent interfaces in
the same subnet. Most servers are going to max out at 200-300 Mbps
of traffic from a network; it would be rare to find one that actually
could use 400-1000 Mbps.
Loadsharing and failover aren't always the same problem, although
they often are related.
>
>...
>Actually, this makes no sense -- the ARP reply isn't a broadcast :|
>
>So I wonder why it wouldn't work for both NICs to reply.
>
>What happens when a requestor sees two replies to an ARP request ?
>Does he accept the first and drop the second?
>Accept the first, use it for his original IP packet, then update his
ARP
>cache with the second reply and subsequent packets use the second
>MAC address?
Without delving into the RFCs, I suspect it's implementation dependent.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
