Problem with STATIC LACP, Comware 5.20.105 1205L01-US

[Trinh_Nguyen]

Hello,

I replaced my current core\distribution switches with HP9500 and HP10500 and try to make these new cores to work with different vendors.  I found this problem with LACP: 

I successful configured dynamic LACP to some closet switches.  I think the dynamic LACP worked because HP dynamic LACP is compatible with IEEE 802.3ad   

When I must use static LACP (HP’s proprietary LACP?), I found the links will aggregate fine, but will not work properly when one link dies.  The link-aggregation interface is still sending data to the dead link.

802.3ad LACP protocol includes a “heart-beat” sensor; the link-aggregation listens to these feedbacks.  If it finds a link dies, it will stop forward data to that link. 

Am I missing anything when I configured static LACP?

Regards,

TN

[Fredrik Lönnman]

Why do you must use static LACP? I've used dynamic LACP and static aggregation in mult-vendor networks without problems. Though I dont think I've seen any other vendor sporting "static LACP". Dynamic LACP and static aggregation should be supported by any other vendor so why not use it?

[Trinh_Nguyen]

Fedrick,

check this post, dynamic won't work over layer 2 Metro-E

http://h30499.www3.hp.com/t5/Comware-Based/LACP-Over-MEtro-E/td-p/5868079

Thanks,

TN

[Fredrik Lönnman]

Have you asked your Metro-E provider about tunneling LACPDUs? Its not that dynamic LACP doesnt work over Metro-E per definition.

But if you can't get tunneled LACPDUs, just use static configured aggregation, not "static LACP", and I doubt you'll find much interoperability issues.

[Trinh_Nguyen]

Fredrick,

I am working with my Metro-E providers to make identical handoff ports.  I have 2x100 copper at one end and 2xfiber at the other, they worked with Nortel MLT but HP link-agg dynamic won’t link up when I had non-matched medias.

Sorry for my terminologies.  I am migrating from Cisco port-channel, and Nortel MLT and SMLT to Comware OS and still struggling with “sh” and “dis”

“use static configured aggregation” you mean “link-aggregation mode static” when do “dis link-agg ver bridge10”?  That where my problem is: in this static mode, if one interface is down, the LAG (or BAGG) is useless, ping packets drop 50%.

Do you know anything need to be configured in the static mode for LACP heartbeat? In Nortel MLT, the heartbeat is “Virtual Link Aggregation Protocol or VLACP”.  When VLACP enable, the LAG listens to the other end, if three missing beats detect, the switch will not send data to that link

Thank you for your help

Best regards.

TN

[Fredrik Lönnman]

Yes, since you can't do LACP over your Metro-E provider I meant "link-aggregation mode static".

Since you're not really spelling this right out I'm just going to guess that static LAGG actually works, but your Metro-E connection are able to go down without the physical handoff to you going down, hence the interface is still up but doesnt work. The static LAGG will think it actually works, egress traffic there and they will go to nowhere. Same ballpark?

One solution on the top of my head would be to use UDLD if your Metro-E provider supports to tunnel it, but then they probably would be able to tunnel LACPDUs also.

BFD maybe, if you're routing?

I dont think there are any way to have keepalives on a static LAGG.. that's, among other things, why we have LACP.

[Trinh_Nguyen]

Fredrik,

Thanks for your expertise.  I have two different Metro-E providers, so it is not easy to request them to support something that they are not familiar with.   I am waiting for them to finish with their fibers hand-off so I can configure BAGG in dynamic mode. 

How about a suggestion for ComWare development team:  a “keepalive or hearbeat-monitor protocol” for static link-aggregation.

Best Regards,

TN

[Fredrik Lönnman]

Heh yeah ofcourse that would be a nice feature. I wish you good luck with your feature request :).

I really dont think that tunneling LACPDU could be so hard, I'm pretty sure the the MEF have some guidelines on LACP handling on E-Lines.

[Peter_Debruyne · Accepted solution]

Hi,

1/ this can be solved with ethernet OAM on both sides (need to test if the OAM packets will pass the metro link of course).

Config is simple, configure this on both sides:

int x

 oam enable

OAM is also using the link local 01:80:C2:xx:xx:xx mac range, so it is possible that these packets will also be blocked by the provider, but you can give it a try.

2/ If you have spare switches, you could place an intermediate comware switch in front of the metro link and use bpdu-tunneling to change the lacp destination mac.

3/ Another trick would be to use an intermediate QinQ+bpdu-tunnel vlan on your CE switches (as alternative to an intermediate switch).

Your former uplink would then be connected via crosscable to this local QinQ vlan, the other port of this vlan would be connected to the metro link.

Via the intermediate QinQ vlan you could apply the bpdu-tunnel and change the LACP/LLDP/OAM mac to a custom destination mac, which will pass the metro lan. (there is a custom mac by default, but you can set one manually if you want as well).

You would need 2 of these QinQ vlans if you want 2 uplink from an IRF stack to be linked to a remote IRF stack of 2 units.

This would be the sample config:

vlan 4001
 des V4001-QinQ-Backbone1

int g1/0/21
 des DOWNLINK-to-local-original-uplink1
 port access vlan 4001
 undo lldp enable
 bpdu-tunnel dot1q eoam
 bpdu-tunnel dot1q lacp
 bpdu-tunnel dot1q lldp
 qinq enable
 
int g1/0/22
 des UPLINK-to-Metrolink1
 port link-type trunk
 port trunk permit vlan 4001
 undo port trunk permit vlan 1

vlan 4002
 des V4002-QinQ-Backbone2

int g2/0/21
 des DOWNLINK-to-local-original-uplink2
 port access vlan 4002
 undo lldp enable
 bpdu-tunnel dot1q eoam
 bpdu-tunnel dot1q lacp
 bpdu-tunnel dot1q lldp
 qinq enable
 
int g2/0/22
 des UPLINK-to-Metrolink2
 port link-type trunk
 port trunk permit vlan 4002
 undo port trunk permit vlan 1

Link your original uplinks with crosscables to g1/0/21 and g1/0/22 and you should be fine.

On the original uplink, you can now set e.g. lacp period short for 1 sec lacp bpdu tx or enable oam. These OAM packets will be customized by the bpdu-tunnel of the QinQ vlan, so should pass the metro link just fine.

Best regards,Peter

[Trinh_Nguyen]

Peter,

Thank you for the detail explaination. I'll test and post the outcome. This seem the best solution so far.

Regrads, TN