Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Alright thanks!it's called teaming. you need a switch/router that supports it. but that is the term you should be googling, "teaming lan"
Figured I'd take advantage of both NICs... don't necessarily need that much speed.just curious what's on your LAN that requires that speed?
You need a switch and NICs that support LACD or "link aggregation". Teaming is another term for it. You're going to need a managed gigabit switch to do it.
Teaming often means a "failover" team so you only actually use one at a team. You want to do link aggregation, or a port-channel, or an Etherchannel (old Cisco name)...or a trunk (in incorrect HP terms). But here is the thing. I've explained this a few times on here.
There is no standard way for a single client to talk to a single server and use both links. Link aggregation uses a hashing method... Hash based on source MAC. Hash based on IP. Hash based on port..all sorts of ways, but the bottom line is that a single connection between your desktop to your server will never use more than 1Gb. The reason that there is no standard way to just do packet/frame round-robin load balancing is that you can't guarantee order of delivery like that which breaks some things.
If you have two desktops connecting to a server with two NICs you MIGHT get utilization across both NICs...it just depends on your hashing method and if you the mathematical algorithm works out so one connection hashes on NIC1 and the other hashes on NIC2. If they don't you may need to adjust IP or something (again, depends on hash type) to fix that.
That's why when I talk about link aggregation in network designs I never say "load balancing", I say "load distribution".
What if you start two separate file copies?
Nope. You're using the same protocol and ports for the "conversation" to the server (conversation is a term I often us when talking about this). If you hash by source/destination IP..they are the same for both connections. Hash by MAC? Same for both connections. Port? Same. See the problem?
Depending on protocol the connection might originate from from a random port.
Possibly..but most switches will hash based on MAC or IP. Some things will do it by source/dest IP and port...just depends and both sides have to agree. VMware, for example, is IP...no port info. So sometimes you can do things between switches and get better utilization but not from end-device to switch. It's annoying.