Hi, the LAG obviously forms and the fact that routed connections use different physical links shows that L3 information is used for hashing, not just L2. Unless per frame round-robin is used, any combination of client and server will always use the same physical link. Both directions use the same link.
My interpretation is that your test clients in the same subnet by chance use the same link. To verify change the IP address of one of the clients to get it to use the other physical link. On an S-Series with current firmware you can use 'show lacp outputportAlgorithm' to verify that the default of L3 (dip-sip) is used. You can even change it with 'set lacp outportAlgorithm', but it do not recommend this. With a significant number of clients all links of the LAG will be used. HTH, Erik -- Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ [email protected] T:+49-631-4149988-0 M:+49-176-64228513 Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630 On Thu, Apr 17, 2014 at 12:19:35PM +0100, Charlie Daffarn wrote: > hi all, > > We have a new Windows 2012 R2 files server which will require maximum speed > comms between them and the users. Windows 2012 now allows, natively, for a > 2+ nic team, using a dynamic LACP lag to the switch. > > The server is in a specific vlan (1010), with the 2 x nic ports, and the > lag in that vlan, untagged. All client desktops are in different vlans, > based on their physical location (eg floor). > > Once configured on the server, the switch config shows: > > #show lacp > > Aggregator: lag.0.12 > Actor Partner > System Identifier: 00:01:f4:7e:89:bf d8:9d:67:79:12:94 > System Priority: 32768 0 > Admin Key: 32768 > Oper Key: 32768 0 > Attached Ports: ge.2.18-19 > > #show config vlan > > *set vlan egress 1010 > lag.0.12*;ge.1.1-7,26,29*;ge.2*.1-7,*18-19*,36;ge.3.1-7,17,19 > *untagged* > > #show port vlan ge.2.18-19;lag.0.12 > ge.2.18 is set to 1010 > ge.2.19 is set to 1010 > lag.0.12 is set to 1010 > > #show port status ge.2.18-19;lag.0.12 > Port Alias Oper Admin Speed Duplex Type > (truncated) Status Status (bps) > ------------ ---------------- -------- ------- ------ ------- > ------------------ > ge.2.18 dormant up 1.0G full 1000-t > rj45 > ge.2.19 dormant up 1.0G full 1000-t > rj45 > lag.0.12 up up 2.0G lag > 3 of 3 ports displayed, 3 port(s) with oper status 'up' or 'dormant'. > > > Test copying a file to or from a client and the server on one particular > subnet, and another client on a different subnet, either on the same edge > switch, or a different switch, to the server, allows each client to each > use one of the connected nics, to achieve > 2gbps transfer speed. > > If we copy from 2 clients, on the same subnet, the copy drops to half speed > on both client, ie, they both use the same connected nic. This behaviour > occurs copying to, or from the server. > > In theory, the subnet the clients are on shouldn't affect the load balanced > lag, but it seems this is not the case. > > The windows lacp config allows either a Dynamic Load Balanced Mode, or > Address Hash mode. We've tried both....both form the dynamic lag on the > switch, with the same copy speed results. > > Is there any reason, from a network pov, you can think of why we're seeing > this behaviour...have you seen this before, and do you have any ideas on > how we can resolve it, save from having each user/client in it's own > subnet/vlan, which would lead to it's own, more significant admin related > problems!! > > thanks all, > Charlie. > > -- > This e-mail is intended only for the named person or entity to which it is > addressed and > contains valuable business information that is proprietary, privileged, > confidential and/or > otherwise protected from disclosure. If you received this e-mail in error, > any review, use, > dissemination, distribution or copying of this e-mail is strictly prohibited. > Please notify > us immediately of the error via e-mail to [email protected] and > please delete > the e-mail from your system, retaining no copies in any media. We appreciate > your cooperation. > > --- > To unsubscribe from enterasys, send email to [email protected] with the body: > unsubscribe enterasys [email protected] --- To unsubscribe from enterasys, send email to [email protected] with the body: unsubscribe enterasys [email protected]
