Packet lost between two switch which are in IRF stack

[adam900331]

Hello!

I have two HPE 1950 switch which are configuring in IRF stack(switch1 and switch2). We also have two server(Server1 and Server2) in cluster which connected to this IRF stack. We use virtualization. There are two VM, VM1 on Server1, VM2 on Server2. Once a day we noticed that there are some packet lost between two VM. We could ping from VM1 to VM2 and vice versa and the acket lost is about 10-20%. We checked it between two standalone PC (PC1 connected to switch1, PC2 connected to switch2) and there are packet lost too. When we connected the PC1 and PC2 to one switch, like switch1, there aren't packet lost.

We already upgrade the latest firmware of the IRF stack. We already change the DAC cable between two switch. Is this issue a configuration issue? The problem is being about two weeks, because there was a power outage two weeks ago. Could cause this network problem an unexpected power outage? Where can I check the log between the two switch (IRF stack)?

Thanks.

[akg7]

Hello @adam900331 ,

Can you share the network conenctivity diagram with servers?

Is there any bridge aggregation configured?

What is the teaming/bonding status on servers?

You can check logs from Log-->System Log

Thanks!

[Ihaqueit]

Excessive Broadcasts in a situation with disabled STP and loop protection almost certainly means you actually have a loop somewhere in your network. My first suggestion would be to read up on STP and loop-protection, and to enable both. Set your switch in the 'core' network as your root bridge (spanning-tree priority 0) and make sure all other switches run it too.

STP prevents L2 loops between your switches and is very easy to configure unless you are fine-tuning settings on a large multi-vlan network. See for example https://community.spiceworks.com/how_to/43285-how-to-set-up-stp-on-hp-switches or the official docs your switches for more details.

Loop-protect prevents loops on ports connected to clients and should be used on client ports, since STP is not intended to prevent loops on the client side. Once you have enabled it, check the switch log ('show log') to see which ports, if any, have a loop. See also https://support.hpe.com/hpsc/doc/public/display?docId=c03398959

These protocols don't usually have bugs in their basic functionality, and if loop-protect started disabling your access ports, that's a pretty good sign you actually have a loop, or several, in your network.

Hope that helps.