Dude, if this is the case…Then that sort of information should be indicated in the downloads page… As it is:
It doesn’t say anything…and it should.
End of story…
Good news, I managed to install a working version of v7RC3 on my 4011. After some problems it worked till the Address-list went berserk. This is an old problem, of not obeying the TTL.
V6 obeys an external TTL in of 30 seconds and it counts from 30 to 27 and then it renews. In v7 the TTL displayed in cache as 0 and renews…renews…renews that fast that after a few minutes the Unbound server slows down to a crawl and is going to get the knit-work out and knits a nice pullover. After a few restarts I had enough pullovers piled up and reverted to 6.48.4. There I had with the same config the problem that IP address was not working and I had to connect trough MAC/RoMON.
After restoring the back for 6.48.4 all was right again
I really hope Mikrotik will add minimal TTL to the DNS client and that address-list will obey that minimale TTL…I am waiting already years for that.
Does HW accelerated IPSec suppose to work on 7.1rc3 / Intel CHR combo? When I upgraded from 6.48 I lost HW acceleration flag for aes-256-gcm tunnels that were offloaded before…
How did you have hardware offload on CHR? It is virtual - there is nothing to offload to. Probably the HW acceleration flag (if you had it) was a bug in the older version and was not true.
It is virtual - there is nothing to offload to
This statement is just incorrect. I’m afraid you are not quite familiar how virtualization and HW offload works…CHRs support HW offload for IPSec via Intel AES-NI, so as long as you’re using the right ciphers and have proper instructions passed through to the VMs, it just works.
Here is the list of HW acceleration capabilities=: IPsec - RouterOS - MikroTik Documentation , - x86 with AES/NI. AES-GCM mode is fully offloaded on AES-NI hardware not just on Mikrotik but on most systems.
When it’s is working properly and HE flag is displayed, CPU usage is 5x lower, so super easy to reproduce.
Interesting - thanks for that explanation. I figured it would be the same thing as fastpath and hardware offload in bridging. I run CHR’s but do not do IPsec on any of them. I never realized that the CHR could do hardware offloaded IPsec in a virtualized environment. It is something special for just IPsec then and not applicable to other offloading mechanisms?
Hardware accelerated bridging means that a switch chip forwards the frames directly, without the CPU even knowing about their existence. There are typically no switch chips on the hosts where CHRs are running, so the virtualization software has no API to hand over control of the switch chip to a VM.
Hardware accelerated IPsec means that the CPU can encrypt a chunk of data using a single instruction, with the help of a dedicated hardware block, rather than using a loop of more elementary instructions and the common registers, so it’s not so complex to give the VMs access to this instruction.
Fasttracking is somewhere in the middle, as it consists in bypassing a lot of CPU processing by simplifying the path of the packet from the in-interface to the out-interface, so even on a CHR, it could speed up processing of some packets by mere exclusion of most firewall processing from that path. But for some reason it is not implemented and each packet takes the full path.