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 <peter.hi...@poggs.co.uk> 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 <peter.hi...@poggs.co.uk> > > _______________________________________________ > 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/
