Feasibility of upgrading from 1.3.5 - Network issues
-
Hi,
So I’ve been using 1.3.5 for a while now on Debian (Jessie) - pretty much the only thing stopping me from updating at this stage is DHCP failing after PXE boot, which I do understand from poking around the forums for the last year is very likely portfast/STP. Basically I get this error only across subnets (I think). I have done the thing where you put a dumb switch between the client and the managed switch which has worked.
So here’s the issue: all of our switches are managed by head office and I need to try and sit down at some stage where both me and the network administrator have time to try and suss it out. Providing this is the same issue:
- does STP/portfast need to be adjusted across all switches, or just the port the server is plugged into (we have a random collection of HP and Dell switches across the whole school)
- is there anything else I can do at the FOG server level or DHCP server (Windows 2008 R2) before stuffing around with the switches?
We are replacing the whole lot with new Meraki switches at some stage - I just don’t know when “some stage” is and it’d be nice if I could update FOG before then.
The FOG server is located on 10.73.81.xxx. The subnets go from 80 (which isn’t used for standard clients) all the way through to 86. I also have 3 nodes scattered across a few subnets (but can move them to the same one if necessary).
Let me know if there’s any other information you need.
Thanks!
-
@joshghz said in Feasibility of upgrading from 1.3.5 - Network issues:
Hi,
So I’ve been using 1.3.5 for a while now on Debian (Jessie) - pretty much the only thing stopping me from updating at this stage is DHCP failing after PXE boot, which I do understand from poking around the forums for the last year is very likely portfast/STP.
Updating or not isn’t going to fix this issue.
Basically I get this error only across subnets (I think). I have done the thing where you put a dumb switch between the client and the managed switch which has worked.
Subnets are irrelevant in regards to this issue. The problem exists between the building switch and the pxe booting computer.
- does STP/portfast need to be adjusted across all switches, or just the port the server is plugged into (we have a random collection of HP and Dell switches across the whole school)
Again if you can place a dumb switch between the pxe booting computer and the building switch and it fixes the issue that is the link where your problem is.
- is there anything else I can do at the FOG server level or DHCP server (Windows 2008 R2) before stuffing around with the switches?
Yes and No. Yes you should upgrade your dhcp server to windows 2012 or later. That will give you the ability to support (PXE boot) both bios (legacy mode) and uefi base computers. The switching between boot files will then be dynamic based on the pxe booting target computer. This is not a fog server or dhcp server issue.
The issue is that with standard stp after the link comes up the port will sit and listen for 27 seconds before it starts to forward data. The side issue is as the target computer boots it “winks” the network link twice. Once as iPXE Menu starts and once as FOS starts. This resets the 27 second timer. The issue is that FOS booting is so fast, by the time the building switch port starts forwarding data again FOS has already given up trying to boot. By placing a dumb switch in between the building switch and the pxe booting computer the building switch never sees the network link “wink” so it continues to forward the data. The dumb switches typically don’t use spanning tree so this is a good test to find out if its a spanning tree or not. Now standard spanning tree is called pessimistic forwarding, it listens first then forwards data if it doesn’t hear another BPDU. RSTP is call an optimistic forwarding, where it starts to forward data first then listens for any BPDU packets.
So what you need to do is have your network engineer turn on one of the fast spanning tree protocols on every user facing network port.
-
Hi George, thanks so much for your prompt answer!
@george1421 said in Feasibility of upgrading from 1.3.5 - Network issues:
@joshghz said in Feasibility of upgrading from 1.3.5 - Network issues:
- is there anything else I can do at the FOG server level or DHCP server (Windows 2008 R2) before stuffing around with the switches?
Yes and No. Yes you should upgrade your dhcp server to windows 2012 or later. That will give you the ability to support (PXE boot) both bios (legacy mode) and uefi base computers. The switching between boot files will then be dynamic based on the pxe booting target computer. This is not a fog server or dhcp server issue.
Yeah, I don’t think this is going to happen any time soon. This is also one of those things controlled by head office.
The issue is that with standard stp after the link comes up the port will sit and listen for 27 seconds before it starts to forward data. The side issue is as the target computer boots it “winks” the network link twice. Once as iPXE Menu starts and once as FOS starts. This resets the 27 second timer. The issue is that FOS booting is so fast, by the time the building switch port starts forwarding data again FOS has already given up trying to boot. By placing a dumb switch in between the building switch and the pxe booting computer the building switch never sees the network link “wink” so it continues to forward the data. The dumb switches typically don’t use spanning tree so this is a good test to find out if its a spanning tree or not. Now standard spanning tree is called pessimistic forwarding, it listens first then forwards data if it doesn’t hear another BPDU. RSTP is call an optimistic forwarding, where it starts to forward data first then listens for any BPDU packets.
So what you need to do is have your network engineer turn on one of the fast spanning tree protocols on every user facing network port.
Okay, that’s fair. So to clarify, RSTP has to be enabled on all client ports/switches, not just the one the FOG server is connected to?
-
@joshghz said in Feasibility of upgrading from 1.3.5 - Network issues:
So to clarify, RSTP has to be enabled on all client ports/switches, not just the one the FOG server is connected to?
Yes client ports only, (typically) the fog server never winks the network link at all while running. This issue is exactly between the pxe booting computer and the building switch.
-
@george1421 said in Feasibility of upgrading from 1.3.5 - Network issues:
@joshghz said in Feasibility of upgrading from 1.3.5 - Network issues:
So to clarify, RSTP has to be enabled on all client ports/switches, not just the one the FOG server is connected to?
Yes client ports only, (typically) the fog server never winks the network link at all while running. This issue is exactly between the pxe booting computer and the building switch.
Yeahhhhhh, that’s what I was afraid of. I’ll have a chat with him at some stage, but I’m going to guess this endeavour may have to wait until we get the Merakis.
Thanks anyway! It was really helpful to suss this out.
