vlan 1

[johnk3r]

@VoIP-Buddy

This screenshot was taken in the ebook for certification level architect (ASE) written by HPE.

[sdide]

Hi all,

there seems to be a bit confusion in the thread about the wording.

"LACP" is a specific protocol. It is this protocol that is used to achieve dynamic behavior in a link aggregation (normally a protocol induces something dynamic, because information travel across units using the protocol and updates behavior accordingly => hence dynamic as opposed to static.) "

Link aggregration" however is not neccesarily dynamic.

As i understand it, the big difference between static and dynamic om Comware is that when using dynamic mode both ends agree on which physical ports are Selected and which are Unselected in the aggregation-group.

And about a "link going down in one end" - normally Link is achieved using LLC frames and so link is something both ends agree about. Normally. I have seens links up in one direction only due to faulty switch or transceivers, but this affects all things among others Link aggregation.

Regards

[BjKo]

---

wrote:

---

If you use static link agg there is no state information maintained and the link is always up.  The other end will never know if there is a link down.

I'm not sure what you mean.
If a link is physically up, and if it is in a LAGG, then that link ID will be included in the LAGG hashing algorithm and potentially receive outgoing packets.
If a link is not physically up and it's in the LAGG, the LAGG will not send any packets to it, no matter how you have it configured.

---

Do not mix up static LACP with a static link aggregation. A static link aggregation does not use any protocol to negotiate, LACP is always negotiated.

With dynamic LACP you could connect the port with another device, which does not use LACP (PC, phone, ...) and it will continue without a link aggregation. The Port does not receive LACPDUs and does not build a link aggregation but still works and learns MACs and forwards traffic normally.

With static LACP the port will not continue to work when it does not receive LACPDUs. It will be in a active LACP port, sending and listening to LACPDUs, but it will not forward traffic. 
In Comware you cannot configure ports to change between link aggregation and "normal" dynamically, in Procurve you can (but you also need GVRP if you want VLANs).

With static link aggregation the link will always send and expect traffic based on the hash algorythm, independent from the state of the other site. If the other site uses LACP, both ports will be physically up, but since static LAs don't send LACPDUs they will not transmit the traffic and the traffic will be discarded. 

 In short: You can just connect two ProCurves, which use dynamic LACP on every port, without creating a loop.
Please refer to this old Procurve document:
http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/WB/15-18/5998-8162_wb_2920_mcg/content/ch04s07.html#s_Static_LACP_trunks

[VoIP-Buddy]

Folks,

There is no such thing as "static LACP."  As was previously pointed out, LACP is the protocol that is used in a link-aggregation group to control the ports dynamically. 

STATIC Link-Aggregation means that the parameters are set up manually on each side to allow data to pass.  There is no port management. 

If you are using LACP, you are creating a dynamic Link-Aggregation group.

Regards,

David

[BjKo]

---

wrote:

Folks,

There is no such thing as "static LACP."  As was previously pointed out, LACP is the protocol that is used in a link-aggregation group to control the ports dynamically. 

STATIC Link-Aggregation means that the parameters are set up manually on each side to allow data to pass.  There is no port management. 

If you are using LACP, you are creating a dynamic Link-Aggregation group.

Regards,

David

---

Static and Dynamic does not refer to the LACP protocol but to the interfaces. 
The interfaces can dynamically join and leave the LACP. 

This is not intended by the LACP protocol, the protocol stops traffic transfer when a mismatch is detected but it does not make the interface leave the link-aggregation.

Imagine you make a 4 interface LACP and connect 2 interfaces to the other switch and, for whatever reason, connect the other two to PCs. The other two (PC) would not work. This is by design of the LACP.
With a dynamic LACP the other two would leave the link-aggregation and would work. The two interfaces are NOT LACP interfaces at this point.

[Vince-Whirlwind]

Thank you, that is very well explained.

Here is why I don't use dynamic protocols:

When I design a network I don't design a network where PCs are connected to link-aggregated ports on a switch. It just doesn't happen.
In fact, I really can't remember using link aggregation on copper ports, and although I deal with PCs that use fibre connectivity at the access layer, those networks are so tightly controlled that I'm pretty sure if anybody connected a PC to link agg port, they'd be fed to the sharks, and rightly so.

As with many of us I guess, my formal network training was originally in Cisco. Cisco had (from memory)
"passive" - which was rubbish and a complete waste of time
 "active" - which really only worked in a pure Cisco environment
"on" - which worked.

From there, as we tried to get our customers to stop wasting their money on Cisco, and as we added good stuff like HP Procurve to their networks, we used Cisco "ON" and HP "Trunk" and it all worked fine.

I have implemented recent 3COM networks. It is powerful kit, and on the whole, it's the way to go for a good many applications, which pains me to say because I am so not a fan of the whole operation at 3COM, from design to business, to the security aspect of where it comes from. I can't recall my configs, but whatever it was, it was going to play nice with Cisco "On" and HP Procurve "Trunk", so nothing dynamic, regardless of how 3COM labels it.

[VoIP-Buddy]

Hi Vince!

I agree with you.  We most often see this on upward or downward links to switches.  HOWEVER, there is a very good reason to use them to servers that support dynamic Link-aggregation.  You get increased aggregated bandwidth for each port connection.  The only caveat is that if they all aren't the same speed, the link will run at the speed of the slowest port.

One reason to consider copper ports is that there are models of the 5130 EI family that support 10g on copper ports.  Typically we would see fiber to a server but we now have a copper solution too.

Regards,

David

[Vince-Whirlwind]

I find when creating a link aggregation for a server, I am at the mercy of the server guy and what he understands about configuring link aggregation on his server (which usually approximates to about nil).
Generally, he will do something undocumented and on the fly and then I have to use trial and error to come up with the link agg config on my switch that works with whatever he has done.

I used DAC to connect two Core switches once, so I guess I lied about never using copper for link aggs.