Imaging across VLANS.

[Sebastian Roth]

@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 /all on 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!

[george1421]

@JLE said in Imaging across VLANS.:

10.241.96.0/19 (Vlan 300)

FOG Server info:
10.241.3.100/16

Something 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.

[george1421]

@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.

[george1421]

@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

[george1421]

@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.

[JLE]

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.

[george1421]

@JLE OK let us know how it works out once routing is fixed.

[JLE]

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.

[Sebastian Roth]

@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.

[JLE]

@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