Gestión de chasis de conversores de medios en una MAN

INDICE
Introducción.................................................................................................................................3
Origen de la INC iGRI....................................................................................................................3
1.- OMEGA................................................................................................................................3
2.- Centros Técnicos: OMAVCTC02, OMRSRTCTU-OPE, OPCSCNOC.........................................3
3.- Asignación y Activación: Normalmente OMRSCOIPDA-01..................................................3
4.- La propia unidad que se ocupe de garantizar la gestión de los chasis.................................3
COMPETENCIAS............................................................................................................................4
Ámbito de actuación................................................................................................................4
Hardware bajo responsabilidad...............................................................................................4
Tipos de chasis.............................................................................................................................4
Unión con la MAN........................................................................................................................4
Acceso a los chasis en banda........................................................................................................5
Chasis Inelcom..........................................................................................................................5
Chasis Telnet (dos posibilidades)..............................................................................................5
Acceso a los chasis fuera de banda..............................................................................................5
Chasis Inelcom..........................................................................................................................5
Chasis Telnet............................................................................................................................5
Tecnología INELCOM....................................................................................................................7
REPUESTOS...............................................................................................................................7
Hardware de chasis INELCOM..................................................................................................7
Conexión en local a una SNMP INELCOM...............................................................................10
Tecnología TELNET.....................................................................................................................11
Repuestos...............................................................................................................................11
Controladoras de chasis Telnet..............................................................................................12
Puertos de las tarjetas SNMP y como encadenan..................................................................12
Fuentes de alimentación Telnet.............................................................................................13
EJEMPLO DE SNMP TELNET....................................................................................................14
Conexión en local a una SNMP TELNET..................................................................................15
TRATAMIENTO DE INCIDENCIAS.................................................................................................17
Anexo FUENTES DE ALIMENTACION ambas tecnologías............................................................21
FOTOS F.A.Telnet.......................................................................................................................21
Introducción
Con éste documento se busca que cualquier técnico pueda diagnosticar y resolver una incidencia de
falta de gestión en un chasis de conversores de medios.

En cualquier caso y dado que siempre se quedan cosas en el tintero, me podéis consultar cualquier
duda, por teléfono: 900122032 o por mail: franciscojavier.quinterocarrasco@telefonica.com

Origen de la INC iGRI

1.- OMEGA
Tipo de síntoma : PERDIDA GESTION CHASIS

Síntoma: Chasis no accesible por telnet o snmp---

Tipo de síntoma : FALLO DE ALIMENTACION ó ALARMA OMEGA

Síntoma: Fallo alimentación echmhe1-101 A=1 B=0--- <---FA A Mal (OJO, en Componente
pondrá que falla la B, Ej.: echmhe1-101_B)

Podemos verlo con el script:

[egrsmco1-001] operador > sacafuentes echmhe1-101

ESTADO DE FUENTES CHASIS echmhe1-101

============================================

FUENTE A MAL

FUENTE B OK

También se puede ver con los gestores gráficos, son muy intuitivos.

2.- Centros Técnicos: OMAVCTC02, OMRSRTCTU-OPE, OPCSCNOC

Síntoma: Nos informarán que por avería han intentado acceder a un CM y no han podido.

NOTA: No aceptar chasis que vengan como avería BOL o REC, normalmente lo descubren a raíz de una
avería de cliente y lo que hacen los CCTT es pasar el BOL/REC y despreocuparse de la avería de cliente.
Pre-franquear diciendo que la avería del cliente no tiene que ver con la “gestión” del chasis de
conversores y que sí no pueden acceder al CM simplemente disponen de una herramienta menos de
diagnóstico para su avería de cliente pero de ninguna manera deben desentenderse de la reclamación
justificándolo en la falta de gestión de un chasis de CM. En tal caso nos deberían pasar una INC iGRI con
el fallo de gestión del chasis. Normalmente creamos nosotros mismos la INC (si no está ya creada por
otra vía…..), y devolvemos el BOL o la REC.

3.- Asignación y Activación: Normalmente OMRSCOIPDA-01

Síntoma: Nos informarán que han intentado dar un alta/baja y no han podido acceder a un CM.

4.- La propia unidad que se ocupe de garantizar la gestión de los chasis .

Les han avisado por teléfono de que no hay gestión de un chasis porque no tienen medios para abrir
INC. O bien vosotros mismos habéis descubierto un chasis sin gestión del cual OMEGA no ha abierto INC.
COMPETENCIAS
Á mbito de actuació n.
La gestión de los chasis de conversores de medios que tienen CM de circuitos de clientes que entran en
las MAN'es.

Normalmente son clientes MetroLAN/MacroLAN, Operadoras, etc...

No llevamos los chasis de conversores de medios de las EEBB, NodosB,... Se debe encargar CNAI

Tampoco llevamos chasis que usan en Transporte, como por ejemplo en los trazados con Radioenlace.
Los lleva OMRSRTCNT.

Hardware bajo responsabilidad.

Prácticamente todas excepto los CM (conversores de Medios). Aunque a veces un CM averiado puede
influir en la controladora y en que el chasis no esté gestionable, en ese caso tenemos que cambiar
nosotros el CM.

Llevamos las controladoras, las fuentes de alimentación, los propios chasis (la estructura física donde
van las tarjetas), cableados/conectores que lo unen a la MAN (en el caso de chasis co-ubicados),
cableados/conectores que lo unen al DWDM (en el caso de centrales remotas donde no hay MAN).

Tipos de chasis
A grandes rasgos los dividiremos en tres:

1.- Chasis tecnología Telnet antiguos o no encadenados.

Su nombre echXY-0zz , X=identificativo Atlas del emplazamiento, Y= nº MAN, zz nº chasis.

Ej. echvcm1-001

2.- Chasis tecnología Telnet encadenados.

Su nombre echXY-1vzz , X=identificativo Atlas del emplazamiento, Y= nº MAN, zz nº chasis. v=0

Telefónica, v distinto de 0= Chasis con clientes ORLA.

Ej. echmaga1-1001, Ej. ORLA echmde1-1301

3.- Chasis tecnología Inelcom:

Su nombre echXY-1zz , X=identificativo Atlas del emplazamiento, Y= nº MAN, zz nº chasis.

Ej. emtsbin2-101

Unión con la MAN

Se hace desde un puerto RJ45 de la controladora y por cable ethernet se une al nodo de la MAN. En caso
de localizaciones remotas (sin MAN), habrá DWDM por medio.

Acceso a los chasis en banda

 Chasis Inelcom
Vía gestor de Inelcom. Acceso al escritorio remoto Inelcom IMUX_11 (User Name: omnimba, Password:
n1v3ld2s!), luego acceso al gestor (Usuario:txxxxxx, Clave:S_xxxxxx), donde xxxxxx es tu matrícula.

Chasis Telnet (dos posibilidades)

1.- Vía gestor de Telnet. Acceso al escritorio remoto Telnet (Contraseña: n1v3ld2s!), luego acceso al
gestor "Login Console" (Server IP Address= localhost, User Name= ctsebcn, Password= "ninguna,
dejamos en blanco")

2.- Que es la que usamos nosotros, vía CLI (línea de comandos). telnet al nombre del chasis, ej:
[egrsmco1-001] operador > telnet echvcm1-001, (login: admin, Password: admin).

Acceso a los chasis fuera de banda

Chasis Inelcom
No tienen gestión fuera de banda (acceso remoto por consola).

Chasis Telnet
Entramos al router de consola del CNSO ersmco1-002, user, pw, y enable = cisco.

Buscamos el chasis de conversores. Entramos en el como en el ejemplo, pw =cisco (lo pide la consola
remota, la del emplazamiento del chasis).

Una vez en la SNMP del chasis, user= admin, nº slot = 0, pw= admin.

Para salir: control+may+6 y manteniendo las tres teclas, pulsamos x. Una vez fuera, damos disc

Veamos un ejemplo:
[egrsmco1-001] operador > telnet ersmco1-002

Trying 172.20.10.158...

Connected to ersmco1-002.gestion.man.telefonica.es.

Escape character is '^]'.

C** TELEFONICA - eBA. Queda prohibido cualquier acceso no autorizado **

User Access Verification

Password:

C GRABAR LA CFG CON EL COMANDO salvar

ersmco1-002>en

Password:

ersmco1-002#show running-config | include echvrub1-1001

ip host echvrub1-1001-SNMP 2069 172.22.22.225

ersmco1-002#echvrub1-1001-SNMP 2069

Trying echvrub1-1001-SNMP (172.22.22.225, 2069)... Open

** TELEFONICA - eBA. Queda prohibido cualquier acceso no autorizado **

User Access Verification

Password:

Password OK

echvrub1-1001 login: admin

Introducir el numero de slot [1-12] o 0 para acceso a Master-SNMP:

Login en Master SNMP

Modulo gestion TELNET-RI para Master SNMP de bastidor v2.5.5

login: admin

Password:

TELNET R.I. Operative System (TRI.OS v1.24)

[admin@echvrub1-1001]#

[admin@echvrub1-1001]# exit

echvrub1-1001 login:

ersmco1-002#disc

Closing connection to echvrub1-1001-SNMP [confirm]

ersmco1-002#exit

Connection closed by foreign host.

[egrsmco1-001] operador >

Tecnología INELCOM
REPUESTOS
Repuestos INELCOM
Sistema en LORCET: CDM_I
Código
Telefónico Código INELCOM Descripción

683200 IMUX209.A Modulo de Control

683201 IMUX210.A Modulo de Conexiones -48v
683202 IMUX211.A Armazón de 19" para bastidor ETSI
683203 IMUX206.A Conversor Central CM-100-IB
683204 IMUX207.A Tarjeta Central AO-GBIC-IB
683205 IMUX208.B Conversor SDHL IP de Central
683206 IMUX306.A Conversor Cliente CM-100-IB
683207 IMUX307.A Adaptador Cliente AO-GBIC-IB
683208 IMUX308.B Conversor SDHL IP de Cliente
683209 IMUX206.C Tarjeta Central CM-100-IB Monofibra
683210 IMUX306.C Conversor Cliente CM-100-IB Monofibra
683215 IMUX206.M U.CTE 100BASE-FX Monofibra SC
683225 IMUX325.A GENERADOR DE MEDIDAS y MONIT. DE CALIDAD

NOTA: Al consultar en el gestor el modelo de conversor, no nos podemos fiar, siempre dirá que es un
CM (683203 IMUX206.A).

Únicamente lo podemos saber cuándo nos lo dice el GMO. Podría ser CM, AO, SDHL, CM monofibra.
Aunque en la mayoría de las veces lo que tenemos en planta son CM. Y en cualquier caso, es la única
parte que “no llevamos”, lo llevan los CCTT.

Hardware de chasis INELCOM

La controladora se llama “CM”, de “control module”, a veces también la llamamos “SNMP” o módulo de
comunicación SNMP como a las de los chasis Telnet. Va en el chasis 1 y controla todos los conversores
de todos los chasis/subchasis del bastidor, realmente son dos bastidores con un total de hasta 16 chasis
o subchasis. Por esa razón el primero tiene un conversor menos, 15 en lugar de 16.

Ocupa el slot 1. Los conversores van del slot 2 al 16. En el resto de estantes los CM van del slot 1 al 16.

En esta tecnología NO tenemos fuentes de alimentación propiamente dicho, realmente son unos
módulos o tarjetas que hacen de “toma de alimentación”, dos tomas de -48 v de cc, A y B. Igual que en
los Telnet, podemos ver la entrada de tensión con el script sacafuentes + nombre del chasis. Hay uno
por estante y van en el slot 0. Se llaman Módulo de conexiones y también presentan un conjunto de
micro-interruptores que posibilita la configuración de determinadas características de funcionamiento.
Presentan dos bancos de micro-interruptores, SW1 y SW2:

SW1: Su función es cargar el bus de comunicaciones (solamente en el primer y último armazón).

SW1-1 y SW1-2 Deben estar a ON en el primer y último armazón y OFF en el resto.

SW2: Asigna la identidad de cada armazón o chasis, puede haber hasta 16 por cada controladora. Y
numeran según la siguiente tabla:
 Conexión en local a una SNMP INELCOM
Por ejemplo para configurar una SNMP nueva. En los chasis Inelcom no hay gestión fuera de banda (por
consola).

No vale el HiperTerminal, se necesita el programa de instalación y pruebas propio de INELCOM,

"IMUX706EXA14.zip " y cable de consola propio de INELCOM cuyo pineado y descripción se puede
encontrar en el apartado 5.4 del manual de Instalación "imux828mi.a04.pdf ".
Tecnología TELNET
Repuestos

Repuestos TELNET Sistema en LORCET: CDM _T

Código
Telefónico Código TELNET Descripción

683302 CHASIS 3U -48V MINISAE CHASIS 3U (ALTA POTENCIA )

683303 CHASIS 3U -48VL MINISAE CHASIS 3UL

683304 CHASIS MICROSAE 220V CHASIS MICROSAE 220V
683340 CHASIS 3U -48VL CORTO MINISAE CHASIS 3U -48VL CORTO
683341 FUENTE 3U -48VL CORTO FUENTE ALIMENT. 3U -48VL CORTO
683306 FUENTE 3U -48V FUENTE ALIMENTACION 3/4V -48v (ALTA POTENCIA )
683307 FUENTE 3U -48VL FUENTE ALIMENTACION 3/4V -48vL
683308 SNMP 3U No hay repuestos no se fabricaTARJETA SNMP 3/4U
683310 SNMP Chain ENCADENADO SNMP Chain ENCADENADO
683311 SNMP Tri Chain SNMP Tri Chain ENCADENADO
683312 CM-100 LX/RJ-IB-SAE TARJETA BIFIBRA 10km(CENTRAL)
683314 CM-100 LX40/RJ-IB-SAE TARJETA BIFIBRA 40km(CENTRAL)
683316 CM-100 LX/RJ-IB-220-19" EQUIPO BIFIBRA 19" 10km(CLIENTE)
683318 CM-100 LX40/RJ-IB-220-19" EQUIPO BIFIBRA 19" 40km

683322 CM100V3 IB SAE LX/RJ TARJETA BIFIBRA V3

683324 CM100V3 IB SAE LX40/RJ TARJETA BIFIBRA V3 40km
683326 SH-104 IB SAE TARJETA SHDSL 4 HILOS
683328 CM100V3 IB SAE MF15TX1550 TARJETA MONOFIBRA CENTRAL
683332 CM100V3 IB SAE MF40TX1550 TARJETA MONOFIBRA CENTRAL 40KM
683334 CM100V3 IB SAE MF15TX1310 TARJETA MONOFIBRA CLIENTE

683336 CM100V3 IB SAE MF40TX1310 TARJETA MONOFIBRA CLIENTE 40KM

744423 METROSAE CHASIS 4U CORTO -48 CHASIS 4U C -48

753108 VENTILAD 4/5U C VENTILADOR 4/5U C -48V (4 ventiladores)

744422 CHASIS 5U C -48
753063 VENTILADOR 4U -48V VENTILADOR 4/5U ( 3 ventiladores)
753060 FUENTE 3/4/5U -48V FUENTE ALIMENTACION 4U -48V
 Controladoras de chasis Telnet
Las hay de tres tipos:

1.- 683308 SNMP antigua (ya no se fabrica aunque quedan en stock). Versión hardware (ver con el
comando #device info):

v1.5.0, 1.6.0 , 2.3.0, 2.4.0 y 3.1.2

2.- 683310 SNMP Chain ENCADENADO no se fabrica, queda alguna, la sustituye 683311. Versión
hardware (ver con el comando #device info): v2.4.1

3.- 683311 SNMP Tri Chain ENCADENADO. Versión hardware (ver con el comando #device info): v2.6.0 ,
3.0.0

Chasis Telnet antiguos, no encadenados pueden usar cualquiera de las tres.

Chasis Telnet encadenados pueden usar 683310 (dos puertos eth), a extinguir, se puede pedir la
683311, son compatibles y en éste caso LORCET acepta la devolución de una 683310. O se puede dar el
caso de pedir 683310 y LORCET enviar 683311.

O también pueden usar 683311 (tres puertos eth, de arriba abajo: Chain, Eth/Con y Console)

Puertos de las tarjetas SNMP y como encadenan

Los chasis telnet encadenados van uniéndose unos a otros, por ej. echmno1-1001 se une a echmno1-
1002, éste a echmno1-1003 y así sucesivamente, en este caso tenemos hasta echmno1-1007

Las SNMP de los chasis 1001 son “maestras”, las demás (1002, 1003….), son SNMP “esclavas”.

La SNMP tri-CHAIN maestras (1001), tiene tres puertos:

Puerto de arriba: Llamado CHAIN, lleva un cable eth. que va al puerto central de la tarjeta 1002.

Puerto central: Llamado ETH/CON, lleva un cable eth. que une la SNMP a la MAN.

Puerto inferior: Llamado CONS, lleva el cable para entrar por consola remota, vía RDSI. No siempre
equipado.

En las SNMP tri-CHAIN esclavas, 1002, 1003, 1004, etc…:

Puerto de arriba: Llamado CHAIN, lleva un cable eth. al puerto central de la tarjeta siguiente (de 1002 a
1003, de 1003 a 1004, etc…).

Puerto central: Llamado ETH/CON, recibe el cable eth. que la une a la tarjeta anterior.

Puerto inferior: Llamado CONS, libre.

La tarjeta CHAIN (683310) tienen dos puertos aunque en los chasis de las SNMP-CHAIN hay un cable que
va desde el puerto de arriba (puerto ETH), a un derivador colocado en la parte superior del chasis a la
altura de la SNMP que convierte dicho puerto en dos, con lo que en la práctica es como si tuviese un
total de tres puertos y funciona como las tarjeta SNMP tri-CHAIN de tres puertos. El puerto inferior es el
de consola.
Ejemplo de chasis encadenados (no está muy claro, ver explicación en texto anterior):

Fuentes de alimentación Telnet

Hay tres tipos: es difícil saber de que tipo son a menos que el GMO nos describa como son:

683341 F.A. 3U -48VL CORTO : Cables de alimentación por delante, ver foto al final del documento.

683306 F.A. 3U -48V (ALTA POTENCIA ): Puede llevar tanto CM como AO (adaptadores ópticos).

Ver foto.

683307 F.A. 3U -48VL: Sólo puede llevar CM. Ver foto al final del documento.
 EJEMPLO DE SNMP TELNET
Es antigua, las tri-Chain son similares pero con tres puertos ethernet en lugar de dos.
 Conexión en local a una SNMP TELNET
Por ejemplo para configurar una SNMP nueva que no tiene gestión fuera de banda (por consola).

Se hace con cualquier PC con tarjeta de red y usando el HiperTerminal:

Para conectarnos hay dos tipos de cables de consola dependiendo del tipo de SNMP-Telnet:

Conector tipo 1 para SNMP antíguas (normales y plus), y SNMP tri-Chain (tres puertos).
Conector tipo 2 para SNMP Chain:
TRATAMIENTO DE INCIDENCIAS
1.-Mirar si hay alguna INC ya abierta del chasis de CM. Evitamos duplicidades.

2.-Mirar sí ha tenido alguna avería reciente. Nos puede servir de orientación. Sí ya se reseteo la SNMP,
iremos directamnete a cambiarla

3.-Mirar sí hay alguna incidencia del puerto de la MAN donde entra el chasis y aunque no la haya, mirar
dicho puerto, ¿tiene link?, ¿tiene errores?, mirar en el LOG, ¿el puerto ha tenido cortes aunque ahora
esté arriba?. Sí hay link en el puerto de la MAN y le hacemos ping al la SNMP, ¿se incrementan los
contadores de tráfico del puerto/MAN?, ¿en entrada y salida?, ¿sólo en salida?, etc:

En este caso, mirar cableado/conectores antes que la SNMP.

4.-¿Hay JDS?, pasar la INC a OMRSSUTX-JDS (con el Id. del circuito), para que nos digan cómo lo ven.
Este circuito, sí no se está usando no tiene tráfico, sí JDS lo necesita le dejamos puesto un ping continuo
a la dir. IP de la SNMP (la podemos encontrar por ej. en el campo Description del puerto de la MAN), o al
nemónico: > ping -s echmno1-1001

5.-¿Se llega por ping a la SNMP pero no por telnet?, en estos casos, casi siempre recupera reseteando la
SNMP, intentar primero por comando (>reset), si no, reseteo físico. En algunos casos, pocos, no es
suficiente con el reseteo y hay que cambiarla.

6.- ¿Vemos la MAC de la SNMP en el nodo de la MAN?. ¿Podemos entrar fuera de banda? (sólo SNMP
telnet, y sólo donde disponible).

7.- ¿Llegamos a la SNMP-Telnet pero los chasis encadenados y/o los CM no se ven?, resetear la SNMP y
sí no recupera cambiarla.

8.-Puede haber un CM que esté mal e influya en la gestión. Habría que sacarlos todos en horario
nocturno e ir metiendo de uno en uno hasta localizar el malo, el que deja el chasis sin gestión. Aunque
sea un CM, lo cambiamos nosostros.

9.-¿Estamos casi seguros que el problema está en JDS pero nos dicen que lo ven bien?, para asegurar
que es problema de JDS:

1º Enfrentamos un PC, JDSU o similar al puerto de la MAN (incluyendo cableado hasta el DWDM), GMO
crea en el PC una conexión con los datos de la SNMP y lanza ping al gateway o nosotros a la dirección IP
de la SNMP, debe contestar el PC del GMO. Con eso comprobamos ese tramo.

2º Vamos al emplazamiento del chasis de CM, GMO conecta el PC a la salida del DWDM y hacemos la
misma prueba, sí no hay conectividad, el problema está en JDS. En este emplazamiento el GMO se
puede conectar también contra la SNMP y hacerle Ping para ver si le contesta. En este caso pondrá
como dir. Ip propia, la del gateway.

Sí es necesario cambiar la SNMP, hay que configurar el nuevo repuesto, al menos la dir. Ip, dir. de re red,
máscara y gateway. Lo hace el GMO entrando por consola (ver apartado entrar por consola, en local).

En muchos chasis Telnet que tienen gestión fuera de banda, podemos entrar nosotros en remoto y
configurar la SNMP:

Recordemos, user: admin, pw: admin. Una vez dentro:

Printamos las variables con “printbootenv”, de fábrica vienen mas o menos así (depende sí es reparado):
[admin@master-snmp-plus]# printbootenv

Variables guardadas en flash (BOOTENVARS)

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

2 SNMPGESTOR: [13] 172.26.128.40

 3 TRAPCOMMUNITY: [06] public

4 IPADDR: [13] 172.26.128.30

5 NETADDR: [12] 172.26.128.0

6 NETMASK: [13] 255.255.255.0

8 HWADDR0: [17] 00:09:58:E0:83:75

10 BAUDSPEED: [06] 115200

12 TIPOEQUIPO: [02] 33

15 SYSNAME: [16] master-snmp-plus

16 SYSLOCATION: [07] 3UCHAIN

37 TARTGESTION: [02] SI

52 MOUNT_USR: [02] SI

53 STARTCONSOLA: [02] SI

54 CONSOLE: [01] 0

57 NUM_IFS_ETH: [01] 2

58 HWADDR1: [17] 00:09:58:E8:83:75

62 IPADDR1: [08] 1.1.1.14

63 NETADDR1: [07] 1.1.1.0

64 NETMASK1: [15] 255.255.255.240

68 SETCOMMUNITY: [06] public

69 GETCOMMUNITY: [06] public

71 DUPLEX: [01] 2

75 POLL_GESTOR: [01] 0

84 SYNC_PROTO: [01] 2

86 BP_MAXIMOS: [52] 5500,3600,20000,20000,800,50000,50000,5600,5600,5600

87 BP_MINIMOS: [36] 4400,3100,0,0,100,0,0,4400,4400,4400

97 DEVCODE: [01] 5

100 PASSWD_TELNET: [11] KmfiIy0OZzw

104 VERSION_HARD: [08] 0x020600

109 LOGLEVEL: [01] 0

121 TIMEOUT_TELNET: [04] 9999

127 NUM_RACK_SLOTS: [02] 12

134 TRAP_FLAGS: [02] 96

140 [sin nombre]: [13] quiet mem=32M

141 [sin nombre]: [01] 1

151 [sin nombre]: [07] 1296000

154 [sin nombre]: [27] Automatic Security Reset ON

166 [sin nombre]: [08] 0x010200

Normalmente tocaremos las variables 4 (dir.IP), 5(dir. Red), 6(mascara), 7(gateway), 12(=33 para SNMP
maestra ó =142 para las encadenadas, 15(nombre del chasis*), y 142(sólo para SNMP esclavas, =2 para
1002, =3 para 1003, etc…)

Las variables se introducen con el siguiente comando y formato:

>setbootenv X Y, donde X= nº variable, Y=parámetro de la variable, ej:

>setbootenv 4 172.26.128.30

>setbootenv 6 255.255.255.240, -----misma máscara en todos los CM Telnet e Inelcom de la planta

>setbootenv 15 echmno1-1001 *,

*El nombre del nodo no aparecerá hasta que reseteemos la tarjeta, los demás valores los toma
inmediatamente al dar “enter”.

No obstante, hay otra manera de meter el nombre para que lo tome sin necesidad de reset:>hostname
echmno1-1001

Veamos un ejemplo de buscar el gateway por si no lo tenemos:

echmno1-1001 entra según Atlas en emtmno2-101;1/2/11

> A:emtmno2-101# show port 1/2/11

===============================================================================

Ethernet Interface

===============================================================================

Description : GST_echmno1-1001_Ethernet_172.22.20.179 ------ Nombre y dir.IP

Interface : 1/2/11 Oper Speed : 10 mbps

Link-level : Ethernet Config Speed : 10 mbps

Admin State : up Oper Duplex : full

Oper State : up Config Duplex : full

Physical Link : Yes MTU : 1514

A:emtmno2-101# show router arp

===============================================================================

ARP Table (Router: Base)

===============================================================================

IP Address MAC Address Expiry Type Interface

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

172.22.17.24 00:1a:f0:08:60:00 00h00m00s Oth system

172.22.21.217 00:16:4d:d7:06:9f 02h33m43s Dyn[I] IPst.2

172.22.21.218 00:1a:f0:08:61:42 00h00m00s Oth[I] IPst.2

172.22.20.177 00:16:4d:7a:d2:6f 00h00m00s Oth[I] IP_GEST_AUX --GATEWAY , (hay que

fijarse en lo verde)

172.22.20.178 00:17:5a:ed:22:50 00h54m04s Dyn[I] IP_GEST_AUX

172.22.20.179 00:09:58:e8:83:ef 03h59m58s Dyn[I] IP_GEST_AUX -- MAC de nuestro
chasis

172.22.20.180 00:09:58:e8:89:f6 03h59m16s Dyn[I] IP_GEST_AUX

172.22.20.181 00:09:58:e8:8d:13 03h59m17s Dyn[I] IP_GEST_AUX

172.22.20.182 00:09:58:e8:8f:d0 03h47m31s Dyn[I] IP_GEST_AUX

172.22.20.183 00:09:58:e8:90:6a 01h40m54s Dyn[I] IP_GEST_AUX

172.22.20.190 00:13:48:00:69:05 03h58m11s Dyn[I] IP_GEST_AUX

172.22.101.29 10:e8:78:4e:50:9d 01h11m48s Dyn[I] IPst.3

172.22.101.30 00:1a:f0:08:61:43 00h00m00s Oth[I] IPst.3

172.22.225.0 00:1a:f0:08:61:45 00h00m00s Oth[I] IPst.5

172.22.225.1 98:b0:39:81:ab:a5 02h25m42s Dyn[I] IPst.5

No. of ARP Entries: 15

Anexo FUENTES DE ALIMENTACION ambas tecnologías
Podemos ver su estado con el gestor gráfico o bien pidiendo las variables snmp’s (mibs),
correspondientes con el script “sacafuentes”, sirve para ambas tecnologías, cuando son encadenados se
le pide a la SNMP maestra y nos dá todos:
> sacafuentes echmno1-1001

echmno1-1001;172.22.20.179;M/NORTE;20081013103407;BASTIDOR_TELNET_SONDA;MADRID;M/
NORTE;ACTIVE;

CHASIS FA FB TEMPERATURA

echmno1-1001 53 52 19

echmno1-1002 49 49

echmno1-1003 47 47

echmno1-1004 48 47

echmno1-1005 47 47

echmno1-1006 48 48

echmno1-1007 48 48

FOTOS F.A.Telnet
683341 F.A. 3U -48VL CORTO : Cables de alimentación por delante:
683306 F.A. 3U -48V (ALTA POTENCIA ): Puede llevar tanto CM como AO (adaptadores ópticos):

683307 F.A. 3U -48VL: Sólo puede llevar CM: