Losing connectivity in to device in Bridge Agg group

[prodigy811]

Hi all,

I have 2 ports set up in Bridge Agg and they are set as link agg mode dynamic. I have a server connected (dual homed) When I shut down one of the ports the connection drops like 4-6 pings. Is this correct.? If I was carrying out an ISSU that means it will definitely be service impacting?

I look forward to hearing back from you guys

Many thanks

[akg7]

Hello,

Connection should not be dropped if you are using BAGG.

Can you please share config from those BAGG interfaces as well as 'display link-aggregation verbose bridge-aggregation' output  and also share 'display logbuufer reverse' output?

Is part of IRF and are you going to upgrade switch via ISSU upgrade?

Thanks!

[Ivan_B]

Just in addition to @akg7 suggestions I'd like to add this document that illustrates ISSU and impact on the traffic forwarding during the upgrade measured in our labs - https://higherlogicdownload.s3.amazonaws.com/HPE/MigratedAttachments/605B9B5B-CA69-431D-A8F6-B53A287B6A9A-1-HPE%2059xx%20FlexFabric%20ISSU%20VRD.pdf

Hope this will help you to plan the upgrade accordingly!

[prodigy811]

Hi there,

Apologies for the delay on the information you looking for. The logs verbose has gone past anthing of relevance to the drop in pings unfortunately. But I have the output of everyhting else;

SW-1>dis link-aggregation ver bri 103

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

        D -- Synchronization, E -- Collecting, F -- Distributing,

        G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation103

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 4cae-a3b4-8add

Local:

  Port                Status   Priority Index    Oper-Key               Flag

  XGE1/1/3(R)         S        32768    10       4                      {ACDEF}

  XGE2/1/3            U        32768    21       4                      {ACG}

Remote:

  Actor               Priority Index    Oper-Key SystemID               Flag  

  XGE1/1/3            255      1        33       0xffff, 704c-a5e8-ccf6 {ACDEF}

  XGE2/1/3            32768    0        0        0x8000, 0000-0000-0000 {EF}

<SW-1>dis link-aggregation ver bri 102

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

        D -- Synchronization, E -- Collecting, F -- Distributing,

        G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation102

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 4cae-a3b4-8add

Local:

  Port                Status   Priority Index    Oper-Key               Flag

  XGE1/1/2(R)         S        32768    20       3                      {ACDEF}

  XGE2/1/2            S        32768    40       3                      {ACDEF}

Remote:

  Actor               Priority Index    Oper-Key SystemID               Flag  

  XGE1/1/2            255      1        33       0xffff, 04d5-9075-6974 {ACDEF}

  XGE2/1/2            255      2        33       0xffff, 04d5-9075-6974 {ACDEF}

<SW-1>sy

System View: return to User View with Ctrl+Z.

[SW-1]int bri 102

[SW-1-Bridge-Aggregation102]dis th

#

interface Bridge-Aggregation102

description *** 

port link-type trunk

port trunk permit vlan 1 200 to 201 204 to 208 240 to 241 243 to 251 255 to 256 258 290 to 291 293 to 295 298

 port trunk permit vlan 300 to 301 305 to 306 308 340 to 341 343 to 345 350 to 351 355 to 356 543 553 to 554

link-aggregation mode dynamic

#

return

[akg7]

Hello @prodigy811 ,

Bagg 102 config and status looks fine.

I believe you are bothered on BAGG 103.

If connection drops like 4-6 pings then definately it will impact the services during ISSU upgrade.

Please share below information to make sure if the issue is with switch or server:

1. Current softwae version

2. Please share 'display logbuffer reverse' output when you will shutdown one of the interface? The putput during that time frame only until get reply from ping.

3. What is the config on physical interface XGE1/1/2 & XGE2/1/2

4. Can oyu please check settings on server side as well, also update the server nic drivers.

Thanks!

[prodigy811]

Hi there,

APologies akg7 on the BAGG 103, we know there must be an sfp issue on the other end of that connection. Thats a different we know that needs fixing. But we had dropps when testing the other BAGG.

Here is the interface config;

interface Ten-GigabitEthernet1/1/2
port link-mode bridge
description Link to 
port link-type trunk
port trunk permit vlan 1 200 to 201 204 to 208 240 to 241 243 to 251 255 to 256 258 290 to 291 293 to 295 298
port trunk permit vlan 300 to 301 305 to 306 308 340 to 341 343 to 345 350 to 351 355 to 356 543 553 to 554
port link-aggregation group 102

interface Ten-GigabitEthernet2/1/2
port link-mode bridge
description Link to 
port link-type trunk
port trunk permit vlan 1 200 to 201 204 to 208 240 to 241 243 to 251 255 to 256 258 290 to 291 293 to 295 298
port trunk permit vlan 300 to 301 305 to 306 308 340 to 341 343 to 345 350 to 351 355 to 356 543 553 to 554
port link-aggregation group 102

Im assuming nothing particularly missing here; I cannot get rest of the info you asked for yet. However, I will ask about opposit connections but was already told they are in LACP

[prodigy811]

Current version; 655P01

[akg7]

Hello @prodigy811,

Interface config looks correct.

Are you facing this on both interface or only one?

Can you please bring down one interface again and share the 'display logbuffer reverse' from the device?

Also share device product number 'JXXXXX'?

Thanks!

[parnassus]

Hi!

But...out of curiosity...looking at the output of:

SW-1>dis link-aggregation ver bri 103

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected, I -- Individual
Port: A -- Auto port, M -- Management port, R -- Reference port
Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
        D -- Synchronization, E -- Collecting, F -- Distributing,
        G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation103
Creation Mode: Manual
Aggregation Mode: Dynamic
Loadsharing Type: Shar
Management VLANs: None
System ID: 0x8000, 4cae-a3b4-8add

Local:

  Port                Status   Priority Index    Oper-Key               Flag
  XGE1/1/3(R)         S        32768    10       4                      {ACDEF}
  XGE2/1/3            U        32768    21       4                      {ACG}

Remote:

  Actor               Priority Index    Oper-Key SystemID               Flag  
  XGE1/1/3            255      1        33       0xffff, 704c-a5e8-ccf6 {ACDEF}
  XGE2/1/3            32768    0        0        0x8000, 0000-0000-0000 {EF}

...the remote peer's MAC Address - 70:4c:a5:e8:cc:f6 - the IRF learned on its XGE1/1/3 physical interface looks the one of Fortinet (maybe a Firewall appliance?) vendor [1], if I'm not mistaken with the MAC Lookup.

Question: are you terminating your two ports BAG id 103 against a single standalone Firewall which is offering two ports set as LACP to the IRF (although here we saw that just one is synchronized on the IRF BAG id 103) or what else?

It's to understand if you're dealing with one or two firewalls (or just one switch instead), the particular case where peers are two (stacked) firewalls in a HA scenario would confirm that the BAG could not terminate against them (one leg on firewall 1 and the other leg on firewall 2, no matter if firewall 1 and 2 form a HA cluster). All other cases should be instead possible and could be diagnosed as usual.

[1] assuming your peer device isn't simply a Fortinet FortiSwitch.