Resumo do Protocolo LLDP

O protocolo LLDP(802.1AB) permite que dispositivos de rede como Servidores, Switches e Roteadores, descubram uns aos outros. Ele opera na camada de enlace do modelo OSI (camada 2)  permitindo que informações básicas como hostname, versão do Sistema Operacional , endereço da interface, entre outros, sejam aprendidas dinâmicamente por equipamentos diretamente conectados.

O mais bacana do Link Layer Discovery Protocol (LLDP)  é a integração entre equipamentos de diversos fabricantes; e para aqueles que já estudaram o material do CCNA da Cisco, a feature é identica ao Cisco Discover Protocol (CDP) – o protocolo proprietário da Cisco para descoberta de vizinhos.

A tirinha abaixo adaptada do site http://vincentbernat.github.com/lldpd/index.html  demonstra bem a utilização do LLDP (ou como ajudaria no caso abaixo.. rs )  O site possui instruções de instalação do protocolo para diversas plataformas.

LLDP tirinha

Conceitos Básicos

Para redes Ethernet, o LLDP é encaminhado dentro do quadro Ethernet da seguinte maneira:

LLDP Packet

A mensagem encaminhada também é chamada de LLDPDU (Link Layer Discover Protocol Data Unit)

Endereço MAC de destino (Destination MAC address)
O endereço MAC de destino de um LLDPDU pode ser anunciado nos endereços Multicast  0180-C200-000E , 0180-C200-0003 ou 0180-C200-0000.

Endereço MAC de  origem (Source MAC address)
O endereço MAC de origem é o da porta que encaminha o LLDPDU, se a interface não tiver endereço MAC, será encaminhado o endereço reservado do Switch/Roteador

Type
O Ethernet type usado para o LLDP é o 0x88CC for LLDP.

Data
LLDP data unit (LLDPDU)

FCS
Frame check sequence é um valor de CRC de 32-bit CRC usado para determinar a validade do recebimento do quadro  Ethernet.

Os LLDPDUs

O LLDP usa os LLPDU’s para troca de informações. Dentro do LLDPDU há uma sequencia de campos TLV ( type [tipo], length [comprimento] e value [valor])

LLDPDU encapsulation format

Um LLPDU pode carregar até 28 tipos de TLVs. Os itens obrigatóriso devem carregar:

  • TLV de identificação do Chassis
  • TLV de identificação da Porta
  • TTL TLV
  • TLV do fim do LLPDU
  • Outros campos são opcionais

A demonstração feita nos dá uma boa visão das informações carregadas pelo protocolo:

LLDPDU encapsulation format 2

A saída do comando display lldp  neighbor-information brief  em um Switch HPN demonstra o estudo:

<Switch>display lldp  neighbor-information brief
LLDP neighbor-information of port 469[GigabitEthernet1/9/0/1]:
Neighbor 1:
ChassisID/subtype: 3822-d6b6-4c01/MAC address
PortID/subtype   : GigabitEthernet1/0/48/Interface name
Capabilities     : Bridge,Router

Para os campos Opcionais é possível obter informações como Hostname, descrição do tipo de equipamento, endereço de gerenciamento, informação sobre VLANs, etc.

LLDP-MED

A extensão do LLDP chamada de Media Endpoint Discovery extension (MED) é muito utilizada para Telefonia IP e provê as seguintes informações:

  • Provisionamento de informações de politicas para a rede local agir de forma plug-and-play (como VLAN, Prioridades na marcação de pacotes e quadros para fins de QoS)
  • Identificação do local do dispositivo
  • Funções para PoE
  • etc

Configuração básica do LLDP

[Switch]lldp enable
! Ativando o LLDP globalmente

[Switch]interface Ethernet 1/0/1
[Switch-Ethernet1/0/1]lldp enable
! Ativando o LLDP na interface

Para ajuste de envio, recebimento ou desativar o LLDP em uma interface, existem as seguintes opções:

[Switch-Ethernet1/0/1]lldp  admin-status ?
disable  The port can neither transmit nor receive LLDP frames
rx       The port can only receive LLDP frames
tx       The port can only transmit LLDP frames
txrx     The port can both transmit and receive LLDP frames

Para  mais informações sobre a compatibilidade entre o LLDP e o CDP, acesse o seguinte post:
http://www.comutadores.com.br/switches-hp-a7500-tabela-de-vizinhos-via-protocolo-cdp/

Obs: Fique sempre atento as informações encaminhadas pelo LLDP em uma rede local, pois o protocolo habilita inumeras informações que tornam a rede “vulnerável”. Certifique-se que o ambiente é controlado e desabilite o LLDP (se possível) após a coleta de informações! 

Para mais informações sobre configuração do LLDP em Switches Cisco, acesse  o seguinte post:
http://www.comutadores.com.br/switches-hpn-12500-utilizando-lldp-ao-inves-do-cdp/

 

Referências

http://www.h3c.com/portal/Technical_Support___Documents/Technical_Documents/Switches/…

http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol

http://vincentbernat.github.com/lldpd/index.html

ACL para Gerenciamento Telnet, SSH, SNMP …

A aplicação de ACL para limitar as redes que poderão efetuar o gerenciamento do Switch e/ou Roteador é uma técnica bastante utilizada para restringir quais redes ou hosts de origem terão a permissão para gerenciar o equipamento via Telnet, SSH ou SNMP

Imaginando uma empresa com diversas sub redes,  permitiremos no cenário abaixo o acesso ao Switch apenas da sub rede 172.31.1.0/24 (lembrando que a mascara para listas de acesso [ACL] são no formato de mascara curinga [wildcard mask])

acl number 2000
rule 0 permit source 172.31.1.0 0.0.0.255
rule 5 deny
#
user-interface vty 0 4
acl 2000 inbound
! Vinculando a ACL 2000 ao VTY
#
snmp-agent community read 123abc acl 2000
snmp-agent community write aaa111 acl 2000
! Vinculando a ACL 2000 às comunidades SNMP "123abc" e "aaa111"

Caso a interface de gerenciamento esteja dentro de uma VRF, ou a origem do acesso inicie de uma vpn-instance (VRF), a ACL deverá fazer referência a isso:

[H3C-acl-basic-2000]rule 1 permit source 172.31.1.0 0.0.0.255 vpn-instance ?
STRING<1-31>  VPN-Instance name

Dúvidas? Deixe um comentário…
Até logo!

Roteador MSR 30 –16: Configurando TACACS em uma VPN-Instance (VRF)

Compatilho abaixo o script (comentado) para a autenticação de usuários em uma base remota para administração de um Roteador MSR 30-16. Os testes serviram para validar um Servidor ACS da Cisco para autenticação via TACACS em um Roteador HPN. A diferença deste teste para as outras configurações é a utilização do TACACS dentro de uma vpn-instance (VRF).


Configuração
#
ip vpn-instance test
 route-distinguisher 1:1
 vpn-target 1:1 export-extcommunity
 vpn-target 1:1 import-extcommunity
! Criando a VRF “test”
#
super password level 3 simple s3nhasup3r
super authentication-mode scheme
#
telnet server enable
#
hwtacacs scheme acs
! Criando o esquema TACACS com o nome acs
primary authentication 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para autenticação
primary authorization 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para autorização
primary accounting 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para contabilidade
nas-ip 172.16.1.1
!Endereço de IP do Switch cadastrado no ACS
key authentication teste123
! Chave para autenticação com o servidor ACS  com a senha"teste123"
key authorization teste123
key accounting teste123
user-name-format without-domain
! Encaminhamento do usuário sem o formato @dominio
#
domain acs
authentication login hwtacacs-scheme acs local
!Configurando a autenticação com TACACS e em caso de falha, a autenticação será local.
authorization login hwtacacs-scheme acs local
accounting login hwtacacs-scheme acs local
authentication default hwtacacs-scheme acs local
authorization default hwtacacs-scheme acs
accounting default hwtacacs-scheme acs
authentication super hwtacacs-scheme acs
accounting command hwtacacs-scheme acs
#
domain default enable acs
! Habilitando o dominio acs como default para auetnticação
#
interface Ethernet0/0
 port link-mode route
 ip binding vpn-instance test
 172.16.1.1 255.255.255.0
#
user-interface vty 0 4
authentication-mode scheme
#

obs: Sugerimos que durante os testes, não configure o authentication-mode scheme no acesso via Console, para em caso de falha nos testes, você não fique trancado do lado de fora do Switch.

A autenticação do “super-usuário” via TACACS também está inclusa no script.

Abração

Switches HP A7500 – Configurando Autenticação para o OSPF na Área 0

Publicado originalmente em 29 DE JANEIRO DE 2011

Para validar a troca de informações de Roteamento, o protocolo OSPF suporta a Autenticação para estabelecimento de adjacência com vizinhos. O Processo incrementa segurança ao Roteamento Dinâmico com troca de chaves em MD5.

Para ativarmos a Autenticação é necessário informar qual a Área OSPF  utilizará  a Autenticação e precisaremos habilitar a chave na Interface VLAN que formará a adjacência.

Configurando

Segue abaixo a configuração dos Switches.

Switch A

#
interface Vlan-interface1
ip address 172.31.0.1 255.255.0.0
ospf authentication-mode md5 10 cipher testeospf
! Configurando a chave md5 cifrada com a chave numero 10 como testeospf na interface VLAN
(a senha será exibida no arquivo de configuração cifrada)
#
ospf 100 router-id 172.31.0.1
area 0.0.0.0
authentication-mode md5
! Habilitando a autenticação utilizando md5 na Area 0
network 172.31.1.1 0.0.0.0
area 2
network 192.168.1.1 0.0.0.0
! Area 2 sem autenticação
#

Switch B

#
interface Vlan-interface1
ip address 172.31.0.2 255.255.0.0
ospf authentication-mode md5 10 cipher testeospf
! Configurando a chave md5 cifrada com a chave numero 10 como testeospf na interface VLAN #
ospf 100 router-id 172.31.0.2
area 0.0.0.0
authentication-mode md5
! Habilitando a autenticação utilizando md5 na Area 0
network 172.31.1.2 0.0.0.0

Display

[SW1] display ospf peer
OSPF Process 100 with Router ID 172.31.0.1
Neighbor Brief Information
Area: 0.0.0.0
Router ID  Address Pri Dead-Time Interface State
172.31.0.2 172.31.0.2 1 36 Vlan1 Full/DR

 

Até a próxima! 😉