• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Connection timed out. Chainloading failed

Scheduled Pinned Locked Moved Unsolved
FOG Problems
2
4
669
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T
    thebrennan47
    last edited by thebrennan47 Apr 24, 2018, 2:00 PM Apr 24, 2018, 7:58 PM

    SERVER
    FOG Version: 1.4.3
    OS: Ubuntu 16.04 Server LTS

    CLIENT
    Service Version:
    OS: Windows 10

    DESCRIPTION

    My current setup is the following:

    • We have a fog server that acts as the imaging / Web UI interface and connects to the outside network.
    • We have 2 Storage Nodes that act as dhcp / tftp servers that also connect to the outside network.
    • We have ~40 hosts that connect to these storage nodes via switch
    • Storage Node #1 (the one that works) is the master node

    The first storage node works perfectly and images it’s hosts as expected, but hosts on the second storage node cannot get past the iPxe boot step. They fail with a “Connection timed out, Chainloading failed”

    I have spent quite a bit of time trying to figure out what the difference is between these two nodes and I am at a bit of a loss. The default.ipxe files are the same between the two, as is /etc/network/interfaces

    I also compared the the contents of /etc/dhcp/dhcpd.conf and the contents of /etc/default/isc-dhcp-server. No issues here either. Also, I moved one of the hosts from node 2 and connected it to node 1. The host no longer had any issues so this seems to be a problem with the storage node and not the clients.

    I have attached two images, one is the error from a host on node 2, and the other is from a host on the working node.

    Any ideas what I could be missing here?

    1_1524600035346_GW2_Err.png 0_1524600035345_GW1_NoError.png

    G 1 Reply Last reply Apr 24, 2018, 8:46 PM Reply Quote 0
    • G
      george1421 Moderator @thebrennan47
      last edited by Apr 24, 2018, 8:46 PM

      @thebrennan47 said in Connection timed out. Chainloading failed:

      Also, I moved one of the hosts from node 2 and connected it to node 1. The host no longer had any issues so this seems to be a problem with the storage node and not the clients.

      Please explain exactly what it means to move a host from node 2 and connected it to node 1

      How do you have the network setup between these two nodes? Are all systems on the same vlan(subnet)? The left image is kind of telling me that the target system doesn’t have a route to 10.8.88.42 from the 192.168.1.1 subnet. SO there is some kind of routing going on here.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      1 Reply Last reply Reply Quote 0
      • T
        thebrennan47
        last edited by thebrennan47 Apr 24, 2018, 3:05 PM Apr 24, 2018, 9:04 PM

        @george1421

        Moving the host means physically moving it and plugging it into the switch that is managed by the other storage node. Both storage nodes are acting as dhcp servers and assigning ips, but they are connected to separate switches. I added a diagram that may help

        0_1524603876030_network.png

        G 1 Reply Last reply Apr 24, 2018, 9:45 PM Reply Quote 0
        • G
          george1421 Moderator @thebrennan47
          last edited by george1421 Apr 24, 2018, 3:51 PM Apr 24, 2018, 9:45 PM

          @thebrennan47 That helps out quite a bit. I thought there was a bit more going on here than I originally imagined.

          You need to change up your configuration. Your storage node is acting as a gateway between the fog server and the target systems. You need to change the served subnet on each storage node. Each storage node needs to be connected to a unique subnet. On the surface you have a routing problem not a fog problem.

          Consider if you are using subnets 192.168.1.x on each storage node. If a computer on SN1 talks to the fog server, and a computer on SN2 talks to the fog server and each has the same subnet, how will the fog server know where/who to respond to.

          So how to fix it? Give SN1 imaging network an IP subnet of 192.168.1.x./24. Give SN2 imaging network an IP subnet of 192.168.2.x/24. Give SN3 imaging network an IP subnet of 192.168.3.x/24.

          Now go to your internet router and create a static route (or you can do this on your FOG Master node) that describes the subnets beyond each storage node. Like

          ip route add 192.168.1.0 mask 255.255.255.0 via {SN1 LAN interface}
          ip route add 192.168.2.0 mask 255.255.255.0 via {SN2 LAN interface}
          ip route add 192.168.3.0 mask 255.255.255.0 via {SN3 LAN interface}

          You will need to change the dhcp server settings on each SN too to match their respective imaging network range.

          Once you have routing and unique IP addresses in play FOG should work a bit better.

          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

          1 Reply Last reply Reply Quote 0
          • 1 / 1
          1 / 1
          • First post
            3/4
            Last post

          214

          Online

          12.0k

          Users

          17.3k

          Topics

          155.2k

          Posts
          Copyright © 2012-2024 FOG Project