Imaging across VLANS.
-
Server
- FOG Version: 1.5.0-RC-2
- OS: CentOS 7
I have been attacking this problem for awhile now but do not seem to be getting any closer to the solution. If any of you have any suggestions - I am willing to try them. I have attached an image at the very bottom describing the setup.
The problem is that I cannot image any computers that are not on the Native VLAN or on a Trunk port.
Spanning-tree mode is set to rapid, portfast is enabled on all links, and all vlans have an ip-helper address configured.
I can change the link between the client and the switch to Trunk or Native and fog will drop an image just fine.I would like to get it working with vlans if possible – does anyone have it working in a multiple vlan environment?
Clients from any vlan can ping the fog server - but any client that isn’t on Native or a Trunk port will fail during an image (or registration) task with this error:
-
@JLE said in Imaging across VLANS.:
10.241.96.0/19 (Vlan 300)
FOG Server info:
10.241.3.100/16Something just struck me, hopefully there is a type-o here.
Your fog server is at 10.241.3.100/16 or subnet mask of 255.255.0.0, your vlan 300 is 10.241.96.0/19 (255.255.224.0). The issue is see is that subnet 10.241.96.0/19 is in the middle of the larger 10.241.3.100/16 subnet.
If this is true, I can understand why routing is not working and things are falling down.
-
@JLE This doesn’t look too bad. I think we should figure this out fairly soon. From the picture you posted (client boot screen) it looks like you got past all the initial PXE hurdles already.
From the messages on screen it looks as if the router address being assigned via DHCP does not match the setup (or maybe it’s the netmask). See this
route: SIOCADDRT: Network is unreachable. Please double check your DHCP server config. Either the specified router is not within the subnet or the netmask is not wide enough for the client to reach the router. -
Yes I have fog running in a fully routed network (with subnets/vlans).
When I see the pattern like you posted in the picture, where the client is obviously getting an ip address (10.241.96.24) and that is sane for the subnet where the target computer is booting(??) The pxe booting client computer (after obtaining an IP address) will make a web curl call back to the FOG server to confirm the network is up. Its possible that the client can’t reach the FOG server on port 80, or the client is being told the wrong information to reach back to the fog server. Now I’m not saying this is your issue, its just typically when we see this, the client can’t reach the fog server so after 3 tries it gives up.
-
I am at a loss.
Client’s info:
10.241.96.0/19 (Vlan 300)
DHCP tells these guys Option 66 (10.241.3.100) and Option 67 (undionly.kpxe)
These clients can ping the fog server, can get to the web console at the IP, can get through the fog boot menu - but show the above error when given an image task or when trying to register.FOG Server info:
10.241.3.100/16
Single NIC with that above setting - I shut down the teaming to simplify for now.
Some values from the .fogsettings file:
ipaddress=10.241.3.100
routeraddress=10.241.3.9
dnsaddress=10.241.3.9I am not even sure that dns address is important? Also I’ve seen a subnet field in other people’s .fogsettings but mine doesn’t even have one? Is that OK?
Should I set the routeraddress= to my dhcp/dns server (that is where it is now @ 10.241.3.9) – or should it be set to the switch stack that has IP routing enabled?
-Also I have disabled the firewall on the FOG server completely-
-
@JLE This sounds really weird! From the information you gave the clients shouldn’t be able to contact (ping etc.) the FOG server at all.
10.241.96.0/19 = range 10.241.96.1 - 10.241.127.254, so the router address needs to be within this range for a client to be able to talk to and beyond that router! Maybe windows is doing some magic here to make it work - check with
ipconfig /allon the command line?But then, why does PXE booting actually get that far. How does a client get the iPXE binary via TFTP if it cannot contact the router?? Ahhhhh, now I see, there are also ip helpers for TFTP - which I didn’t know about until now. So this might be the magic going on, hmm?
Maybe I am wrong but when I learned networking I was told that clients need to have a router address within their subnet!
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@JLE said in Imaging across VLANS.:
10.241.96.0/19 (Vlan 300)
FOG Server info:
10.241.3.100/16Something just struck me, hopefully there is a type-o here.
Your fog server is at 10.241.3.100/16 or subnet mask of 255.255.0.0, your vlan 300 is 10.241.96.0/19 (255.255.224.0). The issue is see is that subnet 10.241.96.0/19 is in the middle of the larger 10.241.3.100/16 subnet.
If this is true, I can understand why routing is not working and things are falling down.
-
@JLE said in Imaging across VLANS.:
-Also I have disabled the firewall on the FOG server completely-
The firewall on the fog server should not be enabled at all.
-
@JLE On the FOG server I need you to check 3 places to make sure the proper IP address is defined for the fog server.
In the FOG Configuration -> FOG Settings confirm:
FOG_TFTP_HOST
FOG_WEB_HOST
point to your FOG server IP
FOG_WEB_ROOT should say/fog/Then in storage management -> Master node (may say defaultmaster)
confirm
IP Address == fog server IP
Web root == /fog -
@Sebastian-Roth said in Imaging across VLANS.:
Maybe I am wrong but when I learned networking I was told that clients need to have a router address within their subnet!
Your training was not wrong. The clients can only talk to clients (and routers) that have interfaces on the same subnet. If the router doesn’t have an interface on the same subnet, then it can’t be used as a gateway to pass traffic.
-
Alright, I will check those IP settings on the different places on the fog server tomorrow. I will also move the fog server’s subnet to a /20 (which is where it is supposed to be based off it’s IP). I am amazed that so many pieces are working with it on the wrong subnet. I guess since FOG was on a larger /16 subnet and vlan 300 happen to be within a piece of it that some things worked.
@Sebastian-Roth When you say that “clients need to have a router address within their subnet” you just mean the ‘default gateway’ that’s handed out by the DHCP server right? Beyond that I would have no idea.
I will make this subnet change on the server and confirm the IP settings tomorrow and then report back.
-
@JLE OK let us know how it works out once routing is fixed.
-
Yep, that solved it. Routing was the whole problem. Option 3 on the DHCP server for Vlan 300 was indeed outside of the subnet for that scope. I pointed it to the SVI on the routing stack and everything is great. We now have FOG with vlans! Thanks guys.
-
@JLE So your FOG server is still configured as 10.241.3.100/16?? Just wondering if you might run into other issues fairly soon. See if you can make multicast deploy work across your vlans.
-
@Sebastian-Roth I changed the FOG server over to 255.255.240.0, the old subnet was from before vlans were implemented it just got passed over
