1

I have a virtual network configured in libvirt and configured to provide DHCP (via dnsmasq) but not configured to provide bootp information (see below), but when I boot an iPXE ISO and look at the traffic in wireshark I see that the DHCP service on that virtual network seems to be responding with a next-server parameter:

bootp.ip.server 192.168.122.1

This causes a problem because I'd like to use another server as a DHCP proxy to provide PXE information and for this to work libvirt's DHCP service has not not provide the next-server value.

How can I get libvirt virtual networks to not send that value?

EDIT: it seems that geeting libvirt's dnsmasq to ignore bootp requests can be accomplished by adding the folling statement to /var/lib/libvirt/dnsmasq/defaut.conf:

dhcp-ignore: bootp

...unfortunately thi file is overwritten when libvirt is restarted. Not sure if there's a configurable template where arguments for all virtual networks can be placed.

Virtual Network config:

<network connections='3'>
  <name>default</name>
  <uuid>59535def-2082-42f4-8e5e-a68f6f0fffbd</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:1c:02:0e'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

DHCP request from iPXE:

16:04:59.394149 IP (tos 0x0, ttl 64, id 2237, offset 0, flags [none], proto UDP (17), length 441)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:35:45:c5, length 413, xid 0xb665d069, secs 11, Flags [Broadcast] (0x8000)
  Client-Ethernet-Address 52:54:00:35:45:c5
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Request
    MSZ Option 57, length 2: 1472
    ARCH Option 93, length 2: 0
    NDI Option 94, length 3: 1.2.1
    Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
    CLASS Option 77, length 4: "iPXE"
    Parameter-Request Option 55, length 21: 
      Subnet-Mask, Default-Gateway, Domain-Name-Server, LOG
      Hostname, Domain-Name, RP, Vendor-Option
      Vendor-Class, TFTP, BF, Option 128
      Option 129, Option 130, Option 131, Option 132
      Option 133, Option 134, Option 135, Option 175
      Option 203
    T175 Option 175, length 51: 177.5.1.16.236.129.57.34.1.1.25.1.1.33.1.1.24.1.1.235.3.1.0.0.38.1.1.17.1.1.19.1.1.23.1.1.21.1.1.39.1.1.16.1.2.18.1.1.27.1.1
    Client-ID Option 61, length 7: ether 52:54:00:35:45:c5
    GUID Option 97, length 17: 0.36.246.109.48.115.66.98.75.170.28.144.120.91.142.203.164
    Server-ID Option 54, length 4: 192.168.122.1
    Requested-IP Option 50, length 4: 192.168.122.178
    END Option 255, length 0

DHCP response from libvirt:

16:04:59.487750 IP (tos 0xc0, ttl 64, id 11805, offset 0, flags [none], proto UDP (17), length 328)
192.168.122.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xb665d069, secs 11, Flags [Broadcast] (0x8000)
  Your-IP 192.168.122.178
  Server-IP 192.168.122.1
  Client-Ethernet-Address 52:54:00:35:45:c5
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: ACK
    Server-ID Option 54, length 4: 192.168.122.1
    Lease-Time Option 51, length 4: 3600
    RN Option 58, length 4: 1800
    RB Option 59, length 4: 3150
    Subnet-Mask Option 1, length 4: 255.255.255.0
    BR Option 28, length 4: 192.168.122.255
    Default-Gateway Option 3, length 4: 192.168.122.1
    Domain-Name-Server Option 6, length 4: 192.168.122.1
    END Option 255, length 0
    PAD Option 0, length 0, occurs 8
Gestellen
  • 35
  • 1
  • 7

1 Answers1

0

You need to actually disable the DHCP settings in libvirt for this network. The server being returned is NOT the next-server but rather who the DHCP server is which of course it's libvirt's local interface. You would need to completly disable DHCP from libvirt's point of view and let your external DHCP server do all the work. It's not trivial (if at all possible) to configure libvirt to act as a DHCP relay and forward the message to your original server.

Diego Garcia Del Rio
  • 1