Hi Alex,
I used a 3560 and a SF300-48 in my test. The 200 series software seems basically a subset of the 300 series switches software, so I am confident that the behaviour is just about identical. I didn't have the luxury of Gig ports only 100Mbit/sec ports to play with. But the indications should have been the same. I link aggregated fe23 and FE24 on my 3560 and ports 24 and 48 on my SF300-48P
interface FastEthernet0/23
channel-group 1 mode active
interface FastEthernet0/24
channel-group 1 mode active
On my 3560 I saw the following;
3560#show lacp nei
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Channel group 1 neighbors
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Fa0/23 SA 1 0025.84e5.51ad 4s 0x0 0x3E8 0x18 0x3D
Fa0/24 SA 1 0025.84e5.51ad 4s 0x0 0x3E8 0x30 0x3D
3560#
3560# show interface port-channel 1
Port-channel1 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 0023.347f.6019 (bia 0023.347f.6019)
MTU 1500 bytes, BW 200000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, link type is auto, media type is unknown
input flow-control is off, output flow-control is unsupported
Members in this channel: Fa0/23 Fa0/24
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:24:23, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
5960 packets input, 814834 bytes, 0 no buffer
Received 3542 broadcasts (2568 multicasts)
96 runts, 0 giants, 0 throttles
96 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2569 multicast, 0 pause input
0 input packets with dribble condition detected
3801 packets output, 1938910 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
3560#
I think we are looking at two indications, the BW 200000 Kbit as seen above does show aggregated Bandwidth, but my SF300 is showing in the screen capture below Operational Port Speed. You will also note That the 3560 also shows Full-duplex, 100Mb/s as a indication of the link speeds of the individual ports, as all ports in a LAG should be at the same speeds.
On my SF300 -48P I noticed the following;
I tested link redundancy between switches and it worked like a charm, I really couldn't 'fill' the lag to test load balancing..
But it sorta doesn't just make a big pipe, like what I think you are indicating ,
It works the following way; the following text was taken from the SG300 admin guide;
Traffic forwarded to a LAG is load-balanced across the active member ports, thus achieving an effective bandwidth close to the aggregate bandwidth of all the active member ports of the LAG.
Traffic load balancing over the active member ports of a LAG is managed by a hash-based distribution function that distributes Unicast traffic based on Layer 2 or Layer 3 packet header information. Multicast packets behave in the same way as Unicast packets.
The switch support two modes of load balancing:
- By MAC Addresses—Based on the destination and source MAC addresses of all packets.
- By IP and MAC Addresses—Based on the destination and source IP addresses for IP packets, and destination and source MAC addresses for non-IP packets.
In my case i could tell the hashing algorithm for LAG was using destination and source MAC addresses to load balance across my two active links.
I sorta agree, I would like to see 200Mbits on a two port LAG not 100Mbits as a indication, but depending on the number of Layer 2 hosts on the switch network traffic balancing may not be too even over the LAG. One port may get much more traffic compared to another port.
The more hosts i have on either side of the LAGed switches the more even will be the distribution of packets over my 100M/bit links.
LAG works, i think it is working for you.
I will pass reference to this posting to the Product Engineers for their comment and any feedback as I agree there seems to be a inconsistancy in the reporting
regards Dave
Hi Alex,
Delete the LAG on my SG200 switch, create it again, this time ticking LACP option when you add the ports to the port-channel.
Think you should place a call with the Small Business Support Center. But I hope the hashing algorithms within the switches that are using destination and source MAC addresses are not skewing your results.
Here is SBSC contact details, refer them to this posting;
http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html
regards dave
