/build/static/layout/Breadcrumb_cap_w.png

DHCP Option 244 and 66 TFTP

Hey everyone! I haven't seen anyone post my exact issue and I am new to the KACE system. I did have my DHCP server setup with option 66 and 67 and my test system here was booting just fine with PXE and I even imaged a few mahcines. Turns out, we have a SIP server that hands out configuration files (TFTP) that has to use option 66 in DHCP. So I figured I could use the alternate option 244. But now I just get a TFTP error (from the option 66 TFTP server) when the PXE boots and it doesn't appear to attempt to use the value I set in option 244. I set the value to be the same, which was the IP address of the KBOX and I also restarted the DHCP service and the scope is set to both DHCP and Bootp. Any suggestions or anyone else have similar issues? Can I not use BOTH 66 and 244 options with different servers?

Seth Coleman
Network and Server Administrator
Synergy Solutions

0 Comments   [ + ] Show comments

Answers (10)

Posted by: airwolf 13 years ago
Red Belt
1
You can't have two PXE servers... you can only boot to one. One of 'em has to go. Or you'll have to segment your K2000 onto a different subnet and build systems on that subnet.
Posted by: jkatkace 13 years ago
Purple Belt
1
Typically, a DHCP server does "scope management", which is where different options are handed out to different set of IP addresses. With Windows-based DCHP, the scopes are handled in a tree view in the DCHP app, and you drag machines from AD into the scopes you want. With unix-based DHCP, scopes are typically defined in the dhcp.conf text file. Here's a relevant excerpt from http://www.linuxmanpages.com/man5/dhcpd.conf.5.php. You'd put appropriate options in the subnet definitions or group defnitions below, or even do host-specific ones.

A typical dhcpd.conf file will look something like this: global parameters...

subnet 204.254.239.0 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.10 204.254.239.30;
}

subnet 204.254.239.32 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.42 204.254.239.62;
}

subnet 204.254.239.64 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.74 204.254.239.94;
}

group {
group-specific parameters...
host zappo.test.isc.org {
host-specific parameters...
}
host beppo.test.isc.org {
host-specific parameters...
}
host harpo.test.isc.org {
host-specific parameters...
}
Posted by: airwolf 13 years ago
Red Belt
1
Right, but you'd still have to use different subnets. You can't have two PXE servers for the same scope. Even if you could, a PXE client would boot to the first one every time - which is why you can't.
Posted by: dyehardfan 13 years ago
Second Degree Blue Belt
1
I am trying to work through a similar issue. The VOIP phone system we've put in place uses DHCP to pull an IP and then the computer runs through the phones pulling DHCP from the same subnet as the phones. What I am trying to find out is if I can basically enact an ACL in Windows DHCP that says if the Node attempting to pull DHCP has one of the following MAC addresses it pulls an IP address from the VOIP subnet, otherwise pull from subnet X where our K1000 and k2000 reside....


ORIGINAL: airwolf

Right, but you'd still have to use different subnets. You can't have two PXE servers for the same scope. Even if you could, a PXE client would boot to the first one every time - which is why you can't.
Posted by: booth2 13 years ago
Yellow Belt
1
Is there a way to hard code the ip of the kace box instead of the startnet.cmd file using kgetdhcp? (probably the simplest way to do it)
Or can you set option 244 and modify the creation of the startnet.cmd to not look at option 66?

I don't see why you do it that way at all. Surely you wouldn't have your kace appliance using an ip that isnt staticed.


This is troublesome. Some of us out there are using pxelinux (which is what kace is using) to chainload several network boot files and option 66 isn't going to be the kace box.
Posted by: dchristian 13 years ago
Red Belt
1
hey booth2,

This is doable.

Have you gone through your jump start training?

Your trainer or support would be able to give you the appropriate upgrade files.

I've had to do this a few times when working with Cisco DHCP.

For some reason I've seen option 66 return some funny results.
Posted by: booth2 13 years ago
Yellow Belt
1
Thanks. I just emailed our support person to ask about those files. Did these upgrade files static in the ip of the kace box or just make it look at option 244?
Posted by: dchristian 13 years ago
Red Belt
1
booth2,

There are a couple of variations available.

Original.bin has KBE search option 66 and then option 244.

Switch.bin has KBE search for option 244 and then option 66. We have seen this needed with Cisco DHCP especially.

Fallback.bin has KBE search for option 66 and then option 244, if both fail then it hard codes the K2000 IP.

Switch_fallback.bin has KBE search for option 244 and then option 66, if both fail then it hard codes the K2000 IP.

Static.bin has the k2000 IP hardcoded in and does not search for either option. This can be used with customers that don’t use DHCP or don’t PXE boot.

Your support person or jumpstart trainer will help you decided which way to go.
Posted by: ramseygr 12 years ago
Senior Yellow Belt
1
@dchristain - where can I find information about the static.bin file? that sounds like what I need - but I don't k now where it exists, or how to implement it.
Posted by: dchristian 12 years ago
Red Belt
1
Static.bin is available from support and trainers.

To be honest I haven't had to use it since 3.3 came out.

After 3.3 they've default to fallback.

Fallback.bin has KBE search for option 66 and then option 244, if both fail then it hard codes the K2000 IP.

If you need it though, i would reach out to support.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ