Hola, he conseguido acceder por SSH al Askey con el usuario 1234 pero la mayoría de comandos están capados y la salida, bloqueada.
¿Existe la posibilidad de acceder por root o mostrar la salida por pantalla de los comandos?
Theliel , sabes si se puede acceder por root o qué versión del HGU no tenía capados los comandos?
Necesito desactivar una regla del iptables que no aparece en la interfaz Web.
Buenas usuario_retirado
Las imágenes ya sabes que hasta que no pasen X nanai.
Respecto a cambiar reglas internas por shell, ya te lo dije, no hay, y si existiese no podrías cambiarla tampoco por la shell limitada. Se pueden manipular, pero solo las que ves en la interfaz Web:
firewall show
Piensa que mientras tengas caudal, no vas a notar mucha diferencia. QoS prioriza, pero si no hay mucho que priorizar porque todo va bien, no ganas mucho. Piensa en una autopista que vas por ella. Mientras no haya tráfico, que mas da por cual de los 3 carreteras vas, puedes ir a 120 de todos modos.
¿Cual es el problema? Cuando te aproximas a un punto donde empieza a poder tener cierto impacto, o mucho. De ahí que por lo general los paquetes de control TCP suelan tener una alta prioridad cuando se configura bien QoS. Mas te acerques a una posible saturación, más entra en juego y más hay gestionar el tráfico.
No depende realmente de la velocidad contratada, ojo, esto puede inducir a error. No por tener 600 o por tener 100 QoS se va a usar más o menos. Es una cuestión de, repito, caudal. Supongamos que tienes 600Mbps, y estas por un lado viendo Netflix a 4K (16Mbps), por otro lado la TV (da igual, la TV va por otro lado independientemente), 4-5 dispositivos navegando y tareas varias (pon en suma 30Mbps), 2 PCs con YT viendo vídeos en 4K HDR (50Mbps)... en ese escenario en el único momento que QoS podría entrar en juego, sería al cargar alguna web poco más.
Otro escenario, un PC subiendo archivos a un NAS/servidor remoto supongamos que puede ir al tope de velocidad y otro PC viendo Netflix a 16Mbps. En este escenario da igual lo que tengas contratado, sin QoS, el equipo subiendo estará constantemente solicitando más y más recursos de la línea, así que se "apoderará" de toda la subida, produciendo un fortísimo bufferbloat que puede dejar KO toda la red.
Otro escenario, el mismo pero en vez de subiendo descargando del NAS/Servidor. En este caso es muy posible que no exista bufferbloat, pero igualmente el primer PC casi con toda seguridad se apoderaría de la bajada, pixelando/congelando la imagen de Netflix
Lo que tienes contratado afecta en la medida que puede ser más "resistente" a una saturación, pero realmente no es lo que la marca, lo que la marca es que haya algún tráfico que digamos absorba los recursos de la red, porque sin QoS, el único sistema que va a regir esto, muy importante por cierto, es el algoritmo de congestión TCP que se esté usando, y aunque los hay mejores y peores, está muy estandarizado, y tampoco es algo que puedas cambiar
# cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
# cat /proc/sys/net/ipv4/tcp_available_congestion_control
cubic reno
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
cubic reno
Perdona, habia leido mal lo de los 0.5ms.
Okey a lo de la shell, lo dejo estar, paso, seguramente no consiga nada visualizando el iptables que tiene y borrando reglas.
He probado a jugar a juegos con QoS/ Sin QoS y no noto diferencia alguna. Ni incluso cuando tengo a la familia viendo Netflix/Youtube/TV, lo que me hace pensar que el QoS de este HGU no es funcional o que solo lo notaría en caso de saturación y, eso, no sucede casi nunca.
Te paso las reglas a ver si observas algún error.
Los juegos que juego usan el puerto 3074 UDP y estoy por cable al eth1 de la interfaz web (que no coincide con el físico, pero he comprobado que es este desde el apartado Diagnostics).
Creo 2 reglas. Una de lan a ppp0.1 y otra de ppp0.1 a eth1. Marcado CS4 y 802.1p 4 basandome en las recomendaciones del RFC De Diff Services original.
https://tools.ietf.org/html/rfc4594#section-4.4
He probado otros valores como EF (46) VoIP pero más de lo mismo, todo parece ir igual.
qos config generalqos queue cola ethernet para paquetes de entradaqos clases (subida y bajada)
Buenas usuario_retirado
Lee bien, puse 0.5ms por 100km, que son 5ms por cada 1000km. Que es muy poco, pero solo ir a EEUU pueden ser cuanto... 7000 u 8000 kilómetros? si se quiere ir a japón el doble o más? y eso solo en cuanto a límite físico, sin ningún tipo de elemento que existiese y con tiempos de cambio instantáneos. A lo que me refiero es que nos guste más o menos, hay limitaciones que no vamos a poder traspasar, ni a corto ni a largo plazo. Los equipos son cada vez mejores y mayores caudales aseguran menos tapones, pero ya vemos muchas veces incluso las limitaciones físicas, que cada vez empiezan a ser más importantes.
Claro que hay otros cuellos, por descontado, nodos que se saturan o van regular no es algo demasiado raro. Sobre problemas de routeo por ejemplo, a pesar de que muchos puedan quejarse en momentos puntuales que si me lleva por aquí o me lleva por allá, que si este camino es mejor que.... eso sucede por el mismo motivo que con el Futbol, todos son expertos y entrenadores desde sus casas, o con el COVID expertos en pandemias y en virus. Debe de ser que la mayoría sabe más de futbol, de fichajes, de colocación... que los mejores preparadores del mundo. No digo que no se puedan tener buenas ideas o mentes realmente geniales en cualquier lugar, pero seamos serios... un Tier1 no se crea en dos días con monos pedaleando, quien crea realmente que no se usan siempre los mejores caminos posibles en ese momento dado, no se ha parado a pensar un segundo
Eso no significa que no existan problemas o errores. De cuando en cuando encontramos un camino totalmente roto, destinos inalcanzables, incluso en alguna ocasión algún paquete dando la vuelta al mundo para acabar al lado de casa. Pero esto es puntual, está todo demasiado bien gestionado y montado.
Los problemas reales son siempre el caudal. Tienes que dar cabida a un trafico dado y tienes el caudal que tienes, si no cabe no cabe, tienes que esperar al próximo tren y eso es latencia. En los últimos años los ISP han mejorado notablemente sus redes, hasta el punto de que es poco habitual encontrarnos con atascos dentro de la propia red. Sí, a veces alguna centralita o algún Peer con su red madre sobre todo en horas puntas, pero la cosa ha mejorado enormemente, y seguirá mejorando.
Los protocolos en tanto a latencia no afectan en gran medida.... protocolos me refiero de bajo nivel. Protocolos en capa de aplicación hay de todo para baja latencia, generalmente paquetes cortos UDP. El rendimiento si es diferente, el rendimiento de una red si puede variar bastante en función de los protocolos usados, el ejemplo más sencillo es el MTU, donde pequeñas variaciones para arriba o para abajo pueden suponer (según que tecnología se use) diferencias de un 5%-10%, que por supuesto eso puede traducirse a un mejor aprovechamiento, y que en teoría podría mejorar la latencia al aprovecharse mejor todo. Pero eso es complicado ya de medir.
---------
Sobre el Askey, no recuerdo cual fue la última con salida... puede ser que fuese la n43 o la anterior, si te soy sincero no lo recuerdo. Creo que esta es la segunda iteración, con lo que la última debería de ser la n43. Pero depende de cual sea la idea es buena idea o mala idea.
Por un lado no vale mucho irse a la n43 para luego usar lo mismo en la n55_5. Algunas cosas seguirán funcionando, pero muchas otras han cambiado, incluso están presentes pero eliminadas realmente del sistema, y por otro lado usar una firmware no actualizada es aun más peligroso.
Oficialmente, no existe forma de sacar por pantalla la salida de la shell limitada, está a propósito, funciona perfectamente pero tienes que saber que y como. En esto puedo ayudarte lo que quieras, me dices que quieres hacer/ver y te digo si se puede, y en caso afirmativo como. Extraoficialmente, siempre se puede hacer de todo, pero obviamente no hablamos de eso.
Si te sirve de consuelo soy el primero que he criticado duramente esa posición, si ya de por sí era bastante limitada, encima omitir la salida es casi un gesto de mal gusto. Mira que he manipulado Routers, desde equipos que directamente no te permiten acceder dentro, pasando por Shell muy limitadas, menos limitadas a accesos completos. Pues creo que es la primera vez que me he topado con una shell limitada que suprime la salida en pantalla. Pero bueno, obviamente explicación habrá, lo que no quiere decir que, para mi al menos, tenga mucho sentido, puesto que cualquier posible respuesta o explicación sería cualquier problema que debería de ser resuelto de otra manera, no así.
Mhmm, buen punto de vista, si que es cierto que Internet es una máquina de hacer dinero a costa de cualquier valor moral, y la neutralidad de la Red pone freno a muchas actitudes no muy "buenas".
Lo de los 5 ms cada 100Km es una buena métrica, aunque es curioso que cada 1000Km deberían haber unos 5ms teniendo en cuenta solo aspectos "velocidad de la luz en cableado de fibra" (200000 km/s).
Pero debe haber alguna variable más que ralentiza la conexión para que suba la latencia con tan poca distancia... como nodos saturados, routing poco óptimo, salto entre routers/switches, incremento de potencia por hubs, encapsulamiento y cambio de capas físicas, acuerdos de peering...
Poco se puede hacer, tener suerte con vivir cerca de un IXP potente o de una ciudad que mueva mucho tráfico TIER1, a poder ser Europea (Amsterdam, Frankfurt, París, Londres, Bruselas...). En España, Madrid.
Respecto al tema general de acceder por SSH al Askey y ver la salida por pantalla (sea con root o sin), ¿se puede?
¿Sabes si hay alguna version del firmware que no capara la salida en shell? Podría probar a poner la n43, pero si me dices que en esa ya estaba capada, ni lo pruebo.
Saludos
Buenas amigo usuario_retirado
En realidad se usa en todos lados.
QoS/CoS son a día de hoy herramientas totalmente imprescindibles, en todos los ámbitos, aunque a veces no las veamos como tal. Sin esas tecnologías te puedo asegurar que Internet no funcionaría lo bien que lo hace, aun con sus problemas, por supuesto.
En casa por ejemplo, QoS es una herramienta potentísima, por supuesto, bien configurada te permite poder usar servicios tanto en tiempo real como transferencias pesadas de fondo sin que se vean afectados prácticamente uno de otro. Esto por supuesto se extrapola también a redes mucho mayores como bien dices, desde entornos empresariales, campus universitarios o lo que podamos imaginar.
Pero realmente se usa en casi todo, aunque a lo mejor no del modo que te gustaría a ti. Por ejemplo, el tráfico que se sube a la OLT, todo el tráfico OMCI tiene prioridad, porque es esencial para el correcto funcionamiento de las propias ONT de cada uno. El tráfico VoIP/IPTV tiene sus propias prioridades en la red de Movistar, y de nuevo gracias a QoS se asegura, en este caso, una baja latencia, siendo muy inmune a las sobrecargas de la propia red de Movistar.
Y en la propia red de Movistar también, y en realidad en todas las redes. No, no se puede priorizar ni penalizar de ningún modo lo que podemos llamar el tráfico de Internet, pero si se prioriza mucho otro "tipo" de tráfico que realmente no es tráfico ordinario. ¿Cuantas veces he dicho por aquí, por ejemplo, la discriminación que se hace del tráfico ICMP? O el tráfico BGP, o OSPF, incluso RIP... y es solo por poner ejemplos, piensa en cualquier protocolo que se pueda usar para gestionar, controlar y mantener cualquier nodo/peer de una red.
Lo que no podemos hacer es manipular el tráfico de Internet a nuestras necesidades. Y realmente no se puede hacer nada. A día de hoy la latencia viene dada fundamentalmente por dos variables bien definidas: La distancia y habitualmente los Peer. Con la distancia no podemos hacer nada, es una cuestión física, como ya he dicho en algún momento yo uso la regla del 0.5 ms por cada 100Km, en el mejor de los casos siempre, de ahí para arriba. Y el otro punto negro suelen ser los Peer, los cuales cada vez están sustentados por equipos/tecnologías/caudales mejores, las estructuras a nivel internacional han mejorado notablemente.
¿Se podría hacer algo? Espero que nunca se haga nada, y te digo por qué. En un mundo utópico en el que no existiesen intereses económicos tan fuertes, en el que nadie fuese amoral, en el que todo el mundo entendiese que el bien de muchos es siempre mejor que el bien de uno... entonces se podría legislar de un modo muy diferente. Pero no vivimos en ese mundo. Vivimos en un mundo en el que es todo por el dinero, en el que cualquier coma mal puesta en un ley es suficiente para poner a un asesino en la calle, o hacer multimillonario a quien sea. Se viva en EEUU o en cualquier parte del mundo, es harto conocido el famoso caso del "asesino" O. J. Simpson, en el que sencillamente se puso en libertad por duda razonable, pese a estar más que comprobado.
¿Que tiene que ver todo esto? Todo. Por mucho que fuese lo ideal, aquí no valen las medias tintas, si abres, no digo la mano digo un dedo, sientas precedente, y empezarán los abusos, por algún lado, no te preocupes, pero se empezará a abusar. ¿Por qué lo sé? Pues porque se ha hecho siempre!! ¿Cuantas veces, años atrás, han estado los ISP bloqueando/restringiendo el tráfico P2p? Era algo común. Se han hecho barbaridades en pos de un supuesto bien común... que si fuese realmente un bien común yo lo firmaba, el problema es que no es buscando un bien común, sino un bolsillo más gordo.
Los políticos son políticos, no son expertos en telecomunicaciones (en este caso), o expertos en medicina, o expertos en... no dudo en muchas ocasiones de sus intenciones en regular ciertas cosas, creo sinceramente en que las cosas se intentan hacer bien!! pero no son políticos no expertos, y que a su vez están presionados desde todos los ámbitos financieros, que tienen sus propios... "expertos" y que de forma burde intentan "engañar".
Mira lo último que está pasando con DoT/DoH. Las telecos y gobiernos principalmente ya han intentado por muchas vías que se ponga freno al uso de estas tecnologiás, apelando a que hay que salvaguardar la seguridad de los países que es necesario conocer las peticiones DNS bla bla bla. ¿Crees que los gobiernos entienden de eso? Con mucha suerte habrá uno o dos países cuyo gobierno tenga una gran curiosidad en el asunto y quiera ver realmente que implicaciones buenas/malas puede existir en el asunto.
Las cosas no funcionan como nos gustaría, y la historia ha demostrado una y otra y otra y otra vez, que por desgracia en cuanto a valores humanos, derechos fundamentales y otras muchas cuestiones, no se puede ir a medias, aunque sobre el papel fuese realmente lo ideal, porque si vas a medias, al final, terminas sin nada.
Entonces, si dices que se sobreescriben al salir de mi red (casa), ¿para qué existe el PHB -Per Hop Behaviour- de QoS, que consiste en implementar ToS / CoS? Si no se usa en redes domésticas, ¿dónde se usa? ¿Exclusivamente en redes privadas o MPLS (con sus variaciones)... o solo en entornos privados grandes estilos universidades, campus , empresas?
Gracias por la info, Theliel. Probaré a cambiar el VLAN Priority a ver si hace algo, ya que el DSCP/802.1p regla a regla se lo está pasando por donde quiere el router, incluso en tráfico entre dispositivos LAN.
Aunque si que es cierto que el ancho de banda está garantizado para la mayoría de los servicios (al menos de manera troncal), no así con la latencia. Muchos servicios de tiempo-real (voip, gaming, op.médicas virtuales, sistemas y coches autónomos teledirigidos...) requieren de baja latencia. Quizás se podría intentar algo a nivel internacional para reducir las latencias de tales servicios. El ancho de banda ha ido mejorando con los años pero las latencias siguen siendo el talón de aquiles, saturación, mayores anchos de banda y mayores tiempo de espera en colas, física, distancia... Algo se tendría que hacer, ya sea a niveles de Tipo de servicio o protocolos.
La neutralidad de la red es necesaria, pero tampoco debe ser un dogma en el que nadie pueda moverse, hay servicios que requieren un tratado específico. La red está construida para ver Netflix o partidos de fútbol y el tráfico a tiempo real sigue sufriendo, todo desde mi punto de vista, claro.
Buenas usuario_retirado
No, hablaba a nivel Ethernet e IP, a nivel ONT/OLT te hablaba que realmente e hipotéticamente hablando, sería lo único que se podría intentar.
Por supuesto, claro que en teoría se podría "respetar" o hacer uso de los Bits CoS/QoS, pero del mismo modo puedes intentar lanzar un paquete sin hacer SNAT antes y que salga con IP de origen 192.168.1.5... pero eso no significa que el siguiente nodo lo vaya a descartar (en el caso de la IP de origen).
La prioridad de las VLAN puedes cambiarla sin problema alguno, pero ya usan los valores que tienen que usar, y siempre de nuevo desde tu perspectiva, no hacia fuera. Es decir que si cambias la prioridad te va a afectar en lo tocante a como gestiona los paquetes el Router/ONT, nada más.
Y respecto a contratar... por suerte, y digo y repito, por suerte, en Europa tenemos neutralidad en la red, lo que impide tratar de forma especial ningún tipo de tráfico. Eso implica por tanto que ningún ISP puede ofrecer un canal "prioritario". Si se permitiese, en unos años, encontraríamos que las tarifas "prioritarias" serían cada vez más prioritarias y las normales mucho peores, al final creando un Internet de dos velocidades. La neutralidad en la red debería de ser obligado a nivel internacional, pero bueno... al menos lo hemos logrado aquí en Europa.
Pasa mucho con los servidores VPN de pago. Muchos se creen que van a tener una preferencia o prioridad. En absoluto, en lo que es llegar a ellos tendrá la misma prioridad que cualquiera, y cuando el tráfico salga de ellos, si es en Europa al menos, también la misma.
Simplemente hay que mentalizarse de una cosa muy muy muy sencilla. Una vez los paquetes salga de casa, su valor es exactamente el mismo que el del resto no solo de clientes de dicho ISP, sino de cualquier otro. Si es verdad que cuanto mejor sea la red del ISP, mejor irá el tráfico (en teoría) mientras circula por ella, pero al igual que no se puede imponer bloqueos o penalizar un tipo de tráfico concreto como el P2P o... tampoco se puede ofrecer ningún tipo de tráfico prioritario.
Cualquier nodo de red de cualquier red troncal, va a ignorar/sobreescribir cualquier tipo de QoS/CoS, el escaso valor que tendría sería dentro del propio ISP que además es donde menos problemas hay, y aun cuando quisiesen, tampoco pueden.
Camino muerto... y no diré me temo, sino que afortunadamente.
Tu hablas a nivel de ONT y paquetes ONT-OLT, pero, teóricamente, si la ISP respetara el marcado CoS (capa ethernet) y ToS (IPv4) por parte del ISP, al salir de la red debería mantenerse las prioridades. Los bits de prioridad incluso bajo VLAN pueden mantenerse.
Cierto es que con una linea MPLS puedes hacerlo o contratar redes privadas con un QoS definido bajo SLA.
Viendo que el QoS así no esta funcionando, sabes si cambiando la prioridad entera de la VLAN de ppp0.1 a otro valor que no sea el por defecto, ¿el servicio seguirá funcionando?
¿Hay alguna manera de contratar una línea privada con QoS bajo SLA por parte de Telefónica o hacer que la priorización de QoS que estableza en el router se propage, al menos, hasta el destino de las conexiones o previo salto a otro ISP?
Buenas usuario_retirado
El Askey no fuerza ni sobreescrbibe ningún marcado. No existe ninguna regla para ello, nada que eliminar. La ONT en cambio tiene mucho que decir aquí, y es pieza fundamental y motivo por el cual, entre otros muchos problemas, no es recomendable usar una ONT propia.
No tiene nada que ver con poder evitar alguna manipulación del ToS, es mucho más simple que todo ello, ya pudieses manipular absolutamente todo lo que quisieses a bajo nivel en el Router, que en lo tocante a DSCP (QoS) o a PCP (CoS) no vas a lograr nunca nada... obviamente con nada me refiero hacia el exterior. Todo lo que sea hacia el exterior jamás será marcado ni tenido en cuenta, da igual lo que quieras hacer.
Otra cosa muy diferente es lo tocante al tráfico interno de Movistar, IPTV o VoIP va por su propia red por otros canales totalmente independientes, sin violar además la neutralidad de la red. El tráfico en la ONT ya se separa, entra en el ramal de fibra que va a la OLT ya no solo por diferentes VLAN, sino que son puertos GEM diferentes. Podrías intentar colar el tráfico de Internet por otro puerto GEM, pero como ese tráfico al final va a parar a ámbito interno, de nuevo sin salida.
A lo más que se podría intentar aspirar, y con casi total seguridad tampoco funcionaría, sería intentar cambiar la prioridad del tráfico que pasará a paquetes GEM, modificar en la ONT los parámetros necesarios para que tuviesen, por así decirlo, mayor prioridad que el resto de los "enganchados" en la misma fobra, y tampoco tendría un recorrido muy largo... y eso todo es teórico, repito, dudo enormemente que la OLT no lo vigilase.
