- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- Comware Based
- >
- Re: Problem with STATIC LACP, Comware 5.20.105 120...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-02-2013 12:14 PM
тАО01-02-2013 12:14 PM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-02-2013 12:38 PM
тАО01-02-2013 12:38 PM
Re: Problem with STATIC LACP, Comware 5.20.105 1205L01-US
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?
CCIE Service Provider
MASE Network Infrastructure [2011]
H3CSE
CCNP R&S
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-02-2013 01:29 PM
тАО01-02-2013 01:29 PM
Re: Problem with STATIC LACP, Comware 5.20.105 1205L01-US
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-02-2013 01:37 PM
тАО01-02-2013 01:37 PM
Re: Problem with STATIC LACP, Comware 5.20.105 1205L01-US
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.
CCIE Service Provider
MASE Network Infrastructure [2011]
H3CSE
CCNP R&S
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-03-2013 08:33 AM - edited тАО01-03-2013 08:36 AM
тАО01-03-2013 08:33 AM - edited тАО01-03-2013 08:36 AM
Re: Problem with STATIC LACP, Comware 5.20.105 1205L01-US
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-03-2013 11:16 AM - edited тАО01-03-2013 11:19 AM
тАО01-03-2013 11:16 AM - edited тАО01-03-2013 11:19 AM
Re: Problem with STATIC LACP, Comware 5.20.105 1205L01-US
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.
CCIE Service Provider
MASE Network Infrastructure [2011]
H3CSE
CCNP R&S
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-03-2013 01:39 PM - edited тАО01-03-2013 01:39 PM
тАО01-03-2013 01:39 PM - edited тАО01-03-2013 01:39 PM
Re: Problem with STATIC LACP, Comware 5.20.105 1205L01-US
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-03-2013 01:53 PM
тАО01-03-2013 01:53 PM
Re: Problem with STATIC LACP, Comware 5.20.105 1205L01-US
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.
CCIE Service Provider
MASE Network Infrastructure [2011]
H3CSE
CCNP R&S
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2013 07:48 AM
тАО01-09-2013 07:48 AM
SolutionHi,
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2013 08:03 AM
тАО01-09-2013 08:03 AM
Re: Problem with STATIC LACP, Comware 5.20.105 1205L01-US
Thank you for the detail explaination. I'll test and post the outcome. This seem the best solution so far.
Regrads, TN