• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Mastriani
    3. Posts
    M
    • Profile
    • Following 1
    • Followers 0
    • Topics 2
    • Posts 28
    • Groups 0

    Posts

    Recent Best Controversial
    • RE: Using dumb switch to troubleshoot imaging, network related

      @george1421 said in Using dumb switch to troubleshoot imaging, network related:

      This is an interesting puzzle here. You should not have this issue (which you know all ready). When I run into this puzzles I remember what one of my university professors told me when debugging an electrical circuit. “You have first find out where the problem isn’t to find out where the problem is” So you start where the problem should be and then work your way away from where the problem isn’t to where it is. So far his statement has worked for me well.

      If you have a better approach, then I am all … well, reading glasses, as it were. Resolution is what is most important. Hopefully I can also make use of Mr. Workman’s talents as well, and grab a few new neuronal connections in the process.

      posted in General Problems
      M
      Mastriani
    • RE: Using dumb switch to troubleshoot imaging, network related

      @Tom-Elliott said in Using dumb switch to troubleshoot imaging, network related:

      Just shedding light that udp, unless using multicast, is limited only to tftp traffic and even then is minimal at best

      Is there something else then, in the protocol stack, that should be looked at more closely? The switches currently have igmp snooping disabled, by factory default.

      posted in General Problems
      M
      Mastriani
    • RE: Using dumb switch to troubleshoot imaging, network related

      @george1421

      I have Fog servers at both buildings, suffering the same issues. I will connect as you specified first thing in the morning, and let the capture run.

      Easy enough to get the data you require, I will post that whenever the test completes.

      Greatly appreciate the input, loss of imaging capability has made this school year … frustrating and inefficient.

      posted in General Problems
      M
      Mastriani
    • RE: Using dumb switch to troubleshoot imaging, network related

      @george1421

      All machines that we use are Dell refurbs, ranging from OptiPlex 755 up to Dell 390 with Win 10.

      All images at this point are Win 7, 35 - 55Gb. After researching through community commentary, I changed compression to 5, as most reported this setting maximized throughput in their experience. Previously tried compression 3 and 9, but in the overall, no observable change in capture time frame.

      posted in General Problems
      M
      Mastriani
    • RE: Using dumb switch to troubleshoot imaging, network related

      @Wayne-Workman

      Thank you sir, I will see if I have a laptop available and answer back when that is confirmed. The one I typically use is Win 10, and carries too much information/applications to be reformatted.

      My Linux/Ubuntu capabilities are intermediate, I have never used a live disk or utilities for network troubleshooting, for my ignorance, I might require more information on how this handled.

      posted in General Problems
      M
      Mastriani
    • RE: Using dumb switch to troubleshoot imaging, network related

      @Tom-Elliott

      Mr. Elliot, you sir are a phenom.

      I had tried 2 months ago to do exactly that, but the trunk version, at that time, errored out continually on pxe image boot. At that time, you and your team were working on a fix, but I reformatted the server back to the previously stated conditions.

      posted in General Problems
      M
      Mastriani
    • RE: Using dumb switch to troubleshoot imaging, network related

      @george1421

      According to just theoretical throughput of the Enterasys switch, yes, all are listed as GbE.

      Yes, I have even moved ports and rechecked, no issue with the FOG server connecting. The server itself is Dell PE 2950 / Dual Quad core / 16 Gb RAM /Broadcom Extreme GbE NIC.

      Yes, there are some other issues. The DNS retardation was cleared up yesterday, I retested this morning; no change in performance outcome. A major issue, (in my thinking at least), is the interface for these switches. Correct me if I am wrong, but FOG utilizes UDP heavily, and as of yet I can find no utility for looking into the protocol stack settings for this hardware.

      Our ISP/Support is ENA, and they have done all they can, even extended past their “contractual” level support, but cannot pinpoint the issue as they can only look inside individual LAN’s on the WAN, not down to device level. There is, from my observations, some issue that is causing chronic IP conflict, no rogue DHCP/DNS servers found, but the tech who installed the switch hardware didn’t seem particularly detail oriented, ie. yesterday I found that jumbo frames/MTU settings were different on every switch in both my buildings, now corrected.

      It looks directly like a switching issue to me, because during the 3.5+ hour capture, you can watch the bandwidth continually degrade, typically starting between 2.4 - 4 Gb/s down to less than 100Mb/s, continual drop off.

      posted in General Problems
      M
      Mastriani
    • Using dumb switch to troubleshoot imaging, network related

      Our district has been using Fog since .29/Ubuntu 10.4

      It has been the most formidable tool in cutting time costs, and saving the minds of most of the very small IT team. Many thanks to the venerable Fog team and community.

      3 years ago we had a one-sided network overhaul, new switches through all schools, addition of wireless to all schools. Extreme Networks/Enterasys switches. I despise this equipment. Fog has never operated correctly since the new hardware install.

      Currently on 1.0.2/Ubuntu 14.04 LTS, no DHCP from Fog server, handled by Win AD/DC, newer server because certain members of the team thought the server was the issue. Not a chance.

      Issues, definitely network hardware related: Capture, minimum 3.5 to 5.5 hours.
      Download: maximum of 4 machines, 45m - 1 hr/per. Anything over 4 machines, imaging hangs/fails/sits in queue indefinitely.

      Need to test on a dumb switch, haven’t been able to get it to work, client requests DHCP, which isn’t available, why am I a moron, and what do I need to change/correct to get this done?

      Many thanks to all members of the Fog team and community for effort and expertise nearly unmatched.

      posted in General Problems
      M
      Mastriani
    • 1 / 1