Por que o dhclient está emitindo um DHCPREQUEST de unicast a cada ~ 15 segundos em vez de em temporizadores T1 / T2?

4

Estou executando um servidor CentOS 6.2 como meu gateway e firewall, além de fornecer alguns serviços internos. Esta é uma configuração que eu tenho há anos usando vários hardwares e distribuições (baseados em redhat). Recentemente eu corri através de um problema de conectividade com a Internet e acredito que é devido a uma falha com o meu ISP (Roadrunner, Nova Iorque) ou uma falha com a minha configuração (padrão) para o dhclient.

Não estou usando o NetworkManager neste servidor, pois a configuração da rede é estática e o servidor é executado 24/7 como um gateway. Eu tenho minha configuração de interface de script de rede sysconfig como abaixo:

que configurou a interface na inicialização e para usar o DHCP, através do utilitário dhclient. Eu tenho um script de firewall iptables válido que tenho trabalhado continuamente há anos para fornecer funcionalidade de roteamento / NAT, mas isso é irrelevante para o meu problema.

Durante a última semana ou duas (pelo menos, já vi essas entradas de log por um tempo agora), vejo que uma vez que a concessão de DHCP oferecida pelo meu provedor chega ao ponto médio, provocando uma renovação, o dhclient entra em um loop onde a cada 15 segundos ele emite um DHCPREQUEST unicast para a entrada do Servidor DHCP especificada no arquivo /var/lib/dhclient/dhclient-eth1.leases (veja abaixo). Isso continua por horas até que a conectividade de rede seja interrompida ou, eventualmente, tente uma descoberta de transmissão e receba uma nova concessão corretamente.

O loop de solicitação do dhclient é sempre unicast, sempre usando o endereço do servidor DHCP especificado na concessão que está tentando renovar e sempre usa o mesmo valor de xid para cada uma dessas solicitações. Eu estou querendo saber, existe uma maneira de forçar dhclient sempre emitir um broadcast DHCPDISCOVER em vez do pacote REQUEST unicast para renovação? Existe um problema de configuração possível ou isso é apenas o serviço DHCP escamoso da Time Warner? Eu usei o TWC como meu ISP nos últimos 5 anos e nunca tive esse problema ao usar o Linux como um gateway.

Aqui está o meu script de configuração da interface:

/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
NAME=Internet
HWADDR=00:D0:B7:**:**:**
MTU=1500
BOOTPROTO=dhcp
PEERDNS=no
IPV6INIT=no
ONBOOT=yes

Aqui está um exemplo de arquivo dhclient-eth1.leases (atual, mas iniciará o loop em ~ 6-8 horas)

lease {
interface "eth1";
fixed-address 74.***.***.***;
option subnet-mask 255.255.240.0;
option routers 74.***.***.***;
option dhcp-lease-time 43200;
option dhcp-message-type 5;
option domain-name-servers 209.18.47.61,209.18.47.62;
option dhcp-server-identifier 10.111.64.1;
option interface-mtu 576;
option broadcast-address 255.255.255.255;
option domain-name "rochester.rr.com";
renew 3 2012/01/18 21:51:02;
rebind 4 2012/01/19 02:57:58;
expire 4 2012/01/19 04:27:58;
}

e um excerto de / var / log / messages em relação a esse problema (iniciado às 12h30 e que continua até as 11h30 da manhã de hoje:

... Lista longa de DHCPREQUEST quase idêntico ao abaixo

Jan 17 16:50:59 server dhclient[1384]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x54a5b374)
Jan 17 16:51:13 server dhclient[1384]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x54a5b374)
Jan 17 16:51:21 server dhclient[1384]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x54a5b374)
Jan 17 16:51:31 server dhclient[1384]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x54a5b374)
Jan 17 16:51:31 server dhclient[1384]: DHCPACK from 10.111.64.1 (xid=0x54a5b374)
Jan 17 16:51:31 server dhclient[1384]: bound to 74.69.54.153 -- renewal in 17309 seconds.

Parece que aqui, finalmente, conseguimos um DHCPACK depois de uma longa lista de tentativas

Na noite passada, por volta das 19h30, bem depois da entrada de log acima, às 16:51, e reiniciei o servidor por outros motivos, o que causa a linha REQUEST abaixo.

Jan 17 20:11:51 server dhclient[3872]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x4a4507ce)
Jan 17 20:11:51 server dhclient[3872]: DHCPACK from 10.111.64.1 (xid=0x4a4507ce)
Jan 17 20:11:51 server dhclient[3872]: bound to 74.69.54.153 -- renewal in 17073 seconds.
Jan 18 00:56:24 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 00:56:32 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 00:56:46 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 00:57:04 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 00:57:24 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)

.... omissão de várias horas e muitas linhas do acima, a cada ~ 15 segundos É aqui que eu trouxe manualmente a interface para baixo e para cima.

Jan 18 11:27:29 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 11:27:45 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 11:27:52 server dhclient[3917]: DHCPREQUEST on eth1 to 10.111.64.1 port 67 (xid=0x4a4507ce)
Jan 18 11:27:58 server dhclient[16174]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x63741216)
Jan 18 11:27:58 server dhclient[16174]: DHCPACK from 10.111.64.1 (xid=0x63741216)
Jan 18 11:27:58 server dhclient[16174]: bound to 74.69.54.153 -- renewal in 19384 seconds.

Sempre tive alguns problemas de MTU em relação à fragmentação com meu firewall, mas essa não parece ser a causa raiz aqui, e seria uma questão separada, se houver alguma.

    
por user1146281 18.01.2012 / 19:57

4 respostas

4

Eu tive o mesmo problema com o mesmo ISP (RoadRunner). Parece que o RR fornece um IP do host do dhcp-server-identifier inválido ou inacessível. Embora seja bom se o ISP resolver o problema, você pode adicionar o seguinte ao seu /etc/dhcp/dhclient.conf (a localização pode ser diferente na sua distribuição):

interface "ethX" {
   supersede dhcp-server-identifier 255.255.255.255;
}

Isso fará com que o cliente ignore o endereço IP do servidor dhcp fornecido na resposta e envie uma transmissão para o DHCPREQUEST. Isso é um hack. Provavelmente viola os RFCs do governo, mas funciona para mim.

    
por 06.01.2013 / 00:27
3

Eu tenho esse problema com meu provedor de TV a cabo. Eles não respondem aos pacotes DHCPREQUEST unicast. Eu uso:

iptables -t nat -A OUTPUT -d 10.0.0.0/255.0.0.0 -o eth1 -p udp -m udp --dport 67 -j DNAT - para o destino 255.255.255.255

para transformá-los em transmissões, e o problema desaparece.

    
por 23.05.2012 / 16:26
1

É mais provável que seja devido a regras estranhas de firewall ou a algumas configurações estranhas no final do provedor de serviços em relação a não permitir solicitações DHCP direcionadas. Seu cliente DHCP provavelmente está se comportando corretamente.

Quando o cliente atingir o tempo RENEW, ele enviará DHCPREQUESTS unicast para tentar renovar o mínimo.

Quando chegar ao horário EXPIRE, ele começará a transmitir novamente. E é isso que estamos vendo nos registros que você colou.

Fazer alguma coisa como matar o dhclient, limpar o arquivo de aluguel e reiniciar o dhclient pode fazer as coisas funcionarem. Mas realmente não deveria ser necessário.

Você tem logs de quando a conectividade de rede realmente quebra?

    
por 18.01.2012 / 21:36
1

Eu tive isso também, o problema é que o dhclient está enviando solicitações de unicast (IP do servidor) para o ISP e meu ISP não aceita unicast apenas multicast (255.255.255.255), dhclient deve retornar ao multicast quando o unicast falha, mas não parece fazer isso até voltar ou expirar (não tenho certeza de qual) e isso pode acontecer dias depois.

Minha solução foi rodar este script diariamente com root em / etc / crontab

#!/bin/bash
/usr/bin/killall -vw dhclient
/sbin/dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0 -cf /etc/dhcp/dhcpd.conf eth0

A primeira linha elimina o dhclient existente que está enviando as solicitações unicast. A segunda linha inicia uma nova instância que usa multicast.

torne o script executável

chmod 755 /root/renew.sh

adicione uma linha como essa em / etc / crontab

10 1    * * *   root /root/renew.sh
    
por 11.03.2016 / 12:56