Buenas @fealdea
Bueno, realmente existen muchos parámetros que pueden limitar la concurrencia de conexiones, algunas limitan en algunos aspectos, otros limitan en otros, y todos ellos afectan al final al número de conexiones simultáneas, dependiendo de que límite se alcance antes. Por desgracia el número de conexiones en cualquier parámetros que miremos viene muy definido y de la mano de la RAM que disponga el sistema, y en el caso del ASKEY, por algún motivo que algún día me gustaría conoce, cuenta "solo" con 128, mientras que el Mitrastar lleva 256.
Si mirásemos sólo la cantidad de conexiones que el Kernel puede mantener en seguimiento, las conexiones que puede mantener la tabla NAT:
# cat /sys/module/nf_conntrack/parameters/hashsize
1579
# cat /proc/sys/net/netfilter/nf_conntrack_buckets
2048
# cat /proc/sys/net/netfilter/nf_conntrack_max
6316
Los datos son más o menos los esperables en un sistema de 128MB. Por defecto deberían de ser unas 8192, pero por lo que se ve se quiere reservar algo más de memoria.
Es decir, si miramos sólo el número de conexiones que el kernel puede seguir, son 6316. Este valor es muy relativo también, porque la propia tabla mantiene o elimina de forma forzada las conexiones seguidas en función de otros parámetros:
# cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait
60
# cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close
10
# cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
120
Es decir, que el propio kernel va liberando conexiones incluso de forma forzada si los timeout se van cumpliendo, al margen de que la tabla pueda contener más o menos entradas.
De forma similar, es el número máximo de conexiones que podrían realizarse por segundo a tenor de la cantidad de puertos disponibles:
# cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
Que podría darnos una cifra aproximada de la cantidad de sockets abiertos por segundo... es decir, si hay un timeout de 60 segundos tras el cual se fuerza un TCP FIN, y tenemos disponibles 6100-32768 puertos = 28232, podríamos abrir conexiones a una cadencia de 28232/60 = 430 conexiones por segundo, superado ese límite, al cago de un minuto, nos podríamos encontrar sin puertos disponibles.
Hay más parámetros que pueden dispararse y limitar. De todos modos, en el caso de los HGU usan configuraciones de kernel estándares prácticamente, con valores que caben esperar en función de su RAM. En cualquier caso no puede modificarse ninguno por la interfaz Web, con lo que guste más o menos, es lo que hay.
Así que... son suficientes dichos "límites"? pues a menos que se usen aplicaciones tipo P2P o algunas otras que requieran un gran número simultaneo de conexiones, yo diría que sí, aunque tengas 10 equipos haciendo un buen uso de la línea no vas a sobrepasar dichos límites, que por supuesto en momentos puntuales pueden sobrepasarse.
Otra cosa diferente es que a tenor que se aumente la "presión" sobre el propio Router, este si descienda su cantidad de RAM libre y esté más expuesto a problemillas, pero es raro, en un entorno "normal" puede tener del orden de 20-30MB libres
-------------
Para terminar, sobre la posibilidad de usarlo como Bridge, sí, no hay problemas, en realidad no podrías ponerlo como bridge completo sino como Medio-bridge, ya que no se pasaría todo hacia abajo, sólo Internet, TV y teléfono se quedaría en el ASKEY, lo tengas o no contratado. Esto es muy diferente ya que los tres servicios van tageados por VLAN, y se hace cargo siempre el ASKEY. Muchos tenemos otro equipo detrás de este, pero por lo general no por problemas de conexiones concurrentes... por supuesto, como todo, siempre hay límites.
Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
