順をおって、確認をしていただきたいです。

・まずそもそも、スイッチ側はポート毎にトラップを投げているか？
・トラップ受信側に届いているか？
対象の SW から発生したトラップを受信するサーバは、zabbix_server を稼働させているサーバ自身で
snmptrapd や syslog 等のログでは、各ポート毎にトラップを受信しているか？

・受信したトラップ情報が、アイテム値として登録されているか？
おそらく snmptt 等を経由して アイテムの値に登録されているはずですが、
snmptrap[linkDown] アイテムの履歴値を見て、各々のポートに関する受信記録がすべて
登録されていますか？

提示頂いている設定キーを見る限り、トラップの種別毎にアイテムがあるようですので
ポート複数分、複数件のトラップ履歴が、１アイテムに連続登録されるような動作に
なっているのだと思います

・トリガーの設定で、「障害イベントを継続して生成」はどのようになっていますか？
提示頂いているトリガー設定の条件だと、おそらく無効なのだと想像します

１．連続して発生する複数のトラップのうち１件目の値を受信した時点で
　「障害」ステータスに変化　→　トリガーからアクションが発動
２．２件め・３件めを受信。既に「障害」ステータスなので、アクションは発動しない
３．nodata で指定されている時間が経過して、「正常」ステータスに復帰
　→　トリガーから復旧アクションが発動、復旧時のアクションが無効ならば特に何も実行されない

１件のアイテムに、複数件の障害を示すデータを連続受信した際に、
全部の受信からアクションを実施したければ、「障害イベントを継続して生成」を有効にする必要があります

しかし、提示頂いているトリガー設定のように、「nodata」を含めている場合には
一定時間おきに「障害」「正常」の判定が行われてしまいます

そのため、以下のような動作となります
おそらく「４」のアクションが、意図されている動作ではなくなってしまうと思います

１．１件目受信　「正常から障害に変化」　→　トリガーからアクション発動
２．２件め受信　継続生成有効なので→　トリガーからアクション発動
３．３件め受信　継続生成有効なので→　トリガーからアクション発動
４．　30sec 間隔で nodata の評価が実行される
　　→ 1m 以内のデータがあるため継続して「障害」として判定される　→　トリガーからアクション発動
５．　30sec 間隔で nodata の評価が実行される
　　→ 1m 以内のデータがなくなったため、「正常」へ復帰
　　　→　トリガーから復旧アクションが発動、復旧時のアクションが無効ならば特に何も実行されない

「継続して生成」を有効にしたうえで、トリガー条件式に「nodata」を利用しなければ、
「４」のアクション動作は回避することができますが、
今度は、トリガーを「障害」から「正常」に戻す方法がなくなってしまい、
いったんトラップを受信してしまうと、常に「障害」のままになってしまうことになります

運用なども絡むかと思いますので、今一度、見合う設定を検討されるのが良いかと思います

最後に、ご利用のバージョン 2.4.1 ですが、2.4系列のなかでも相応に古いものとなります
SNMPTrap周りに限らず、多くの不具合修正されていますので、2.4 系のなかでも
新しい版にすることをおすすめします

また、先日の3.0リリースに伴い、2.4系はサポート期間が終了しています
3.0への移行も含め、検討されることをおすすめします