bridge-aggregation interface remains UP even if all lacp members on other site are down

[arnevt]

Hi,

Due to an acquisition we inherited a network based on HPE/procurve switches, the central core being an A5500-48G-4SFP stack

on that switch we have 2 long distance links towards our network. This is an mpls service, no dark-fiber, so link down on 1 side is not propagated to other side.

For that reason we enabled LACP (via bridge-aggregation) do have faster failover timers in case of an intermediate problem with our provider which doesn't cause link down situations. This is a technique we also use with cisco and juniper, so that if the aeX / PoX interface goes down, the switch knows there is a problem

Now it seems that our Bridge-Aggregation interface remains up, even if we shut the link on our side of the network

state of the bridge aggregation while our side is down (in our setup it is port   GE1/0/48   that is the long distance link, the other links are physical down) .What bothers me (as an juniper/cisco guy) is the flags E & F

display link-aggregation verbose Bridge-Aggregation 46
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-Aggregation46
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, d07e-2869-0a7f
Local:
  Port             Status  Priority Oper-Key  Flag
--------------------------------------------------------------------------------
  GE1/0/47         U       32768    16        {ABCG}
  GE1/0/48         S       32768    16        {ABCDEFG}
  GE2/0/47         U       32768    16        {ABCG}
Remote:
  Actor            Partner Priority Oper-Key  SystemID               Flag
--------------------------------------------------------------------------------
  GE1/0/47         0       32768    0         0x8000, 0000-0000-0000 {EF}
  GE1/0/48         0       32768    0         0x8000, 0000-0000-0000 {DEF}
  GE2/0/47         0       32768    0         0x8000, 0000-0000-0000 {EF}

interface Bridge-Aggregation46
 description " ****** "
 port link-type trunk
 undo port trunk permit vlan 1
 port trunk permit vlan 123 444 555 666 777
 link-aggregation mode dynamic
 link-aggregation selected-port minimum 1
 stp edged-port enable
 arp rate-limit disable

interface GigabitEthernet1/0/48
 port link-mode bridge
 port link-type trunk
 undo port trunk permit vlan 1
 port trunk permit vlan 123 444 555 666 777
 sflow sampling-rate 1000
 sflow flow collector 1
 lacp period short
 port link-aggregation group 46
 arp rate-limit disable

any suggestions? The problem here is that if we have a problem on 1 of the links, our VPLS service failover doesn't work because the HPE keeps sending all the mac addresses toward the old (broken) link until they age out. We were hoping by getting the bridge-aggregation interface to go down, the mac would be flushed and flooded to the other link (so learning can happen there)

version is

Comware Software, Version 5.20.99, Release 5206P01

thx

Arne

[parnassus]

It looks like there is something wrong on your three interfaces' LAG on your IRF stacked Switches (note how GE1/0/47 an GE2/0/47 aren't in Selected state, see the U).

display link-aggregation verbose Bridge-Aggregation 46
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-Aggregation46
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, d07e-2869-0a7f
Local:
  Port             Status  Priority Oper-Key  Flag
--------------------------------------------------------------------------------
  GE1/0/47         U       32768    16        {ABCG}
  GE1/0/48         S       32768    16        {ABCDEFG}
  GE2/0/47         U       32768    16        {ABCG}
Remote:
  Actor            Partner Priority Oper-Key  SystemID               Flag
--------------------------------------------------------------------------------
  GE1/0/47         0       32768    0         0x8000, 0000-0000-0000 {EF}
  GE1/0/48         0       32768    0         0x8000, 0000-0000-0000 {DEF}
  GE2/0/47         0       32768    0         0x8000, 0000-0000-0000 {EF}

AFAIK LACP (IEEE 802.3ad) requires direct connectivity (copper or fiber, no matters) between involved peers' ports

Switch A LAG <=== uninterrupted/direct links ===> LAG Switch B

No intermediate devices not partecipating to end peers' LAGs are admitted.

[arnevt]

Hi

the 2 U ports are links that are disconnected (for testing purposes). So I'm not worried about that

about the direct connection... as long as you have a service that forwards your LACP packets, there can be as many devices in between as you want. The problem is also not that the link doesn't come up. The problem is that the link doesn't go down :)

[parnassus]

---

@arnevtwrote: The problem is also not that the link doesn't come up. The problem is that the link doesn't go down :)

---

Exactly because there are intermediate devices to which links are not down even if one side of the aggregated links is down.

---

@arnevtwrote:a bout the direct connection... as long as you have a service that forwards your LACP packets, there can be as many devices in between as you want.

---

AFAIK the point-to-point is (and always was) an essential prerequisite.

[Vince-Whirlwind]

Yeah, I found that very confusing - you've got a point-to-point Layer2 protocol and you think it can work over a routed network.
That's a very confusing concept for me.

802.3 (of which 802.3ad is one) are ethernet standards.

I don't even understand the problem that is trying to be solved here - you should be getting routes from your MPLS provider for each site that is currently up on their network. If one of those sites goes down, you should have either a default route pointing at a different link, or maybe the different link is advertising a higher-cost route.

Link aggregation has nothing to do with directing traffic onto alternate links, because all the members of each bundle have the same two end-points.