A couple quick possibilities:
1. Duplicate IP addresses. Okay - yes....dumb thing, but check it
out. If you are somehow netbooting and getting a dupe IP, well...that
would not show up on a direct x-over connection!
2. Frame size/fragmentation. Netbooting maybe different kernel/
different configs, slightly different parameters for ethernet card.
Some switches don't like larger packet sizes.
3. Put a sniffer on it. I'm not an expert on sniffing from Hosts
(yet), but the ethershark/ethereal derivatives are pretty thorough.
This would need to be on the systemimager server of course.
4. Check the switch for errors on that port.
5. Speed/Duplex issues. Again - kind of a dumb one, but if the
netboot kernel/driver has a problem with eth negotiation - OR doesn't
leave the card auto, then you can have a speed or duplex mismatch.
Speed mismatch generally causes issues IMMEDIATELY and doesn't work
well at all. Duplex mismatch (100-full one side, 100-1/2duplex on the
other) can cause REAL problems with larger traffic loads. In general
a REALLY quick way to test this one is to ping with a larger packet
size through the connection. With small packets getting close to 0%
loss, and the larger the packet the larger the % loss. Generally we
always check with 32, 1600, 3500, 6000, 10000, 50000 byte packets.
This ASSUMES you are pinging something that will accept packets that
large! 100% packet loss generally means you've tried to ping with a
larger packet than the host will accept! This is kind of a long shot
- but it doesn't take long to check! OH - final note here - try the
test in BOTH directions. You SHOULD see the issue from either side,
but occasionally I've seen issues where it wasn't detectable from the
full duplex side.
6. Check the switch for errors on that port! Did I say this
already? Depending on the type of error - I can probably tell you
MORE (frags, crc, align, runt, etc).
Erik
On Aug 22, 2008, at 2:09 PM, Brodie, Kent wrote:
> Well, I'm floored.
>
> Even though I didn't believe it would be the cause, I finally
> snagged a
> crossover cable from the closet-of-goodies and re-imaged my client.
> Eliminating variables is what we sysadmins just gotta do. Even
> when it
> feels stupid.
>
> Worked. (Insert deer in headlights look here)
>
> OK, so it seems that in one way or another, rsync is causing the
> switch
> to choke. I buy that, since I just saw that with a direct crossover,
> it works.
>
> What I don't get is, why does rsync _NOT_ have any issues when I do
> stuff like build the golden client image etc, and I only see this
> behavior after net-booting? It's the same freaking set of files....
> "when is rsync not really rsync"?
>
> If any of you net gurus out there have an explanation- I'm all ears.
> Not to mention any ideas on a switch/port setting that might make my
> HP
> procurve switch play nice?
>
> What a long day.
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sisuite-users mailing list
> sisuite-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sisuite-users
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
sisuite-users mailing list
sisuite-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-users
