Uplink del Aruba AP-375: ¿alguna forma de correr un SFP BiDi de Cisco, o el AP está bloqueado a óptica aprobada?
Estamos llevando Wi-Fi a un anexo en un campus. La única fibra que va hacia allá es una sola hebra, así que el plan era colgar un AP-375 ahí y alimentarlo por un par BiDi que ya teníamos en el estante.
- Aruba AP-375, ArubaOS 8
- SFP BiDi de Cisco en la jaula del AP, su longitud de onda pareja en el switch
- una hebra monomodo entre los dos edificios
- el AP en sí está bien, sube normalmente por cobre
AP-375 SFP cage: Cisco BiDi module seated, uplink never comes up
Same BiDi pair between two switches on the bench: link up, no complaintsLo que ya he hecho:
- intercambié las dos longitudes de onda por si tenía el par al revés
- reasenté el módulo y probé un segundo AP-375 del mismo lote
- busqué en la CLI del AP el equivalente al parámetro
allow-unsupported-transceiverque tienen los switches, y no encontré nada parecido
Entonces, ¿un AP-375 acepta algo que no sea la óptica que Aruba bendice, y hay algún comando de desbloqueo en ArubaOS 8 para el AP mismo en lugar de para un switch? Si esto es un bloqueo duro simplemente compraré las piezas aprobadas, pero preferiría saberlo antes de pedir.
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Es un bloqueo duro, y no es la típica historia de óptica codificada. Aruba califica exactamente dos módulos para el uplink del AP, uno SX y uno LX, y el firmware del AP no tiene ningún comando de desbloqueo en absoluto, así que no hay nada que habilitar y ninguna pieza BiDi va a ser aceptada sin importar quién la fabricó.
La razón que dan es térmica más que comercial. El interior de la carcasa de un AP funciona muy por fuera de lo que está clasificado un módulo no industrial normal: un módulo que se cocina ahí dentro puede morir prematuramente, y un módulo que falla en la jaula puede dañar al AP junto con él. Por eso la lista aprobada es corta y por eso no les interesa ampliarla.
Respuesta práctica: saca el número de parte SX o LX aprobado de la guía de pedidos del AP y compra eso. Tu hebra única es la parte incómoda, porque nadie bendice un módulo BiDi para este AP.
Gracias, eso coincide con lo que fui averiguando por el camino largo. Realmente no hay nada en la CLI del AP que se parezca a
allow-unsupported-transceiver, y el AP ni siquiera insinúa que haya visto un módulo, simplemente se queda ahí con el uplink muerto. El mismo par BiDi enlaza dos switches sobre la misma hebra, así que la óptica y la fibra no son el problema.Vamos a pedir el LX aprobado y tender una segunda hebra, el conducto tiene capacidad de sobra. Ligeramente molesto de que el AP no dé nada útil en el log, un simple mensaje de módulo no soportado me habría ahorrado una tarde entera cambiando longitudes de onda.
El mismo tipo de dolor del lado del switch, por si sirve de algo. Un switch Instant On aquí empezó a lanzar una alerta de transceptor no soportado sobre un módulo 1000BASE-T de marca HPE, J8177C, que llevaba ahí siglos en ese puerto. El módulo no cambió, el software sí: la validación de transceptores llegó en el software Instant On 2.9 y cualquier cosa fuera de su lista aceptada queda marcada, incluyendo revisiones más antiguas de piezas HPE.
allow-unsupported-transceivertampoco está ya ahí, y nadie a quien le pregunté ha encontrado cómo silenciar la alerta manteniendo el enlace.En la línea 1930 puede ser peor que una alerta cosmética. Un colega tiene un JL680A donde un SFP de cobre estilo J8177D se registra correctamente como módulo 1000BASE-T y el puerto de todas formas nunca enlaza, sea lo que sea lo que se conecte en el lado RJ45, y esa caja no tiene ninguna forma de anularlo. Los resultados con terceros ahí me parecieron una lotería: algunas piezas FS subieron, otras nunca negociaron, y los mismos módulos andaban bien en equipo Cisco. Compra uno y pruébalo antes de pedir toda una caja.