[c-nsp] tftp woes

Dan Letkeman danletkeman at gmail.com
Mon Jul 25 14:12:47 EDT 2011


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.hicks at 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.hicks at poggs.co.uk>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



More information about the cisco-nsp mailing list