LLDP em automação: vizinhos, TLVs, topologia e limites da descoberta
Entenda anúncios LLDP, chassis ID, port ID, TTL, TLVs, MIB, topologia, segurança e como validar conexões de switches e ativos OT.
TLVs e uso no inventário
| Informação | Uso | Limitação |
|---|---|---|
| Chassis ID | identificar sistema | subtipo e valor podem mudar |
| Port ID | mapear adjacência | nome pode divergir do painel |
| TTL | idade da informação | alarme ocorre após expiração |
| System Name | leitura humana | pode ser duplicado ou incorreto |
| Management Address | acesso de gestão | não garante rota ou permissão |
| Capabilities | papel anunciado | não prova função habilitada |
LLDP confirma anúncio de vizinhança, não operação do protocolo de automação.
LLDP anuncia identidade para vizinhos diretos
LLDP é um protocolo de descoberta em camada 2. Dispositivos enviam anúncios a vizinhos do mesmo enlace com informações codificadas em TLVs. Em geral, esses frames não atravessam roteadores e bridges não os encaminham como tráfego comum. O resultado descreve adjacência direta, não toda a rota até o SCADA.
Switches, servidores, telefones e alguns IEDs podem anunciar ou receber. A ausência de vizinho não prova cabo rompido: LLDP pode estar desabilitado em uma direção, não suportado ou filtrado. A presença confirma anúncio recente, mas não valida VLAN de produção, protocolo de automação ou saúde completa.
Chassis ID, Port ID e TTL formam o núcleo
Chassis ID identifica o sistema segundo um subtipo; pode ser MAC, nome ou valor local. Port ID identifica a interface do anunciante e também pode usar formatos diferentes. TTL informa por quanto tempo o receptor mantém a informação. Nome do sistema e descrição são opcionais e podem ser configurados incorretamente.
Inventário deve guardar identificadores brutos e nomes amigáveis. Confiar apenas no system name permite duplicidade. Quando uma placa ou stack muda, o chassis ID pode mudar; quando uma porta é renomeada, o Port ID pode não acompanhar. Compare com MAC, serial e configuração.
TLVs opcionais enriquecem e também confundem
TLVs podem anunciar descrição de porta, nome, capacidades e endereço de gestão. Extensões organizacionais acrescentam informações específicas. Um endereço de gestão anunciado não significa que ele é alcançável pela VLAN da estação de coleta. Capacidade declarada também não prova que a função está habilitada.
NMS precisa tratar ausência de TLV como dado desconhecido, não valor zero. Atualização de firmware pode mudar texto ou ordem sem mudar topologia. Parsers devem usar tipo e valor, preservando anúncio bruto quando possível.
LLDP ajuda a conferir desenho contra campo
Colete vizinhos por SNMP ou CLI e compare com diagrama esperado. Uma porta de IED ligada ao switch errado, uplinks cruzados ou conexão temporária podem aparecer rapidamente. A matriz deve considerar redundância: portas A/B de PRP, anéis e uplinks possuem adjacências diferentes e intencionais.
LLDP não vê elementos passivos nem necessariamente conexões através de conversores. Em topologias com equipamentos transparentes, o vizinho anunciado pode estar além do elemento físico imediato. Combine com tabela MAC, inventário de patch panels e inspeção.
TTL e desaparecimento revelam cronologia limitada
Se anúncios param, a entrada permanece até o TTL expirar. O NMS pode detectar vizinho ausente depois do link já ter caído. A relação entre intervalo de transmissão e TTL define velocidade e tolerância a perda. Reduzir agressivamente aumenta tráfego e processamento sem necessariamente melhorar diagnóstico.
Correlacione linkDown, LLDP age-out, RSTP, Syslog e contadores. Se o link fica up e o vizinho some, o processo LLDP ou a direção do anúncio pode ter falhado. Se a porta cai, o desaparecimento é consequência, não causa.
Descoberta expõe informação útil a um atacante local
Nomes, modelos, versões e endereços de gestão ajudam operação, mas também reconhecimento. Habilite somente nas interfaces e direções necessárias conforme política. Portas de usuário ou zonas não confiáveis podem receber anúncios mínimos ou nenhum, desde que a operação não dependa deles.
LLDP não autentica nativamente toda informação anunciada. Um host conectado pode declarar identidade falsa. Não automatize mudança crítica apenas pelo vizinho descoberto. Use-o como evidência a correlacionar com port security, 802.1X quando aplicável, inventário e configuração.
Diagnóstico com captura e tabelas
Capture na interface local e filtre LLDP. Verifique MAC de destino reservado, chassis ID, port ID, TTL e TLVs. Consulte tabela local de vizinhos nas duas pontas: A pode ouvir B enquanto B não ouve A por configuração direcional. Confirme interface física usada.
Se o NMS não mostra vizinho mas o switch mostra, examine coleta SNMP, OID, credencial e polling. Se nem o switch mostra e frames chegam, investigue agent ou limite de tabela. Preserve anúncios antes de reiniciar.
Comissionamento e baseline
Registre todos os vizinhos esperados, identificadores, portas, endereços e TTL. Remova um cabo de laboratório ou desabilite LLDP controladamente, confirme alarme e recuperação. Teste mudança de ativo e atualização do inventário. Não provoque falha em caminho de proteção sem plano.
Após correção de patching, confirme vizinho dos dois lados, tabela MAC e serviço real. O aceite deve provar que a topologia descoberta coincide com o projeto onde LLDP é aplicável e que divergências geram alerta contextual.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- IEC 62443-3-3:2013 — System security requirements and security levels — IEC. Requisitos técnicos de segurança para sistemas de automação e controle industrial.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security — NIST. Arquiteturas, ameaças e controles aplicáveis a ambientes OT.
- RFC 1122 — Requirements for Internet Hosts — Communication Layers — RFC Editor / IETF. Requisitos de IP, ICMP e camadas de comunicação em hosts.
- RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification — RFC Editor / IETF. Especificação vigente do IPv6.
- RFC 9110 — HTTP Semantics — RFC Editor / IETF. Semântica atual de métodos, campos e códigos HTTP.
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — RFC Editor / IETF. TLS 1.3, handshake, autenticação e proteção do transporte.
- RFC 9325 — Recommendations for Secure Use of TLS and DTLS — RFC Editor / IETF. Recomendações atuais para versões, algoritmos e configuração TLS.
- RFC 4251 — The Secure Shell (SSH) Protocol Architecture — RFC Editor / IETF. Arquitetura SSH e separação entre transporte, autenticação e conexão.
- RFC 5424 — The Syslog Protocol — RFC Editor / IETF. Formato, facility, severity, timestamp e dados estruturados de Syslog.
- RFC 3411 — Architecture for Describing SNMP Management Frameworks — RFC Editor / IETF. Arquitetura do framework SNMP.
- RFC 3414 — User-based Security Model (USM) for SNMPv3 — RFC Editor / IETF. Autenticação e privacidade do SNMPv3 USM.
- IEEE 802.1AB-2016 — Station and Media Access Control Connectivity Discovery — IEEE Standards Association. LLDP e descoberta de conectividade em camada 2.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.