<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Expectations for Single Port LAG behavior on the DFE in FAQs</title>
    <link>https://community.extremenetworks.com/t5/faqs/expectations-for-single-port-lag-behavior-on-the-dfe/m-p/41511#M56</link>
    <description>Article ID: 5649 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Products&lt;/B&gt;&lt;BR /&gt;
DFE&lt;BR /&gt;
Firmware 5.11.21 and higher &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Protocols/Features&lt;/B&gt; &lt;BR /&gt;
Single port LAG &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Standards&lt;/B&gt;&lt;BR /&gt;
802.3ad &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Commands&lt;/B&gt;&lt;BR /&gt;
'set lacp singleportlag' &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Solution&lt;/B&gt;&lt;BR /&gt;
Firmware &lt;A href="https://extranet.enterasys.com/Downloads/Pages/Platinum.aspx" target="_blank" rel="nofollow noreferrer noopener"&gt;5.11.21 release notes&lt;/A&gt; state, in the Software Changes and Enhancements section:&lt;BR /&gt;
Single port LAG behavior has changed in this release. In previous firmware&lt;BR /&gt;
(introduced in 5.01) a LAG would re-form with just one port if the system had&lt;BR /&gt;
formed a multiport lag to the same partner in the past. Versions prior to&lt;BR /&gt;
5.01 would maintain a lag if it failed back to a single port but would not&lt;BR /&gt;
reform it the next time the system booted, or that single port left the LAG&lt;BR /&gt;
due to partner activity. &lt;BR /&gt;
 &lt;BR /&gt;
A system wide command that allows the user to optionally choose to have the&lt;BR /&gt;
system form lags when only one port is receiving protocol from a lag partner&lt;BR /&gt;
is now available. A CLI command 'set lacp singleportlag enable/disable' will&lt;BR /&gt;
have set, show, clear and show config options. This feature is disabled by&lt;BR /&gt;
default.&lt;BR /&gt;
 &lt;BR /&gt;
 In summary (and expanding upon what is stated in release notes), as of firmware 5.11.21:&lt;UL&gt; 
&lt;LI&gt;Knowledge of previous Dynamic LAG peers is persistent (survives a reboot), causing the learned partner to be "preferred" in two ways by the local actor: (1) It will re-form a LAG using one or more links and (2) it will reserve and try to use the same aggregator instance (ex: lag.0.1) if possible. A learned entry consists of a paired partner MAC address and actor Aggregator instance. Learning may be cleared by dropping back to a system Factory Default configuration (&lt;A href="http://bit.ly/1g6lQZH" target="_blank" rel="nofollow noreferrer noopener"&gt;5296&lt;/A&gt;), or may be more simply cleared by establishing ('set lacp static lag.0.x fe.x.x') then clearing ('clear lacp static lag.0.x fe.x.x') a Static LAG for the affected aggregator and port (&lt;A href="http://bit.ly/1g8Sbz1" target="_blank" rel="nofollow noreferrer noopener"&gt;5203&lt;/A&gt;). 
&lt;/LI&gt;&lt;LI&gt;The requirement of needing to form a multi-port Dynamic LAG to a particular peer before a single-port Dynamic LAG can form to that peer may be overridden by means of the 'set lacp singleportlag enable' command. 
&lt;/LI&gt;&lt;LI&gt;A single-port Dynamic LAG may also form while the 'set lacp singleportlag' command is disabled on the local actor &lt;I&gt;and&lt;/I&gt; no LAG has previously formed with the peer in question, if the peer device is willing to form a single-port LAG, and advertises that fact. Once such a LAG has formed, while physical link remains the singleportlag behavior will tend to be persistent through a combination of peer learning and cross-advertisement - even if the above "learning clear" workaround is applied.&lt;/LI&gt;&lt;/UL&gt;
The 'set lacp singleportlag' command should be used carefully, since the default Dynamic LACP configuration for all the ports may well cause every single connection between LACP-capable devices to form LAGs - and VLAN configurations associated with those physical ports will be ignored (&lt;A href="http://bit.ly/1g8Sbz1" target="_blank" rel="nofollow noreferrer noopener"&gt;5203&lt;/A&gt;). It also could consume a significant number (maybe all) of the LAG virtual ports since servers sometimes run LACP. &lt;BR /&gt;
&lt;BR /&gt;
To avoid these side-effects, consider first configuring the unused LAG virtual ports to require a specific key. Often the lower-numbered LAG aggregators will already be in use and active. This command form, issued on each of the peer chassis, would set the key for the rest of the aggregators:  DFE(rw)-&amp;gt;&lt;B&gt;set lacp aadminkey lag.0.x-48 1234&lt;/B&gt;&lt;BR /&gt;
 &lt;BR /&gt;
 Then, assign to the same aadminkey each of the ports you want to form singleport LAGs after singleportlag behavior is enabled:  DFE(rw)-&amp;gt;&lt;B&gt;set port lacp port ge.x.y aadminkey 1234&lt;/B&gt;&lt;BR /&gt;
 &lt;BR /&gt;
 You will also need to configure onto the resulting lag.&lt;I&gt;x.y&lt;/I&gt; logical port any port-specific settings you had already applied to the physical port, once the LAGs form. To make this more deterministic (allowing port reconfiguration &lt;I&gt;before&lt;/I&gt; the LAGs form) you may opt to use unique aadminkey values for each physical/logical port pair rather than one value for all. &lt;BR /&gt;
&lt;BR /&gt;
As the final step, allow the single-port LAGs to form, as possible:  DFE(rw)-&amp;gt;&lt;B&gt;set lacp singleportlag enable&lt;/B&gt;&lt;BR /&gt;
 &lt;BR /&gt;
 &lt;A href="http://www.enterasys.com/support/contact-support.aspx" target="_blank" rel="nofollow noreferrer noopener"&gt;Contact Enterasys Networks Technical Services&lt;/A&gt; for further assistance, as necessary.</description>
    <pubDate>Mon, 25 Nov 2013 01:46:00 GMT</pubDate>
    <dc:creator>FAQ_User</dc:creator>
    <dc:date>2013-11-25T01:46:00Z</dc:date>
    <item>
      <title>Expectations for Single Port LAG behavior on the DFE</title>
      <link>https://community.extremenetworks.com/t5/faqs/expectations-for-single-port-lag-behavior-on-the-dfe/m-p/41511#M56</link>
      <description>Article ID: 5649 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Products&lt;/B&gt;&lt;BR /&gt;
DFE&lt;BR /&gt;
Firmware 5.11.21 and higher &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Protocols/Features&lt;/B&gt; &lt;BR /&gt;
Single port LAG &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Standards&lt;/B&gt;&lt;BR /&gt;
802.3ad &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Commands&lt;/B&gt;&lt;BR /&gt;
'set lacp singleportlag' &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Solution&lt;/B&gt;&lt;BR /&gt;
Firmware &lt;A href="https://extranet.enterasys.com/Downloads/Pages/Platinum.aspx" target="_blank" rel="nofollow noreferrer noopener"&gt;5.11.21 release notes&lt;/A&gt; state, in the Software Changes and Enhancements section:&lt;BR /&gt;
Single port LAG behavior has changed in this release. In previous firmware&lt;BR /&gt;
(introduced in 5.01) a LAG would re-form with just one port if the system had&lt;BR /&gt;
formed a multiport lag to the same partner in the past. Versions prior to&lt;BR /&gt;
5.01 would maintain a lag if it failed back to a single port but would not&lt;BR /&gt;
reform it the next time the system booted, or that single port left the LAG&lt;BR /&gt;
due to partner activity. &lt;BR /&gt;
 &lt;BR /&gt;
A system wide command that allows the user to optionally choose to have the&lt;BR /&gt;
system form lags when only one port is receiving protocol from a lag partner&lt;BR /&gt;
is now available. A CLI command 'set lacp singleportlag enable/disable' will&lt;BR /&gt;
have set, show, clear and show config options. This feature is disabled by&lt;BR /&gt;
default.&lt;BR /&gt;
 &lt;BR /&gt;
 In summary (and expanding upon what is stated in release notes), as of firmware 5.11.21:&lt;UL&gt; 
&lt;LI&gt;Knowledge of previous Dynamic LAG peers is persistent (survives a reboot), causing the learned partner to be "preferred" in two ways by the local actor: (1) It will re-form a LAG using one or more links and (2) it will reserve and try to use the same aggregator instance (ex: lag.0.1) if possible. A learned entry consists of a paired partner MAC address and actor Aggregator instance. Learning may be cleared by dropping back to a system Factory Default configuration (&lt;A href="http://bit.ly/1g6lQZH" target="_blank" rel="nofollow noreferrer noopener"&gt;5296&lt;/A&gt;), or may be more simply cleared by establishing ('set lacp static lag.0.x fe.x.x') then clearing ('clear lacp static lag.0.x fe.x.x') a Static LAG for the affected aggregator and port (&lt;A href="http://bit.ly/1g8Sbz1" target="_blank" rel="nofollow noreferrer noopener"&gt;5203&lt;/A&gt;). 
&lt;/LI&gt;&lt;LI&gt;The requirement of needing to form a multi-port Dynamic LAG to a particular peer before a single-port Dynamic LAG can form to that peer may be overridden by means of the 'set lacp singleportlag enable' command. 
&lt;/LI&gt;&lt;LI&gt;A single-port Dynamic LAG may also form while the 'set lacp singleportlag' command is disabled on the local actor &lt;I&gt;and&lt;/I&gt; no LAG has previously formed with the peer in question, if the peer device is willing to form a single-port LAG, and advertises that fact. Once such a LAG has formed, while physical link remains the singleportlag behavior will tend to be persistent through a combination of peer learning and cross-advertisement - even if the above "learning clear" workaround is applied.&lt;/LI&gt;&lt;/UL&gt;
The 'set lacp singleportlag' command should be used carefully, since the default Dynamic LACP configuration for all the ports may well cause every single connection between LACP-capable devices to form LAGs - and VLAN configurations associated with those physical ports will be ignored (&lt;A href="http://bit.ly/1g8Sbz1" target="_blank" rel="nofollow noreferrer noopener"&gt;5203&lt;/A&gt;). It also could consume a significant number (maybe all) of the LAG virtual ports since servers sometimes run LACP. &lt;BR /&gt;
&lt;BR /&gt;
To avoid these side-effects, consider first configuring the unused LAG virtual ports to require a specific key. Often the lower-numbered LAG aggregators will already be in use and active. This command form, issued on each of the peer chassis, would set the key for the rest of the aggregators:  DFE(rw)-&amp;gt;&lt;B&gt;set lacp aadminkey lag.0.x-48 1234&lt;/B&gt;&lt;BR /&gt;
 &lt;BR /&gt;
 Then, assign to the same aadminkey each of the ports you want to form singleport LAGs after singleportlag behavior is enabled:  DFE(rw)-&amp;gt;&lt;B&gt;set port lacp port ge.x.y aadminkey 1234&lt;/B&gt;&lt;BR /&gt;
 &lt;BR /&gt;
 You will also need to configure onto the resulting lag.&lt;I&gt;x.y&lt;/I&gt; logical port any port-specific settings you had already applied to the physical port, once the LAGs form. To make this more deterministic (allowing port reconfiguration &lt;I&gt;before&lt;/I&gt; the LAGs form) you may opt to use unique aadminkey values for each physical/logical port pair rather than one value for all. &lt;BR /&gt;
&lt;BR /&gt;
As the final step, allow the single-port LAGs to form, as possible:  DFE(rw)-&amp;gt;&lt;B&gt;set lacp singleportlag enable&lt;/B&gt;&lt;BR /&gt;
 &lt;BR /&gt;
 &lt;A href="http://www.enterasys.com/support/contact-support.aspx" target="_blank" rel="nofollow noreferrer noopener"&gt;Contact Enterasys Networks Technical Services&lt;/A&gt; for further assistance, as necessary.</description>
      <pubDate>Mon, 25 Nov 2013 01:46:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/faqs/expectations-for-single-port-lag-behavior-on-the-dfe/m-p/41511#M56</guid>
      <dc:creator>FAQ_User</dc:creator>
      <dc:date>2013-11-25T01:46:00Z</dc:date>
    </item>
  </channel>
</rss>

