Problemas al hacer un update de una Tabla Squeltch

Al hacer unas pruebas de contingencia en la Isla de Hierro se ha producido un error al dar de baja un camino.

Resulta qua al hacer un update de la Tabla Squeltch esta falla, da KoConnect, vamos que no ha hecho nada.

Miramos los tp’s involucrados en ese nodo y se observa que existe una crossconexión entre ambos, y como uno es el lado este y otro el Oeste, es una conexión de las denominadas de paso.

Para Actualizar la Tabla MS-Spring una de las condiciones es que no exista esa conexión de paso.

Realizamos una Auditoria del equipo y nos da esa conexión solo GER. Hacemos el Autodescubrimiento del Tp, y no hay rutas alternativas, es decir que no pertenece a ningún circuito. Por lo tanto podemos directametne eliminar la crossconexión y posteriormente Actualizar la Tabla.

Supongo que se eliminó esa conexión o directamante dieron de baja el camino, solución mala (ya que deja la planta desalineada) pero en caso de urgencia… habría que pasar para ello el autodescubrimiento.

Crossconexiones Ocupadas

Se nos presenta un nuevo caso en un equipo de LUCENT, el usuario realiza un nuevo trazado, y le sale erróneo, no sabe porqué. Me pasan la incidencia, y en seguida veo el identificador de la petición que  falla. Es al realizar una crossconexión que la rechaza el gestor, es más ni siquiera la manda al equipo. La respuesta es bien clara:

Creation of Cross Connection between CC1,12.133 and CC1,3.141 on PDSPER16P1/46AB081 failed.
Unable to comply because SNC ports in use for NE PDSPER16P1/46AB081.
Request not sent to the Network Element(s)

identificamos los Tp’s, el puerto al que pertenecen y el equipo de Red correspondiente.

Realizamos una Auditoría, y ¡¡ Dios mio !! la de Tp’s y Puertos que tiene, lo más complicado es moverse entre tanta “letra”, cada identificador del Tp es de la forma “PDSP.ER TR01:TTSF16P 16-1C:1:X622_LKA44:91:622MB_T:1:TU12_CTP::2:133:N:::::” si , suena a Chino, pero con un poco de práctica se entiende, el identificador prácticamente nos dice donde está el Tp, aque puerto pertenece, la tarjeta y el equipo, y donde está el equipo.

Bien a lo que voy , al realizar la auditoría sale que uno de los Tp’s esta crossconectado con otro de la misma tarjeta pero otro puerto. Y está identificado como SOLO GESTOR, es decir qeu nuuestro sistema no lo tiene.

Bueno pues ahora le toca decidir al Usuario si borra la crossconexión , es peligroso por que puede cortar el tráfico, o si elige otro camino. Esto son los problemas de tener mal inventariada la planta, que al final quedan caminos huerfanos.

Yo soy partidario de Buscar al circuito de la crossconexión ocupante otro camino, e inventariarlo que no la 2º solución buscar un trazado alternativo, por que al final seguro que vuelve a pasar la misma incidencia pero con otro circuito.

Problemas de Malos Trazados

Incidencia interesante en los equipos de Ericsson.

El Usuario nos dice que el equipo rechaza la operación de alta de circuito Ethernet con el mensaje “ResourceProblem::WrongTypeObject desde la interfaz Q3 del gestor”

Vamos al equipo y vemos 2 Tp’s Resueltos pero lo que es raro el tipo de crossconexión que pide es un agregado con un puerto de Otra tarjeta.

Revisamos el trazado para ello abrimos el trabajo y consultamos el plan, -> en el lado izquierdo ver entidad asociada, nos la llevamos al browser, y vemos el routing display,  observando el enlace que aparece con DV vemos como salta ala vista que pertenecen a 2 puertos de tarejtas diferentes, ahí está el error!.

Se verifica también con el nombre tan largo que facilidad usa y si esa está disponible.

 

 

Problemas de cruce de caminos

Hoy me ha tocado atender una incidencia acerca de una crossconexión que se pedía en un equipo Alcatel. Mirando las trazas se pide una crossconexión tradicional (al estilo SDH) entre 2 puertos de la misma placa, 2 puertos ethernet. Evidentemente casca

El pardillo de mi, en cuanto ve que el Tp ( el punto de conexion de capas, que no Puerto) está alarmado, Zas supongo que por estar alarmado no dejará hacer la conexión.

Pues maaaal, esa no es la razón. 1º es un equipo WDM no admite “crossconexiones”, por decirlo así, tan solo mira lo que hay en el equipo, osea es una incedencia de Provisión en vez de CMG, y yo me la trago, avisar a Provisión de que no metan la pata.

Hay que analizar el circuito que se pretende crear, y se ve que la facilidad del camino , digamos inferior, el SFO, cruza sus facilidades, es decir la facilidad 3 la conecta al puerto 4 y la facilidad 4 al puerto 3.

Si lo hubiese realizado correctamente la configuración, al elegir la facilidad 3 necesariamente necesita elegir el puerto 3 de la placa, y lo mismo con la 4.

Otro asunto es ¿como deducir apartir del camino , sacar la facilidad y los Tp’s involucrados en el puerto? Eso para otro día os lo cuento