Re: PAgP Learn Method and Port-channel Loadbalancing

I think , what should happen is that traffic in both directions should use
the same interface (just a guess).

On Tue, Nov 10, 2009 at 4:30 PM, Miroslav Kosut <miroslav.kosut_at_me.com>wrote:

> 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 <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 - 17:03:10 ART