*) improve SFP+ link establishment;
*) GPEN21: allow to select up-link port;
*) make IGMP snooping work with multiple VLANs;
*) stop forwarding multicast traffic on client unsubscribe;
*) do not show learned IGMP addresses under Hosts;
*) fixed ACL Set-VLAN-ID, DSCP and Priority fields;
*) make flow-control disabled by default;
*) CSS610: allow to configure both rx & tx flow-control;
*) SNMP: fixed ifSpeed & ifHighSpeed;
*) do not tag outgoing packets if their VLAN matches port Default-VLAN-ID and
port is in Optional VLAN mode;
*) port is now automatically its Default-VLAN-ID member;
*) make Port statistics more precise;
*) do not send Mikrotik neighbor discovery packets on ports that have it disabled;
*) fixed ACL to be able to drop any neighbor discovery packets;
*) report correct RSTP root path cost on LAG links;
*) make SwOS respond only to its own ip address even if MAC address is correct;
You can select an uplink port on the “Forwarding” page. This selected port can talk to the other two ports, while two non-uplink ports are isolated from each other.
Thanks bpwl, will try to fix this as soon as possible.
Can anybody confirm if this fixes the link issues with Intel SFP NIC’s? Currently on 2.13 release candidate for that to work as 2.13 final could not link.
SwOS Lite 2.14 acts as igmp querier using IGMPv3 when igmp-snooping is turned on. You can’t change the igmp version being used nor can you turn off the querier function.
What makes things worse, it sends out these igmp reports using 0.0.0.0, since it has no IP Address other than on the management vlan.
Because of the low ip address, it wins every querier election and ultimately breaks multicast, where a L3 device needs to be the querier for PIM / igmp-proxy to work correctly.
Please add the option to enable igmp-snooping together with no-querier and let users select on which vlans they want to use this feature including the igmp version.
Hi!
As already mentioned with Version 2.13 (see other post of mine: http://forum.mikrotik.com/t/swos-lite-version-2-13-released/147685/1 ) the problem with SNMP on the GPEN21 still persists.
The values for SFP RX Power and SFP TX Power are not given (even though listed in Mikrotiks MIB), but shown on the Web Interface.
~# snmpwalk -v2c -c public 192.168.88.1 1.3.6.1.4.1.14988.1.1.19
iso.3.6.1.4.1.14988.1.1.19.1.1.2.3 = STRING: "SFP1"
iso.3.6.1.4.1.14988.1.1.19.1.1.5.3 = Gauge32: 0
iso.3.6.1.4.1.14988.1.1.19.1.1.6.3 = Gauge32: 65408
iso.3.6.1.4.1.14988.1.1.19.1.1.7.3 = Gauge32: 0
iso.3.6.1.4.1.14988.1.1.19.1.1.8.3 = Gauge32: 0
iso.3.6.1.4.1.14988.1.1.19.1.1.8.3 = No more variables left in this MIB View (It is past the end of the MIB tree)
While digging around i found out that the raw values of the SFP are almost directly given to the web browser and all the calculation is done there.
This makes sense if the resources in the GPEN21 are extremly thin.
All calculations are quite simple … except the ones for the SFP RX and TX Power. Which are given in linear steps of 0.1 microwatts. To arrive to dBm a logarithm would have to be calculated.
For the web interface, this happens in the browser, for SNMP however it would have to be calculated directly by the GPEN21 - and i guess it does not have the resources to do so.
Can you confirm or dismiss my theory @Mikrotik?
and please add some kind of "safe mode" too.
Make it possible to first apply changes without saving them permanently.
If. the switch is still accessible after that, confirm changes to save them permanently.
If you make a mistake and can't access it anymore, power-cycle to restore previous config.
Optionally support a timeout after which config is reverted if not confirmed, for situations where power-cycle may be difficult to do (reverse-PoE).
The config file is small, I don't think there is not enough memory to implement such a feature.
SwOS Lite 2.14 acts as igmp querier using IGMPv3 when igmp-snooping is turned on. You can’t change the igmp version being used nor can you turn off the querier function.
What makes things worse, it sends out these igmp reports using 0.0.0.0, since it has no IP Address other than on the management vlan.
Because of the low ip address, it wins every querier election and ultimately breaks multicast, where a L3 device needs to be the querier for PIM / igmp-proxy to work correctly.
Please add the option to enable igmp-snooping together with no-querier and let users select on which vlans they want to use this feature including the igmp version.
There is no option to configure the IGMP querier version, we will see if this option can be added in the next release. Also, there is no option to disable the querier, but the switch will stop sending queries in case another querier is detected. As for the 0.0.0.0 querier address, this is a special case querier address that should not affect the querier election, the multicast routers and IGMP proxy should ignore such packets.
The values for SFP RX Power and SFP TX Power are not given (even though listed in Mikrotiks MIB), but shown on the Web Interface.
Thanks for sharing this, hope to include the Tx/Rx power values for SNMP in the next release.
As of release 2.14 GPEN21 and maybe others won’t auto negotiate correctly with certain generic lasers in them.
Thanks for reporting, please share the details about used SFP modules to support if not already.
This is not what I’ve observed here.
The packet is not ignored by ROS 6.48.3 / igmp-proxy, even if the bridge port the packet arrives on is set to multicast-router=disabled.
The moment you connect the CSS610 to the CCR or reboot the CSS, igmp-proxy receives the general membership query from 0.0.0.0 and immediately stops sending queries, and won’t recover by itself unless you disconnect the CSS again. It’s basically a race condition.
Still not sure if this is a SwOS and / or ROS issue. IMHO if there won’t be an option to disable the querier in future versions of SwOS Lite, at least the switch upon boot should wait 4m15s (default querier-interval) and listen if there’s already another querier on the network before sending a general membership query. The other option is to fix igmp-proxy, ignoring messages from 0.0.0.0.
Should I file a ticket about that?
With the many issues discovered in 2.14 (especially the regressions from 2.13), can we expect a 2.15 (with more bugs fixed, and no new ones added) soon?
On Link Tab there are new columns such as “Length”, “Fault at”, “Cable Pair”
How can we read Cable Pair property? Couldn’t find any explanation on the wiki.
I am asking because I have one remote CSS610-8G-2S+ which reports on ether8 Cable Pair: __oo
