Aula 15: DHCP no Cisco IOS — servidor e relay agent

DHCP no Cisco IOS é um dos recursos mais poderosos e subutilizados por administradores de rede que trabalham com equipamentos Cisco. Nesta aula, você vai dominar a configuração completa do servidor DHCP embutido no Cisco IOS e do agente de retransmissão (relay agent), eliminando a necessidade de servidores externos em filiais, escritórios remotos ou laboratórios. O protocolo DHCP (Dynamic Host Configuration Protocol) é responsável por fornecer endereçamento IP automático, máscara de sub-rede, gateway padrão, servidores DNS e dezenas de outras opções de configuração para dispositivos finais. Quando compreendemos profundamente como o DHCP no Cisco IOS opera, ganhamos agilidade na implantação de novos segmentos de rede e reduzimos a complexidade operacional do ambiente.

O domínio deste tópico diferencia o profissional que apenas conhece configuração básica daquele que resolve problemas reais de conectividade em campo. Em nossos projetos na JRT Technology Solutions, frequentemente nos deparamos com cenários onde um roteador de filial precisa fornecer IPs para a LAN local, enquanto os usuários de VLANs específicas precisam alcançar servidores DHCP centralizados na matriz. É exatamente isso que você aprenderá a fazer hoje: transformar um roteador ou switch Cisco em um servidor DHCP completo e, ao mesmo tempo, configurar o relay para que dispositivos em sub-redes diferentes possam obter endereços de servidores remotos através do DHCP no Cisco IOS.

Ao final desta aula, você será capaz de projetar, implementar e solucionar problemas em serviços DHCP usando exclusivamente a CLI do Cisco IOS, sem dependência de sistemas operacionais externos. Abordaremos cada comando com seu propósito claro, mostraremos as saídas esperadas em cada etapa e forneceremos tabelas de referência que você poderá consultar durante sua rotina profissional. Prepare-se para elevar seu conhecimento a um patamar onde a automação de atribuição de endereços IP se torna uma tarefa trivial e controlada.

Nossos especialistas utilizam diariamente os procedimentos aqui descritos para integrar novos equipamentos à infraestrutura de clientes corporativos. A metodologia que aplicamos segue o princípio de entender o processo DORA (Discover, Offer, Request, Acknowledge) e mapeá-lo diretamente para a configuração do IOS. Se você já compreende os fundamentos do DHCP e possui acesso a um roteador ou switch Cisco — físico ou emulado via GNS3, EVE-NG ou Cisco Modeling Labs — está pronto para acompanhar cada etapa sem dificuldades.

O que você vai aprender nesta aula

• Diferenciar os papéis de servidor DHCP, cliente DHCP e relay agent no ecossistema Cisco IOS
• Configurar um pool DHCP completo com rede, máscara, gateway, DNS, domínio e lease time
• Excluir endereços do pool para reservar IPs fixos de servidores e impressoras
• Ativar o servidor DHCP em interfaces específicas e compreender o comportamento por sub-rede
• Implementar DHCP relay com o comando ip helper-address em cenários multi-VLAN
• Analisar o processo DORA através de debug e mensagens de log do IOS
• Verificar bindings ativos, estatísticas e solucionar os erros mais comuns em configurações DHCP
• Aplicar boas práticas de segurança e alta disponibilidade usando múltiplos pools e temporizadores otimizados

Pré-requisitos e Ambiente

Para executar todos os procedimentos desta aula com sucesso, você precisa de um equipamento Cisco com IOS versão 12.4 ou superior — recomendamos 15.x para acesso a todos os recursos discutidos. Switches Catalyst das famílias 2960, 3560, 3650 e 3850, assim como roteadores ISR 800, 1900, 2900, 4000 e séries 7200 e 10000, possuem suporte completo ao servidor DHCP. Em nossos ambientes de validação na JRT Technology Solutions, utilizamos majoritariamente imagens IOS 15.7 e IOS-XE 16.x para garantir compatibilidade com as sintaxes aqui apresentadas.

Seu ambiente de laboratório deve conter pelo menos um roteador com duas interfaces Ethernet (ou subinterfaces com VLANs) para que você possa testar tanto o servidor DHCP local quanto o relay. Você também precisará de um ou dois dispositivos cliente — podem ser máquinas virtuais, containers ou até mesmo roteadores configurados como clientes DHCP. É fundamental que as interfaces estejam em segmentos de rede distintos para que o relay faça sentido prático. Certifique-se de que não há outro servidor DHCP ativo nos mesmos segmentos, pois isso invalidaria os testes e poderia causar comportamentos indeterminados.

O acesso à CLI deve ser privilegiado (modo enable) e você precisará entrar no modo de configuração global com configure terminal. Recomendamos fortemente que todos os testes sejam realizados em ambiente isolado, jamais em produção, especialmente quando utilizarmos comandos de debug que podem impactar a performance do equipamento. Mantenha um terminal de console aberto e, se possível, habilite logging synchronous e logging buffer para acompanhar as mensagens do sistema.

O processo DORA e a arquitetura DHCP no Cisco IOS

Antes de mergulhar nos comandos, é obrigatório compreender o fluxo de comunicação que sustenta qualquer implementação de DHCP no Cisco IOS. O processo DORA — Discover, Offer, Request, Acknowledge — representa as quatro mensagens trocadas entre cliente e servidor durante uma atribuição bem-sucedida. No momento em que um dispositivo conecta-se à rede e não possui endereço IP, ele envia um broadcast DHCP Discover para o endereço 255.255.255.255 na porta UDP 67. O servidor DHCP, ao receber essa mensagem, responde com um DHCP Offer contendo um endereço IP sugerido e parâmetros de configuração. O cliente então envia um DHCP Request confirmando que aceita a oferta, e o servidor finaliza com um DHCP Acknowledge, formalizando o lease.

No Cisco IOS, o servidor DHCP opera como um processo interno que escuta as interfaces configuradas e responde a broadcasts locais. Diferentemente de um servidor DHCP tradicional como o ISC DHCP ou o Windows Server, o IOS armazena os pools e bindings em sua NVRAM ou RAM, dependendo da configuração de persistência. O comportamento padrão é armazenar os bindings em um arquivo de database que pode ser gravado em flash ou em um servidor TFTP externo para recuperação após reload. Este é um detalhe crítico que muitos administradores ignoram até enfrentarem um reboot inesperado e perderem todos os leases ativos.

Quando o servidor DHCP está em uma sub-rede diferente dos clientes, entra em cena o relay agent — função que retransmite os broadcasts DHCP como pacotes unicast direcionados ao servidor real. O comando ip helper-address transforma a interface do roteador em um relay, capturando broadcasts DHCP (e também TFTP, DNS, NetBIOS e outros, a menos que filtrados) e encaminhando-os ao endereço IP especificado. O campo GIADDR (Gateway IP Address) é preenchido com o IP da interface que recebeu o broadcast, permitindo que o servidor identifique de qual pool deve alocar o endereço.

Compreender essa arquitetura é essencial para interpretar as saídas de debug e diagnosticar falhas. Na prática, quando um cliente não consegue obter endereço, o problema está quase sempre em uma destas etapas: broadcast não alcança o servidor (VLAN não permitida no trunk, filtro de broadcast), o pool não corresponde à sub-rede do GIADDR, os endereços disponíveis se esgotaram ou uma ACL está bloqueando o tráfego UDP 67-68. Esta estrutura mental acelera a resolução de incidentes em campo.

Configurando o servidor DHCP no Cisco IOS — passo a passo completo

Vamos construir do zero um servidor DHCP funcional em um roteador Cisco. Nosso cenário será uma LAN corporativa onde o roteador R1 atende a sub-rede 192.168.100.0/24 através de sua interface GigabitEthernet0/1. O servidor distribuirá IPs no intervalo .50 a .200, fornecerá gateway 192.168.100.1, DNS primário 8.8.8.8 e secundário 8.8.4.4, nome de domínio empresa.local e tempo de lease padrão de 8 dias. Endereços de .1 a .49 e de .201 a .254 ficarão reservados para equipamentos com IP fixo, como switches, roteadores, servidores e impressoras.

O primeiro passo é acessar o modo de configuração global e definir as exclusões de endereço. As exclusões devem ser configuradas antes da criação do pool, pois o IOS não impede que você crie um pool que inclua endereços excluídos, mas simplesmente não os oferecerá — e a ordem de configuração afeta a clareza da configuração final. Em seguida, criamos o pool nomeado, definimos a rede e a máscara, e especificamos todos os parâmetros obrigatórios e opcionais.

R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.

1. Excluir endereços reservados: Execute o comando ip dhcp excluded-address para cada faixa. Isso impede que o servidor atribua esses IPs dinamicamente.
2. Criar o pool DHCP: Com ip dhcp pool NOME_DO_POOL, você entra no submode dhcp-config.
3. Definir a rede e máscara: O comando network especifica a sub-rede atendida e a máscara no formato CIDR ou decimal.
4. Configurar o default-router: Com default-router IP, você informa o gateway que os clientes usarão.
5. Definir servidores DNS: Use dns-server IP1 IP2 — é possível listar até 8 endereços.
6. Especificar o nome de domínio: domain-name DOMINIO injeta o sufixo DNS nos clientes.
7. Ajustar o tempo de lease: lease DIAS HORAS MINUTOS controla a validade do IP. O padrão é 1 dia.

R1(config)# ip dhcp excluded-address 192.168.100.1 192.168.100.49   ! Reserva para infraestrutura
R1(config)# ip dhcp excluded-address 192.168.100.201 192.168.100.254 ! Reserva alta
R1(config)# ip dhcp pool LAN_CORPORATIVA                         ! Cria o pool com nome descritivo
R1(dhcp-config)# network 192.168.100.0 255.255.255.0               ! Sub-rede e máscara
R1(dhcp-config)# default-router 192.168.100.1                      ! Gateway padrão
R1(dhcp-config)# dns-server 8.8.8.8 8.8.4.4                       ! DNS primário e secundário
R1(dhcp-config)# domain-name empresa.local                          ! Sufixo de domínio
R1(dhcp-config)# lease 8 0 0                                        ! 8 dias, 0 horas, 0 minutos
R1(dhcp-config)# exit
R1(config)#

Após criar o pool, o servidor DHCP ainda não está funcional, pois é necessário ativar o serviço na interface que atende a sub-rede. O IOS vincula automaticamente o pool à interface cujo IP pertence à rede definida no network. Contudo, por segurança e controle, devemos garantir que a interface não tenha nenhum filtro que bloqueie o tráfego UDP 67-68 e que o serviço DHCP esteja habilitado globalmente — o que é o padrão, mas pode ser desabilitado com no service dhcp.

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 192.168.100.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# service dhcp                         ! Garante que o serviço DHCP está ativo (padrão)
R1(config)# end
R1#

Neste ponto, o servidor DHCP está ativo e responderá a broadcasts na interface GigabitEthernet0/1. A lógica de funcionamento é simples: quando o IOS recebe um DHCP Discover em uma interface, ele verifica se existe algum pool cuja rede corresponda à sub-rede da interface. Em caso positivo, e havendo endereços disponíveis no pool (respeitando as exclusões), ele encaminha um DHCP Offer. Todo esse processo acontece sem nenhuma configuração adicional de rotas ou protocolos — o próprio IOS gerencia o estado do lease e a renovação.

Configuração avançada de pools e opções DHCP customizadas

Além dos parâmetros básicos que configuramos, o DHCP no Cisco IOS suporta dezenas de opções definidas pela RFC 2132. Opções como servidor TFTP para telefones IP (opção 150), servidor de tempo NTP (opção 42), servidor WINS para redes legadas (opção 44) e até mesmo rotas estáticas sem classe (opção 121) podem ser configuradas diretamente no pool. A sintaxe genérica é option CÓDIGO [ascii|hex|ip] VALOR. Vamos enriquecer nosso pool com opções comuns em ambientes de telefonia IP e infraestrutura de impressoras.

R1(config)# ip dhcp pool LAN_CORPORATIVA
R1(dhcp-config)# option 150 ip 192.168.100.10                ! Servidor TFTP para telefones Cisco
R1(dhcp-config)# option 66 ascii printer-server.empresa.local ! Servidor de boot para impressoras
R1(dhcp-config)# option 42 ip 192.168.100.1                  ! NTP server (mesmo roteador)
R1(dhcp-config)# netbios-name-server 192.168.100.5           ! WINS legado (opção 44)
R1(dhcp-config)# exit

Também é possível configurar client-identifier e hardware-address dentro do pool para criar associações estáticas — bindings manuais que reservam um IP específico para um determinado endereço MAC. Isso é feito com o comando address IP client-id STRING ou address IP hardware-address MAC. A diferença entre eles é que o hardware-address é usado para clientes que se identificam pelo MAC (maioria dos dispositivos Ethernet), enquanto o client-id é uma string enviada pelo cliente (comum em Windows, que envia um identificador derivado do MAC).

R1(config)# ip dhcp pool IMPRESSORA_RH
R1(dhcp-config)# host 192.168.100.20 255.255.255.0             ! Define IP fixo por host
R1(dhcp-config)# hardware-address 001a.a2b3.c4d5                ! MAC da impressora
R1(dhcp-config)# default-router 192.168.100.1
R1(dhcp-config)# dns-server 8.8.8.8
R1(dhcp-config)# exit
R1(config)# ip dhcp excluded-address 192.168.100.20             ! Exclui do pool dinâmico

Observe que criamos um pool separado para a impressora e utilizamos o comando host em vez de network. Essa é a prática recomendada para reservas manuais: pools com host especificam um único IP e não entram no pool dinâmico. Mesmo assim, é prudente manter o endereço na lista de exclusões para evitar conflitos caso outro pool dinâmico inclua essa faixa. Em nossa experiência na JRT Technology Solutions, recomendamos sempre documentar cada pool estático e revisar as exclusões antes de expandir um pool existente.

Configurando o DHCP Relay Agent — retransmissão entre sub-redes

Em uma arquitetura corporativa típica, os servidores DHCP estão centralizados no datacenter ou na matriz, enquanto os clientes estão espalhados por diversas VLANs e filiais. O roteador que interconecta essas sub-redes precisa atuar como relay agent, capturando os broadcasts DHCP de cada VLAN e encaminhando-os via unicast para o servidor central. O comando responsável por essa mágica é o ip helper-address, aplicado na interface ou subinterface que recebe os broadcasts dos clientes.

Vamos simular um cenário onde o roteador R1 interconecta a VLAN 10 (clientes em 192.168.10.0/24) e a VLAN 20 (clientes em 192.168.20.0/24). O servidor DHCP está na rede 10.0.0.0/24, com IP 10.0.0.5. R1 possui as subinterfaces para cada VLAN e uma interface conectada ao servidor. Nosso objetivo é fazer com que clientes em ambas as VLANs obtenham IPs do servidor 10.0.0.5, sem configurar pool local algum no roteador.

R1(config)# interface gigabitethernet0/0.10
R1(config-subif)# encapsulation dot1Q 10
R1(config-subif)# ip address 192.168.10.1 255.255.255.0
R1(config-subif)# ip helper-address 10.0.0.5                ! Relay para servidor DHCP
R1(config-subif)# exit

R1(config)# interface gigabitethernet0/0.20
R1(config-subif)# encapsulation dot1Q 20
R1(config-subif)# ip address 192.168.20.1 255.255.255.0
R1(config-subif)# ip helper-address 10.0.0.5                ! Mesmo servidor atende VLAN 20
R1(config-subif)# exit

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 10.0.0.1 255.255.255.0            ! Interface voltada para o servidor
R1(config-if)# no shutdown
R1(config-if)# exit

Quando o cliente na VLAN 10 envia um DHCP Discover, o roteador o recebe na subinterface Gi0/0.10. O IOS identifica que há um ip helper-address configurado e reencapsula o pacote como unicast UDP porta 67 para 10.0.0.5. O campo GIADDR é automaticamente preenchido com 192.168.10.1 — o IP da interface que recebeu o broadcast. O servidor DHCP remoto, ao receber esse pacote, consulta seus pools e encontra aquele que corresponde à rede 192.168.10.0/24, graças ao GIADDR. A resposta (DHCP Offer) é enviada de volta ao GIADDR (192.168.10.1) como unicast, e o roteador a entrega ao cliente via broadcast ou unicast, dependendo da flag de broadcast no pacote.

Um ponto frequentemente negligenciado é que o ip helper-address, por padrão, encaminha não apenas DHCP (portas 67-68), mas também TFTP (69), DNS (53), Time (37), NetBIOS (137-138) e outros protocolos. Em ambientes seguros, isso pode ser indesejado. Felizmente, o IOS permite filtrar quais protocolos são retransmitidos com o comando ip forward-protocol global e comandos de negação específicos por interface usando no ip forward-protocol udp.

R1(config)# no ip forward-protocol udp 69     ! Bloqueia TFTP globalmente
R1(config)# no ip forward-protocol udp 53     ! Bloqueia DNS
R1(config)# interface gigabitethernet0/0.10
R1(config-subif)# ip forward-protocol udp 67   ! Permite apenas DHCP server
R1(config-subif)# ip forward-protocol udp 68   ! Permite apenas DHCP client
R1(config-subif)# end

Com esta configuração refinada, apenas o tráfego DHCP é encaminhado ao servidor remoto. Este detalhe demonstra o nível de controle que o DHCP no Cisco IOS oferece ao administrador. Em nossos projetos na JRT Technology Solutions, sempre configuramos filtros de protocolo no helper-address para reduzir tráfego desnecessário e mitigar vetores de ataque que exploram serviços legados como TFTP.

Verificando a Instalação / Testando a Configuração

Após implementar o servidor DHCP ou o relay agent, precisamos validar o funcionamento com uma série de comandos de verificação. O Cisco IOS oferece um ecossistema rico de comandos show e debug que expõem cada aspecto da operação DHCP. Vamos explorar os mais importantes e interpretar suas saídas.

Comece pelo comando show ip dhcp binding, que exibe todos os leases ativos no servidor local. Para cada binding, você verá o endereço IP, o MAC do cliente, a data de expiração do lease e o tipo de binding (automático ou manual). Se você configurou reservas manuais, elas também aparecerão aqui. Este é o comando mais utilizado no dia a dia para verificar se os clientes estão recebendo endereços corretamente.

R1# show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
                    Hardware address/
                    User name
192.168.100.51      0100.1a2b.3c4d.5e       Jun 28 2026 02:30 PM    Automatic
192.168.100.52      0100.1a2b.3c4d.5f       Jun 28 2026 02:35 PM    Automatic
192.168.100.20      001a.a2b3.c4d5          Infinite                 Manual

R1# show ip dhcp pool
Pool LAN_CORPORATIVA :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 254
 Leased addresses               : 2
 Excluded addresses             : 102
 Pending event                  : none

 1 subnet is currently in the pool :
 Current index        IP address range                    Leased/Excluded/Total
 192.168.100.51       192.168.100.1 - 192.168.100.254     2     / 102    / 254

O comando show ip dhcp pool fornece uma visão consolidada da utilização do pool: total de endereços, quantos estão alugados, quantos foram excluídos e o índice atual de alocação. Preste atenção especial ao campo “Utilization mark” — quando atinge 100%, o pool está esgotado e novos clientes não conseguirão endereços. Em ambientes monitorados pela JRT Technology Solutions, configuramos alarmes baseados neste contador para evitar exaustão silenciosa.

Para analisar o funcionamento do relay, utilize show ip dhcp server statistics para contabilizar os pacotes encaminhados, e o clássico debug ip dhcp server events ou debug ip dhcp server packet para acompanhar o processo DORA em tempo real. O debug é verboso e deve ser usado com cautela em equipamentos de produção, mas é insuperável para diagnóstico.

R1# debug ip dhcp server events
DHCP server events debugging is on

*Jun 27 15:45:01.123: DHCPD: Sending notification of ASSIGNMENT:
*Jun 27 15:45:01.123: DHCPD: address 192.168.100.53 mask 255.255.255.0
*Jun 27 15:45:01.123: DHCPD: htype 1 chaddr 001a.2b3c.4d60
*Jun 27 15:45:01.123: DHCPD: lease time remaining (secs) = 691200
*Jun 27 15:45:01.123: DHCPD: interface = GigabitEthernet0/1

R1# show ip dhcp server statistics
Memory usage          : 42156
Address pools         : 3
Database agents       : 0
Automatic bindings    : 2
Manual bindings       : 1
Expired bindings      : 0
Malformed messages    : 0
Message               Received         Sent
DHCPDISCOVER          27               --
DHCPOFFER             --               25
DHCPREQUEST           25               --
DHCPACK               --               25
DHCPNAK               --               0

As estatísticas mostram claramente o número de mensagens DHCP trocadas. Uma discrepância grande entre DISCOVER recebidos e OFFER enviados pode indicar que o pool está cheio ou que há um problema de conectividade na resposta. Se a coluna DHCPNAK apresentar valores altos, significa que clientes estão solicitando renovação de IPs que não pertencem a eles ou que a sub-rede mudou sem a devida limpeza dos bindings.

Erros Comuns e Como Resolver

Durante a implementação de DHCP no Cisco IOS, alguns erros se repetem com frequência entre profissionais de todos os níveis. Abaixo, listamos os quatro mais comuns que encontramos em nossos atendimentos na JRT Technology Solutions, com a causa raiz, sintoma observado e solução definitiva.

• Erro 1: Cliente não recebe IP — pool não corresponde à sub-rede da interface.
  • Causa: O pool foi criado com uma rede diferente do IP configurado na interface que recebe os broadcasts. O IOS só oferece endereços de um pool se a sub-rede do pool coincidir com a sub-rede da interface de entrada.
  • Sintoma: Debug mostra “DHCPD: network not found for interface” ou simplesmente o servidor ignora o Discover. O cliente fica com APIPA (169.254.x.x).
  • Solução: Execute show ip interface brief e show ip dhcp pool e compare as sub-redes. Corrija o comando network no pool ou ajuste o IP da interface para que correspondam exatamente.
• Erro 2: Relay não encaminha pacotes — rota ausente para o servidor DHCP.
  • Causa: O roteador que possui o ip helper-address configurado não tem uma rota válida — estática ou dinâmica — para alcançar o IP do servidor DHCP remoto. Como o pacote é transformado em unicast, ele precisa ser roteado.
  • Sintoma: Debug mostra “DHCPD: forward broadcast packet to IP_ADDRESS failed” ou “encapsulation failed”. Clientes não recebem ofertas.
  • Solução: Verifique a tabela de roteamento com show ip route SERVER_IP. Se ausente, adicione uma rota estática ou corrija o protocolo de roteamento. Teste conectividade com ping do roteador ao servidor.
• Erro 3: Conflito de IPs — dois servidores DHCP na mesma sub-rede.
  • Causa: Outro servidor DHCP (Windows, Linux, outro roteador) está ativo no mesmo domínio de broadcast. O cliente pode receber ofertas conflitantes e aceitar a primeira que chegar, causando IPs fora da faixa esperada.
  • Sintoma: Clientes obtêm endereços de sub-redes erradas, com gateways incorretos. show ip dhcp conflict no IOS exibe múltiplos conflitos.
  • Solução: Identifique o servidor DHCP não autorizado com sniffer de rede (Wireshark) ou analisando os MACs dos Offers. Desabilite-o imediatamente. Para prevenir, configure DHCP snooping nos switches de acesso, limitando portas confiáveis.
• Erro 4: Pool esgotado — nenhum endereço disponível para novos clientes.
  • Causa: A faixa de endereços disponíveis (pool menos exclusões) foi totalmente alugada, e os leases ainda não expiraram. Comum em redes Wi-Fi de alta rotatividade com lease time muito longo.
  • Sintoma: show ip dhcp pool mostra “Leased addresses” igual a “Total addresses” menos “Excluded addresses”. Clientes novos recebem DHCP NAK ou timeout.
  • Solução: Reduza o tempo de lease com lease no pool (ex: 0 8 0 para 8 horas), aumente a faixa de endereços reduzindo exclusões ou expanda a sub-rede (ex: de /24 para /23). Em emergência, limpe bindings com clear ip dhcp binding *.

Boas Práticas e Dicas Avançadas

Após dominar a configuração básica e o diagnóstico de erros, é hora de elevar sua implementação de DHCP no Cisco IOS ao nível corporativo. A primeira recomendação envolve a persistência dos bindings. Por padrão, o IOS armazena os leases na RAM e os perde durante um reload, o que pode causar conflitos quando o equipamento retorna e atribui IPs que ainda estão em uso pelos clientes. Para resolver isso, configure um database agent que grava os bindings em um arquivo na flash local ou em um servidor TFTP/FTP/RCP externo.

R1(config)# ip dhcp database flash:dhcp-bindings.txt        ! Persiste na flash
R1(config)# ip dhcp database tftp://10.0.0.10/dhcp-bindings.txt ! Persiste em TFTP
R1(config)# ip dhcp database write-delay 60                   ! Grava a cada 60 segundos

Outra prática essencial é a configuração de alta disponibilidade com múltiplos pools e temporizadores de failover. O IOS suporta a criação de pools secundários com network de backup que serão ativados caso o pool primário se esgote. Embora não substitua um cluster DHCP dedicado, essa técnica oferece uma camada extra de resiliência para pequenas filiais onde o roteador é o único servidor disponível.

A segurança também merece atenção especial. Habilite ip dhcp snooping nos switches de acesso para prevenir ataques de DHCP starvation e rogue DHCP server. Combine isso com ip arp inspection e ip source guard para criar um ambiente robusto de defesa na camada 2. No roteador que atua como servidor, você pode limitar a taxa de pacotes DHCP recebidos por interface com ip dhcp limit lease per interface para mitigar tentativas de exaustão.

Para ambientes com milhares de clientes, considere segmentar os pools em múltiplas sub-redes menores (ex: /24 em vez de /20) para reduzir domínios de broadcast e confinar falhas. Utilize a opção client-identifier ou option 82 (DHCP relay agent information option) para identificar clientes com granularidade e aplicar políticas diferenciadas por switch, porta ou VLAN. Em nossos projetos na JRT Technology Solutions, frequentemente empregamos option 82 para atribuir IPs fixos a dispositivos IoT com base na localização física, independentemente do MAC.

Por fim, monitore proativamente seus pools. Agende um script que execute show ip dhcp pool e show ip dhcp binding periodicamente, comparando com thresholds definidos. Integre esses dados ao seu NMS (Zabbix, PRTG, SolarWinds) usando SNMP OIDs da MIB CISCO-DHCP-SERVER-MIB. A galera de monitoramento ama quando entregamos dashboards com utilização de pools em tempo real.

Resumo da Aula 15

Nesta aula intensiva sobre DHCP no Cisco IOS, você percorreu desde os fundamentos do processo DORA até a implementação avançada de servidores DHCP locais e agentes de relay. Aprendemos que o IOS oferece um servidor DHCP completo que pode substituir soluções externas em cenários de pequeno e médio porte, com suporte a opções customizadas, reservas manuais, persistência de bindings e monitoramento através de comandos show e debug. Dominamos a configuração do ip helper-address para retransmissão entre sub-redes, compreendendo o papel do GIADDR na seleção do pool correto pelo servidor remoto.

As tabelas de referência fornecidas condensam comandos e parâmetros para consulta rápida durante seu trabalho. Os cenários de erro com suas soluções formam um guia de troubleshooting que recomendamos ter sempre à mão. Lembre-se: a ordem das exclusões, a correspondência exata entre sub-redes e o controle de protocolos no helper-address são detalhes que fazem a diferença entre uma configuração que funciona e uma implementação robusta e segura. Em nossos projetos na JRT Technology Solutions, vemos diariamente como esses cuidados evitam horas de debug e insatisfação dos usuários.

Na próxima aula (Aula 16), avançaremos para “NAT e PAT no Cisco IOS — tradução de endereços e sobrecarga”, onde você aprenderá a configurar NAT estático, dinâmico e sobrecarga (PAT) para prover acesso à internet para suas redes internas, integrando perfeitamente com os pools DHCP que configuramos hoje. Até lá, pratique cada comando em seu laboratório, explore as saídas de debug e tente quebrar a configuração intencionalmente para ver como o IOS reage — essa é a melhor forma de fixar o conhecimento. Bons estudos!