Acceso por SSH Hgu Askey n55_5

Highlighted
Acceso por SSH Hgu Askey n55_5

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.

 

Mensaje 1 de 24
827 Visitas
23 RESPUESTAS 23
Highlighted

Hola @carlvif

 

Siento no poder ayudarte con esa configuración, dejamos el hilo abierto para ver si algún usuario puede aportar algo al tema.

 

Un saludo.

 

Galder



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 2 de 24
794 Visitas
Highlighted

Buenas @carlvif 

 

Que regla?

 

Si no está en la interfaz Web de cualquier forma, no podrás cambiarla desde la Shell limitada


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 3 de 24
781 Visitas
Highlighted

Hay una regla en mangle que cambia todos los bits DSCP que salen de LAN hacia ppp0.1 a 000000, solo se mantiene el QoS DSCP de voip :((... de ahí a que no se marque el QoS 😞

Mensaje 4 de 24
766 Visitas
Highlighted

Supongo que lo han hecho por seguridad y para que la gente no haga un "exploit" del ToS..

 

Aun así con ONT + neutro te lo saltas fácil (hasta el siguiente nodo, claro, donde probablemente te lo vuelvan a mapear a best effort DSCP 000000).

 

Meh.

Mensaje 5 de 24
765 Visitas
Highlighted

Buenas @carlvif 

 

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.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 6 de 24
748 Visitas
Highlighted

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?

 

 

 

Mensaje 7 de 24
734 Visitas
Highlighted

Buenas @carlvif 

 

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.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 8 de 24
720 Visitas
Highlighted

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.

Mensaje 9 de 24
703 Visitas
Highlighted

Buenas amigo @carlvif 

 

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.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 10 de 24
619 Visitas
Highlighted

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

 

Mensaje 11 de 24
589 Visitas
Highlighted

Buenas @carlvif 

 

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í.

 


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 12 de 24
563 Visitas
Highlighted

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 config generalqos queue cola ethernet para paquetes de entradaqos queue cola ethernet para paquetes de entradaqos clases (subida y bajada)qos clases (subida y bajada)

 

 

 

 

Mensaje 13 de 24
556 Visitas
Highlighted

Buenas @carlvif 

 

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

 

 


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 14 de 24
536 Visitas
Highlighted

Ok , esperare a que se cargen las fotos del QoS que te quiero mostrar para ver qué opinas . De la misma manera que hay un comando "firewall show" entiendo que no hay alguno del estilo "qos show"...

Mensaje 15 de 24
532 Visitas
Highlighted

@Theliel ya aparecen las fotos, ¿ podríamos decirme si la regla parece a priori estar bien configurada? 


Saludos

Mensaje 16 de 24
483 Visitas
Highlighted

Buenas @carlvif 

 

Por desgracia la interfaz de estos equipos para la configuración QoS es, como la mayoría de los casos, un tanto críptica y poco... amigable.

 

Según lo que yo interpreto en como está concebido en este equipo QoS (Askey), estaría mal.  Por supuesto a partir de aquí es todo hipotético, no lo he probado en ningún caso y es solo aplicando lógica, que no tiene por qué que ellos lo hayan hecho así.

 

Dicho esto...

 

Parece que realmente no están haciendo una gestión mediante DSCP, sino más bien por colas. Como bien dicen al principio solo se permiten 8 colas por interfaz, de mayor a menor peso, y aunque en principio se presupone que se podrían configurar colas de igual peso y aplicar Round-Robing a ellas, parece que aquí solo puede hacerse si se configuran con política estricta de 8 (8/SP). En cualquier caso,  a lo que nos interesa, por defecto el Askey ya crea varias colas para ello, y las que nos interesarían realmente son las 5 colas veip0, key 33 al 37 por defecto, se podrían crear 3 colas más.  Estas van a ser las encargadas en priorizar el tráfico a la hora de sacarlo por WAN, y ese es tu primer error

 

Has creado una/varias colas para eth1. Eso lo que haría sería priorizar tu propio tráfico en relación a otro posible tráfico que tu equipo generase, pero no lo priorizaría en lo relativo al tráfico global del Router hacia fuera. Hay mucha inconsistencia en el sistema usado y muchas incógnitas que solo podemos presuponer.

 

1º. Podemos escoger interfaz para crear las colas, y si bien tenemos interfaces para los dos adaptadores WIFI, tenemos 5 para Ethernet. 4 pertenecen a los puertos físicos, el 5º puede ser o la CPU o Quantenna. No podemos saberlo... internamente está claro eth0-eth3 son los puertos físicos, wl0 la interfaz  WIFI de 2.4GHz y eth4 la interfaz WIFI de 5GHz. Pero aquí ya tenemos wl0 y wl1... entonces que es eth4 aquí? Podría ser redundante, o podría ser la CPU¿? Solo presuponer...

 

2º.  No aparece la interfaz propia. Si vemos en la clasificación, el tráfico que genera el propio Router como DHCP lo mete dentro de una cola para WAN, esto no tiene ningún sentido porque DHCP es un tráfico local. Sí, está bien clasificado, es decir, se considera local, puerto etc... clasificado sí, pero se asigna a una cola que es para WAN, tendría que existir otro conjunto de colas para el tráfico interno del propio Router. ¿Podría ser ese eth4? No lo sé, lo que está claro es que en la configuración por defecto de dicho tráfico usa la misma cola WAN

 

3º. Como he dicho no parece que usen realmente un marcado para uso interno. Si miramos la clasificación hay dos partes, la primera hace referencia clara a las condiciones a cumplir de dicho tráfico para categorizarlo, la segunda parte como categorizarlo. Teniendo en cuenta que parece siempre hacer la gestión por cola, el marcado lo estaría usando sólo para uso propio si por ejemplo dicho paquete se envía a otro Router propio. Es decir, que realmente no nos importa el marcado, solo la cola en este caso. Si lo marcamos, el paquete saldrá en teoría marcado con los bits que especifiquemos, pero dado que va para fuera poco valor van a tener. El sistema QoS que va a funcionar para nosotros realmente va a tomar simplemente la cola.

 

4º. Por desgracia, la interafaz no permite especificar dentro del tráfico TCP los flags de estos, con lo que deja fuera de poder categorizar algo esencial, que son los paquetes de control.

 

---------------------

 

Teniendo en cuenta todo eso... yo crearía 3 colas más en WAN para tener de sobra, por si acaso. en la clasificación cambiaría bastantes cosas incluso de lo que viene por defecto

 

Las reglas CPU tienen sentido siempre y cuando el tráfico vaya a asalir. Pero no tenemos cola de prioridad para el tráfico local que va al bridge. Por eso que las dos primeras reglas, relativas a DHCP, tal como lo veo, para mi no tendrían sentido alguno.  O a lo mejor internalmente el tráfico que va a LAN desde el Router es indiferente en la interfaz a la que vaya dirigida la cola, quien sabe.

 

Las reglas ACS son para el servidor TR069, en lo personal no tiene ningún tipo de prioridad, yo le asignaría el key que estuviese asignado al 8/SP de WAN (si se crearon 3 adicionales, sino al 5/SP)

 

La regla DEF imagino que quiere referirse a que cola se usará por defecto para el tráfico que no cumple las anteriores, y les da una prioridad menor, id 35 por defecto que sería 3/SP

 

Dentro de las reglas LAN tenemos el mismo problemas. LANPPPDISC y PPPSE, pero en ete caso ponen como interfaz de origen LAN, es decir, darían prioridad a clientes PPPoE conectados al Router, no el del propio Router, y en este caso es correcto sacarla por la cola WAN.

 

Las dos reglas finales dan un peso medio al resto de tráfico IP.

 

Configurar bien QoS aquí sería tedioso.

 

1º. Tendríamos que saber realmente que cola es la que hay que establecer para el tráfico cuyo destino sea el propio bridge, no se especifica. Movistar usa en la clasificación PPPoE (WAN), pero esto no tiene a priori sentido.

 

2º. Aclarado eso, el tráfico que más prioridad debería de tener es siempr eel tráfico de control, paquetes PPPoE (pero del router, no de LAN, interfaz local), DHCP, ARP... pero como ya he dicho no sabemos la cola que se usa para br0, y tampoco podemos especificar los paquetes de control TCP , lo máximo que poedmos configurar es el tipo de protocolo, nada más. Por ejemplo 1/SP

 

3º. Después crearía otras con lo que realmente queremos priorizar, la tuya a lo mejor de la consola, siempre en una cola con menos peso (mayor SP) que las anteriores, si los paquetes de control no tienen máxima prioridad, da igual la prioridad que tengan los paquetes UDP/TCP que mandas, y se puede ademas causar problemas de estabilidad. Digamos que 2/SP

 

4º. Crearía luego otra para tráfico general que no esté incluido en las otras dos, y a lo mejor asignarle 3/SP

5º. No es posible especificar como dios manda el tráfico por servicio. Se puede por puerto, pero no en función de que tipo de carga. Si se permitiese podría especificar que a partir de unos 5Mbps por ejemplo en tráfico HTTPs/HTTP se degradase a otra cola. Aqi no se puede, así que de forma patatera se podría crear una clasificación a puerto 80/443 con menos peso (mayor SP) que las anterioes, asumiendo que la mayoría de descarga se harán por protocolos Webs y evitaría interrupciones de estos, aplicando menor prioridad a estos (mayor SP), me facilitaría el resto, por ejemplo 4/SP. En este caso el tráfico que no fuese HTTP tendría más prioridad, y dejaría el tráfico HTTP por debajo, lo que incluiría las descargas, YT y otros.

 

-----------

 

Se podría crear una cola delimitante y meter en ella tráfico que nos quisiésemos asegurar que no supersae cierto umbral...

 

El marcado aquí como digo no parece que tenga la mayor importancia a menos que el tráfico fuese enviado a un nodo/Router/Switch que si lo clasificase en función de su marcado. Pero a como lo gestiona el Router, es lo de menos.

 

Tampoco veo positivo marcar 802.1p, puede confundir cuando lo meta en el ramal de la VLAN6. Las cosas están para que funcionen ya bien, es como intentar engañar a un sistema para supuestamente querer mejorarlo. Ya fue diseñado para ser bueno, y dudo enormemente que ninguno de los presentes sepa más que los crearon el estándar y las recomendaciones :), el tráfico "de fondo" que llamamos, lo normal y la recomendación siempre es 802.1p = 1, que es lo que usa Movistar por defecto para su VLAN 6.  Además es muy posible que al cruzar el tráfico por WAN lo vuelva a configurar a 1

 

----------------

 

Todo esto como digo siempre teniendo en cuenta que es aplicando la lógica y lo que se puede ver. Realmente la firmware podría estar haciendo por detrás lo que le diese la real gana.

 

Las colas Eth1 por otro lado podrían tener igualmente importancia, pero para tu propio tráfico. Es decir, configurar las colas que afectaría al tráfico que escupe tu dispositivo. Esto en consolas no es que tenga mucho sentido porque por lo general no son equipos multitarea... es decir no vas a estar descargando sin parar con la consola mientras que estás  jugando ymientras que ves un vídeo... todo ello desde, repito, la misma consola. En un PC si podría tener más uso, por ejemplo relegar el tráfico P2P a favor del tráfico HTTP (por ejemplo).


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 17 de 24
460 Visitas
Highlighted

jaja @Theliel, tendré que mirarme tu respuesta unas cuantas veces...

 

Lo de eth1 tienes razón, al no ser multitarea no tiene mucho sentido, pero pensaba que eth1 hacia ppp0.1(routed) se refería de LAN(eth1 puerto) a WAN (ppp0.1)..

 

Mirare de hacer lo que me has dicho, pero, a resumidas cuentas, ¿para priorizar el tráfico UDP 3074 hacia fuera / hacia dentro (aunque no tiene sentido ya que ya ha llegado a la interfaz) que colas crearías y a qué lo asignarías?

 

Este QoS da dolores de cabeza, no se entiende nada pero me basé en las especificaciones de Netcomm (ISP Australiana), que tenía varias guías de QoS con la misma interfaz para routers domésticos...

 

https://support.netcommwireless.com/sites/default/files/3G29Wn_QoS_Setup_guide.pdf

https://support.netcommwireless.com/sites/default/files/NB604n_QoS_SetupV2.pdf

http://media.netcomm.com.au/public/assets/file/0019/72109/NB6Plus4Wn_QoS_Setup_Guide.pdf

https://www.telechoice.com.au/uploads/nbn/NF10WV-User-Guide.pdf

 

Mensaje 18 de 24
395 Visitas
Highlighted

Hola @Theliel , Finalmente, he dejado la cola de prioridad más alta LAN -> ppp0.1 con el puerto 3074 UDP y ToS DSCP desactivado (al igual que CoS 802.1p). Es cierto que no tiene sentido marcarlo ya que al salir, Movistar lo remarca a best effort cs0 y el sistema de colas por prioridad es lo que funciona en estos routers, aplicándose marcados en switchers/routers posteriores y en este caso, no se mantiene. Aunque es cierto que el teléfeno tiene puesto Expedited Forwarding en el apartado Voice > SIP Advanced Settings.

 

Por otro lado, ¿no crees que las colas LOCAL hacia ppp0.1 pueden ser para obtener IP pública desde servidores de Movistar en vez de asignar DHCP a clientes en LAN?

Aunque es cierto que es raro ya que pone el puerto 67 como origen y ese es el que usa un server DHCP...es decir, habla del DHCP del router... muy raro, luego hay una regla llamada CPU_ACS con una IP pública, que sale por la misma interfaz que CPU_DHCP. Muy raro.

 

 
CLASSIFICATION CRITERIA
CLASSIFICATION RESULTS
 
Class NameOrderClass IntfEther TypeSrcMAC/ MaskDstMAC/ MaskSrcIP/ PrefixLengthDstIP/ PrefixLengthProtoSrcPortDstPortDSCP Check802.1P CheckQueue KeyDSCP Mark802.1P MarkEnableRemove

 

Xbox1(interfaz)LAN(ether type) IP    (protocolo) UDP(puerto origen) 3074   (queue key) 33  

 

No se si crear una  cola Local > ppp0.1 con puerto de destino 3074... No se si eso haría la función de "paquetes de descarga", ya que con la regla anterior solo priorizo los tiempos en cola de los paquetes de  "subida".

 

Gracias

 

Mensaje 19 de 24
380 Visitas
Highlighted

Buenas @carlvif 

 

Como te dije es todo basado en suposiciones. Para saber exactamente que está pasando sería necesario encontrar herramientas internas que permitiesen ver el tráfico que pasa por las colas y como va entrando/saliendo. Que no digo que no se pueda hacer, pero honestamente no tengo tiempo para ponerme con algo así

 

Todo lo que dije podría no ser así. Las reglas SIP/VoIP es totalmente diferente, son canales independientes y que si es posible Movistar tenga en cuenta por su red interna, aunque los sobreescriba al margen de que se configure, pero estoy seguro que internamente usan QoS en su red, es lógico. La regla ACS tiene en parte lógica es la conexión al servidor TR069, con lo que parte de local. Tendría todo mucho más sentido una cola para br0, pero esa no existe.

 

Las colas están ya creadas, lo úico que habría uqe hacer es meter diferentes reglas para que el tráfico se clasificase correctamente. el 1/SP que por defecto creo que es el 33 debería de ser la de mayor prioridad, yo no pondría ahí tráfico preferente para juegos ni para nada, lo dejaría para tráfico de control, es mucho más importante tráfico tipo ARP, DHCP, DNS...  y por supuesto flags para TCP, que no pueden usarse.  Además me aseguraría de tener otras colas detrás de menor prioridad y menor que la que quisieses meter entre medias, para clasificar tb la mayoría del tráfico que se pueda generar, sea web o sea del tipo que sea.

 


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 20 de 24
369 Visitas
Highlighted

Ok, pues la moveré un par por de debajo de la cola con key 33, gracias por la ayuda.

 

Saludos

 

Mensaje 21 de 24
360 Visitas
Highlighted

Hola @carlvif.

 

Te pedimos disculpas por las molestias ocasionadas. ¿Podrías confirmarnos si la información facilitada por @Theliel (muchas gracias por tu aportación), se ha resuelto la consulta que nos planteabas, por favor?

 

Un saludo.

 

Angela.



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 22 de 24
315 Visitas
Highlighted

Bueno @Theliel , al final he intentado configurar una cola más en QoS (veip_6) y asignar a ella el tráfico de la consola,

dejando a las 2 ultimas colas (veip_7,veip8) posteriores con mayor SP (menor peso) tráfico restante tipo IP normal desde LAN y W0/w1, pero a la que creo una regla con w1 se reinicia la interfaz web y no me deja crear la regla.

 

También, si creas una regla en una posición intermedia, se solapa con otras reglas (el array con Js está mal programado) y 2 reglas obtienen el mismo ID en la lista de orden. Solo se pueden poner reglas en la primera y última posición... tampoco quiero borrar las reglas QoS predefinidas.

 

Así que al final no uso reglas o dejo en la cola con máxima prioridad (key33) el tráfico UDP3074, tampoco es excesivo y no hace que se "mueran de hambre" el resto de colas o los paquetes DHCP y de control de la misma. El tráfico es muy bajo por el puerto 3074UDP y no noto inestabilidad...

 

No se puede hacer nada con este QoS por la cantidad de bugs que tiene, parece que lo han puesto así para que no toquemos nada.

 

Saludos

 

Mensaje 23 de 24
305 Visitas
Highlighted

Hola @carlvif

 

Te pedimos disculpas por las molestias ocasionadas y que no hayas podido realizar la configuración como deseabas porque no permitiese. Ya sabes donde nos tienes para otras consultas.

 

Un saludo.

 

 

Angela. 



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 24 de 24
230 Visitas