Re: [c-nsp] tftp woes
Dan Letkeman wrote: > > I think the server might be over utilized as well, because if we are > imaging off of one server and then we tftp off of another, things are > faster. So that to me says that its a server problem and not a > network problem. > > Yes we multicast as well, but sometimes the guys who do the imaging > want to unicast instead for what ever reason. > Our guys need the same (they rarely use the multicast functionality although they do still need it) as we unfortunately have to use FreeGhost, well I guess it's better than that 'other' ghosting tool. Anyway, I remember duct taping the problem by configuring SFQ on the Linux host in the egress direction to stop the unicast NFS flows saturating the link and preventing the TFTP flows from being starved. Not perfect, but it was good enough as a quick fix. Cheers -- Alexander Clouter .sigmonster says: Are you a turtle? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] tftp woes
Thanks guys, I will do some packet captures and see what it shows me. I think the server might be over utilized as well, because if we are imaging off of one server and then we tftp off of another, things are faster. So that to me says that its a server problem and not a network problem. Yes we multicast as well, but sometimes the guys who do the imaging want to unicast instead for what ever reason. Dan. On Mon, Jul 25, 2011 at 2:25 AM, Peter Hicks wrote: > On Sun, 2011-07-24 at 21:43 -0500, Dan Letkeman wrote: > >> After about 12-15 machines start the image transfer the server gets >> over utilized and the tftp download from the server starts to take a >> lot longer on the rest of the machines that need to download the >> imaging software, not the image itself. Is there a simple way on >> these switches to prioritize the tftp traffic over the actual image >> transfer? Possibly some simple QOS commands? > > tftp is UDP-based, have you checked the whole network to make sure you > don't have a duff link producing errors and dropping UDP packets? Are > you suffering over-utilization at any point? > > Is the initial software download happening in a machine's PXE > environment? If so, the timeout for tftp packets may be a lot larger > than you expect, hence a single packet being dropped equates a much > larger impact. > > Have you looked at a multicast-based solution for imaging the machines? > > > Peter > > -- > Peter Hicks > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] tftp woes
On Sun, 2011-07-24 at 21:43 -0500, Dan Letkeman wrote: > After about 12-15 machines start the image transfer the server gets > over utilized and the tftp download from the server starts to take a > lot longer on the rest of the machines that need to download the > imaging software, not the image itself. Is there a simple way on > these switches to prioritize the tftp traffic over the actual image > transfer? Possibly some simple QOS commands? tftp is UDP-based, have you checked the whole network to make sure you don't have a duff link producing errors and dropping UDP packets? Are you suffering over-utilization at any point? Is the initial software download happening in a machine's PXE environment? If so, the timeout for tftp packets may be a lot larger than you expect, hence a single packet being dropped equates a much larger impact. Have you looked at a multicast-based solution for imaging the machines? Peter -- Peter Hicks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] tftp woes
Hello, We have imaging servers in all of our locations, and we normally image around 30 to 60 machines at once. The image is usually stored on a server with local SAS raid storage, which is connected to a 3560G at1Gbps, and then to 2960's (10/100 w/Gig Uplinks to the 3560G). After about 12-15 machines start the image transfer the server gets over utilized and the tftp download from the server starts to take a lot longer on the rest of the machines that need to download the imaging software, not the image itself. Is there a simple way on these switches to prioritize the tftp traffic over the actual image transfer? Possibly some simple QOS commands? Thanks, Dan. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
