It would help a lot to have the RADIUS service local to that location. Apparently you are using the MikroTik as a local access concentrator for several customers that then use the same satellite link. I would say your network could be redesigned so that the RADIUS requests do not have to go over the satellite.

We have fixed this issue successfully by increasing the timeout on our routers to 6000ms but you have removed this repair from us by limiting this setting. We really need this change reverted, or at least a more reasonable maximum of 5000 or 6000ms used.

3000 ms is just not enough when you start taking satellite setups like ours into account. We are already doing queueing everywhere to prioritize the RADIUS and SNMP requests. Suggesting that we make 'network improvements' to fix this is basically asking us to move the satellite in orbit closer to the planet, or make the speed of light faster. This entire process cannot happen in 3000 ms total from the opening authentication, when the basic authentication already uses 2000ms, and where each one way satellite transit thereafter takes 300-400 ms due to the limitation of the speed of light. If the RADIUS server thinks the customer is already logged in, it contacts the MikroTik with SNMP to find out if there is actually an interface named, this contact begins to happen at around the 2000 ms mark.Īt this point, the RADIUS server has to send the SNMP request over satellite, receive the SNMP response over satellite, parse the list to determine whether the customer is logged in or not, and send the Access-Accept or Access-Reject reply back to the MikroTik. This part is fine with your new limit, but the next part is not: The initial RADIUS request from the satellite site takes 300-400 ms to get to the radius server due to limitations of the speed of light, then it has to look up the customer etc, probably half a second or second later it sends a reply which takes another 300-400ms to get back to the satellite site (again due to the limitations of the speed of light). Here is the precise justification for why 3000 ms is not enough with all attainable 'network improvements' implemented: We cannot do 'network improvements' to fix this. We are dealing with bi-directional satellite so we have 600ms latency just to get up into orbit and back again with a ping, and we are dealing with very limited bandwidth. You are saying this is a coincidence? It seems really hard to believe given how many times it failed before making the change (several hours) and how immediately the change corrected the issue (after hours of trying to connect every minute and failing, the first connection after the change (30 seconds later) was successful). We have had it happen several times (in a particular scenario documented further below) where we had the timeout at first set to 3000 ms and the customer could not connect (due to the unusually high latency for bidirectional satellite Internet), but immediately after increasing the timeout, the customer connected successfully (after repeated automated connection attempts up until the instant of change). If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.Īnyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Update: Contacted support and MT is already aware of the issue. I hope you fellas are able to solve this on your own because I will not be able to test this again as the switch will be in live production this week.

Sorry if my feedback isn't as clear as can be. So I'm simply reporting that sfp+ DEFINITELY have some hw offload issues or some other sort of issues. Simply reverting to 6.40.5 gave me good stable expected rates. it finally hit me it could be the 6.41 bridge implementation. So it's just iscsi where transfer rates are quite quirky.Īfter a lot of testing, trying to figure out where the point of issue is - ixgbe driver, iscsi initiator/target, etc etc. I tested samba transfers on the sfp+, and speeds appear quick. Rates are stable on the gigabit ports (80MB/sec). I have a 10gbit nic (also first time) connected directly to the CRS326 and couldn't figure out why iscsi rates to a single client in my test environment were unstable 10-40MB/sec, at times less than 10MB/sec, FAR slower than gigabit nic. I'm tasting my first time experience on 10gbit sfp+ on CRS326.

2018 free strongest best ip booter