Resumo
- Luz no receptor prova presença de sinal, não que as duas fibras chegam à porta vizinha pretendida. Device-ID, Port-ID e Echo TLV produzem um recibo diferente: a identidade que efetivamente fez a ida e a volta.
- O modo normal mantém a falta de evidência como
undetermined. O agressivo só pode convertê-la em errdisable depois de uma relação antes bidirecional, expiração do estado e uma sequência final e limitada de tentativas.
Uma fibra óptica pode entregar uma verdade estreita. O receptor vê luz e o hardware declara o enlace ativo, embora a fibra de transmissão termine num equipamento e a de recepção venha de outro. Cada porta pode parecer saudável isoladamente enquanto o arranjo de camada 2 forma um circuito perigoso. O indicador verde responde à física local; ele não identifica o par remoto.
O UDLD acrescenta uma prova de identidade. O equipamento anuncia Device-ID e Port-ID. O vizinho devolve, no Echo TLV, os pares que ouviu naquela interface. A bidirecionalidade deixa de ser inferida apenas pela portadora e passa a depender do retorno da identidade esperada pelo mesmo relacionamento.
Esse recibo não é universal. O protocolo roda no plano de controle, depende de CPU, agendamento, implementação, temporizadores e cache. Não testa cada VLAN, tamanho de quadro, fila, entrada de encaminhamento ou transação de aplicação. Uma troca UDLD bem-sucedida não certifica toda a entrega de dados.
A tabela de vizinhos tem prazo de validade
Hellos periódicos mantêm cada vizinho pelo holdtime anunciado. Uma mensagem válida substitui a entrada e reinicia o relógio. Desabilitar a interface ou o protocolo, ou reiniciar o equipamento, apaga estado e tenta fazer o outro lado limpar sua cópia.
Por isso, show udld não fotografa o cabo. Ele exibe a interpretação de uma máquina de estados sobre mensagens recentes, configuração e tempo local. Uma linha confirma que determinada identidade foi aceita dentro da janela do cache. Não confirma que o percurso permanece igual no instante da leitura, muito menos que o tráfego de produção compartilha o mesmo destino.
Quando surge um vizinho ou um pedido de ressincronização, o RFC prevê uma sequência de mensagens. A premissa é que N envios deem oportunidade para pelo menos um atravessar um enlace sujeito a perdas. A falha de todos eles não identifica sozinha a causa: fibra rompida, dano bidirecional, taxa de erro, duplex incorreto, controle sobrecarregado, UDLD desabilitado, vizinho incapaz ou uma mudança cuja mensagem de limpeza se perdeu continuam possíveis.
O modo normal não preenche silêncio com certeza
O modo normal reage a eventos afirmativos. Uma mensagem recebida pode demonstrar pareamento correto ou revelar incompatibilidade explícita de eco. Quando informação útil não chega, inclusive depois de desaparecer uma relação antes bidirecional, o protocolo conserva undetermined.
Essa recusa é disciplina probatória. A orientação atual da Cisco observa que erros altos ou incompatibilidade de duplex podem envelhecer informações de vizinhança; perda de pacotes, por si, não prova unidirecionalidade. Expirar cache não dá ao modo normal licença para inventar uma falha física e desligar a porta.
A disponibilidade preservada tem custo. A equipe precisa correlacionar contadores, potência óptica, estado remoto, mudanças do spanning tree, sondas de dados e efeito no serviço. O modo normal evita uma conclusão automática forte, mas deixa à operação o trabalho de resolver a incerteza.
O oitavo envio encerra uma política, não uma investigação
No modo agressivo, o histórico muda a ação. A relação precisa ter sido reconhecida como bidirecional. Depois o registro expira, a camada física continua up e as últimas sondas não restauram o vizinho. A documentação atual da Cisco para implementações pertinentes descreve oito tentativas, com um segundo entre elas, antes do errdisable.
O número oito não torna o silêncio mais eloquente. Ele delimita quanto esforço de recuperação a organização considera suficiente antes de preferir retirar capacidade. Em enlaces tipicamente ponto a ponto, continuar encaminhando sem comunicação aceitável com o vizinho pode ser pior que fechar a porta: um loop pode crescer ou o tráfego pode continuar entrando num buraco negro.
Portanto, o desligamento é contenção, não laudo. O evento explica por que a máquina de estados agiu; não diz qual fibra, transceptor, ASIC, processo ou configuração remota o técnico encontrará. Descrever errdisable como prova da causa confundiria uma regra de risco com uma medição física.
Há outra corrida no mesmo enlace
Enquanto o holdtime e as tentativas correm, STP ou RSTP podem mudar papéis e encaminhamento. A orientação da Cisco alerta que um cálculo fixo baseado no STP clássico não garante que o UDLD aja antes de uma transição RSTP. Plataforma, versão, meio, topologia, temporizadores e instante da falha decidem a ordem real.
O registro do incidente precisa separar portadora, último hello aceito, expiração, cada sonda, errdisable, mudança STP/RSTP, entrada do caminho alternativo e recuperação da aplicação. “O UDLD pegou” comprime recibos distintos. “O serviço voltou” é uma afirmação posterior, que também exige sua própria evidência.
A contribuição duradoura do RFC 5171 é forçar uma escolha explícita: quando a ausência deve continuar sendo ausência, e quando uma ausência delimitada passa a justificar falhar fechado. O protocolo não remove o risco. Ele torna visível quem decidiu onde colocá-lo.
Fontes
- https://www.rfc-editor.org/rfc/rfc5171.html
- https://www.rfc-editor.org/rfc/rfc5171.txt
- https://www.rfc-editor.org/info/rfc5171
- https://datatracker.ietf.org/doc/rfc5171/
- https://datatracker.ietf.org/doc/rfc5171/history/
- https://datatracker.ietf.org/doc/rfc5171/references/
- https://www.rfc-editor.org/errata/rfc5171
- https://www.rfc-editor.org/rfc/rfc3932.html
- https://www.rfc-editor.org/rfc/rfc5880.html
- https://www.rfc-editor.org/rfc/rfc5881.html
- https://www.rfc-editor.org/rfc/rfc7419.html
- https://www.rfc-editor.org/rfc/rfc7880.html
- https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10591-77.html
- https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/lyr2-fwd/cdp-lldp-mac-udld/cdp-lldp-mac-udld-configuration-guide/configure-udld.html
- https://www.cisco.com/c/en/us/td/docs/routers/ncs4200/configuration/guide/lanswitch/lanswitch-ncs4200-book/lsw-udld.pdf
- https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/24330-185.html
- https://www.cisco.com/c/en/us/td/docs/switches/lan/csbms/CBS_250_350/CLI/cbs-250-cli/udld-commands.html
- https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-4SY/config_guide/sup2T/15_4_sy_swcg_2T/udld.pdf
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
