CodingBox Q&A Ask question

Stick ONU GPON de FS en una jaula SFP+ de un UDM-Pro: sin forma de alcanzar su IP de gestión para escribir el número de serie

Asked Active Viewed 93 AI translation from English
3

Montaje doméstico, y estoy intentando quitar el router del ISP en una línea GPON de Cosmote. La idea es llevar la fibra directamente al UDM-Pro y dejar que el stick haga de ONU, pero el proveedor solo acepta la sesión si se presentan el número de serie de 12 caracteres y la cadena de modelo del CPE antiguo, así que tengo que entrar en el módulo y escribir ambos.

  • Ubiquiti UDM-Pro, stick en el puerto SFP+ 10
  • stick ONU GPON de FS con MAC SFP, artículo 133619
  • latiguillo SC/APC a SC/APC desde la toma de pared
  • CPE antiguo todavía en el escritorio como referencia del número de serie y la cadena de modelo

Mi problema es más básico que la clonación en sí: no puedo alcanzar el módulo en absoluto. Desde el shell del gateway nada responde en su dirección de gestión.

ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10

El segundo comando simplemente se queda ahí hasta que se rinde. Sin banner, sin conexión rechazada, nada.

Lo que ya hice:

  • reasenté el stick y cambié el latiguillo, el módulo enciende y su LED se comporta
  • me aseguré de que nada en el UDM-Pro esté usando 192.168.1.0/24, mi LAN vive en otra subred
  • consideré montar una VLAN de gestión dedicada para la jaula, pero es mucha fontanería para una sola escritura

¿Hay una forma de direccionar la jaula SFP directamente desde el shell del UDM-Pro para poder entrar al stick y escribir el número de serie y el ID del dispositivo, sin levantar una VLAN separada para ello?

Comments 4

Accepted answer

Hay dos cosas separadas en tu camino, y ninguna de las dos es el módulo.

Primero, el direccionamiento. La jaula SFP es una interfaz normal en el UDM-Pro, numerada como el número de puerto mostrado menos uno, así que el puerto 10 es eth9. Dale al gateway una dirección dentro de la subred del módulo y asegúrate de que las respuestas salgan con esa dirección de origen:

ip addr add dev eth9 local 192.168.1.2/24
iptables -t nat -A POSTROUTING -o eth9 -d 192.168.1.0/24 -j SNAT --to 192.168.1.2

Después de eso 192.168.1.10 responde desde el shell del gateway.

Segundo, el handshake. El firmware de estos sticks es lo bastante antiguo como para que su lista de intercambio de claves se quede en los algoritmos heredados, así que hay que nombrar uno explícitamente:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 ONTUSER@192.168.1.10

Una vez dentro, el número de serie del ISP se pone con set_serial_number AVMGXXXXXXXX y la cadena de modelo del dispositivo se clona con sfp_i2c -i7 -s. Reinicia el stick y comprueba qué quedó realmente grabado:

fw_printenv | grep nSerial

Dos advertencias. Nada de esto es una configuración soportada - estás añadiendo a mano una dirección y una regla NAT en un equipo, así que trátalo como fontanería temporal para la sesión de programación y conserva el CPE antiguo hasta que la línea se autentique. La otra mitad de la advertencia es sobre la tasa: 2.5 Gbit no es algo que esta plataforma vaya a aceptar por sí sola, así que incluso un módulo que anuncie 2.5G termina emparejado a 1G o a 10G. Si prefieres no tocar el gateway en absoluto, la alternativa es programar el stick en otra caja con un puerto SFP enrutado y moverlo después.

4 IndonesiaedgepilotID Show original (English) AI translation

¿Cómo llama el propio gateway a esa jaula? En esta caja los puertos SFP son interfaces normales, pero la numeración no coincide con los números impresos en el panel frontal, así que es fácil estar empujando paquetes por algo que no es en absoluto la jaula - y desde el shell eso se ve exactamente como lo que obtuviste, una sesión ahí quieta sin nada al otro lado.

Pega la lista de interfaces del shell del gateway. Una vez esté claro qué interfaz pertenece a ese puerto, la parte del direccionamiento es la mitad fácil.

0 GermanycoreadminDE Show original (English) AI translation

eth9 era exactamente eso, puerto 10 menos uno. La dirección más la regla SNAT hicieron que 192.168.1.10 respondiera al primer intento, y la opción de intercambio de claves heredado fue la otra mitad: sin esa marca mi cliente se rendía durante el handshake, con ella obtuve el prompt de ONTUSER de inmediato.

Escribí el número de serie con set_serial_number AVMGXXXXXXXX, cloné la cadena de modelo con sfp_i2c -i7 -s, reinicié, y fw_printenv | grep nSerial devuelve el valor que fijé. La línea se autenticó unos minutos después y el CPE antiguo ya está desconectado.

Una cosa se confirmó por las malas: el puerto subió a 1G, exactamente como se advirtió sobre los 2.5G en esta jaula. Bien para el perfil que me da el ISP aquí.

3 ChinasfpnodeCN Show original (English) AI translation

Mismo trabajo, piezas distintas, y el número de serie es donde se pone feo. Estaba moviendo una identidad de Calix GigaPoint 801Gv2 a un stick G-010S-A con ritool:

ritool set MfrID 3720
ritool set G984Serial 10010470
ritool set YPSerialNum 10010470

El número de serie del ONT es 372010010470, pero el módulo lo devolvió registrado como

read_sn_from_RI sn is: 3720101470

un cero menos. La razón está en la disposición del campo: el número de serie GPON tiene 8 bytes, los primeros cuatro llevan el ID de fabricante como caracteres ASCII (3720 leído literalmente como cuatro letras) y los últimos cuatro llevan la parte numérica empaquetada en hexadecimal. Una cola decimal como 10010470 no entra dígito por dígito, por eso el eco pierde un carácter.

Así que antes de declarar victoria, comprueba cómo registra tu proveedor el ONT en primer lugar - número de serie o SLID / ID de registro. Escribir solo el número de serie no siempre es lo que ellos usan para el emparejamiento.

4 SpainoptictechES Show original (English) AI translation
Log in to comment. Log in