No DHCP response (Multiple VLAN setup)

[mhanna]

Server

• FOG Version: 1.3.5
• OS: CentoOS 7

Description

Here is the situation I am having… I’ve been scouring the internet for a few days now with no luck solving so I’m hoping someone can point me in the right directions. I have a network with 3 vlans each with a different network. I have routers in place that route between the vlans/networks just fine. I previously had Fog 1.20 running on Ubuntu just fine with this setup but I stood up a new Fog server on CentOS and am having an odd issues I cant figure out. The Fog server is on a vlan/network 192.168.91.X. There is a Windows DHCP server on this VLAN that dishes out IP’s just fine. Clients on this VLAN are given DNS servers in the 172.30.10.X VLAN and all clients can access DNS just fine. I’ve setup DHCP option 66 and 67 as specified and clients pxe boot into the Fog menu just fine. Just to clarify the clients are on the 192.168.91.x vlan (same vlan as Fog server). The issues start when I try to do anything from this point on. For example when doing a full host registration there are multiple lines of udhcpc stating that a lease of 192.168.91.x was obtained. Followed deleting routers, adding dns 172.30.1.x. After this it goes to sending discover and sending select for the IP which was obtained by DHCP. At this point the whole process starts again and it just keeps looping until it finally bugs out and says no DHCP response on interface eth0. I’m not really sure where the issue is or what to look at so any friendly pointers in the right direction would be appreciated.

[Tom Elliott]

Could you please install one of the 1.4.0-RC-9.3? There was work in regards to this finding IP’s and what not.

[mhanna]

@Tom-Elliott said in No DHCP response (Multiple VLAN setup):

f the 1.4.0-RC-9.3? There was work in

I upgraded as suggested and the behavior is identical… nothing changed that I can see.

[Tom Elliott]

You’re sure the client machine is getting an IP in the same VLAN as the FOG Server?

[mhanna]

@Tom-Elliott

Yes, when watching the information scroll up the screen I can see the line where it indicates lease of 192.168.91.x was obtained… this is the same vlan/network on which the Fog server is located. It then shows it is deleting routers and then adding the DNS servers on the 172.30.1.x VLAN. It then goes right back to udhcpc: started and begins the loop again.

[Tom Elliott]

@mhanna Anyway, for now, to separate the vlan and allow just the FOG Server and clients to communicate initially? This really seems, to me, to indicate the fog server is inaccessible to the Client machine.

FOG, during boot, will attempt to use a curl request after obtaining the IP to validate that it can communicate with the FOG Server. It would seem, too me, that this is where the problem is occurring. It simply has no way to communicate to the FOG Server at this point.

If you’d like, you can recreate the tasking, or append isdebug=yes to the registration menu item parameters to have the FOS Engine drop into a terminal so we can run more direct tests.

[mhanna]

@Tom-Elliott

I’ll double check all my firewall rules and routing one more time to make sure I didnt miss something there. If I find nothing I’ll do as suggested and report my finding.

[mhanna]

@Tom-Elliott said in No DHCP response (Multiple VLAN setup):

isdebug=yes

Ok, I’ve verified I have no firewall rules at all in place that would block clients that are both on the 192.168.91.x subnet from communicating. Where is exactly do I add the isdebug=yes… in the boot options for the registration? If so are the options comma seperated? Once added what are my next steps?

[Tom Elliott]

@mhanna they’re space separated.

The “easiest” but applies to ALL things (menu, taskings, etc…) would be to add isdebug=yes to:

FOG Configuration Page->FOG Settings->General Settings->FOG_KERNEL_ARGS

Save and restart your client machine and you should see it load into debug mode (after failing to do the ip stuff).

[mhanna]

@Tom-Elliott

Ok, I am sitting at debug windows now… any steps you suggest I perform. ifconfig looks as it should. Its on the same vlan as fog server with correct netmask. No errors, no drops.

[Tom Elliott]

@mhanna Can you run:
curl -Ifso /dev/null http://fogserverip/fog/management/index.php --connect-timeout 5

Change fogserverip with your fogserver’s IP address.

What comes back?

[mhanna]

@Tom-Elliott

The command executed. Didn’t generate anything… just ran and nothing. I’m not able to ping from the client to fog server or the other way around. Which is odd because I can ping from the fog serve to every other IP on the VLAN that I’ve attempted.

[Tom Elliott]

@mhanna But ifconfig returns with a valid IP Address?

You could try:

udhcpd -i eth0 (I don’t remember the syntax off the top of my head sorry).

[george1421]

@Tom-Elliott While I understand this will not help right now. I was able to duplicate this condition in my home dev environment last week. I was able to also correct it, it was simple and stupid. I’m sure I communicated with you via chat what I found. But at this point I can’t remember for the life of me what it was.

I was using a virtual box vm and pxe booting it going to test either uefi of dnsmasq and I got that boot loop in FOS. It was a fos thing where it would get the address and then deallocate it and then try again, eventually giving up with the message the OP posted.

[mhanna]

@Tom-Elliott

Yes, valid IP and netmask.

[Tom Elliott]

@mhanna now if you run the curl command followed immediately by:

echo $? it should print a number

[mhanna]

@Tom-Elliott

I added to the end of the curl command you sent me and it still just drops me back at the command line with no output.

[Tom Elliott]

@mhanna so you did:

curl request
echo $?

Or you did:

curl request echo $?

The first form is what I mean sorry for the confusion.

[mhanna]

@Tom-Elliott

Sorry, I did the second… after doing it the correct way the number 7 was returned.

[Tom Elliott]

@mhanna Well your ping command seems to indicate an issue here as well.

And for reference:

CURLE_COULDNT_CONNECT (7)

Failed to connect() to host or proxy.

So both sides seem to point in the same direction. For whatever reason, this vlan is not able to locally communicate.