[f-nsp] link aggreagtion (lacp) with load balancing

Tue Jun 5 01:09:59 EDT 2012

Hmmm, that is interesting.  Yes, the default settings provide for a diverse
hash (usually), this was not always the case as there were 'switch' and
'server' trunks, but 802.3ad provides more guidance as to what must be
hashed.  Could it be MTU size?  Are you sending mostly jumbos?  I notice
that setting is different between the two interfaces.

Mike

On Mon, Jun 4, 2012 at 8:48 PM, Edward Rosinzonsky <ed at entetel.com> wrote:

> **
> Mike, thanks for your response.  My source and destination IP addresses
> are definitely different, but all outbound traffic is going through the
> first interface.  Are you sure that it uses source and destination IP by
> default?  Is there a setting for this that I can set explicitly?  I had the
> same problem on the cisco, until I set the "*port-channel load-balance
> src-dst-ip" option. *Is there something similar on the foundry?  Here's
> the "show interface" for the two members of the LAG:
>
> show interface ethernet 3/3
> GigabitEthernet3/3 is up, line protocol is up
>   Hardware is GigabitEthernet, address is 000c.dba5.e842 (bia
> 000c.dba5.e842)
>   Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
>   Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING
>   STP configured to ON, priority is level0, flow control enabled
>   mirror disabled, monitor disabled
>   Member of active trunk ports 3/3-3/4, primary port
>   Member of configured trunk ports 3/3-3/4, primary port
>   No port name
>   MTU 9000 bytes
>   300 second input rate: 253106560 bits/sec, 144914 packets/sec, 27.62%
> utilization
>   300 second output rate: 509824184 bits/sec, 232136 packets/sec, 54.69%
> utilization
>   143595350 packets input, 30715638578 bytes, 0 no buffer
>   Received 1869 broadcasts, 2135 multicasts, 143591346 unicasts
>   0 input errors, 0 CRC, 0 frame, 0 ignored
>   0 runts, 0 giants, DMA received 143595234 packets
>   228617165 packets output, 63786592895 bytes, 0 underruns
>   Transmitted 1974 broadcasts, 3854 multicasts, 228611337 unicasts
>   0 output errors, 0 collisions, DMA transmitted 228617164 packets
>
> show interface ethernet 3/4
> GigabitEthernet3/4 is up, line protocol is up
>   Hardware is GigabitEthernet, address is 000c.dba5.e842 (bia
> 000c.dba5.e842)
>   Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
>   Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING
>   STP configured to ON, priority is level0, flow control enabled
>   mirror disabled, monitor disabled
>   Member of active trunk ports 3/3-3/4, secondary port, primary port is 3/3
>   Member of configured trunk ports 3/3-3/4, secondary port, primary port
> is 3/3
>   No port name
>   MTU 1518 bytes
>   300 second input rate: 281677768 bits/sec, 158529 packets/sec, 30.70%
> utilization
>   300 second output rate: 1224 bits/sec, 1 packets/sec, 0.00% utilization
>   155802286 packets input, 33799467638 bytes, 0 no buffer
>   Received 11 broadcasts, 1085 multicasts, 155801190 unicasts
>   0 input errors, 0 CRC, 0 frame, 0 ignored
>   0 runts, 0 giants, DMA received 155802169 packets
>   1163 packets output, 121019 bytes, 0 underruns
>   Transmitted 0 broadcasts, 39 multicasts, 1124 unicasts
>   0 output errors, 0 collisions, DMA transmitted 1163 packets
>
> You can see that 3/3 has 54.69% output utilization, while 3/4 has 0%.
>
> Thanks.
>
>
> On 06/04/2012 08:19 PM, Mike Allen wrote:
>
> Edward, seems like there is confusion about trunking lately on the
> list...:)  So as mentioned in my previous post to the list, there are two
> different trunking options in the FastIron code base.  You are already
> configured for 802.3ad Link Aggregation dynamically, and your trunk is up
> and operational.  You do not need the static trunking, and that is why you
> see that error.
>
>  As for the hash diversity, it all depends on what your flows look like.
>  By default for ip traffic, it uses Source and destination IP addresses,
> and source and destination TCP/UDP ports for the hash, so as long as those
> are different, you should see outbound traffic spread accordingly.  Note
> that unknown unicast, broadcast, and multicast traffic will all usually
> take on the first port.  Unicast traffic is what would be load balanced.
>
>  Mike
>
> On Mon, Jun 4, 2012 at 6:11 PM, Edward Rosinzonsky <ed at entetel.com> wrote:
>
>>  Shameless bump.
>> When I try to trunk the lacp ports, I get an error:
>>
>> trunk ethernet 3/3 to 3/4
>> error - trunk ports contain LACP-enabled ports.
>>
>>
>>
>> Here's the relevant part of the config:
>>
>> interface ethernet 3/3
>>  mtu 9000
>>  link-aggregate configure key 10000
>>  link-aggregate active
>> !
>> interface ethernet 3/4
>>  link-aggregate configure key 10000
>>  link-aggregate active
>> !
>>
>>
>>
>>
>> show link-ag:
>> System ID: 000c.dba5.e840
>> Long  timeout: 90, default: 90
>> Short timeout: 3, default: 3
>> Port  [Sys P] [Port P] [ Key ]
>> [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
>> 3/3        1        1   10000   Yes   L   Agg  Syn  Col  Dis  No   No
>> Ope
>> 3/4        1        1   10000   Yes   L   Agg  Syn  Col  Dis  No   No
>> Ope
>>
>>
>>
>>
>>
>> show trunk:
>> Configured trunks:
>>
>> Trunk ID: 66
>> Type: Switch
>> Ports_Configured: 2
>> Primary Port Monitored: Jointly
>>
>> Ports         3/3     3/4
>> Port Names    none    none
>> Port_Status   enable  enable
>> Monitor       off     off
>> Mirror Port   N/A     N/A
>> Monitor Dir   N/A     N/A
>>
>> Operational trunks:
>>
>> Trunk ID: 66
>> Type: Switch
>> Duplex: Full
>> Speed: 1G
>> Tag: No
>> Priority: level0
>> Active Ports: 2
>>
>>
>> Ports         3/3     3/4
>> Link_Status   active  active
>> LACP_Status   ready   ready
>> Load Sharing
>>  Mac Address  6       5
>>  IP           0       0
>>  IPX          0       0
>>  Apple Talk   0       0
>>  Multicast    0       0
>>
>>
>>
>> On 04/12/2012 07:16 PM, Edward Rosinzonsky wrote:
>>
>>  Hi,
>>
>> I'm trying to setup LAG between my si350 and the cisco switch.  I set up
>> the LAG without problems, but all traffic just defaults to the first port
>> in the LAG.
>>
>> On the cisco, I solve this problem with the following command:
>> *port-channel load-balance src-dst-ip*
>>
>> But, I can't find anything similar for the foundry.  Anyone know how to
>> do this?
>>
>> Thanks.
>>
>>
>> _______________________________________________
>> foundry-nsp mailing listfoundry-nsp at puck.nether.nethttp://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp at puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20120604/d9f1c8ff/attachment.html>