>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).
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?
-------------------------------------------------
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Friday, February 09, 2001 5:27 PM
To: CISCO_GroupStudy List (E-mail)
Subject: RE: loadbalancing with NIC's
> 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.
In fact, Intel touts just a solution with their NIC "teaming" concept,
without FEC (although they also support that). They support their
2-port adapters as well as separate adapters -- in fact, IIRC, they
don't even have to be the same speed !. In their solution, though, the
load balancing is on output only, implying that the "primary" NIC is the
only one that answers ARPs. The "teaming" also supports automatic
failover upon NIC port failure.
This relates to a scenario I described a short while back, 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.
Comments?
-------------------------------------------------
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Howard C. Berkowitz
Sent: Friday, February 09, 2001 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: loadbalancing with NIC's
>We are planning to connect a server with a single NIC that supports
>faultolerance , redudndancy and load balancing. How does a C6509 treat
a
>Nic that is connected to two of its ports (same vlans)
>Mo Durrani
Multiple Fast EtherChannel aware NICs can load-share on the same
VLAN. Otherwise, the 802.1D spanning tree algorithm will block more
than one card; you will get failover but no load distribution.
By putting them into different VLANs, you can get load-sharing,
assuming, of course, that the higher layers know how to distribute
the load. The ideal situation is that your clients could be
configured with primary and secondary server addresses.
At some point, you need to consider, in your fault tolerance model,
what to do if either the server or the 6509 itself fails. Frankly,
I'd consider isolated NIC failures less likely than either of these
cases. Other people may have different experience.
If you are going to have different NICs, do consider running them to
different wire closets, or otherwise maximizing cable plant
diversity. Never underestimate the power of a less than clueful
wiring technician.
_________________________________
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
