Comware

Dear,

We try to setup a static aggregated link between our firewall and our A5500 irf stack but no traffic seems to go over the link. The trunk config seems to be ok and als the VLAN config. We do not make use of LACP.  Any ideas?

display link-aggregation summary

AGG          AGG     Partner ID    Select   Unselect      Share
Interface   Mode                         Ports    Ports            Type
-------------------------------------------------------------------------------
BAGG1        S           none              2           0                Shar

Config:

What is the output of the display link-aggregation verbose bridge-aggregation1 command?

Which type of Firewall are you exactly using (Doesn't it support LACP)?

What is the Trunk configuration Firewall side?

Why aren't you setting up a Dynamic Trunk (LACP) instead of a Static Trunk (Non-Protocol)?

Are the interfaces Gigabit Ethernet 1/0/32 and Gigabit Ethernet 2/0/32 "near" (of the same "group" of) the physical ports used to form the Logical IRF port of the IRF Stack?

display link-aggregation verbose Bridge-Aggregation 1
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected
Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
D -- Synchronization, E -- Collecting, F -- Distributing,
G -- Defaulted, H -- Expired

Aggregation Interface: Bridge-Aggregation1
Aggregation Mode: Static
Loadsharing Type: Shar
Port             Status      Priority      Oper-Key
--------------------------------------------------------------------------------
GE1/0/32          S           32768              1
GE2/0/32         S           32768              1

---

WimV wrote: The firewall supports LACP but according our security partner is shouldn't be needed. I gave it a try with LACP but with the same result. (Switch Active / FW passive).

Interesting statement/recommendation the one provided you by your Security Partner!

Which justifications they provided about that choice?

If I were you I will follow what was written above by @VoIP-Buddy.

The fact you tried also with LACP (Dynamic) Port Trunking other than trying with Non Protocol (Static) Port Trunking...and, in both cases, it didn't work...is possible a signal of probable misconfiguration IRF Stack side/Firewall side or on both sides:

1. You haven't followed the proper Port Trunking (LAG) setup as described for Comware based units (reference: your product Documentation) --> could you share (sanitized) configuration file of your IRF Stack?
2. Firewall side there is an issue/misconfiguration. You didn't show us which (sanitized) configuration the Firewall has with regard to its Port Trunking facing the IRF Stack.

---

WimV wrote: the port of the link aggregation are on different members of the IRF stack. I'll check if it will be a difference when we use two port on the same physical switch...

There should not.

Since a properly configured IRF Stack creates a single virtual logical switch to downstream/upstream devices (the Firewall, in your case) those devices will see a single logical switch SO termination of a LAG (LACP/Non-Protocol, doesn't matter) which is originating on those devices should be irrelevant from the point of view of the physical ports to which that LAG terminates its links: in other terms, with IRF properly running, you can (a) terminate a LAG on physical ports residing on different IRF members (sort of load balancing in case against SPoF) or (b) terminate a LAG on ports residing all on the same IRF member.

Clearly, considering IRF and Firewall sides, configured LAGs need to be properly configured.

As you see from the command output...using the Non-Protocol (Static) provides very few information (especially regarding the "paired" device, your Firewall) with respect to what is provided by using LACP (test it!).

Dear All,

Maybe the issue has to do with duplicate IP addressing when failing over from FW A to FW B. Both switches are connected with two core switches also with an aggregated link. It seems te mac address tables are not refreshed fast enough when switching from FW A to FW B.

following setting is active on the switches:  mac-address mac-roaming enable

In the syslog we see the message:

Detected an IP address conflict. The device with MAC address xxxx-xxxx-xxxx connected to Bridge-Aggregation1 in VLAN 25 and the device with MAC address xxxx-xxxx-xxxx connected to Bridge-Aggregation2 in VLAN 25 are using the same IP address xxx.xxx.xxx.xxx.

PS: on site B we have still Avaya but we are migrating to HP...

KR, Wim

Dear All,

Tanks for the recommendations. I will recheck the LACP option with our security partner. If i well remember is think when we tested with the option LACP activated the status of one port was always "Unselected" status and the other one was "Selected" status. tryed to fix this but always the same result. Without the LACP option both port receive the "Selected" status. 

KR, Wim

Dear All,

Just to inform you. the problem was not caused by the Aggreted link but the way comware handles VLAN tagging on trunk ports. The PVID (VLAN 1) was not tagged althought we thought is was. We needed to set PVID to another VLAN (Dummy not used vlan) to have this VLAN tagged.

Kind Regards, Wim 

Wimv,

It would be better to use dynamic link-aggregation with LACP because it will manage the connection when a link goes down.  Static link-aggregation is always up so you run the risk of dropping packets when a link fails with no warning to the upper protocols.

David

I second @VoIP-Buddy about LACP versus Non Protocol link aggregation: if the device you're uplinking to with a port trunking does support LACP go with LACP.