Interface múltipla Red Hat 6 ISC Servidor DHCP enviando PXE incorreto próximo servidor

Question

Minha configuração: Red Hat 6,7 servidor isd dhcp 2x redes conectadas (A e B) Um pool DHCP configurado na rede A

Quando eu tive este servidor configurado em uma única rede ("A") funcionou bem, agora que eu adicionei uma segunda rede ("B") o servidor DHCP está enviando o endereço IP da rede "B" para "próximo servidor" para clientes PXE. Não consigo descobrir o porquê.

Os endereços DHCP saem corretamente, portanto, quando um cliente na Rede A solicita uma concessão, o servidor DHCP envia corretamente uma concessão do pool na Rede A.

Eu adicionei a diretiva next-server com o endereço correto da Rede B por todo o lugar e ela ainda não faz nada. Eu tentei: Como a primeira linha na configuração global do dhcpd.conf Dentro da declaração de sub-rede Dentro da declaração de piscina abaixo da sub-rede Dentro da classe pxeclient

Editar: Rede A é 192.168.0.0/24 A rede B é 192.168.1.0/24

Quando os clientes PXE aparecem na Rede A, eles recebem a concessão do DHCP do pool, mas o próximo servidor é enviado como 192.168.1.1, em vez de 192.168.0.1

Config file /etc/dhcp/dhcpd.conf

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#   see 'man 5 dhcpd.conf'
#
#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#   see 'man 5 dhcpd.conf'
#
# dhcpd.conf

next-server 192.168.0.1;
option tftp-server-name = "192.168.0.1";
server-name = "192.168.0.1";

option space PXE;
option PXE.mtftp-ip    code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16; # RFC4578

default-lease-time 86400; #1 day
max-lease-time 604800; #7 days
option domain-name "satellite";
option domain-name-servers 192.168.0.1;

allow booting;
allow bootp;

log-facility local7;

ddns-update-style interim;
ignore client-updates;
authoritative;

omapi-port 7911;
#Optional key:
key omapi_key {
        algorithm HMAC-MD5;
        secret "[...]";
}
omapi-key omapi_key;

  option pxegrub code 150 = text ;

#################################
# local
#################################
subnet 192.168.0.0 netmask 255.255.255.0 {
  pool
  {
next-server 192.168.0.1;
option tftp-server-name = "192.168.0.1";
server-name = "192.168.0.1";
    range 192.168.0.10 192.168.0.253;

  }
    allow booting;
    allow bootp;

next-server 192.168.0.1;
option tftp-server-name = "192.168.0.1";
server-name = "192.168.0.1";

  option routers 192.168.0.254;
  option domain-name    "satellite";
  option domain-name-servers  192.168.0.1;
  option subnet-mask 255.255.255.0;
  option fqdn.no-client-update    on;  # set the "O" and "S" flag bits
  option fqdn.rcode2            255;

  # PXE Handoff.
        class "pxeclients" {
                  match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
                 #option pxegrub code 150 = text;
next-server 192.168.0.1;
option tftp-server-name = "192.168.0.1";
server-name = "192.168.0.1";


                  if option arch = 00:06 {
                          filename "bootia32.efi";
                  } else if option arch = 00:07 {
                          filename "bootx64.efi";
                  } else {
                          filename "pxelinux.0";
                  }
          }


}



include "/etc/dhcp/dhcpd.hosts";

    

Answer 1

Eu descobri o que estava acontecendo, estou usando o Foreman (o Red Hat Satellite's upstream) para provisionar esses hosts e parece que ele escreveu uma concessão estática em /var/lib/dhcpd/dhcpd.leases com um servidor de superação.next-server = AA: BB: CC: DD; Onde o IP é representado como 4 octetos HEX.