LACP is the Link Aggregation Control Protocol. It is all about setting up link aggregation automatically and dynamically whenever more than one link is available and the other side speaks LACP as well. It typically is used with redundant server-switch interconnection since a static setup with link aggregation would break server connectivity as long as the NIC drivers (where link aggregation is implemented) have not been loaded, thus effectively breaking pre-boot server management or network boot capabilities.
For switch interconnects, usually a static setup is preferred - although I would consider it purely a matter of taste.
"Link aggregation" and "trunking" are usually used as synonyms. There is a defined IEEE standard for LA (802.3ad) and many proprietary vendor extensions have arisen before standardization, most of which have implementations even in newer switch models for backward compatibility reasons.
If you set up a link aggregation or trunk group (LAG/TG), you should define the same VLANs as members of the group for switches on both sides. You only should define more than one path (i.e. more than one LAG interconnection) between two switches if you a) know exactly what you are doing and b) have enabled STP on both connected switches.
If you just suspect a bandwidth bottleneck, use the port statistics counters of your switches to verify it - quite possible that the bandwidth usage will turn out fine and your problem is an entirely different one. Mostly, switches do have rather slow CPUs and fast ASICs able to do most of the processing without any burden on the CPU. Some operations still would eat CPU cycles, one that is quite "popular" is the reception of broadcasts or multicast packets. If your network is generating a lot of broadcast/multicast traffic, processing and discarding the packets itself might saturate the CPU of a switch beyond reason. Again, check the counters to see if an excessive number of broadcasts is seen on the net.
The 5400zl series supports a very full feature list to provide quality of service (QoS) and traffic management. And for your specific requirement it also supports rate-limiting. Your best bet will be to upgrade to the latest version (K.15.8 at this point in time). The reference is the Advanced Traffic Management guide (current version)
What you need to do is
1. Define a class to match the traffic you wish to limit
2. Define a policy on how to treat the traffic
3. Apply the policy on a interface or VLAN
Something like the following should work:-
class ipv4 servers-to-be-slowed
match ip 1.2.3.4/32 any
match ip 1.2.3.5/32 any
exit
policy qos SlowBadServers
class servers-to-be-slowed action rate-limit kbps 1000
exit
interface all service-policy SlowBadServers in
I have written interface all above but you probably want to apply it only to your so called head end connection
Best Answer
No, you can't delete it.
Instead, just don't use it.