There is no clear recommendation for one of these options. If it was, there would be no point in offering more than the one and only option. Actually, I would suggest you to read the chapter 4 in the "Management and Configuration Guide", because it describes the advantages and disadvanges for each of the options and then you have to decide what you want on your own
But I had the same question some time ago and I will sum up the main points. I skip all points that are related to trunking vs. aggregation with other equipments, because you are only interested into a conenction between two 5400zl.
- A "trunk" is a very "dumb" thing. This is not meant to be negative, I only want to say there is no negiotation between both ends of a trunk. Each end uses all links of a trunk in some kind of round-robin fashion and expects the remote end to do the same. Moreover within the switch firmware a trunk is seen as an individual, proper port. It forgets about the members of a trunk, they won't even show up in "show interfaces" anymore. If both ends are under your control this is totally fine, but dare you if you create a trunk on one side and then put both links into non-trunked ports at the other side or even into two ports of two different devices. But in my opinion this is not a real disadvantage but an advantage. Either is works and then it works 100% as expected or it does not work at all and you will notice it. Moreover and this is a real advantage of a trunk you can sniff traffic on it because it is seen as a proper interface by the switch. If you need this capability for network monitoring or error analysis then a trunk is the only option.
- LACP takes some burden from the administrator and puts more "intelligence" into the switch. If you aggregate some ports on one side but then forget to do the same at the remote end or if you suddenly decide to use the links for something totally different, nothing bad will happen. This is fine, if you do not have control about the remote end. LACP is more fault-tolerant. Moreover there is one advantage. A trunk as well as an LACP link can only have at most 8 "active" member links. For a trunk this is all you can have, because each member of a trunk is always active. A LACP link can have additional members as "inactive" spares. If one of the active links fails (the cord is removed or whatever) one of the spares becomes active. Unfortunately, you cannot sniff traffic on a LACP link, because the switch still sees the members as individual ports.
To make a long story short: Back in times, I myself decided to use a trunk.
(a) From I technical perspective I wanted to have the capability to monitor traffic if I need to. I did not need the option to have more than 8 inactive spares. I did not need the intelligence of LACP, because I had both sides and the wiring under my control.
(b) From a more "social" perspective, I do not like auto-negiotation and "intelligent" devices. What I say now is a total personal attitude. If I have both ends under my control and if I do something wrong I want to notice it. It is OK for me, if things go really wrong in this case, because then it is my fault and I want to know it as soon as possible. For me this is a question of "digital sovereignty". In my personal experience, auto-negiotation causes more problems than it solves. If something goes wrong, you normally do not notice it directly, because there is only a silent decrease in performance. Hence, you need some kind of monitoring to ensure that everything still works as you want it to work. This monitoring introduces some additional complexity that is not really necessary. If you use "dumb" devices, you get this monitoring for free. Either it works and then it works as it should or it does not work at all.
