Interesting device: Our review of the MikroTik CRS226-24G-2S+RM a 1U rackmount 24 port gigabit switch with dual 10 gigabit Ethernet SFP+ ports and a slick management interface.
Since G+ is very bad at searching, I created this summary of the tools; read the full G+ post (Google Translate is quite OK), including comments on why.
Edit: 20160402 – I’m posting regular updates based on the comments for that G+ post. I’ve changed or added German iTunes store links to US-English ones.
In the future, I need to add my own experience as well. For now some links:
Short stroking is the process by which the capacity of a volume is reduced in order to improve drive performance. There are benefits to short stroking any mechanical disk, regardless of whether the drives are used in any type of RAID array.via Short-Stroke: Why, and how….
TL;DR: People use VPNs for security, Netflix fucks them up, they hate Netflix for that and just torrent that shit.
tl;dr If you have issues with Netflix on public Wifi, contact the provider and forward tr@netflix.com to them so they can settle issues.
I’m not a netflix user (or user of any form of DRM) as I really dislike the fact that DRM means for any reason your license can be ended. I’ve seen too many players going out of business or taking decisions turning.
So I buy CDs, DVDs, BlueRays or DRM-free media files. Now it’s my problem of making proper back-ups to ensure future access to them (:
The DRM walls and ladders war^w game has gone so far that in this case, Netflix is blocking even though the WiFi provider / proxy / VPN is in the same country like the below imgur image:
20150412 ping statistics from WiFi -> ADSL -> VPN -> fiber (where ADSL and fiber both are Fritz!Box machines having LAN-LAN VPN to each other):
PING 192.168.71.1 (192.168.71.1): 56 data bytes
64 bytes from 192.168.71.1: icmp_seq=0 ttl=63 time=19.190 ms
...64 bytes from 192.168.71.1: icmp_seq=1 ttl=63 time=18.905 ms
64 bytes from 192.168.71.1: icmp_seq=2 ttl=63 time=19.261 ms
64 bytes from 192.168.71.1: icmp_seq=3 ttl=63 time=19.982 ms
64 bytes from 192.168.71.1: icmp_seq=4 ttl=63 time=19.332 ms
64 bytes from 192.168.71.1: icmp_seq=5 ttl=63 time=26.800 ms
64 bytes from 192.168.71.1: icmp_seq=6 ttl=63 time=20.139 ms
64 bytes from 192.168.71.1: icmp_seq=7 ttl=63 time=19.498 ms
64 bytes from 192.168.71.1: icmp_seq=8 ttl=63 time=18.915 ms
64 bytes from 192.168.71.1: icmp_seq=9 ttl=63 time=19.200 ms
64 bytes from 192.168.71.1: icmp_seq=10 ttl=63 time=18.948 ms
64 bytes from 192.168.71.1: icmp_seq=11 ttl=63 time=19.524 ms
64 bytes from 192.168.71.1: icmp_seq=12 ttl=63 time=19.511 ms
64 bytes from 192.168.71.1: icmp_seq=13 ttl=63 time=20.417 ms
64 bytes from 192.168.71.1: icmp_seq=14 ttl=63 time=19.350 ms
64 bytes from 192.168.71.1: icmp_seq=15 ttl=63 time=18.690 ms
64 bytes from 192.168.71.1: icmp_seq=16 ttl=63 time=18.632 ms
64 bytes from 192.168.71.1: icmp_seq=17 ttl=63 time=18.912 ms
64 bytes from 192.168.71.1: icmp_seq=18 ttl=63 time=19.397 ms
64 bytes from 192.168.71.1: icmp_seq=19 ttl=63 time=19.257 ms
64 bytes from 192.168.71.1: icmp_seq=20 ttl=63 time=18.147 ms
64 bytes from 192.168.71.1: icmp_seq=21 ttl=63 time=18.601 ms
^C
--- 192.168.71.1 ping statistics ---
22 packets transmitted, 22 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.147/19.573/26.800/1.657 ms
same but LAN –> fiber -> VPN -> ADSL
Pinging 192.168.24.1 with 32 bytes of data:
Reply from 192.168.24.1: bytes=32 time=19ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Ping statistics for 192.168.24.1:
Packets: Sent = 24, Received = 24, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 19ms, Average = 17ms
Mikrotik have statistics and way more features. The most lacking or disturbing features on the TP-LINK (none of which are mentioned in their documentation):
Balanced Routing work when you perform these steps as mentioned at time point 457 in this video https://youtu.be/YDUfP8a5zNY
Enable Application Optimized Routing
Enable Bandwidth Based Balance Routing
Virtual-Server table can only handle 32 incoming port redirects; you get the message “Cannot add more than 32 Virtual Server entries” like in the picture below.
No IPv6 support
No way to show any statistics as graphs.
Every once in a while the web interface becomes really really slow which only a reboot can resolve.
You cannot have one of the WAN connections have multiple IP addresses.
You cannot configure how often to check WAN connections
On the other hand: when you do balanced routing indeed bundles all the WAN connections, configured Virtual Servers do work well and WAN specific routing settings to what they need to.