Yes correct, we are getting closer. My question is weird, I know :-)
We LOAD-BALANCE outgoing frames and we LEARN from incoming frames.
Completely true.
However,
what If I learned the MAC address on the physical interface from
incoming frame, and I would like to send a frame in the opposite
direction (a reply to the previous frame, sent to the same host). Will
I use the MAC address entry that has been learned a while before? I
think yes, but I am not sure. I simply think that the load balancing
will not occur when the MAC is located behind the physical interface
(instead of aggregate interface - Po1).
Regards,
Miroslav Kosut
On Nov 10, 2009, at 10:19 PM, S Malik wrote:
> In my opinion (I could be wrong) pagp learn-method is setting the
> source-address learning of incoming packets received from an ether-
> channel, now as far as LB in ether-channels is concerned, it is done
> for the outgoing packets not incoming.
>
>
> On Tue, Nov 10, 2009 at 4:00 PM, Miroslav Kosut
> <miroslav.kosut_at_me.com> wrote:
> Assume the following scenario:
>
> Two switches (SW1 and SW2), interconnected via 4-membered L2
> etherchannels (on both ends, using fa0/1 - 4).
>
> SW1 fa0/1 <------------> SW2 fa0/1
> SW1 fa0/2 <------------> SW2 fa0/2
> SW1 fa0/3 <------------> SW2 fa0/3
> SW1 fa0/4 <------------> SW2 fa0/4
>
> Each physical interface on SW1 is configured with the command:
>
> pagp learn-method physical-port
>
> Then, some frame with src mac address DE:AD:DE:AD:DE:AD :-) is
> received on the SW1 etherchannel, on the fa0/2 physically. We are
> using physical-port learning so the mac address entry looks like this:
>
> DE:AD:DE:AD:DE:AD fa0/2 (if I was using "aggregate-port"
> learning method, I would see here, let's say Po1)
>
> If SW1 receives the frame with a destination mac address of
> DE:AD:DE:AD:DE:AD, will it load-balance using a hash? It is already
> learned on the physical interface so I don't see any reason of
> wasting a time with loadbalancing.
>
> If my question is completely wrong, let me know.
>
> Regards,
> Miroslav
>
> On Nov 10, 2009, at 9:39 PM, Rick Mur wrote:
>
>> The loadsharing on portchannels works with so-called hashes. In
>> your case for each destination MAC address that is seen outgoing on
>> the port-channel a hash is generated and divided over 1 of the
>> links (buckets). So after a while all the possible variations are
>> divided and are 'shared' on the links. But keep in mind that this
>> is fixed, traffic to the same destination MAC address is using only
>> 1 of the links.
>>
>> Therefore it's highly recommended to use layer 3 and if possible
>> layer 4 information to get the best balancing over the links in the
>> channel.
>>
>>
>> --
>> Regards,
>>
>> Rick Mur
>> CCIE2 #21946 (R&S / Service Provider)
>> Sr. Support Engineer IPexpert, Inc.
>> URL: http://www.IPexpert.com
>>
>> On 10 nov 2009, at 21:09, Miroslav Kosut wrote:
>>
>>> Dear group,
>>>
>>> a quick question to confirm my understanding. Suppose I configure
>>> the following on the same etherchannel:
>>>
>>> 1. PAgP learning method to be a "physical-port learning"
>>> 2. Port-channel loadbalancing to be based on a "destination mac
>>> address"
>>>
>>> Then, am I right when I am saying that load-balancing method is
>>> ignored when a destination mac address is already learned (on a
>>> physical-port) ?
>>>
>>> My understanding:
>>> Since the mac is already learned on a physical-port, there is no
>>> need to calculate the outgoing member interface (load-balancing).
>>> Of course, if the mac address hasn't been learned, frames would be
>>> unicast-flooded. Then, load balancing IS performed and the
>>> outgoing interface is chosen.
>>>
>>> Regards,
>>> Miroslav Kosut
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:http://www.groupstudy.com/
>>> list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Tue Nov 10 2009 - 22:30:42 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:28 ART