DHCP option 82 usage problem , shared switchport Blade+BMC

LARPENT Jacques jacques.larpent at altran.com
Wed Oct 15 12:53:37 UTC 2014


Gentlemen,

I'm facing a DHCP issue with the following set up and prerequisites.

DHCP server is version dhcp-4.2.5-27 running on a RHEL7.0.

I have several blade enclosures. Inside an enclosure, an ethernet switch federates all the blades and the blades's BMCs so that behind a switchport inside the enclosure we see two MAC@ : NIC blade + NIC BMC. (This is constraint #1).
The blade enclosures are uplinked to switch acting as layer 3 router between the different VLANs/subnet deployed inside the enclosures (typically a VLAN for blade NICs and another for the BMCs).

"Classic" host addressing with hardware ethernet host identifier and fixed-address inside hosts declaration works fine : the initial DHCPREQUEST is correctly forwarded to DHCP server via "dhcp ip-helper" address defined on each routing VLAN interfaces on the layer 3 switch. The rest of the DHCP handshake finalizes corredclty.

Then, my goal was to "get rid" of MAC@ management especially to avoid MAC@ harvesting to build DHCP server conf files by using DHCP option 82.
I have configured the ethernet switches embbeded in the enclosures to append the DHCP frames initiated by all clients : blades and BMCs, with option 82 suboptions remote_id and circuit_id. The remote_id is unique for a given switch in an enclosure.
This is working fine : frames received on the DHCP server correclty show the right circuit_id and remote_id.

Since I have several blade enclosures, a single circuit_id received on DHCP server is not globally unique on the network so that the server's lookup must also take the remote_id into account.

Then I have created DHCP classes with one IP range in each of them.

The classes are designed to match :   remote_id AND circuit_id AND vendor-class-identifier   to identify a client.

I precise that considering constraint #1 I have to check the vendor-class-identifier to make the difference between a blade  or its BMC.

examples for blade n°11 and its BMC plugged on switchport n°11:

class "BMC11" {
                match if ( substring (option agent.remote-id, 0 , 7) = "switch1" and
                         ( binary-to-ascii (10, 16, ".", substring(option agent.circuit-id, 1, 4)) ="11") and
                         ( substring (option vendor-class-identifier, 0, 6) = "iamBMC"));
             }

        pool {
                allow members of "BMC11";
                range 10.0.0.11;
             }

class "blade11" {
                match if ( substring (option agent.remote-id, 0 , 7) = "switch1" and
                         ( binary-to-ascii (10, 16, ".", substring(option agent.circuit-id, 1, 4)) ="11") and not
                         ( substring (option vendor-class-identifier, 0, 6) = "iamBMC"));
             }

        pool {
                allow members of "blade11";
                        range 12.0.0.11;
                filename "ipxelinux.0";

             }

Testing procedure :

Step 1. DHCP server is started. At statrup, no lease are present in the .lease file
Step 2. BMC power ON : everything is fine, DHCP handshake based on class matching is OK, IP is rechable. On DHCP server side, a lease entry is created for this client.
Step 3. Blade power ON:  the intel boot agent does his job by obtainnig a DHCP IP at . This DHCP handshake is done OK. On DHCP server side, a lease entry is created for this client.
Step 4. The blade is forced power OFF.
Step 5. Blade is powered ON:  the intel boot agent does his job by obtainning a DHCP IP at . Then,  DHCP handshake is NOK, the intel boot agent keeps sending DHCPREQUEST replied by the server with a: "no free leases" messages.

My understanding is that usually a "no free leases" message occurs when either the DHCP client is not matched by the server or when the lease is effectively already allocated. Then, as the DHCP handshake worked well for the blade at Step 3 my opinion is that the server correclty matches again the blade at Step5 but the lease is not free at that time. Where is the trick?


Thanks in advance.

Regards,
Jacques.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20141015/102014a3/attachment.html>


More information about the dhcp-users mailing list