Cool, thanks! I'll use this feature.There is the option:src-address-type (unicast | local | broadcast | multicast; Default: )
local - if address is assigned to one of router's interfaces
Yes, exactly.Is this the ping time between the monitoring system and the bras?
I have turned off connection tracking for most connections (using raw table), so it won't be efficient in my case.Fasttracking that traffic you want to be excluded from queues is much more efficient.
But keep the exclusion queue for the cases when some connections couldn't be fasttracked.
"real operator class router" costs 10-20 times more. For me, CCR delivers good enough performance. Especially considering it's cost.Lol. You didn't see any real operator class router if you are willing to name this board like that.
I've heard that x86_64 code is a bit faster. More processor registers are available, for example.I am satisfied with the 32 bit version. Why would you need a different one ? Thanks.
If I understand correctly, multicast-helper works only for point-to-point radio links. Udpxy can help if there is a standard home WiFi network with multiple client devices.well, now (v6, AFAIR) ROS can send mutlicast paskets as unicast frames, so udpxy is not actual just for wifi
3 2001:5a0:2800::e (2001:5a0:2800::e) 77.652 ms 77.582 ms 77.526 ms 4 ffm-b10-link.telia.net (2001:2000:3080:30c::1) 79.093 ms 79.060 ms 77.255 ms 5 s-b3-v6.telia.net (2001:2000:3018:9::1) 100.877 ms 99.454 ms 106.812 ms 6 * * * 7 * * *
30 seconds would be fine for me. This timeout is only needed for peak loads when 1000 users reconnect simultaneously after router reboot.typical user is only willing to wait 'several seconds'