Nortel 5520 stack with LACP against IBM RackSwitch G8124-E VLAG

[Alessan]

Hi,

  I'm having trouble connecting a stack of Avaya switches against a switch ibm.

  At both sides gives me lacp up (nortel) and lacp/vlag(ibm) up and formed.

  When the two links are connected computers behind nortel switch can resolve dns, adquire ip by dhcp and i can even connect using vnc to them, but this computers (connected to nortel switch) can not access the shared folders of the domain (user profiles, etc).

  As soon as I disconnect one link (any of them) instantly desktop is loaded and i can access user profiles.

  Any idea what could be happening? I really need help.

  I attach a network diagram.

Thanks in advance.

[Øyvind Nikolaisen]

Sounds like you have a hashing problem. It may be that you haven't enabled the LACP crrectly on the Avaya side, or there may be some problems with the switch clustering (vlag) on the IBM side. IBM isn't something I'm overly familiar with, but you could post the relevant portions of your Avaya configuration to have it verified here.

Brdgs
Øyvind

[Alessan]

Hi onikolaisen, thanks for reply.

I attach Nortel config.

[Alessan]

Hi,

  After toons of test... I see that only fail against IBM system storage N6040 (domain profiles and all company data).

Behind this switch:
  - Computers at VLAN 1 sometimes can comunicate and sometimes not. (hours, no daily pattern).
  - Computers at other VLAN can communicate allways with N6040.
  - If i remove 1 link, all works (any of them)
  - Changing native VLAN don't help (native vlan tagged too at ibm switch).
 
Note: IBM N6040 is connected against another Nortel 5520 with 2 LACP Links, BUT aggregation is not enabled at switch.

¿What happend when adminkey is enabled (lacp mode port x active) but aggregation is off?

Thanks in advance,

[Dominik]

Can you provide the config please.

It sounds like on side is doing a link aggregation and the other side is not aggregating.

Do you see a trunk on the ERS5520 has formed up ?

[Alessan]

Hi,

  Seems to be a IBM netapp config issue.

  I think the problem is solved, we disabled the fastpath option at storage disk and instantly begin works.

  Tomorrow I could confirm it.

  Thanks to all.

With fastpath enabled, the filer will respond to the same MAC address and tries to send the packet back thru the same interface as it came in. This allows for loadbalancing on multiple trunk interfaces on the same subnet. Disabling this means that ONTAP has to look up its routing table to figure out where to stick the packet in and *might* introduce a delay. In other scenarios, if you have the filers connected to switches running HSRP, then it might conflict with the fastpath setting.

Symptoms:
All nodes work in communicating across subnets through a non-Cisco switch except for the filer. A packet trace might show heavy network delays to short bursts of successful communication.

Cause:
This is because options ip.fastpath.enable is on (default setting). This means that the Filer is responding back to the same MAC address and not just routing to the default route. It does not matter if only one interface is involved. The non-Cisco layer 3 switches/routers need the Filer to respond to the default route first.

If options ip.fastpath.enable is on, then the Filer will respond to the sending MAC first and then as a last resort, respond via the default route. This causes too long a network delay for applications to function properly.

Solution:
Disable fastpath:
options ip.fastpath.enable off

[Dominik]

Thanks for the feedback.
Good to hear that everything works now.

Cheers