Troubleshooting de Flaps de Porta nos Catalyst 9000 Switches
Contents
Problema
Este documento descreve como solucionar problemas de uma ou mais interfaces de switch que alteram repetidamente o estado entre ativo e inativo (oscilações de porta ou oscilações de link), o que causa conectividade intermitente.
Ambiente
Switches Cisco Catalyst 9000 Series com uplinks/downlinks de cobre ou fibra. O problema pode ocorrer em portas de acesso, uplinks e (quando presentes) portas removíveis do módulo de rede. O caminho físico pode incluir patch panels, dispositivos de endpoint e transceptores ópticos.
- Aplicabilidade de mídia: O TDR aplica-se somente a interfaces de cobre; O DOM se aplica somente a transceptores ópticos suportados.
- Tipos de interface: As portas fixas autônomas e as portas de módulo estão no escopo; use o mesmo fluxo de trabalho para ambos.
- Suporte óptico: Use somente a óptica suportada para a plataforma e a versão do software.
Causa
As causas comuns incluem cabeamento incorreto ou não suportado, transceptores Small Form-Fator Pluggable (SFP) ou Small Form-Fator Pluggable Plus (SFP+) sem suporte ou defeituosos, incompatibilidades de negociação ou duplex, comportamento de economia de energia de endpoint e outras falhas de camada física.
Resolução
Siga o fluxo de trabalho de Troubleshooting neste artigo para confirmar a oscilação nos logs, validar a conectividade física e óptica, revisar os contadores de interface e executar verificações de TDR somente de cobre ou DOM somente de fibra conforme aplicável.
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento.
Componentes Utilizados
As informações neste documento são baseadas nos switches Cisco Catalyst 9000 Series.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
Uma oscilação de porta, também conhecida como oscilação de link, ocorre quando uma interface física no switch fica repetidamente ativa e inativa. As causas comuns incluem cabeamento incorreto, não suportado ou fora do padrão, transceptores Small Form-Fator Pluggable (SFP) não suportados e outros problemas de sincronização de link. A condição pode ser intermitente ou permanente.
Como oscilações de link tendem a ser um problema físico, este documento descreve como diagnosticar o problema, coletar registros úteis e solucionar problemas de oscilações de porta em switches Cisco Catalyst 9000 Series.
Troubleshooting de Fluxo de Trabalho
Use esse fluxo de trabalho para isolar as causas mais comuns de oscilações de porta. Inicie na Etapa 1 e continue na ordem. Execute etapas opcionais somente quando o tipo de link e os sintomas corresponderem.
- Confirme a oscilação nos logs. Use show logging para confirmar eventos repetidos de atividade/inatividade e capturar carimbos de data/hora.
- Verifique a conectividade física e a óptica. Verificar o cabeamento, os patch panels e os transceivers suportados; recoloque ou troque por componentes em boas condições.
- Revise os contadores da interface e as estatísticas do hardware. Use show interfaces e contadores de controlador para identificar erros de Camada 1 (CRC, erros de símbolo, erros de FCS).
- Execute o TDR (apenas links de cobre). Use o TDR para detectar condições OPEN/SHORT e a distância aproximada da falha.
- Verifique DOM (somente links de fibra). Reveja a potência/temperatura/tensão óptica em relação aos limites da folha de dados.
- Verifique o FEC (somente ópticas suportadas). Confirme as configurações Forward Error Correction e compatibility quando aplicável.
- Use os comandos debugsomente se o problema persistir. Colete a saída de debug direcionada durante uma janela de reprodução e desative ela imediatamente após a captura.
Cada seção inclui uma breve observação que indica quando usá-la.
Use esta seção quando o acesso físico estiver disponível. Verifique se os módulos de rede, os cabos e os transceptores SFP ou SFP+ estão instalados corretamente antes de examinar os contadores ou executar diagnósticos adicionais.
Referência de instalação do módulo de rede
Use esta referência quando um módulo de rede removível estiver presente. A tabela descreve as melhores práticas para instalar um módulo de rede em um switch Cisco Catalyst 9000 Series:
| Platform |
URL |
| Catalyst 9200 Series Switches |
Guia de instalação de hardware dos switches Catalyst 9200 Series |
| Catalyst 9300 Series Switches |
Guia de instalação de hardware dos switches Catalyst 9300 Series |
| Catalyst 9400 Series Switches |
Guia de instalação de hardware dos switches Catalyst 9400 Series |
| Catalyst 9500 Series Switches |
Guia de instalação de hardware dos switches Catalyst 9500 Series |
| Catalyst 9600 Series Switches |
Guia de instalação de hardware dos switches Catalyst 9600 Series |
Verifique o cabo e os dois lados da conexão
Use esta seção depois que a oscilação for confirmada nos logs. Essas tabelas descrevem as causas comuns relacionadas ao cabo das oscilações de link e as ações de recuperação recomendadas.
| Causa |
Ação de Recuperação |
| Cabo incorreto |
Troque o cabo suspeito por um cabo em boas condições. Procure por pinos quebrados ou faltantes nos conectores. |
| Conexão solta |
Recoloque o cabo. Remova o conector e reinsira-o para garantir que esteja totalmente encaixado. |
| Painéis de Correção |
Elimine conexões defeituosas do patch panel. Ignore o patch panel, se possível, para eliminá-lo. |
| SFP ruim ou errado (específico para fibra) |
Troque o SFP suspeito por um SFP em boas condições. Verifique o suporte de hardware e software para esse tipo de SFP. |
| Porta ou porta do módulo defeituosa |
Mova o cabo até uma porta em boas condições para solucionar problemas de uma porta ou módulo suspeito. |
| Dispositivo de ponto de extremidade inválido ou antigo |
Troque o telefone, o alto-falante ou outro endpoint por um dispositivo em boas condições ou um dispositivo mais novo. |
| Modo de hibernação do dispositivo |
Esta pode ser uma oscilação esperada. Verifique o carimbo de data/hora da aba da porta. Compare-o com outros eventos simultâneos. Em seguida, determine se a causa é uma configuração de suspensão. |
Verificar compatibilidade SFP e SFP+
Use esta seção quando o link não sincronizado usar um transceptor de fibra. O portfólio de interfaces de conexão automática da Cisco oferece um amplo conjunto de opções para velocidades, protocolos, alcances e meios de transmissão suportados.
Use qualquer combinação de módulos transceptores SFP ou SFP+ suportada pelo switch Cisco Catalyst 9000 Series. Cada porta deve corresponder às especificações de comprimento de onda na outra extremidade do cabo. O cabo não deve exceder o comprimento suportado para comunicação confiável.
Use apenas módulos transceptores SFP da Cisco no dispositivo Cisco. Cada módulo transceptor SFP ou SFP+ suporta o recurso de identificação de qualidade (ID) da Cisco. Esse recurso permite que um switch ou roteador da Cisco identifique e valide se o módulo transceptor é certificado e testado pela Cisco.
Identificar oscilações de porta
Pré-requisitos: Acesso EXEC privilegiado (por exemplo, habilitar) e acesso ao buffer de log do sistema do dispositivo ou syslog remoto.
Resultado esperado: Mensagens up/down repetidas para a mesma interface em uma janela de tempo curta confirmam uma condição de oscilação.
Use esta seção primeiro para confirmar se está ocorrendo uma oscilação. Execute o comando show logging | include changed para identificar um evento de oscilação de link. Este exemplo mostra mensagens de log do sistema de switch parcial para um evento de oscilação de link na interface TenGigabitEthernet1/0/40:
Switch#show logging | include changed
August 17 21:06:08.431 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:06:39.058 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:06:41.968 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:06:42.969 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:07:20.041 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:07:21.041 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:07:36.534 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:06.598 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:07.628 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:08:08.628 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:08:10.943 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:11.944 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
- Identifique o carimbo de data/hora de cada transição ativa/inativa.
- Compare o carimbo de data/hora com outros eventos na mesma interface (por exemplo, comportamento de economia de energia do endpoint).
- Determine se a oscilação é esperada ou indica um problema na camada física.
Comandos show da interface
Quando usar: Após a confirmação de repetidos eventos up/down, o caminho físico é validado.
Comando: show interfaces e show controllers ethernet-controller interface para a interface afetada.
Resultado esperado: Os contadores de erro (CRC, erros de símbolo, FCS) permanecem estáveis ou aumentam lentamente em condições normais.
Ação seguinte se anormal: Troque cabo/fibra ótica, mova-se para uma porta em boas condições e verifique os contadores novamente; vá para TDR (cobre) ou DOM (fibra), conforme aplicável.
Use esta seção depois que a oscilação for confirmada e o caminho físico for verificado. O comando show interfaces fornece informações que ajudam a identificar um possível problema na Camada 1 que causa um evento de oscilação de link:
Switch#show interfaces tenGigabitEthernet 1/0/40
TenGigabitEthernet1/0/40 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 00a5.bf9c.29a8 (bia 00a5.bf9c.29a8)
MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 10Gb/s, link type is auto, media type is SFP-10GBase-SR <-- SFP plugged into the port
input flow-control is on, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, 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
670 packets input, 78317 bytes, 0 no buffer
Received 540 broadcasts (540 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 540 multicast, 0 pause input
0 input packets with dribble condition detected
1766 packets output, 146082 bytes, 0 underruns
0 Output 0 broadcasts (0 multicasts)
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
A tabela lista alguns dos contadores do comando show interfaces:
| Contador |
Problemas e causas comuns que aumentam os contadores de erros |
| CRC |
Um número alto de erros de verificação de redundância cíclica (CRC) é geralmente o resultado de colisões. Ele também pode indicar um problema físico, como cabeamento, um SFP, uma interface incorreta ou uma placa de rede (NIC). Também pode indicar uma incompatibilidade duplex. |
| Erros de Entrada |
Isto inclui runts, giants, sem buffer, Verificação de Redundância Cíclica (CRC), frame, overrun e contagens ignoradas. Outros erros relacionados à entrada também podem aumentar a contagem de erros de entrada. |
| erros de saída |
Os erros de saída podem aumentar quando a fila de saída estiver subdimensionada ou quando a interface estiver com excesso de assinaturas. |
| Total de quedas de saída |
Os descartes de saída geralmente são o resultado do excesso de assinaturas de interface causado por padrões de tráfego muitos para um ou uma transferência de 10 Gbps para 1 Gbps. Os buffers de interface são um recurso limitado e podem absorver um burst apenas até um ponto. Depois desse ponto, os pacotes começam a cair. Os buffers podem ser ajustados para fornecer alguma almofada, mas não podem garantir quedas de saída zero. |
| Descartes de protocolo desconhecidos |
Quedas de protocolo desconhecidas ocorrem quando a interface de recebimento não está configurada para esse protocolo ou quando o switch não reconhece o protocolo. Por exemplo, se dois switches estiverem conectados e o Cisco Discovery Protocol (CDP) estiver desabilitado em uma interface de switch, quedas desconhecidas de protocolo ocorrerão nessa interface. Os pacotes CDP não são mais reconhecidos e o switch os descarta. |
O comando history permite que uma interface mantenha o histórico de utilização em um formato gráfico semelhante ao histórico da CPU. O histórico pode ser mantido como bits por segundo (bps) ou pacotes por segundo (pps), como mostrado neste exemplo:
Switch(config-if)#history ?
bps Maintain history in bits/second
pps Maintain history in packets/second
Junto com a taxa, vários contadores de interface podem ser monitorados:
Switch(config-if)#history [bps|pps] ?
all Include all counters
babbles Include ethernet output babbles - Babbl
crcs Include CRCs - CRCs
deferred Include ethernet output deferred - Defer
dribbles Include dribbles - Dribl
excessive-collisions Include ethernet excessive output collisions -
ExCol
flushes Include flushes - Flush
frame-errors Include frame errors - FrErr
giants Include giants - Giant
ignored Include ignored - Ignor
input-broadcasts Include input broadcasts - iBcst
input-drops Include input drops - iDrop
input-errors Include input errors - iErr
interface-resets Include interface resets - IRset
late-collisions Include ethernet late output collisions - LtCol
lost-carrier Include ethernet output lost carrier - LstCr
multi-collisions Include ethernet multiple output collisions -
MlCol
multicast Include ethernet input multicast - MlCst
no-carrier Include ethernet output no-carrier - NoCarr
output-broadcasts Include output broadcasts - oBcst
output-buffer-failures Include output buffer failures - oBufF
output-buffers-swapped-out Include output buffers swapped out - oBSwO
output-drops Include output drops - oDrop
output-errors Include output errors - oErr
output-no-buffer Include output no buffer - oNoBf
overruns Include overruns - OvrRn
pause-input Include ethernet input pause - PsIn
pause-output Include ethernet output pause - PsOut
runts Include runts - Runts
single-collisions Include ethernet single output collisions - SnCol
throttles Include throttles - Thrtl
underruns Include underruns - UndRn
unknown-protocol-drops Include unknown protocol drops - Unkno
watchdog Include ethernet output watchdog - Wtchdg
<cr> <cr>
SW_1(config-if)#
Assim como no histórico da CPU, os gráficos estão disponíveis para os últimos 60 segundos, os últimos 60 minutos e as últimas 72 horas. Gráficos separados são mantidos para histogramas de entrada e saída:
Switch#show interfaces gigabitEthernet 1/0/2 history ?
60min Display 60 minute histograms only
60sec Display 60 second histograms only
72hour Display 72 hour histograms only
all Display all three histogram intervals
both Display both input and output histograms
input Display input histograms only
output Display output histograms only
| Output modifiers
<cr> <cr>
------ Sample output ---------
Switch#show interfaces tenGigabitEthernet 1/0/9 history 60sec
10
9
8
7
6
5
4
3
2
1
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
TenGigabitEthernet1/0/9 input rate(mbits/sec) (last 60 seconds)
10
9
8
7
6
5
4
3
2
1
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
TenGigabitEthernet1/0/9 output rate(mbits/sec) (last 60 seconds)
Use o comando show controllers ethernet-controller interface {interface{interface-number}} para exibir contadores de tráfego por interface (Transmissão e Recebimento) e estatísticas de erro lidas do hardware. Use a palavra-chave phy para exibir os registros internos da interface. Use a palavra-chave port-info para exibir informações sobre o ASIC (application-specific integrated circuit) da porta.
Este é um exemplo de saída do comando show controllers ethernet-controller para uma interface específica:
Switch#show controllers ethernet-controller tenGigabitEthernet 2/0/1
Transmit TenGigabitEthernet2/0/1 Receive
61572 Total bytes 282909 Total bytes
0 Unicast frames 600 Unicast frames
0 Unicast bytes 38400 Unicast bytes
308 Multicast frames 3163 Multicast frames
61572 Multicast bytes 244509 Multicast bytes
0 Broadcast frames 0 Broadcast frames
0 Broadcast bytes 0 Broadcast bytes
0 System FCS error frames 0 IpgViolation frames
0 MacUnderrun frames 0 MacOverrun frames
0 Pause frames 0 Pause frames
0 Cos 0 Pause frames 0 Cos 0 Pause frames
0 Cos 1 Pause frames 0 Cos 1 Pause frames
0 Cos 2 Pause frames 0 Cos 2 Pause frames
0 Cos 3 Pause frames 0 Cos 3 Pause frames
0 Cos 4 Pause frames 0 Cos 4 Pause frames
0 Cos 5 Pause frames 0 Cos 5 Pause frames
0 Cos 6 Pause frames 0 Cos 6 Pause frames
0 Cos 7 Pause frames 0 Cos 7 Pause frames
0 Oam frames 0 OamProcessed frames
0 Oam frames 0 OamDropped frames
193 Minimum size frames 3646 Minimum size frames
0 65 to 127 byte frames 1 65 to 127 byte frames
0 128 to 255 byte frames 0 128 to 255 byte frames
115 256 to 511 byte frames 116 256 to 511 byte frames
0 512 to 1023 byte frames 0 512 to 1023 byte frames
0 1024 to 1518 byte frames 0 1024 to 1518 byte frames
0 1519 to 2047 byte frames 0 1519 to 2047 byte frames
0 2048 to 4095 byte frames 0 2048 to 4095 byte frames
0 4096 to 8191 byte frames 0 4096 to 8191 byte frames
0 8192 to 16383 byte frames 0 8192 to 16383 byte frames
0 16384 to 32767 byte frame 0 16384 to 32767 byte frame
0 > 32768 byte frames 0 > 32768 byte frames
0 Late collision frames 0 SymbolErr frames <-- Usually indicates Layer 1 issues. Large amounts of symbol errors can indicate a bad device, cable, or hardware.
0 Excess Defer frames 0 Collision fragments <-- If this counter increments, this is an indication that the ports are configured at half-duplex.
0 Good (1 coll) frames 0 ValidUnderSize frames
0 Good (>1 coll) frames 0 InvalidOverSize frames
0 Deferred frames 0 ValidOverSize frames
0 Gold frames dropped 0 FcsErr frames <-- Are the result of collisions at half-duplex, a duplex mismatch, bad hardware (NIC, cable, or port)
0 Gold frames truncated
0 Gold frames successful
0 1 collision frames
0 2 collision frames
0 3 collision frames
0 4 collision frames
0 5 collision frames
0 6 collision frames
0 7 collision frames
0 8 collision frames
0 9 collision frames
0 10 collision frames
0 11 collision frames
0 12 collision frames
0 13 collision frames
0 14 collision frames
0 15 collision frames
0 Excess collision frames
LAST UPDATE 22622 msecs AGO
Use o comando show platform pm interface-flaps {interface{interface-number}} para exibir o número de vezes que uma interface fica inativa:
Este é um exemplo de saída do comando show platform pm interface-flaps {interface{interface-number} para uma interface específica:
Switch#show platform pm interface-flaps tenGigabitEthernet 2/0/1 Field AdminFields OperFields =============================================================== Access Mode Static Static Access Vlan Id 1 0 Voice Vlan Id 4096 0 VLAN Unassigned 0 ExAccess Vlan Id 32767 Native Vlan Id 1 Port Mode dynamic access Encapsulation 802.1Q Native disl auto Media unknown DTP Nonegotiate 0 0 Port Protected 0 0 Unknown Unicast Blocked 0 0 Unknown Multicast Blocked 0 0 Vepa Enabled 0 0 App interface 0 0 Span Destination 0 Duplex auto full Default Duplex auto Speed auto 1000 Auto Speed Capable 1 1 No Negotiate 0 0 No Negotiate Capable 1024 1024 Flow Control Receive ON ON Flow Control Send Off Off Jumbo 0 0 saved_holdqueue_out 0 saved_input_defqcount 2000 Jumbo Size 1500 Forwarding Vlans : none Current Pruned Vlans : none Previous Pruned Vlans : none Sw LinkNeg State : LinkStateUp No.of LinkDownEvents : 12 <-- Number of times the interface flapped XgxsResetOnLinkDown(10GE): Time Stamp Last Link Flapped(U) : Aug 19 14:58:00.154 <-- Last time the interface flapped LastLinkDownDuration(sec) 192 <-- Time in seconds the interface stayed down during the last flap event LastLinkUpDuration(sec): 2277 <-- Time in seconds the interface stayed up before the last flap event
Use esta seção para links de fibra quando for necessário verificar a saúde da fibra óptica. Use o comando show idprom interface {interface-number} para exibir as informações de IDPROM para o transceptor instalado na interface especificada. Use a palavra-chave detail para exibir campos detalhados de IDPROM hexadecimal.
Este exemplo mostra a saída do comando show idprom {interface{interface-number}} para uma interface específica. Os valores de High e Low Warning|Alarm threshold listados nesta saída de comando são os parâmetros operacionais normais do transceptor óptico. Esses valores podem ser verificados na folha de dados da óptica específica. Consulte a Documentação dos módulos do transceptor óptico da Cisco.
Switch#show idprom interface Twe1/0/1
IDPROM for transceiver TwentyFiveGigE1/0/1 :
Description = SFP or SFP+ optics (type 3)
Transceiver Type: = GE CWDM 1550 (107)
Product Identifier (PID) = CWDM-SFP-1550 <--
Vendor Revision = A
Serial Number (SN) = SERIALNUMBER
Vendor Name = CISCO-FINISAR
Vendor OUI (IEEE company ID) = 00.90.65 (36965)
Common Language Equipment Identifier (CLEI) code = CNTRV14FAB
Cisco part number = 10-1879-03
Device State = Enabled.
Date code (yy/mm/dd) = 14/12/22
Connector type = LC.
Encoding = 8B10B (1)
Nominal bitrate = OTU-1 (2700 Mbits/s)
Minimum bit rate as % of nominal bit rate = not specified
Maximum bit rate as % of nominal bit rate = not specified
The transceiver type is 107
Link reach for 9u fiber (km) = LR-2(80km) (80)
LR-3(80km) (80)
ZX(80km) (80)
Link reach for 9u fiber (m) = IR-2(40km) (255)
LR-1(40km) (255)
LR-2(80km) (255)
LR-3(80km) (255)
DX(40KM) (255)
HX(40km) (255)
ZX(80km) (255)
VX(100km) (255)
Link reach for 50u fiber (m) = SR(2km) (0)
IR-1(15km) (0)
IR-2(40km) (0)
LR-1(40km) (0)
LR-2(80km) (0)
LR-3(80km) (0)
DX(40KM) (0)
HX(40km) (0)
ZX(80km) (0)
VX(100km) (0)
1xFC, 2xFC-SM(10km) (0)
ESCON-SM(20km) (0)
Link reach for 62.5u fiber (m) = SR(2km) (0)
IR-1(15km) (0)
IR-2(40km) (0)
LR-1(40km) (0)
LR-2(80km) (0)
LR-3(80km) (0)
DX(40KM) (0)
HX(40km) (0)
ZX(80km) (0)
VX(100km) (0)
1xFC, 2xFC-SM(10km) (0)
ESCON-SM(20km) (0)
Nominal laser wavelength = 1550 nm.
DWDM wavelength fraction = 1550.0 nm.
Supported options = Tx disable
Tx fault signal
Loss of signal (standard implementation)
Supported enhanced options = Alarms for monitored parameters
Diagnostic monitoring = Digital diagnostics supported
Diagnostics are externally calibrated
Rx power measured is "Average power"
Transceiver temperature operating range = -5 C to 75 C (commercial)
Minimum operating temperature = 0 C
Maximum operating temperature = 70 C
High temperature alarm threshold = +90.000 C
High temperature warning threshold = +85.000 C
Low temperature warning threshold = +0.000 C
Low temperature alarm threshold = -4.000 C
High voltage alarm threshold = 3600.0 mVolts
High voltage warning threshold = 3500.0 mVolts
Low voltage warning threshold = 3100.0 mVolts
Low voltage alarm threshold = 3000.0 mVolts
High laser bias current alarm threshold = 84.000 mAmps
High laser bias current warning threshold = 70.000 mAmps
Low laser bias current warning threshold = 4.000 mAmps
Low laser bias current alarm threshold = 2.000 mAmps
High transmit power alarm threshold = 7.4 dBm
High transmit power warning threshold = 4.0 dBm
Low transmit power warning threshold = -1.7 dBm
Low transmit power alarm threshold = -8.2 dBm
High receive power alarm threshold = -3.0 dBm
Low receive power alarm threshold = -33.0 dBm
High receive power warning threshold = -7.0 dBm
Low receive power warning threshold = -28.2 dBm
External Calibration: bias current slope = 1.000
External Calibration: bias current offset = 0
Esta tabela lista os comandos que podem ser usados para solucionar problemas de oscilações de link. Ordem de uso recomendada: show logging, show interfaces, show controllers ethernet-controller, show platform pm interface-flaps e, em seguida, comandos específicos de fibra ou cobre, conforme aplicável.
| Comando |
Propósito |
| show interfaces counters errors |
Exibe os contadores de erro de interface. |
| show interfaces capabilities |
Exibe os recursos da interface específica. |
| show interface transceivers (específico para fibra ou SFP) |
Exibe informações sobre os transceptores ópticos que têm o monitoramento óptico digital (DOM) ativado. |
| show interface link |
Exibe informações no nível do link. |
| show interface {interface{interface-number}} platform |
Exibe informações sobre a plataforma da interface. |
| show controllers ethernet-controller {interface{interface-number}} port-info |
Exibe informações adicionais sobre a porta. |
| show controllers ethernet-controller {interface{interface-number}} link status detail |
Exibe o status do link. |
| show errdisable flap-values |
Exibe o número de oscilações que podem ocorrer antes do status errdisable. |
| clear counters |
Use esse comando para zerar os contadores de tráfego e de erro para que você possa ver se o problema é apenas temporário ou se os contadores continuam a aumentar. |
| clear controllers ethernet-controller |
Use este comando para limpar os contadores de transmissão e recepção do hardware. |
Verifique o status do cabo com o Time Domain Refletor (TDR)
O recurso Reflectômetro no Domínio do Tempo (TDR) permite determinar se um cabo está ABERTO ou CURTO quando está com defeito. Com o TDR, você pode verificar o status dos cabos de cobre para as portas nos Switches da Série Catalyst 9000. O TDR detecta uma falha no cabo com um sinal que é enviado através do cabo e lê o sinal que é refletido de volta. Todo ou parte do sinal pode ser refletido de volta devido a defeitos no cabo
Use o teste cable-diagnostics tdr {interface{interface-number} } para iniciar o teste TDR e, em seguida, use o comando show cable-diagnostics tdr {interface-number}.
O exemplo mostra um resultado de teste TDR para a interface Tw2/0/10:
Switch#show cable-diagnostics tdr interface tw2/0/10
TDR test last run on: November 05 02:28:43
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Tw2/0/10 1000M Pair A 1 +/- 5 meters Pair A Impedance Mismatch
Pair B 1 +/- 5 meters Pair B Impedance Mismatch
Pair C 1 +/- 5 meters Pair C Open
Pair D 3 +/- 5 meters Pair D Open
Diretrizes de TDR
Estas diretrizes aplicam-se ao uso do TDR:
- Não altere a configuração da porta enquanto o teste TDR estiver em execução.
- Se você conectar uma porta durante um teste de TDR a uma porta habilitada para MDIX automático, o resultado do TDR poderá ser inválido.
- Se você conectar uma porta durante um teste de TDR a uma porta 100BASE-T, como a do dispositivo, os pares não utilizados (4-5 e 7-8) serão relatados como defeituosos porque a extremidade remota não termina esses pares.
- Devido às características do cabo, você deve executar o teste TDR várias vezes para obter resultados precisos.
- Não altere o status da porta (por exemplo, remova o cabo na extremidade próxima ou distante) porque os resultados podem ser imprecisos.
- O TDR funciona melhor se o cabo de teste estiver desconectado da porta remota. Caso contrário, poderá ser difícil interpretar os resultados corretamente.
- O TDR opera através de quatro fios. Com base nas condições do cabo, o status pode mostrar que um par está ABERTO ou CURTO, enquanto todos os outros pares de fios são exibidos como defeituosos. Esta operação é aceitável porque você pode declarar um cabo defeituoso desde que um par de fios seja ABERTO ou CURTO.
- A intenção do TDR é determinar quão mal um cabo funciona em vez de localizar um cabo defeituoso.
- Quando o TDR localiza um cabo defeituoso, você ainda pode usar uma ferramenta de diagnóstico de cabo off-line para diagnosticar melhor o problema.
- Os resultados do TDR podem diferir entre execuções em diferentes modelos de switch dos Catalyst 9300 Series Switches devido à diferença de resolução das implementações do TDR. Quando isso ocorrer, você deverá consultar uma ferramenta de diagnóstico de cabos offline.
Monitoração Óptica Digital (DOM - Digital Optic Monitoring)
O Digital Optical Monitoring (DOM) é um padrão de todo o setor, destinado a definir uma interface digital para acessar parâmetros em tempo real, como:
- Temperatura
- Tensão de alimentação do transceptor
- Corrente de polarização do laser
- Potência de transmissão óptica
- Potência óptica Rx
Como ativar o DOM
A tabela lista os comandos que você pode usar para ativar/desativar o DOM para todos os tipos de transceptores no sistema:
| Etapas |
Comando ou Ação |
Propósito |
| Passo 1 |
enable Exemplo: switch > enable |
Ativa o modo EXEC físico. Digite sua senha, se solicitado. |
| Passo 2 |
configure terminal Exemplo: switch#configure terminal |
Entra no modo de configuração global. |
| Etapa 3 |
transceiver type all Exemplo: switch(config)#transceiver digite all |
Entra no modo de configuração do tipo de transceptor. |
| Passo 4 |
monitoramento Exemplo: switch(config)#monitoring |
Permite o monitoramento de todos os transceptores ópticos. |
Use o comando show interfaces {interface{interface-number}} transceiver detail para exibir informações do transceiver:
Switch#show interfaces hundredGigE 1/0/25 transceiver detail
ITU Channel not available (Wavelength not available),
Transceiver is internally calibrated.
mA: milliamperes, dBm: decibels (milliwatts), NA or N/A: not applicable.
++ : high alarm, + : high warning, - : low warning, -- : low alarm.
A2D readouts (if they differ), are reported in parentheses.
The threshold values are calibrated.
High Alarm High Warn Low Warn Low Alarm
Temperature Threshold Threshold Threshold Threshold
Port (Celsius) (Celsius) (Celsius) (Celsius) (Celsius)
--------- ----------------- ---------- --------- --------- ---------
Hu1/0/25 28.8 75.0 70.0 0.0 -5.0
High Alarm High Warn Low Warn Low Alarm
Voltage Threshold Threshold Threshold Threshold
Port (Volts) (Volts) (Volts) (Volts) (Volts)
--------- ----------------- ---------- --------- --------- ---------
Hu1/0/25 3.28 3.63 3.46 3.13 2.97
High Alarm High Warn Low Warn Low Alarm
Current Threshold Threshold Threshold Threshold
Port Lane (milliamperes) (mA) (mA) (mA) (mA)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A 6.2 10.0 8.5 3.0 2.6
Optical High Alarm High Warn Low Warn Low Alarm
Transmit Power Threshold Threshold Threshold Threshold
Port Lane (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A -2.2 1.7 -1.3 -7.3 -11.3
Optical High Alarm High Warn Low Warn Low Alarm
Receive Power Threshold Threshold Threshold Threshold
Port Lane (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A -16.7 2.0 -1.0 -9.9 -13.9
Mensagens do Syslog de Monitoramento Óptico Digital
Esta seção descreve as mensagens de syslog de violação de limite mais relevantes:
Níveis de temperatura da óptica SFP
- Explicação: Essas mensagens de registro são geradas quando a temperatura está baixa ou excede os valores normais de operação óptica:
%SFF8472-3-THRESHOLD_VIOLATION: Te7/3: Temperature high alarm; Operating value: 88.7 C, Threshold value: 74.0 C.
%SFF8472-3-THRESHOLD_VIOLATION: Fo1/1/1: Temperature low alarm; Operating value: 0.0 C, Threshold value: 35.0 C.
Níveis de voltagem da óptica SFP
- Explicação: Essas mensagens de registro são geradas quando a voltagem é baixa ou excede os valores normais de operação óptica:
%SFF8472-3-THRESHOLD_VIOLATION: Gi1/1/3: Voltage high warning; Operating value: 3.50 V, Threshold value: 3.50 V.
%SFF8472-5-THRESHOLD_VIOLATION: Gi1/1: Voltage low alarm; Operating value: 2.70 V, Threshold value: 2.97 V.
Níveis de luz de óptica SFP
- Explicação: Essas mensagens de registro são geradas quando a energia da luz está baixa ou excede os valores de operação da óptica:
%SFF8472-3-THRESHOLD_VIOLATION: Gi1/0/1: Rx power high warning; Operating value: -2.7 dBm, Threshold value: -3.0 dBm.
%SFF8472-5-THRESHOLD_VIOLATION: Te1/1: Rx power low warning; Operating value: -13.8 dBm, Threshold value: -9.9 dBm.
Cisco Optics e FEC (Forward Error Correction)
O FEC é uma técnica usada para detectar e corrigir um determinado número de erros em um fluxo de bits e anexa bits redundantes e código de verificação de erros ao bloco de mensagens antes da transmissão. Como fabricante de módulos, a Cisco cuida de projetar nossos transceptores para atender às especificações. Quando o transceptor óptico é operado em uma plataforma de host da Cisco, o FEC é habilitado por padrão com base no tipo de módulo óptico que o software de host detecta (Consulte esta tabela para download). Na grande maioria dos casos, a implementação do FEC é ditada pelo padrão da indústria que o tipo óptico suporta.
Para determinadas especificações personalizadas, as implementações de FEC variam. Consulte o documento Compreendendo o FEC e sua Implementação na Cisco Optics para obter informações detalhadas.
O exemplo mostra como configurar o FEC e algumas das opções disponíveis:
switch(config-if)#fec? auto Enable FEC Auto-Neg cl108 Enable clause108 with 25G cl74 Enable clause74 with 25G off Turn FEC off
Use the show interface command to verify FEC configuration:
TwentyFiveGigE1/0/13 is up, line protocol is up (connected)
Hardware is Twenty Five Gigabit Ethernet, address is 3473.2d93.bc8d (bia 3473.2d93.bc8d)
MTU 9170 bytes, BW 25000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 25Gb/s, link type is force-up, media type is SFP-25GBase-SR
Fec is auto < -- The configured setting for FEC is displayed here
input flow-control is on, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
--snip--
Comandos debug
Esta tabela lista os vários comandos que podem ser usados para depurar Flaps de Porta
| Comando | Propósito |
| debug pm | Depuração do gerenciador de portas |
| debug pm port | Eventos relacionados à porta |
| debug platform pm | Informações de depuração do gerenciador de porta da plataforma NGWC |
| debug platform pm l2-control | Depuração de Infraestrutura de Controle L2 NGWC |
| debug platform pm link-status | Eventos de detecção de link de interface |
| debug platform pm-vetors | Funções de vetor do gerenciador de portas |
| debug condition interface <interface name> | Habilitar depurações seletivamente para uma interface específica |
| debug interface state | Transições de estados |
Este é um exemplo de saída parcial dos comandos debug listados na tabela:
SW_2#sh debugging
PM (platform):
L2 Control Infra debugging is on <-- debug platform pm l2-control
PM Link Status debugging is on <-- debug platform pm link-status
PM Vectors debugging is on <-- debug platform pm pm-vectors
Packet Infra debugs:
Ip Address Port
------------------------------------------------------|----------
Port Manager:
Port events debugging is on <-- debug pm port
Condition 1: interface Te1/0/2 (1 flags triggered)
Flags: Te1/0/2
------ Sample output ---------
*Aug 25 20:01:05.791: link up/down event : link-down on Te1/0/2
*Aug 25 20:01:05.791: pm_port 1/2: during state access, got event 5(link_down) <-- Link down event (day/time)
*Aug 25 20:01:05.791: @@@ pm_port 1/2: access -> pagp
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Vp Disable: pd=0x7F1E797914B0 dpidx=10 Te1/0/2
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: Maintains count of VP per Interface:delete, pm_vp_counter[0]: 14, pm_vp_counter[1]: 14
*Aug 25 20:01:05.792: *** port_modechange: 1/2 mode_none(10)
*Aug 25 20:01:05.792: @@@ pm_port 1/2: pagp -> dtp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:05.792: *** port_bndl_stop: 1/2 : inform yes
*Aug 25 20:01:05.792: @@@ pm_port 1/2: dtp -> present
*Aug 25 20:01:05.792: *** port_dtp_stop: 1/2
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 dtp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 unknown
*Aug 25 20:01:05.792: *** port_linkchange: reason_link_change(3): link_down(0)1/2 <-- State link change
*Aug 25 20:01:05.792: pm_port 1/2: idle during state present
*Aug 25 20:01:05.792: @@@ pm_port 1/2: present -> link_down <-- State of the link
*Aug 25 20:01:06.791: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/2, changed state to down
*Aug 25 20:01:07.792: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/2, changed state to down
*Aug 25 20:01:11.098: IOS-FMAN-PM-DEBUG-LINK-STATUS: Received LINKCHANGE in xcvr message, if_id 10 (TenGigabitEthernet1/0/2)
*Aug 25 20:01:11.098: IOS-FMAN-PM-DEBUG-LINK-STATUS: if_id 0xA, if_name Te1/0/2, link up <-- Link became up
*Aug 25 20:01:11.098: link up/down event: link-up on Te1/0/2
*Aug 25 20:01:11.098: pm_port 1/2: during state link_down, got event 4(link_up)
*Aug 25 20:01:11.098: @@@ pm_port 1/2: link_down -> link_up
*Aug 25 20:01:11.098: flap count for link type : Te1/0/2 Linkcnt = 0
*Aug 25 20:01:11.099: pm_port 1/2: idle during state link_up
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_up -> link_authentication
*Aug 25 20:01:11.099: pm_port 1/2: during state link_authentication, got event 8(authen_disable)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_authentication -> link_ready
*Aug 25 20:01:11.099: *** port_linkchange: reason_link_change(3): link_up(1)1/2
*Aug 25 20:01:11.099: pm_port 1/2: idle during state link_ready
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_ready -> dtp
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: pm_port 1/2: during state dtp, got event 13(dtp_complete)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: dtp -> dtp
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: DTP flapping: flap count for dtp type: Te1/0/2 Dtpcnt = 0
*Aug 25 20:01:11.099: pm_port 1/2: during state dtp, got event 110(dtp_done)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: dtp -> pre_pagp_may_suspend
*Aug 25 20:01:11.099: pm_port 1/2: idle during state pre_pagp_may_suspend
*Aug 25 20:01:11.099: @@@ pm_port 1/2: pre_pagp_may_suspend -> pagp_may_suspend
*Aug 25 20:01:11.099: pm_port 1/2: during state pagp_may_suspend, got event 33(pagp_continue)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: pagp_may_suspend -> start_pagp
*Aug 25 20:01:11.099: pm_port 1/2: idle during state start_pagp
*Aug 25 20:01:11.099: @@@ pm_port 1/2: start_pagp -> pagp
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: *** port_bndl_start: 1/2
*Aug 25 20:01:11.100: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:11.100: pm_port 1/2: during state pagp, got event 34(dont_bundle)
*Aug 25 20:01:11.100: @@@ pm_port 1/2: pagp -> pre_post_pagp
*Aug 25 20:01:11.100: pm_port 1/2: idle during state pre_post_pagp
*Aug 25 20:01:11.100: @@@ pm_port 1/2: pre_post_pagp -> post_pagp
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: pm_port 1/2: during state post_pagp, got event 14(dtp_access)
*Aug 25 20:01:11.100: @@@ pm_port 1/2: post_pagp -> access
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: Maintains count of VP per Interface:add, pm_vp_counter[0]: 15, pm_vp_counter[1]: 15
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: vlan vp enable for port(Te1/0/2) and vlan:1
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: VP ENABLE: vp_pvlan_port_mode:access for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: VP Enable: vp_pvlan_native_vlanId:1 for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: *** port_modechange: 1/2 mode_access(1)
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: The operational mode of Te1/0/2 in set all vlans is 1
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: vp_pvlan port_mode:access vlan:1 for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: vp_pvlan port_mode:access native_vlan:1 for Te1/0/2
*Aug 25 20:01:11.102: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:13.098: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/2, changed state to up
*Aug 25 20:01:14.098: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/2, changed state to up
Bugs relacionados da Cisco
| ID de bug da Cisco |
Descrição |
| ID de bug da Cisco CSCvu13029 |
Flaps de link intermitentes em switches Cat9300 mGig para terminais compatíveis com mGig. |
| ID de bug da Cisco CSCvt50788 |
Problemas de interoperabilidade mGig Cat9400 com outros dispositivos mGig causam oscilações de link. |
| ID de bug da Cisco CSCvu92432 |
CAT9400: Interface Mgig não sincronizada com APs Mgig. |
| ID de bug da Cisco CSCve65787 |
Suporte a Autoneg para 100G/40G/25G Cu xcvr. |
Informações Relacionadas
- Matriz de compatibilidade da óptica com o dispositivo da Cisco
- Dados técnicos dos módulos Cisco SFP para aplicações Gigabit Ethernet
- 25GE e 100GE - White paper Como viabilizar velocidades mais altas em empresas com proteção do investimento
- Dados técnicos da solução Cisco CWDM SFP
- Inovação de suporte: Como o Cisco TAC está transformando a documentação e simplificando o autoatendimento
- Suporte técnico e downloads da Cisco
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
3.0 |
09-Sep-2026
|
Recertificação - Problema atualizado, SEO, Tradução automática, Requisitos de estilo e Formatação. |
2.0 |
13-Mar-2024
|
Recertificação |
1.0 |
04-Nov-2022
|
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)