Netonix Forums

When committing a change to a switch will the switch drop packets as the commit takes place?

It would be possible to drop packets depending on the nature of the configuration change.

Now if your talking about pings "to the switch" or rather the UI/CLI so to say and not packets the switch is forwarding that could be more common as the small embedded MIPS 24K CPU that is responsible for running the UI/CLI and stats may get over loaded for a moment and not respond to ICMP as it is too busy.

As far as packets the switch is forwarding that would depend on the nature of the configuration change being applied.

There was a commit change to QoS of a separate interface and we dropped packets to the switch and all the backhauls connected to the switch saw the identical packet loss during the change. We are using a WS-24-400A switch running version 1.4.6 firmware.

What changes would you expect to see that would defiantly cause high latency?

Yes I would imagine that changes to QOS could impact the switch for a moment as it sets up the the Ques, how many packets did you drop?

Changing your QOS settings is not something that you should do very often.

I know that when I apply config changes to my $5,000.00 Cisco routers they too drop packets depending on the nature of the configuration changes being applied.

I work with Daniel and thought I would chime in.

We are seeing about 3-5 seconds of a complete loss of all traffic to and from the switch and all of it's ports during a commit via the web GUI. Even when updating an Ethernet ports speed/duplex settings. This behavior seems to be a bit odd and the purpose of Daniels post is to find out if others experience this or not. We are going to test with other Netonix switches on various firmwares to see if they all behave the same.

If this is a normal behavior of the switch, it will obviously limit when we can make any changes in them to after hours. This is of course a trade-off for the many benefits that the Netonix switches provide.

Is this normal? Has anyone else had this issue?

Thanks in advance,
Keith

SYS7EM-Keith wrote:We are seeing about 3-5 seconds of a complete loss of all traffic to and from the switch and all of it's ports during a commit via the web GUI. Even when updating an Ethernet ports speed/duplex settings.

When changing the speed duplex of a port that port will disconnect for a couple seconds to re-negotiate but that would not affect any other port unless traffic was flowing through the changed port to another port then of course that traffic would stop during the re-negotiation.

The only way you will possibly see switch wide interruptions is a major VLAN change, QOS or other things of that nature.

Now if your running higher level routing protocols through a switch such as I do where say port 3 powers an AF24 and port 5 goes to a router and the router is running OSPF and I make a change to setting on port 3 or 5 then the adjacency would go down and traffic would be interrupted until the router adjacency came back up and traffic resumed.

But changing settings such as POE, or Speed/Duplex on one port has no effect on another port unless traffic from the changed port is passing through to another port.

Making VLAN changes on ports that are not in another VLAN would not affect those other port unless the VLANs share ports that are changed in the VLAN matrix.

I made the change on a port facing a client in the building, not the uplink port. Since we are seeing this issue, do you think we have a bad switch?

Anything is possible but I highly doubt it, switch cores generally either work or fail.

You are always welcome to RMA it for us to evaluate.

you could try a factory default then manually set back up, a corrupted config can cause weird issues.

We will give that a try and let you know. Thanks!