IPTV HGU (Layer 2 Eth, no Gpon)

NicolasNogueiraRius
Yo probé el VDSL
IPTV HGU (Layer 2 Eth, no Gpon)

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.

 

Mensaje 1 de 9
3.439 Visitas
8 RESPUESTAS 8
NicolasNogueiraRius
Yo probé el VDSL
/interface bridge
add igmp-snooping=yes name=bridge1
/interface ethernet
set 0 name=ether1-gateway
set 1 name=ether2-local
set 2 name=ether3-local
set 3 name=ether4-local
set 4 name=ether5-local
set 5 name=ether6-local
set 6 name=ether7-local
set 7 name=ether8-local
set 8 name=ether9-local
set 9 name=ether10-local
/interface vlan
add interface=ether1-gateway name=vlan2 vlan-id=2
add interface=ether1-gateway name=vlan3 vlan-id=3
add interface=ether1-gateway name=vlan6 vlan-id=6
/interface pppoe-client
add add-default-route=yes allow=pap,chap disabled=no interface=vlan6 \
    keepalive-timeout=60 max-mru=1492 max-mtu=1492 name=pppoe-out1 password=\
    adslppp use-peer-dns=yes user=adslppp@telefonicanetpa
/ip dhcp-server option
add code=240 name=option_para_deco value=\
    "':::::239.0.2.10:22222:v6.0:239.0.2.30:22222'"
/ip pool
add name=dhcp ranges=192.168.1.201-192.168.1.249
/ip dhcp-server
add address-pool=dhcp bootp-support=dynamic disabled=no interface=bridge1 \
    name=Servidor_DHCP
/interface bridge port
add bridge=bridge1 interface=ether2-local
add bridge=bridge1 interface=ether3-local
add bridge=bridge1 interface=ether4-local
add bridge=bridge1 interface=ether5-local
add bridge=bridge1 interface=ether6-local
add bridge=bridge1 interface=ether7-local
add bridge=bridge1 interface=ether8-local
add bridge=bridge1 interface=ether9-local
add bridge=bridge1 interface=ether10-local
/interface bridge settings
set use-ip-firewall-for-pppoe=yes use-ip-firewall-for-vlan=yes
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip settings
set tcp-syncookies=yes
/ip address
add address=192.168.1.1/24 comment="default configuration" interface=bridge1 \
    network=192.168.1.0
add address=192.168.100.10/24 interface=ether1-gateway network=192.168.100.0
add address=192.168.1.10/24 interface=ether1-gateway network=192.168.100.0
 
/ip dhcp-client
add add-default-route=no dhcp-options=hostname,clientid disabled=no \
    interface=vlan3 use-peer-ntp=no
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=80.58.61.254,80.58.61.250 gateway=\
    192.168.1.1 netmask=24
add address=192.168.1.200/30 dhcp-option=option_para_deco dns-server=\
    172.26.23.3 gateway=192.168.1.1 netmask=24
/ip dns
set servers=80.58.61.250,80.58.61.254
/ip firewall filter
add chain=input comment="default configuration" protocol=icmp
add chain=input comment="default configuration" connection-state=established
add chain=input comment="default configuration" connection-state=related
add action=drop chain=input comment="default configuration" in-interface=\
    pppoe-out1
add action=fasttrack-connection chain=forward connection-state=\
established,related
add chain=forward comment="default configuration" connection-state=\
    established
add chain=forward comment="default configuration" connection-state=related
add action=drop chain=forward comment="default configuration" \
    connection-state=invalid
/ip firewall mangle
add action=set-priority chain=postrouting new-priority=4 out-interface=vlan3
add action=set-priority chain=postrouting new-priority=4 out-interface=vlan2
add action=set-priority chain=postrouting new-priority=1 out-interface=\
    pppoe-out1
/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" \
    out-interface=pppoe-out1
add action=masquerade chain=srcnat comment="default configuration" \
    out-interface=ether1-gateway
add action=masquerade chain=srcnat comment="default configuration" \
out-interface=vlan2
add action=masquerade chain=srcnat comment="default configuration" \
    out-interface=vlan3
add action=dst-nat chain=dstnat dst-address-type=local in-interface=\
    vlan2 comment="VOD" to-addresses=192.168.1.200
/ip route
add distance=255 gateway=255.255.255.255
/ip upnp interfaces
add interface=bridge1 type=internal
add interface=pppoe-out1 type=external
/routing igmp-proxy interface
add alternative-subnets=0.0.0.0/0 interface=vlan2 upstream=yes
add interface=bridge1
/routing rip interface
add interface=vlan3 passive=yes receive=v2
add interface=vlan2 passive=yes receive=v2
/routing rip network
add network=10.0.0.0/8
add network=172.26.0.0/16
/system clock
set time-zone-name=Europe/Madrid
/system identity
set name=Router-Core
/system ntp client
set enabled=yes primary-ntp=129.6.15.28 secondary-ntp=129.6.15.29
Mensaje 2 de 9
3.421 Visitas
Theliel
Yo probé el VDSL

Buenas @NicolasNogueiraRius 

 

Uff, voy a ver si logro responder a todo, seguramente se me pase algo, así que me vas diciendo en otros post y vamos viendo.

 

-Sobre QoS/CoS:

Cualquier tráfico hacia Internet, ni QoS ni CoS va a tener ningún impacto fuera de tu red, da igual lo que quieras intentar hacer a nivel de DSCP o PCP. Cualquier nodo va desde ignorar a los bits correspondientes o directamente a sobreescribirlos. Como entenderás, al margen de lo que dicten las normativas, ningún operador de red va a permitir que el usuario por su cara bonita le diga que tiene que priorizar :). Además sería igualmente ilegal, la neutralidad de la red, por suerte obligada en Europa, no permite que ningún tipo de tráfico pueda priorizarse sobre otro, y por ende tampoco penalizarse. Todo el tráfico tiene que tratarse igual. Con lo que ni por buenas ni por malas va a tener el menor efecto. Por supuesto puede tener un gran impacto dentro de la red local.

 

Sobre 802.1p la cosa difiere. Movistar al usar VLANs para separar el tráfico, usa también 802.1p para marcar la prioridad del tráfico ,o mejor dicho, para clasificarlo. El estándar no fija las reglas que tendrá cada prioridad, eso lo configura cada uno, es decir, en este caso Movistar configura en sus sistemas (no en el Router) las reglas que se aplicarán a cada prioridad. Pero viendo las prioridades que usa en sus servicios, siguen las recomendaciones de 802.11p, 1 para el tráfico de fondo (internet) y 4 para el tráfico VoIP/IPTV, aunque aquí es verdad que la recomendación es usar 5 para VoIP. Esto si tiene cierto impacto, pero no para internet, ya hemos dicho que eso es digamos totalmente tabu. Pero que no se pueda priorizar el tráfico externo, no quiere decir que Movistar en su red si pueda priorizar los servicios. Es decir, Movistar va a tratar todo el tráfico de Internet de sus usuarios de igual modo, pero ese tráfico puede tener menos prioridad en su red que el tráfico VoIP o IPTV.

 

Tampoco ganaríamos mucho en este punto, la red de Movistar lleva por caminos muy diferentes cada tráfico. Lo único que conseguiríamos en todo caso en manipular 802.1p en el Router sería empeorar la conexión, y eso siempre que Movistar no lo sobreescribiese en la OLT, que sería lo más normal, ya que el tráfico va por una VLAN diferente, Movistar casi no tiene que hacer nada para sobreescribir de las cabeceras lo que le de la gana.

 

 

-Sobre IPTV

Nunca he tenido un Mikrotik, nunca me he llevado bien con ellos, demasiados bug, caros para el hardware que es no me gustan. Me quedo mucho antes con EdgeRoute para eso. Así que realmente específicamente sobre ellos no puedo decirte nada, solo de un modo general, que realmente no existe motivo por el que no se pueda implementar en cualquier Router que permita un acceso a bajo nivel. Sinceramente tampoco me ha quedado claro que equipo quieres conectar a que y como, luego lo releo un poco porque no me queda claro que es lo que quieres pasar a cada lado

 

Partamos de lo sencillo, tenemos una ONT, la que sea, y entrega todo el tráfico a un Router. Dices que ignoramos de base la VLAN 6 y la 3 y nos centramos en la IPTV, que es la VLAN 2. Es cierto que la configuración va a ser muy muy diferente si se configura IPTV a nivel global en el Router o específicamente a un puerto. Jamás lo he configurado a puerto, me parece una pérdida de tiempo y una solución cutre, que es la que usan muchos fabricantes para ahorrarse hacer las cosas como dios manda. Así que seguiré con mi esquema de siempre, una configuración del Router "global".

 

Para configurar la interfaz WAN para IPTV se necesita básicamente sólo 4-5 cosillas:

 

-VLAN y Etiquetado

-Rutas y enmascaramiento

-Servidor DNS condicional
-Configuración IP

-Extra: IGMP Proxy/Snooping.

 

La mayoría de esos 5 puntos son casi directos, y creo que casi en cualquier sistema la configuración es sencilla:

 

-Configuración IP:

Efectivamente hace falta los datos del Router de Movistar. Estos datos son únicos para cada cliente, no se obtienen por DHCP como si pasa con VoIP. Así que no queda más remedio que tenerlos a mano, y se configura la VLAN2 con los datos pertinentes, IP, Máscara y Puerta de enlace. Dependiendo del Router, pues se configura como sea, en sistemas Linux simplemente:

 

 

 

ifconfig vlan2 $VLAN2_IP netmask $VLAN2_MASK up

 

 

 

-Rutas (Y enmascaramiento):

Movistar usa RIP, con lo que en realidad se pueden usar directamente con cualquier cliente/demonio RIP. Movistar usa en la mayoría de los equipos Zebra, pero no tiene que dar más problemas. La configuración de RIP ya dependerá del cliente/demonio que sea. En equipos donde esto no es viable, tampoco tiene mayor complicación, se pueden crear 1 o 2 rutas estáticas para cubrir todas las que pueda anunciar Movistar. Es un truco sucio, pero extremadamente efectivo, simplemente es coger todas las rutas que suele usar, y usar una máscara más incluyente. Por ejemplo, esta es la que suelo usar cuando configuro equipos manualmente, o para otras luchas:

 

 

 

TVIP_DEST="172.26.0.0"
TVIP_MASK="255.240.0.0"

route add -net $IPTV_DEST gw $IPTV_GATEWAY netmask $IPTV_MASK vlan2

 

 

 

O si se quiere afinar un poco más se pueden crear dos con una máscara algo menor. El caso es que sea por RIP, sea de forma manual, las rutas como es lógico tienen que estar, para que el Router sepa a que interfaz WAN subirla.

 

Como es habitual, al hacer un cambio de interfaz y meternos en la red pertinente, todo el tráfico IPTV que suba se debe de enmascarar a la interfaz WAN pertinente, es decir, hacer en esencia un snat. De nuevo en sistemas Linux es trivial:

 

 

iptables -t nat -A POSTROUTING -o vlan2 -j MASQUERADE

 

 

 

-Servidor DNS Condicional

A muchos fabricantes le da como que repulsión el poder usar un servidor DNS que contemple la asignación de un servidor DNS diferente en función del cliente DHCP que la solicite. La cuestión es simple, cuando se configura de forma global, el Deco recibirá los datos por DHCP al igual que cualquier otro dispositivo. Lo ideal es que el Router solo tenga corriendo un servidor DHCP. Que es lo que hacen algunos fabricantes? Lo anclan solo a un puerto Ethernet concreto, y obligan al deco a configurarse de forma manual con los datos IP, mascara, puerta de enlace y DNS, así que lo único que hacen es pasar ese puerto físico como VLAN directamente, es más, dependiendo de, no tienen siquiera que lidiar con rutas.

 

La cuestión es que un servidor DHCP bien configurado debería de ser capaz perfectamente de asignar una DNS específica a un cliente específico en función de su ID. Por lo general no es necesario especificar  la opción 240, pero ya que estamos se hace también. De nuevo el como se configura pues depende de cada Router. Siguiendo con Linux, lo mas habitual es usar dnsmasq, sería algo así, sin asignar ningún rango diferenciado IP

 

 

dhcp-vendorclass=ial,IAL
dhcp-option=ial,6,172.26.23.3
dhcp-option=ial,240,:::::239.0.2.10:22222:v6.0:239.0.2.30:22222

 

 

Movistar en los HGU usa una implementación modificada de udhcpd para añadir el servidor condicional y algunas cosas más. Repito, esto ya depende de cada servidor DHCP. Lo importante es en cualquier caso el servidor DNS, que es prioritario

 

 

-IGMP Proxy/Snooping

De nuevo esto va a depender del equipo que sea, y otra de las cosas que se ahorran los fabricantes al usarlo a puerto. Esto tampoco debería de ser ningún problema, cualquier Router mínimamente decente soportará ambos. En Linux, usando igmpproxy:

 

 

quickleave
phyint vlan2 upstream ratelimit 0 threshold 1
altnet 172.26.0.0/16;        
altnet 172.23.0.0/16;
phyint br0 downstream ratelimit 0 threshold 1

 

 

En ese caso he puesto las dos rutas separadas, la que puse originariamente incluía ambas. Se puede poner tb ahí incluyente cambiando la máscara.

 

Movistar en este caso ahora usa mcpd, también bastante implementado en muchos Routers, en este caso eth0

 

 

##### IGMP configuration #####
igmp-default-version 3
igmp-query-interval 120
igmp-query-response-interval 10
igmp-last-member-query-interval 10
igmp-robustness-value 2
igmp-lan-to-lan-multicast 0
igmp-max-groups 25
igmp-max-sources 25
igmp-max-members 25
igmp-fast-leave 1
igmp-admission-required 0
igmp-admission-bridging-filter 0
igmp-proxy-interfaces vlan2
igmp-snooping-interfaces br0
igmp-mcast-interfaces vlan2
#

 

 

La configuración de IGMP snooping es aun más dependiente de cada router. Con mcpd lo gestiona también, pero cada equipo bueno... lo dicho.

 

 

-VLAN y Etiquetado

Aquí tampoco debería de existir más problemas, lo único es conocer como siempre que sintaxis y herramientas nos da el Router. En sistemas Linux esto es más puñetero porque generalmente la gestión se tiene que derivar al propio Switch interno, y es muy habitual que el fabricante use unas herramientas u otras. En lo que llevo de vida me he encontrado muchas. Lo habitual es usar vconfig para asignar las interfaces que se quieran a la VLAN, en este caso entendiendo eth0 el puerto que va a la ONT

 

 

vconfig add eth0 2

 

 

Y por último... bueno realmente tendría que ser lo primero, la creación y etiquetado del trunk. En todo momento se ha usado vlan2, pero realmente dependiendo de la herramienta usada la interfaz se llamará de un modo o de otro. La configuración aquí como digo si es totalmente dependiente y es complicado encontrar 2  iguales. Por ejemplo, algunos equipos Asus usan robocfg, otros usan ethctl como algunos Asus/Askey...

 

Con Robocfg sería así:

 

 

robocfg vlan 2 ports "4t 5t"

 

 

 En este caso concreto, el puerto 4 sería eth0 (WAN) y el puerto 5 sería el "puerto" interno a la CPU del Router, necesario igualmente para configurarse de forma global, a todos los puertos. La t designaría que se está etiquetando (trunk). Eso crearía una VLAN2 dentro del Switch de manera global, sin estar asignada a un puerto en concreto de este. La ventaja es obvia... puedes conectar lo que quieras donde quieras.

 

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

 

 

Por supuesto todo esto se puede simplificar mucho si dedicamos un puerto específico para ello, pero... para gustos colores, en lo personal me gusta hacer las cosas bien. El como exactamente se tendría que hacer el Mikrotik.. .eso me temo que ya no puedo ayudarte mucho, no tengo ninguno por aquí y tampoco me interesa demasiado su hardware, como he dicho les tengo manía 😉

 

No tengo claro si me dejo algo....



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 3 de 9
3.377 Visitas
juaneduardoleche
Más integrado que la RDSI

 

 

Señor @Theliel  

 

Gracias por todo ese informacion que usted tiene comparitdo con la comunidad. Perdon mi espanol si no escribo perfecto. Soy Italiano y Colombiano... ahora vivo en Colombia fijo...

 

Tengo una problema muy simular. Hace poco tenemos servicio Fibra optica de Movistar aca en Medellin. Mis equipos que tengo aca son un EdgeRouter 6p y un EdgeSwitch 8 - y un Ubiquiti Fiber Nano por mi ONT

 

Como entiendo ... el servico aca es muy simlular como funciona todo con movistar en Espana. 

 

pppoe0 con usaro / clave robado del router "GPT-2741GNAC " pero muy poko configuraciones se pueden acceder por como tiene el router completamente bloqueado. 

 

por un script de java fue capaz de robar el usario y clave del pppoe int y ya tengo internet funcionando - 

 

hay tres lineas virtuales que llegan desde el ONT:

 

int pppoe sobre eth0.100 es el internet 

int eth0.101 es el Voice (no lo uso ni me importa)

int eth0.102 es el IPTV

 

Routes llegando desde GW:  10.91.64.1 

172.28.12.32/28

172.29.48.0/20

172.29.32.0/20

 

Estos parece que están llegando desde el int wan (pppoe) pero no estoy seguro. 

Voy a ajuntar una captura de modem de la fabrica mostrando el "routing table" 

 

 

tengo lo mismo problem que muchos y estoy acuerdo de lo que tienes escrito sobre todo lo que necesito uno para dejar todo funcionando:

 

por el poco información q puedo ver es que el modem de Movistar esta usando RIP y MCAST para llevar los "routes" y "grupos" de MCAST al VLAN.

 

Yo ha intentando de conectar un neighbor con RIP al router upstream pero no funciona. ( esto es el primer paso como entiendo para puede sigue con el MCAST y IGMP

 

No se si usted tiene tiempo para ayudaré con eso estará demasiado agradecido y capaz de colaborarte con algo por su tiempo.

 

Creo que si podemos llegar un solución y compile un configuración que funciona con Ubiquiti y Movistar (Triple play)  eso va a ayudar mucha gente aca en Colombia que tiene lo mismo configuración. 

 

Voy a ajuntar el "routing table" Y otras capturas que tengo del modem de la fabrica. 

 

Million de gracias antes de todo si leas ese mensaje. 

 

Bendiciones Señor,

 

JL

 

Screen Shot 2021-08-09 at 10.51.26 AM.png• General.pngGPon Wan Interface Editclose.pngO Obtain an IP Address Automatically.pngLAN1.pngLAN2.png

 

Mensaje 4 de 9
2.560 Visitas
Theliel
Yo probé el VDSL

Buenas @juaneduardoleche 

 

Como entenderás, no puedo saber feacientemente nada desde España, no sé como tiene allí configurado todo Movistar, y mucho menos los por menores.

 

En cualquier caso, por lo que dices, parece bastante simple, y "similar" a la estructura en España.

 

Por lo que dices allí se usan igualmente una configuración en 3 VLAN taggeadas:

 

-Internet: VLAN 100 -> Interfaz ppp0
requerirá autentificación usuario/contraseña posiblemente. Aquí en España hace años que no se valida, y en cualquier caso el  usuario/contraseña aquí es universal, todos tenemos el mismo.

 

-VoIP: VLAN 101 -> Interfaz nas1

Aquí en España la interfaz VoIP no requiere de una configuración especial, obtiene los datos IP de forma automática como cliente DHCP, pero si requiere una o dos rutas, que por defecto obtiene (repito aquí en España) desde la misma interfaz de VoIP. Allí puede requerir una configuración IP manual estática o no, y las rutas podrían llegar desde la misma interfaz o desde WAN directamente sin etiquetar.

 

-IPTV: VLAN 102 -> Interfaz nas2

Aquí en España se requiere una configuración manual de los datos IPs (IP, Máscara, GW), cada cliente tiene la suya propia, que generalmente se extrae del Router de Movistar, echando un ojo en la interfaz IPTV configurada en el Router. Aquí en España no vale obtener los datos por DHCP.

Respecto a las Rutas, de nuevo, tanto la interfaz VoIP Como la interfaz IPTV, ambas usan RIP para obtener las rutas necesarias.

 

-----------

 

Allí no puedo saber por qué interfaz están llegando las rutas. Pueden estar llegando cada una por su propia interfaz, que es lo que hacen aquí y sería lo más normal, pero no puedo saberlo de forma segura por lo que pones.

 

En cualquier caso de querer sustituir también la ONT por una propia, ten en cuenta que no vale cualquier ONT, y que estás sumando más incertidumbre al problema, y que podría ser la ONT la causante de todo. Tendríamos que asumir en todo momento que la ONT que usas está bien configurada y que soporta perfectamente la configuración de Fibra de Movistar. Repito, es mucho suponer.

 

Suponiendo que eso fuese correcto, el resto sería simplemente configurar las 3 interfaces WAN en el Edge. Una PPPoE sin complicación, La VoIP tampoco requiere mucho porque usa un cliente DHCP, y la IPTV yo buscaría los datos asignados por Movistar, si es igual que aquí, los requiere.

 

Una vez configuradas las Interfaces WAN, levantar RIP en IPTV y VoIP. CUIDADO!! Si las rutas no están llegando por las interfaces independientes, no se van a poder ver, y abría que levantar RIP en la interfaz WAN de entrada, no en las "subinterfaces". Otra razón por la que las rutas pueden no estar llegando, es porque las emiten con un TTL ajustado, si el TTL se reduce a cero el paquete se descarta, Es una práctica muy común, y suele ser necesario en muchos casos configurar el Router para modificar el TTL si cae por debajo de un valor ANTES de procesar el tráfico, o el Router lo descartará. Esto igualmente en iptables es trivial.

 

Para el ER específicamente, escribí hace tiempo un post por el foro explicando la configuración para TripleVLAN en España, gracias a la aportación de un compañero del Foro que me donó una unidad. Sería readaptarlo a las peculiaridades y cambios que se estén haciendo allí, que como te digo no conozco ni tengo forma de saber.

 

Saludos.

 

 



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 5 de 9
2.524 Visitas
Técnico-Movistar
Técnico Banda Ancha

Hola @juaneduardoleche.

 

Te pedimos disculpas por las molestias ocasionadas. Comprobamos que nos escribes desde fuera de territorio español. Por este motivo debo informarte que desde este foro sólo tratamos consultas sobre productos y servicios comercializados por Movistar de España. Para contactar con tu Comunidad, accede a www.movistar.com

Muchas gracias @Theliel por tu aportación.

 

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 6 de 9
2.515 Visitas
juaneduardoleche
Más integrado que la RDSI

@Técnico-Movistar 

 

Con todo respeto Señora Angela. Estoy aca en los foros de España porque no hay comunidad con conocimiento aca sobre esas temas mucho menos sobre protocolos de IGMP y RIP. El servico y equipo es nuevo aca. 

 

Pero si me estan echando 😉 agale pues... 

 

Saludos y gracias por toda la bienvenida.

 

jL

Mensaje 7 de 9
2.509 Visitas
Técnico-Movistar
Técnico Banda Ancha

Hola @juaneduardoleche.

 

Para poder ayudarte mejor, sobre la conexión que se realiza en tu línea, te recomendamos que contactes con el foro de la Comunidad del país donde tienes contratada la línea en www.movistar.com, porque ahí podrán comprobar la configuración de tu línea y así podrán ayudarte mejor. 

 

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 8 de 9
2.487 Visitas
Técnico-Movistar
Técnico Banda Ancha

Hola @juaneduardoleche

 

No hemos tenido respuesta tuya en unos días, entendemos que no tienes más dudas Si no es así, o tienes cualquier duda/incidencia estamos a tu disposición. 


Un saludo. 


Fernando.



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 9 de 9
2.474 Visitas