Buenas tardes a todos, especialmente a @Theliel. Tengo una duda que espero me podáis resolver. Actualmente tengo en mi cuarto mi linea de movistar con ont y un routerboard de Mikrotik. Por diversas cuestiones, empíricas más que nada, quiero utilizar la linea principal de mi casa (la que utiliza el resto); la ont de Alcatel de mi linea personal me está dando problemas y necesito cambiar de ont. No soy capaz de hacer funcionar telnet en el mac y no tengo windows, así que no puedo acceder al ont de Alcatel (se supone que no tiene interfaz web, por lo que no sé la idont. Si la tuviese cambiaría ont y listo). Movistar TV tiene que mantenerse en el salón porque mi padre es quien lo usa. Entonces lo que quiero es tener la ont en mi cuarto (tengo una ont antigua de movistar y otra típica de Huawei sin los límites que tiene la de movistar en la interfaz), y mantener la VLAN 6 en el Mikrotik. Al final solo yo voy a usar el internet de esta linea; al resto les configuro un Asus con mi otra linea y cambio el ssid para que no se den cuenta de que he hecho algo... La VLAN 3, a priori, no me importa. Ahora, la Vlan2. 1) He intentado configurar el IPTV en el mikrotik (la de mi linea personal para después aplicarlo a la linea princpipal) para ver si era capaz de configurarlo y hallar una solución. Estuve ayer varias horas y nada. Pongo lo que hice ayer y a ver si alguien puede ver en qué estoy fallando. La IP del desco la saqué del router. En la parte de "IP / Addresses" la meto en la interfaz de vlan2. Añado el RIP para vlan2 y, después, la red 172.26.0.0/16. Habilito igmp proxy en upstream para vlan 2 (subnet alternativa 0.0.0.0/0) En el dhcp server (en opciones) añado la opción típica del code 240 y el script que sale en el hgu/comtrend (en lan). Después, añado la lease 192.168.1.200 para el desco y le añado la opción creada antes. Aquí tengo una duda: es recomendable meter el desco en el bridge o en un puerto fuera del bridge. En caso de usar el bridge, activo vlan filtering? lo he estado buscando y nadie habla de activarlo (en caso de activarlo lo dejo con la vlan 1 típica del lan o meto una regla aparte para añadir o strip el vlan -supongo que no, pero no sé qué probar-?) Si meto el desco en un puerto separado: aquí si que tuve muchas dudas. Que yo crea tengo que asginarle la 192.168.1.200, si quisiese otra, véase en la 192.168.3.0/24 que no la uso actualmente, no funcionaría) En la parte de network (dentro de dhcp server) además de los que ya estaban (pondré foto de todas estas cosas para que sea más claro) meto la 192.168.1.200 con gateway 192.168.1.2 (que es la que tengo en el router y a su vez la que utiliza el bridge), añado el dns de IPTV y la opción de antes (code 240...). Al intentarlo así, estuve probando varias cosas en la parte de ip / addresses. Al compartir la subred del bridge no podía meter la 192.168.1.2/24 con network 192.168.1.0. Entonces probé 192.168.1.200/32 (si pongo subred 31 o menor me obliga a tener la 192.168.1.200 como network aparte de en address) y network 192.168.1.2 (tb probé cambiar todos los parámetros para 192.168.1.1). Al añadir esta address te crea una regla en routing. Al añadirla, RIP me añadió las 4 ó 5 reglas para vlan 2 (que ya había añadido manualmente ya que pensaba que no me las iba a añadir de manera dinámica). Parecía que algo iba bien ya que al meter la address, RIP reaccionó añadiendo esas reglas... En routing hay más lío. Al igual que cuando tengo dos lineas de internet en el router (una pppoe y la otra por dhcp client) las reglas de enrutamiento tienen que ser hechas con "routing mark" en mangle ya que si intento añadir rutas en base a la IP de procedencia (preferred source = 192.168.1.2; 192.168.2.2, etc. solo activa una de ellas y las otras las deja en idle ya que las debe ver redundantes) Al principio los paquetes del desco iban por la regla src-nat para pppoe-out1; no "sabían" que tenían que ir por vlan2. Metí una regla al efecto ( e incluso desactive el pppoe para que no hubiese problema), pero aunque pasaban por vlan2, no funcionaba. Llegaban paquetes de vuelta que pasaban por la regla de dst-nat que cree para vlan2 y 192.168.1.200. Pero está claro que algo iba mal. La regla que añadí en routing para que el tráfico no fuese por pppoe-out1 fue con gateway vlan2 y después probé directamente metiendo la 10.128.0.1. Probé a añadir regla en src-nat con acción masquerade (que es la que estaba usando) y tb con srcnat y la ipv4 del desco. Nada, seguía sin funcionar). Comprobé el filter del firewall para ver si alguna de las reglas estaba bloqueando el tráfico del desco, pero nada, ninguna. No sé si hay que añadir alguna regla para especificar que x puerto va con vlan2. Como Asus te obliga a usar el puerto 4 para IPTV, pues otra opción que pensé; pero no encontré nada que pudiese hacer eso. Lo unico era cambiar el gateway de la subred, en vez de 192.168.1.2 (en alguno de los parámetros) meter 10.128.0.1 o alguna de las otras de vlan2, pero tampoco le vi mucho sentido así que ni lo probé porque este tipo de cambios le sientan muy mal al mikrotik y le encanta no responder a mis intentos de acceder a la interfaz. Cualquier cambio en gateways (sea en bridge o en un puerto que no se usa) lo lleva muy mal... ---- Ahora lo que debería ser más fácil, en caso de poder hacerse. - A priori el método de bridiging con vlan id=0 y priority=0 para que sea un bridge puro ya está capado por firmware hace tiempo, no? Si quiero tener el vlan6 en el mikrotik y el vlan2 en el hgu: -Puedo conectar la ont al mikrotik, añadir todo lo de vlan6 ahí; y crear un bridge en el mikrotik dónde añada vlan2 a los paquetes salientes, para que el puerto del bridge lo conecte al hgu y funcione. En caso de poder hacerse: Recuerdo hace un año más o menos que al cambiar al hgu el layer2 de gpon a Eth iba fatal. Y era solo para usarlo como router secundario. Cierto es que no me molesté en revisar reglas del firewall, QoS, etc que pudiesen estar pensadas para funcionar con gpon, pero no con eth. ------Acabo de darme cuenta que ayer borré todo lo de vlan2 del router y ahora no puedo usar vlan2 porque tal y como lo tengo configurado todo, si cambio algo o les quito internet a mi familia o le dejo sin Movistar TV a mi padre, así que no podría crear todas las reglas y que se vises todo bien ya que ni habría RIP ni demás. Pego ahora el script que usé de base (el que lo hizo contestó a alguien que el script había que modificarlo para que funcionase bien para Movistar TV... así que, per se este, script no está bien). Su configuración, en general, es muy básica pero al final que funcione o no no va a depender de la complejidad de cosas que no tienen relación alguna. Gracias a todos, especialmente a @Theliel que cuando le consulto algo, nunca es un párrafo fácil de leer y tal... perdona jajaja. -------Ya que estoy voy a por otra duda. Para optimizar la jugabilidad del nefasto fifa 20, está claro que lo más importante es la ruta de tus paquetes al servidor (AWS en este caso, lo que hace que los paquetes udp de fifa no tengan una prioridad increíble). Hay diversas regiones con diferentes rangos de IP (cada vez menos rangos, por desgracia). Voy probando la conexión (directamente jugando) en cada región y rango de ip; la conexión varía de forma increíble (incluso dentro del mismo rango). DNS y CDN aparte... Hay alguna manera de poder analizar e interpretar la conexión y específicamente la ruta de los paquetes hacia una determinada dirección ip? Todos los típicos de tracerout y demás son inservibles. Entre que los icmp te sirven de muy poco, salvo que haya problemas evidentes en algún nodo. Y los UDP son rechazados por el servidor final y la ruta hasta el server varía en cada paquete (se van alternado 2 ó 3 rutas), pero nada de lo que se pueda apreciar tiene correlación alguna con lo que ocurre después en el juego. Literalmente me paso más tiempo probando regiones y rangos distintos; DNS; ajustes dentro del router, etc. que jugando de verdad al juego... Evidentemente la ruta de los paquetes hacia mí no se puede saber, ojalá nos dejasen una herramienta para esto... Utilizo vlan priority=5 (que en movistar va bien, en Jazztel va horrible (no me preguntes el porqué va mejor con 0) y DSCP value=46. Aunque de vez en cuando alterno con el 32 y 40 y el 34. El vlan priority tengo claro que, una vez pase por el primer nodo de la red de movistar, se "descarta"; no creo que movistar incluya una regla para que la vlan Priority de los paquetes se vuelva incluir en los paquetes salientes para que pueda ser utilizada en otro nodo. En cuanto a DSCP, a priori se mantiene en todos los nodos (de ahí que pueda tener la regla en mangle prerouting y no en postrouting como para la priority). ¿puede ser que AWS tenga reglas para priorizar paquetes con DSCP de AF y/o CS, pero dejar EF PHB con menos prioridad? Todo lo que he leído de AWS y Cisco es que no mencionan a EF PHB por ningún lado (salvo en la tabla de dscp evidentemente) y recomiendan usar AF41 para paquetes prioritarios. Se me está yendo la olla pensando que esto puede implicar alguna diferencia (como es el caso de la priority 5 que sí que lo noto de verdad)? Supongo que EA tendrá sus acuerdos con AWS para la prioridad (es decir, que serán los menos prioritarios de toda la red de AWS...) y será esta prioridad general tan importante que cambiar el DSCP no tendrá mucho o ningún efecto. Para poner contexto. He llegado a jugar en servers de Virginia y Connecticut... se notaba que la latencia era brutal, pero era una conexión estable dentro de lo que cabe. El gameplay era más fluido, respondían mejor a los comandos (dentro de que la latencia era 8 ó 9 veces mayor). Es decir, el tráfico saliente de europa (o España en este caso) iba por rutas con mucha menos congestión. Es más, se nota que por la noche (si bien algunas cosas especificas del juego van más fluidas, pero no es por conexión, solo por la incompetencia de los programadores y desarrolladores del juego...) la conexión es infumable, ocurren cosas demasiado raras en los partidos. Como si hubiese mucha pérdida de paquetes. No Delay puro, sino que no llega toda la información cuando tiene que llegar (si un control del balón requiere, por ejemplo, 30 paquetes, si solo llegan bien y rápido 25-27, 3 se pierden (sea por A, por B que por C), se reenvían y llegan 0,5-1s más tarde (vamos que ya no sirven de nada) pues esa acción de controlar la bola se hace mal; lo que lleva a que parezca que tus jugadores son tontos: no controlen la bola, les atraviese, se ralentice el balón al acercarse al jugador, etc. Me podría pasar horas escribiendo cosas especificas del gameplay que son afectadas por la conexión... mejor lo dejo. Última cosa, la ruta de los paquetes será la misma para mi ordenador (ping plotter, etc.) que para los paquetes de xbox? dejando de lado que puede cambiar un poco entre ahora y 5 segundos. Pero esto ocurre en el trace route, ves que varios nodos pueden ir cambiando. Al tener EA sus correspondientes IPs elásticas y reglas de enrutamiento y balance, etc. esto hace que la ruta dentro de AWS sea distinta a la que yo puedo tener si hago un trace route? Muchas gracias de nuevo, Un saludo y espero vuestras respuestas.
... Mostrar más