Segmento de fibra queda UP en un solo extremo
Fecha: 16 de abril del 2021
Escenario
Al realizar una nueva conexión de fibra a un switch mediante un uplink de fibra, notamos que el puerto no levanta,
pero en el equipo remoto si. Tratándose de un enlace del tipo P2P donde si un extremo cae se lleva abajo al otro
esto inicialmente puede dejarnos perplejos, aunque la solución, luego de un mal rato, nos parece sencilla y queda
como una anécdota mas (y un laboratorio mas).
1. Verificación inicial:
Verificamos tanto en el chasis 6500 como en el switch en el extremo de la fibra (al que llegamos por otro camino).
2.- Verificamos el transceiver y el Rx de
la fibra:
Podemos ver que la recepción de fibra está OK y coincide con lo medido en el power meter.
6500#sh int gi1/20 transceiver
Transceiver monitoring is disabled
for all interfaces.
ITU Channel not available
(Wavelength not available),
Transceiver is internally calibrated.
Alarms applicable
when thresholds or values are not N/A.
If device is externally calibrated,
only calibrated values are printed.
++ : high
alarm, + : high warning, - : low warning, -- : low alarm.
NA or N/A: not applicable, Tx: transmit, Rx: receive.
mA: milliamperes, dBm: decibels
(milliwatts).
Optical Optical
Temperature Voltage Current
Tx Power Rx Power
Port (Celsius) (Volts) (mA)
(dBm) (dBm)
---------- ------------ ---------- ---------- ----------- ------------
Gi1/20 35.1 3.27 22.6 -5.3 -6.4
6500#
Podemos verificar que los dBm son aproximados con lo que reporta el SFP.
Podemos comprobar que con un media converter el vínculo levanta sin problemas, por lo que
definitivamente descartamos la fibra.
3.- Verificamos que sucede en el extremo si
bajamos / levantamos el port:
De paso probamos con el “viejo truco” del shut / no shut que muchas veces nos salva.
4.- Verificamos cambiando valores en el
port del equipo remoto:
Al intentar empezar a “jugar” con los parámetros del port (aunque en un SFP no hay mucho por tocar,
ya que el GBIC si es de 1000 trabajará a 1000 y la fibra nunca será half-duplex) nos encontramos con
el siguiente mensaje en el switch del extremo:
Lo cual nos lleva a probar en el chasis 6500:
6500#conf t
Enter configuration
commands, one per line. End with CNTL/Z.
6500(config)#int gi1/20
6500(config-if)#speed ?
1000 Force 1000 Mbps
operation
nonegotiate Do not negotiate
speed
6500(config-if)#duplex ?
% Unrecognized command
6500(config-if)#
6500(config-if)#speed nonegotiate
6500(config-if)#shut
6500(config-if)#no shut
6500(config-if)#end
6500#
6500#sh int gi1/20
GigabitEthernet1/20 is
up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is
0021.a00a.2783 (bia 0021.a00a.2783)
Description:
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload
1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s
input flow-control is off, output
flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output
hang never
Last clearing of "show interface"
counters never
Input queue: 0/2000/0/0
(size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0
packets/sec
9 packets input, 2150 bytes, 0 no buffer
Received 9 broadcasts (9 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun,
0 ignored
0 watchdog, 0 multicast, 0 pause input
6500#
5.- Resúmen:
El estado de la situación era este: un extremo tenía negociación y el otro no. Un extremo quedaba negociando
y el otro asumía que los parámetros eran fijos y levantaba, sin tener en cuenta que el extremo quedaba down.
Afortunadamente me encontré con esta página que me aclaró la situación mediante esta simpática tabla:
Fuente: herdingpackets.net
Fuente: https://kb.vmware.com/s/article/1004089
Mas allá de
lo simple de esta lab, es importante tener esto en cuenta para no tener uno de
“esos días”.
(2021) Stand UP ! (please)
Rosario, Argentina