SwOS Lite version 2.13 released
http://www.mikrotik.com/download

What's new in v2.13:

*) properly report SFP port speed;
*) make SFP port work in forced 1G speed mode;
*) make fiber optic modules work with auto-negotiation (1000BaseX);
*) fixed management access over SFP ports;
*) CSS610: report temperature under System tab;
*) fixed problem where logout blocked new logins for 5min;
*) correctly forward snooped DHCP & PPPoE packets;
*) accept only VLAN tagged packets if Allow-VLAN was specified;
*) for ports with vlan-receive=any mode send out vlan packets with
default vlan id as untagged;
*) make Allow-From work;
*) fixed ACL rule ip source & destination network matching;
*) make ACL not match DSCP=0 by default if no value was specified;
*) fixed SNMP GetBulk;
*) make SNMP sysUpTimeInstance to not overflow in 5min;
*) correctly report extended SNMP info about SFP ports;
*) fixed LAG linking and monitoring;
*) make LAG use L2 hash based load balancing;

I am still seeing issues on 2.13 released firmware when using direct attach SFP28 cables (both 1m long and 3m long purchased from FS.com) when connecting from my CSS610-8G-2S+IN SFP+ ports to Intel XXV710 based 25Gb NICs. I have commented about this in a thread here which also was discussing Intel 500 series NICs where a similar problem was occurring: viewtopic.php?f=17&t=172697

The 2.13rc12 firmware works correctly for me with my Intel XXV710 NICs. The 2.13 released firmware does not work correctly. The switch sees the link as being up but the Intel cards see the link as being down.

*) CSS610: report temperature under System tab;

...not true for the CSS610-8G-2S+IN or what am I missing on mine, running SwOSLite v2.13?

Where can we get information regarding SwOS Lite?

The information about CSS610 series switches and SwOS Lite is available here:
https://wiki.mikrotik.com/wiki/SwOS/CSS610

*) CSS610: report temperature under System tab;

...not true for the CSS610-8G-2S+IN or what am I missing on mine, running SwOSLite v2.13?

Sorry, the changelog entry should have been more specific. It applies only to the CSS610-1Gi-7R-2S+ "netPower Lite 7R".

*) fixed management access over SFP ports;

So is this the needed fix for the GPEN21 to behave more as a "3-port switch" (all ethernet ports and SFP bridged together), like everyone had expected?

Would be great, as I could remove an additional media converter.

There is still problems with GPEN21 device. I have a standard configuration with GPEN21.
I want to use SFP1 port as Uplink and Port 2 for POE IP Camera, Port 1 is unplugged.
With this simple setup I don't get access from SFP1 to Port 2, seems that those two ports are not actually switched.
If Port 1 are connected, then I have access to Port 2 aswell.
I want to use GPEN21 device as manageble fiber-to-copper converter with POE-out functionnality, currently it's not work this way.

I think everyone expected this to be like a 3 port switch, I wish Mikrotik can respond to confirm if this can be changed in software or if the current behavior is limited by Hardware

I still cannot setup storm control, Ingress and Egress rate. For example when I set 10% under Forwarding and press "Apply all" my 10% is gone.

Also I have issues whit SNMP. I tried to add it to my local Zabbix server, as result CSS610 started to randomly reboot.

I am having problems with LAG and DHCP.

I have a pfsense router that I would like to connect my CS610 with 2 port LAG.

If my dhcp server is connected via LAG, I can't get any client (including the mikrotik switch) to receive DHCP address. Anyone else seeing this issue?

I am having problems with LAG and DHCP.

I have a pfsense router that I would like to connect my CS610 with 2 port LAG.

If my dhcp server is connected via LAG, I can't get any client (including the mikrotik switch) to receive DHCP address. Anyone else seeing this issue?

Try disabling "Add Information Option" under "DHCP & PPPoE Snooping" section in System.

connecting from my CSS610-8G-2S+IN SFP+ ports to Intel XXV710 based 25Gb NICs.

Same here, except a CSS610-8G-2S+IN SFP+ ports to Intel x520 card with Intel E10GSFPSR optics or FS DAC.
SwOS v2.13
Switch reports 10g link, card says no.
Forcing 1g at both ends gets link up.
Swapping switch side optics for an FS.com 1g SFP delivers a 1g auto-negotiated connection.
Swapping x520 card for a Cisco switch (with appropriate settings) auto-negotiates a seemingly working 10g connection.

SwOS v2.13rc12
Does deliver an auto-negotiated 10g connection, but then I get bitten with the no-DHCP/data bug so it's just as useless.

Mellanox Connect-X 3 card currently in-transit for more testing.

I've also noted that each time the switch boots, it grabs a different IP address from my DHCP server (Ubuntu + ISC DHCP Server 4.3.5) - presumably because it's still insisting on hanging onto & responding to the old address which my DHCP pings before assigning to be sure the addy is available.
Logs from a quick reboot this morning.

Mar 21 06:05:01 dhcpd: DHCPDISCOVER from 08:55:31:a0:5d:51 (MikroTik) via ens33
Mar 21 06:05:01 dhcpd: ICMP Echo reply while lease 192.168.100.33 valid.
Mar 21 06:05:01 dhcpd: Abandoning IP address 192.168.100.33: pinged before offer
Mar 21 06:05:02 dhcpd: DHCPDISCOVER from 08:55:31:a0:5d:51 via ens33
Mar 21 06:05:03 dhcpd: DHCPOFFER on 192.168.100.42 to 08:55:31:a0:5d:51 (MikroTik) via ens33
Mar 21 06:05:04 dhcpd: DHCPDISCOVER from 08:55:31:a0:5d:51 (MikroTik) via ens33
Mar 21 06:05:04 dhcpd: DHCPOFFER on 192.168.100.42 to 08:55:31:a0:5d:51 (MikroTik) via ens33
Mar 21 06:05:04 dhcpd: DHCPREQUEST for 192.168.100.42 (192.168.13.3) from 08:55:31:a0:5d:51 (MikroTik) via ens33
Mar 21 06:05:04 dhcpd: DHCPACK on 192.168.100.42 to 08:55:31:a0:5d:51 (MikroTik) via ens33

I am having problems with LAG and DHCP.

I have a pfsense router that I would like to connect my CS610 with 2 port LAG.

If my dhcp server is connected via LAG, I can't get any client (including the mikrotik switch) to receive DHCP address. Anyone else seeing this issue?

Try disabling "Add Information Option" under "DHCP & PPPoE Snooping" section in System.

Disabling did help other clients get dhcp, but the switch itself is still not getting dhcp.

@maigonis - use bits per second for storm control settings, the "K", "M", "G" postfixes are supported, for example - 10M. And please report the SNMP reboot issue to support.
@mikronerd - I was not able to repeat the DHCP issue with LAG, could you report this to support?

@maigonis - use bits per second for storm control settings, the "K", "M", "G" postfixes are supported, for example - 10M. And please report the SNMP reboot issue to support.
@mikronerd - I was not able to repeat the DHCP issue with LAG, could you report this to support?

Thanks EdPa, I reported that to support.

Another issue in 2.13, is the SFP port speed. Although the update claims that the correct speed is reported, that is not the case. I am connecting to a 2.5 gbps AP through SFP port, but link is reported as 10G. The link is reported correctly on the AP side.

I got my switch yesterday.

Unable to get 10G link working switch to switch the other switch I am using is CRS326-24G-2S+

If I disable auto-negotiation both sides and set the speed to 1G the link comes up on 1Gbps Speed.

Also There is no option to set the speed to 10Gbps after disabling auto-negotiation.

I got my switch yesterday.

Unable to get 10G link working switch to switch the other switch I am using is CRS326-24G-2S+

Are you sure that you are running yours on SwOS 2.13lite or SwOS2.13rc25
Because I can not confirm that behaviour...my CSS610-8G-2S+ is doing fine, linked to a CRS326 -24G-2S+ (running latest ROS long-term) via a S+RJ10 on each side, even over cat5e cable (approx 18m) and at full 10G speed.

Are you sure that you are running yours on SwOS 2.13lite or SwOS2.13rc25
Because I can not confirm that behaviour...my CSS610-8G-2S+ is doing fine, linked to a CRS326 -24G-2S+ (running latest ROS long-term) via a S+RJ10 on each side, even over cat5e cable (approx 18m) and at full 10G speed.

I am running SwOS 2.13lite and on CRS326 -24G-2S+ its 6.47.9 (RouterOS long-term), but I am using this.

I haven't been able to get my CSS610-8G-2S+IN to work yet with the SFP+ cages. I got it with a Cisco Active DAC H10GB-ACU10M (10M Active DAC cable) and a Passive DAC H10GB-ACU3M (3M Passive DAC Cable). Only the Passive DAC cable worked. So I spent the money on fs.com transceivers and multi-mode fiber. Low and behold, the mikrotik doesn't detect them either (SFP-10GSR-85). Link page with the 3M cable shows a 10G link. SFP tab shows no information at all for SFP1 or SFP2. With the 10M DAC, and any of the fiber SFP's, Link page shows no link (setting negotiation doesn't do any good), and the SFP still shows no information for SFP1 or SFP2. Same result on SwOS 2.12 or 2.13. I kind of expected this thing would work with more than a 3 meter cable....

Same here, except a CSS610-8G-2S+IN SFP+ ports to Intel x520 card with Intel E10GSFPSR optics or FS DAC.

Update
After a couple of days, 1g autoneg between my x520 and the CSS610 stopped sorting out a connection. Had to force the card to 1g to get it linking again.

Mellanox Connect-X 3 card arrived. Same test platform, same OS, same fibre, same Intel optics (or the same FS.com DAC) = immediate 10g auto negotiated link.

Running Dude 6.47 right now. SNMP can walk the 7R and 610, but interface cannot be selected in link (says Unknown) on SNMP.

Any fix for this?

Does the latest/later Dude version handle this ok?

Can anyone confirm for me?

On the CSS610-7R on 2.13, the Egress rate appears to work correctly within about ~20M. But the Ingress rate, limits to <1M no matter what setting I use.

Currently facing multiple issue still with the NetPower Lite 7R units running latestSwOS Lite 2.13 within our network.

1- Still able to access and manage device via GUI on any port although "Allow From Ports" only has ports 7 and 8 marked as enabled.
2- Unable to consistently access GUI for device through some of the management ports, it's a hit and miss, sometimes it works sometimes it doesn't. (Not a browser issue and happens from different computers, networks).
3- Device randomly shows Faults on all network interfaces to which we have devices connected to (TPLink WR850N units), cables are in perfect conditions and pass standard testing with Fluke.
4- Connection passing through switch for some ports randomly stops working, reboot required on NetPower Lite 7R in order to restore service for connected clients.

We were in the process of purchasing 15 more of these units, but we have asked the sale not to be completed until we can be certain that we have fully functional units.

1. Do you have any VLANs set up? Separate VLANs for customers and management are good practice. Or are you saying that you use VLANs, but they still don't protect the management VLAN from access by non-member ports?

4. Reboot is especially difficult in reverse-PoE switches, when getting redundant power from several customers. Recent experience - tried to ask just 3 customers to turn off their PoE at the same time to reboot the reverse-PoE switch (in this case, Omnitik modified by adding diodes). What I got instead was each of them powered off their own home router, but not the PoE adapter - all ethernet links went down but the Omnitik was still up (so I could still see all link event in the logs). The result was an unnecessary and expensive replacement of a radio that was powered from that Omnitik, was not damaged but just needed a reboot (that didn't happen, but customers told me it did). This needs some solution that can be done from one port only (visit to just one customer). Like a short sequence of power down/up events, since the hardware can detect it (there are checkboxes "disable ethernet link when no power on this port").

Regarding ingress and egress rate limiting. The traffic policer is used for ingress rate and shaper is used for egress rate. The ingress policer controls the received traffic with packet drops. Everything that exceeds the defined limit will get dropped. This can affect the TCP congestion control on the end hosts and achieved throughput can be actually less than defined. The egress shaper tries to queue packets that exceed the limit instead of dropping them right away. Eventually, it will also drop packets when the output queue gets full, however, it should allow utilizing the defined throughput better.

1 - I did not manage to repeat the issues with the "Allow From Ports". Can you report this to support and share the details?
2, 4 - Please report this to support.
3 - What errors did you get? In case of "Tx Pauses", you can disable the "Flow Control" on the Link page.

The 2.13rc12 firmware works correctly for me with my Intel XXV710 NICs. The 2.13 released firmware does not work correctly. The switch sees the link as being up but the Intel cards see the link as being down.

I am seeing the same thing. The released version is not working with Intel X520-DA1 NIC - had to downgrade to 2.13rc12.

Regarding ingress and egress rate limiting. The traffic policer is used for ingress rate and shaper is used for egress rate. The ingress policer controls the received traffic with packet drops. Everything that exceeds the defined limit will get dropped. This can affect the TCP congestion control on the end hosts and achieved throughput can be actually less than defined. The egress shaper tries to queue packets that exceed the limit instead of dropping them right away. Eventually, it will also drop packets when the output queue gets full, however, it should allow utilizing the defined throughput better.

It means that ingress/egress rates works or not?

For example, when I set 50M/50M and do speedtest via web I get download about 48 Mbit/s (correct) and about 0,3 Mbit/s upload. Sic!
When I'll set 200M upload, I'm getting about 30-40 Mbit/s (100 Mbit/s NIC). No chance to deduction what's going on. What is this feature for?

For me rates on exactly this device/point of the network and VLANs (look next) are crucial. I was very disappointment when I got to work with SwOS instead of RouterOS on which my all network stands.

There is also something about VLANs here, that I don't understand or something else is wrong. On RouterOS when I set PVID on some switch port (e.g. CRS354...) and want to communicate with some other interface with this tag outside the switch, I will not being able to see nothing else on layer 2 except the same ID tagged port/NIC. Here on CSS610 I can see some other hosts by mac discovering in Winbox! And it's not the same as if it wasn't there VLANs at all, when it's showing up fast and everything on bridge. It's showing up slowly and starting after 1-3 seconds. Next difference (comparing to no VLANs) only about 20% of my devices are showing up in Winbox. After some longer time there is more and more, maybe all, don't know. Fortunately I can't connect with them, but I was never experiencing this in RouterOS managed switches. If there is some function which I omitted to cut off mac/discovery/whatever/L2 packets from my rest no VLANed network on SwOS, then probably doesn't work, because I think I've tried everything to rid of this visibility something else than specific VLAN as PVID on the port. It can be described as a leak from default VLAN 1 to created VLAN ID (on connected to PVID port device).

Of course, on every devices on the way to termination of this VLAN ID in bridge "VLAN filtering" is on and VLAN ID are added as tagged VLAN ID.

Best Regards
Luke

I'm using LibreNMS to monitor the CSS610 and the device hasn't rebooted yet.

I made the same observation. Also got my CSS610 yesterday, and noticed that my Devices didn't get an IP address today morning, worked fine yesterday.
I'm using DHCP Snooping on all devices between the DHCP server and the CSS and all Ports inbetween are set as trusted.
I disabled "Add Information Option", and this was the solution in my case.

The problem on GPEN21 with SNMP not giving SFP TX Power and RX Power is still not solved.
Previously there was an error where the output of SNMPWALK just stopped mid-character.
Now we get this error with the new Version 2.13 on output. On the webinterface the values are displayed correctly.
We would hope this will be fixed, since its the only reason we don't use this device.

Best regards

Edit: The MIB file specifies SNMPv2-SMI::enterprises.14988.1.1.19.1.1.9 and SNMPv2-SMI::enterprises.14988.1.1.19.1.1.10 for TX and RX power, but the paths are not available.

Just to leave this here for anyone that may be reading the thread in the future, my issue was not solved even with 2.14 firmware. After finally getting an accepted RMA, the new switch came (still running 2.12 just like my first switch) and immediately worked with both my active and passive DAC cables as well as 8 different types and brands of fiber SFP+ modules. Upgrading to 2.14 fixed the management over SFP+ issue and added functioning chassis temperature. So the issue wasn't firmware at all, it was just a semi-functioning switch. Enough that the RMA dragged out from April until now.

I think this topic probably should have been closed since 2.14 is out now?

Indeed, SwOS Lite version 2.14 topic is here: viewtopic.php?f=21&t=175736