One minor correction here....if you are hardcoding the servers speed/ duplex in normal boot - but the netboot is in auto - you are almost CERTAIN to have a duplex mismatch. Switches are getting smarter about this - but the negotiation protocols will pretty much leave you in 100/ FULL on one side, and 100/HALF on the other.
Generally, having come from the ages of dark and mysterious issues with auto-negotiation, I only allow auto-negotiation for clients/ users. Most configs from netboot/install will be auto - if your switches are set/hard-coded 100FULL, well then - there is your problem. I would note - this is not necessarily the case if you are using Gig nics and gig switches (gig negotiation is different and "smarter" than 100Mbps). But still worth checking. Erik On Aug 22, 2008, at 2:37 PM, Erik M. Cummings wrote: > 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-users
