So I have some servers with dual NICs connected to a Summit X440-48. I would like to start using Link aggregation. I have not found a lot of details in the documentation I have on enabling and configuring the switch for this. So looking for some tips on setup and best practices. Most of my servers are Win2008. One of the server is Win2003. I have to double check some of the odler servers to verify they support 802.3ad but I know newer ones I have do. Do I need vlan for the LAG like I have seen suggested or is that a preference thing? And what about QoS for the LAG? We use Avaya IP phone system, so I have to be mindful of our phone vlan setup as right now I believe it is the only currently using a specific QoS setting. XOS ver is 15.3.1.4
-
430 Points
Posted 3 years ago
-
430 Points
SO I been doing some reading in the Basic Switch Operations Document.
It states the LAG requires a configuration at both ends. But the reading confused me some.
SO my question is the server NIC considered one end and the Switch ports considered the other end thus completing the requirements?
Last thing I want to do is a create a loopback as that could possibly screw our phone system, as nobody is 100% on the loop back prevention for it properly working.
It states the LAG requires a configuration at both ends. But the reading confused me some.
SO my question is the server NIC considered one end and the Switch ports considered the other end thus completing the requirements?
Last thing I want to do is a create a loopback as that could possibly screw our phone system, as nobody is 100% on the loop back prevention for it properly working.
-
430 Points
No insight on this? I guess I can tinker with it the worse that happens I kill my network for a few minutes.
Daniel Flouret, Employee
-
7,470 Points
Joe,
LACP must be enabled on both sides of the aggregated links.
Unfortunately, Link Aggregation is natively supported only in Windows Server 2012. Windows Server 2003 and 2008 don't support it and you have to check if your NIC vendor provides drivers that support it.
Check https://social.technet.microsoft.com/Forums/windowsserver/en-US/7dc861fb-9813-485e-ac91-7fc50dd8f123...
LACP must be enabled on both sides of the aggregated links.
Unfortunately, Link Aggregation is natively supported only in Windows Server 2012. Windows Server 2003 and 2008 don't support it and you have to check if your NIC vendor provides drivers that support it.
Check https://social.technet.microsoft.com/Forums/windowsserver/en-US/7dc861fb-9813-485e-ac91-7fc50dd8f123...
-
430 Points
We use the Broadcom Suite which does support it. I also would have sworn I read r2 sp1 supported it as well but that may have been bad info. My biggest concern was switch settings I usualy do a lot reading before I mess with it, but it seems like the XOS documentation leaves a lot out on this.
Daniel Flouret, Employee
-
7,470 Points
Joe,
There's really nothing misterious about link aggregation in XOS.
To create a LAG use the following command:
In the second one the individual links will be activated only if they find a LACP configured peer at the other end. Thus, if you make a mistake nothing will happen. Literally. The links won't come up...
The algorithm part of the command deals with the method used to distribute traffic among the groups in the link. I usually configure L3_L4 which gives the best distribution in most cases.
The thing to remember is that, once created, the LAG is represented by the port chosen when you created it (port 1 in the example).
There are other commands that let you add or remove individual ports from the LAG
There's really nothing misterious about link aggregation in XOS.
To create a LAG use the following command:
enable sharing <port> grouping <port-list> {algorithm [address-based {L2 | L3 | L3_L4 | custom | port-based}]} {lacp}For example, to create a LAG using ports 1 and 2, where 1 is the port that will represent the LAG:
enable sharing 1 grouping 1-2Want to use LACP?
enable sharing 1 grouping 1-2 lacpThe first one will work right away. It is up to you to make sure that link aggregation is configured on the other side of the links and that the individual links are correctly connected. If you make a mistake you will probably create a loop. this is known as a static LAG.
In the second one the individual links will be activated only if they find a LACP configured peer at the other end. Thus, if you make a mistake nothing will happen. Literally. The links won't come up...
The algorithm part of the command deals with the method used to distribute traffic among the groups in the link. I usually configure L3_L4 which gives the best distribution in most cases.
The thing to remember is that, once created, the LAG is represented by the port chosen when you created it (port 1 in the example).
There are other commands that let you add or remove individual ports from the LAG
configure sharing <port> add ports <port_list>To add ports 3 and 4 to the previous LAG:
configure sharing <port> delete ports <port_list>
configure sharing 1 add ports 3-4
-
430 Points
So I was reading thru the command ref guide for XOS 15.4 (page 274 or so) and it should a vlan for ALG Health Checks. I thought about trying this out but because we use a VIOP here is there a chance I create a loopback that screws with the phone?
-
430 Points
Bad editing on my part. I was in hurry at the end of the day.. I was just wondering whether anyone uses a health check for their LAG set ups and whether or not the one in the reference guide would play havoc with a VOIP set up. I know our switches still have some vulnerability to loopbacks caused by the phone system. I am not sure why yet, I was told the VIOP config was set up to prevent them.
(Edited)