*) l3hw - added support for IPv6 route offloading (disabled by default); I never thought I'd see the day; but here we are! Status on a CRS317 after enabling l3hw-ipv6 and running iperf3 between two IPv6 subnets: [SUM] 0.00-10.00 sec 10.7 GBytes 9.20 Gbits/sec receiver Great work, MikroTik!

7.2rc1 killed L2 connection on all my SFP+ fiber modules on a CRS317 to servers and switches. DAC cable works though. Downgrade to 7.1.1 resolved it.

Fixed in 7.1rc6.

I'm so sorry. The MAC src fix in the rc5 is for the DX2000/DX3000 switch chip series. However, CRS317 has a DX8216 chip. Currently, we are testing the fix for the DX8000 series. If you wish, we may send you a private firmware build with the fix included after the testing is done. So you won't have ...

The issue has been fixed. Now, L3HW uses bridge/vlan's MAC for the source address of routed packets. The fix will be included in the upcoming 7.1rc5. Hi again, @raimondsp. I've just tried 7.1rc5 which is supposed to include the following fix: *) l3hw - fixed source MAC address usage for routed pack...

The issue has been fixed. Now, L3HW uses bridge/vlan's MAC for the source address of routed packets.

The fix will be included in the upcoming 7.1rc5.

Awesome, that was extremely quick. Thanks a lot!

Hi, If a port is a bridge member, it should set the bridge's MAC as the source address in the routed packets. We will investigate the issue. Thanks for the feedback! Hi @raimondsp; I just reported the issue as SUP-63543. You can find the configuration and a supout.rif there in case you need it to r...

Hi, I have a CRS317 running 7.1rc4 configured with L3 hardware routing. I have noticed that the src_mac used on routed packets changes when the HW offloading setting is changed: with l3-hw-offloading= yes , the src_mac address used for routed traffic is the MAC for the outgoing, physical port on the...

1. IPv6 support for L3 HW Offloading is on the roadmap. Should be implemented later this year.

This is great news!

This level 3 offloading looks very interesting. Do we have any numbers to show what it can mean as this has the potential to put emphasis on the R in CRS :-) I have no problem pushing ~9.3Gbit/s IPv4 in a single thread using iperf3 between two hosts routed on the CRS317 with L3 offloading enabled. ...

Resolved in RouterOS v7.1beta2.

I'm happy to report that this issue has been resolved in RouterOS v7.1beta2!

I'm happy to test configuration changes, devel builds, whatever it takes to get IPv6 working with BGP. Right now my CCR2004 is just sitting there with nothing to do.

ROS v7.1beta1 still have trouble with IPv6 BGP as described here: viewtopic.php?f=1&t=162424&p=800209

Version: 7.0beta8 Model: CCR2004 Neighbor device: Edgerouter 2.0.9beta3 IPv6 routes learned from BGP always ends up unreachable as illustrated below. The same setup works fine with 6.47. Ib afi=ip6 contribution=unreachable dst-address=::/0 gateway=:: distance=200 scope=40 target-scope=10 belongs-to=...

Version: 7.0beta8 Model: CRS317 After upgrading from 6.47 to 7.0beta8 on my CRS317, I noticed a large (10-20%) packet loss at times on my home network. After some debugging, I narrowed it down to a bond/port-channel between a Cisco SG500X-48 and a Mikrotik CRS317. It seems like something changed bet...

Hello, setting mode "balance-xor" on a bond triggers a kernel oops in 7.0beta8. On subsequent boots, the oops is triggered again causing the switch to halt before the boot process is completed. After I removed the SFP+ modules for the slave interfaces, I was able to boot the system again a...