Em um servidor DHCP Linux, estou obtendo várias dessas linhas de log:
dhcpd: DHCPDISCOVER from 00:30:48:fe:5c:9c via eth1: network 192.168.2.0/24: no free leases
Eu não tenho nenhuma máquina com 00: 30: 48: fe: 5c: 9c e não pretendo dar um IP para 00: 30: 48: fe: 5c: 9c (o que quer que possa ser ).
Eu rastreei o servidor de onde isso está vindo e matei todos os clientes DHCP que estavam em execução, mas as solicitações DHCPDISCOVER não pararam.
Eu posso provar que este é o servidor de envio puxando o cabo Ethernet - os pedidos param.
O estranho é que o servidor de envio só tem 2 interfaces:
Qual pode ser a causa do endereço off-by-one? Quem poderia estar enviando os pedidos?
Meu cliente DHCP é o padrão no link do do Debian 6.0 (Squeeze)
No host do cliente DHCP:
root@n34:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 100
link/ether 00:30:48:fe:5c:9a brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 00:30:48:fe:5c:9b brd ff:ff:ff:ff:ff:ff
4: ib0: <BROADCAST,MULTICAST> mtu 2044 qdisc noop state DOWN qlen 256
link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:08:81:9f brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
5: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 256
link/infiniband 80:00:00:49:fe:80:00:00:00:00:00:00:00:02:c9:03:00:08:81:a0 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
No host do cliente DHCP (mesmas informações acima):
root@n34:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:30:48:fe:5c:9a
inet addr:192.168.2.234 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fefe:5c9a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:72544 errors:0 dropped:0 overruns:0 frame:0
TX packets:152773 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4908592 (4.6 MiB) TX bytes:89815782 (85.6 MiB)
Memory:dfd60000-dfd80000
eth1 Link encap:Ethernet HWaddr 00:30:48:fe:5c:9b
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Memory:dfde0000-dfe00000
ib0 Link encap:UNSPEC HWaddr 80-00-00-48-FE-80-00-00-00-00-00-00-00-00-00-00
BROADCAST MULTICAST MTU:2044 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ib1 Link encap:UNSPEC HWaddr 80-00-00-49-FE-80-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.3.234 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::202:c903:8:81a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2044 Metric:1
RX packets:1330 errors:0 dropped:0 overruns:0 frame:0
TX packets:255 errors:0 dropped:5 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:716415 (699.6 KiB) TX bytes:17584 (17.1 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)
Os nós foram criados com Perseus que usa kexec ao invés de reinicializar.
A primeira coisa que vem à mente é uma interface Supermicro IPMI (o fabricante dos endereços MAC mostra como Supermicro). Por padrão, as placas IPMI tentam puxar um endereço DHCP. Em placas mais novas, as interfaces IPMI são incorporadas e geralmente compartilham uma porta ethernet. Mas tem seu próprio endereço MAC.
Qual placa Supermicro ou modelo superserver é essa?
Verifique as informações do BIOS para as interfaces, não apenas o que é mais fácil de obter no sistema operacional.
Está se tornando comum que as placas de rede de servidor incluam o suporte a iSCSI (ou FCoE) embutido. Quando fazem isso, é através de uma placa Ethernet compartilhada, mas com um endereço MAC diferente. E o endereço MAC diferente será desativado em um. Você pode ser capaz de parar as solicitações DHCP, bloqueando o carregamento de um driver de armazenamento (ou, de alguma forma, configurando esse driver de armazenamento). Seria parecido com algum tipo de driver SCSI ou FC. Se isso é o que é, as solicitações DHCP extras são inofensivas, no entanto.
Também é possível que seja uma interface de gerenciamento (sem luzes) compartilhando a mesma porta. Isso provavelmente também apareceria em algum lugar no BIOS.
A própria mensagem de erro informa tudo o que você precisa saber. Especificamente: no free leases . Isso significa que o servidor DHCP não tem mais endereços livres para distribuir. Como a máquina que está solicitando um endereço não obteve um, mas obteve uma resposta válida de um servidor DHCP, ele continuará pedindo por um. Em outras palavras, você está olhando para o lado errado do problema.
Você pode tentar usar o comando lshw -short para obter informações detalhadas sobre seu hardware. Pode apontar na direção certa. No entanto, como John disse, é provável que seja um porto de gerenciamento de algum tipo. Você provavelmente poderia filtrar o mac no seu switch.
Algo como:
mac-address-table static 00:30:48:fe:5c:9c vlan <vlan> drop
É provavelmente a placa IPMI. Você pode desativar as solicitações DHCP com este comando:
sudo ipmitool lan set 1 ipsrc static
(Você pode precisar alterar o '1' nesse comando, dependendo do seu canal de lan.)
Tags dhcp linux mac-address ipmi ipmitool