I've searched high and low for this issue, and it's starting to bug the heck out of me. A search in this group gives me some results, but none of it fixes the problem.
I use Ghost 9 to image clients currently. Imaging over a Cisco switch(3524s and 3548s) yeilds 15MB/min, sometimes slower. Imaging over any other switch(A rackmount Dlink, a rackmount Linksys) gives what I'm used to: 400-500MB/min. I've been donig Ghost imaging for years from my previous employers, and I just got into this new place, where it's not working.
The results I've seen have suggested that there could be a speed-duplex mismatch. I took a machine with the e100 NDIS driver, hardcoded it to use 100 Full, and then looked at the switch, where it says it's set to do 100 Full. I've isolated the problem entirely to two machines and one switch: DHCP/Ghost server and the client, with a 3524XL in the middle. Cables are professionally made, a media test on them shows no problems. The problem exists on all machines, any time a 3524/3548 is used. At all my old employers, I've never had to hardcode anything, always did auto. I also never had access to switch configs, so I don't know what was set in there to compare to what I have now. All this leads me to believe it's an issue with how the switches are set up.
I'd really like to fix this issue myself, because if I don't, my boss has to pay big bucks to an outside firm, thus causing us to lose some money better spent on upgrades. Any help, guys?
As you say the most likely thing to cause this is a duplex mismatch.
Please "clear counters" and do a Ghost run. Post sh run (best to take confidential info out) and a sh int of the relvant interfaces after the "failure".
I see the same problems with Altiris imaging. I live with it at the moment, it's not a duplex mismatch. I almost feel like it has something to do with multicasting.
Anyway like I said above, I didn't really look into it too much but would LOVE some suggestions.
Verify if IGMP snooping is enabled. On the 3550s it is enabled globally & per vlan by default. It can slow forwarding performance considerably with high bandwidth apps since every frame is inspected for an IGMP header.
Disabling it, however, may lead to unnecessary flooding. CGMP may be a suitable alternative.
Current configuration: ! version 12.0 no service pad service timestamps debug uptime service timestamps log datetime no service password-encryption service sequence-numbers ! hostname SW252 ! ! ! ! ! ! ! ip subnet-zero ! ! ! interface FastEthernet0/1 duplex full speed 100 switchport access vlan 10 ! Everything between here is the same ! interface FastEthernet0/24 duplex full speed 100 switchport access vlan 10 ! interface GigabitEthernet0/1 switchport access vlan 2 switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/2 switchport trunk encapsulation dot1q switchport mode trunk ! interface VLAN1 ip address 192.168.0.252 255.255.255.0 no ip directed-broadcast ip nat outside no ip route-cache ! interface VLAN10 ip address 192.168.10.26 255.255.255.0 no ip directed-broadcast no ip route-cache shutdown ! ip default-gateway 192.168.0.1 snmp-server engineID local 00000009020000049A8B4880 snmp-server community sca-az RW banner motd ^C UNAUTHORIZED ACCESS IS PROHIBITED AND WILL BE PUNISHED TO THE FULLEST EXTENT OF THE LAW! ^C ! ! end
FastEthernet0/34 is up, line protocol is up Hardware is Fast Ethernet, address is 0004.275e.8ca2 (bia
0004.275e.8ca2) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 2/255, rxload 6/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:01, output hang never Last clearing of "show interface" counters 00:03:39 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 2502000 bits/sec, 223 packets/sec 5 minute output rate 934000 bits/sec, 197 packets/sec 105388 packets input, 144291114 bytes Received 24 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 9 multicast 0 input packets with dribble condition detected 77202 packets output, 40759621 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
FastEthernet0/3 is up, line protocol is up Hardware is Fast Ethernet, address is 0004.275e.8c83 (bia
0004.275e.8c83) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 245/255, txload 7/255, rxload 2/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:00, output hang never Last clearing of "show interface" counters 00:04:31 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 869000 bits/sec, 152 packets/sec 5 minute output rate 2795000 bits/sec, 277 packets/sec 73542 packets input, 38715181 bytes Received 21546 broadcasts, 0 runts, 0 giants, 0 throttles 2799 input errors, 2799 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 21527 multicast 0 input packets with dribble condition detected 133518 packets output, 176781935 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
0/34 is the client, 0/3 is the ghostcast server. The port light is also flashing amber.
As far as IGMP and CGMP: I d> I've searched high and low for this issue, and it's starting to bug the
Turning on global cgmp fast-leave doubled the multicast rate to
30MB/min(was 15MB/min). Unicast(creating the image) incurs no problems at all, it's just restoring the image(multicast) that has issues. Setting the switch and clients to auto-negotiate did nothing.
Notice that the CRC and frame errors are on the ghostcast server port, and there's no problems on the client end. I don't know what that means, but it sure does mean something.
The ONLY thing that I trust when it comes to duplex determination are the error counters on reputable network equipment. Search the group for more ranting from me on subject.
Looks like it's settled around 350MB/min! Thanks so much for your help!
Now, to understand exactly how you figured this out, so I can help some one else should I ever encounter it again...
The errors on just the one end told you that just that end is having the issue. The duplex mismatch idea just comes with experience, or is there something that tipped you off to that as well?
Experience. Errors on one end happens nearly all the time when there is a duplex mismatch. About the only other thing that can cause the same problem is a bad transmit driver on one end (or an exceptionally dirty telephone.)
I always hesitate before disagreeing with Walter however in this case I do.
It could be called experience however I would not do so. I have a (mental) model of how how ethernet works and I run the model against the observed behaviour and get the answer. There is no black magic only logic.
The keys to understanding the error pattern that duplex missmatches create are the csma/cd algorithm and the way that HD ethernet interfaces are constructed. There is (in truth I am not quite 100% on this but I have a lot of evidence that I am correct) a feedback loop (yes really - a wire) that connect the output of the transmitter to the input of the receiver inside HD interfaces. The purpose of this is to permit collision detection. The interface compares what is sent with what is received and if they are not the same then it assumes that a collision has occured.
It also helps to know exactly what each error counter is counting.
The experience comes in when I estimate that 99% (or more 99.99?) of such error conditions are caused by misconfiguration and not by real hardware problems. The HD/FD thing has, it seems clear in retrosoect, been badly designed from a usability perspective. It may have been the best solution available at the time. I am not in a position to be able to criticise the individuals involved and that is not my intention however it seems to me that the result has not been pretty.
Anyway at the end of the day the FD end of a mismatch sees CRC and/or frame (sometimes called align) and/or runts (sometimes called short frames).
The HD end sees only Late Collisions although normal HD operation can see certain other errors but I now quite frankly forget the details. They don't matter. Late collisions on a modern switched network == duplex mismatch and you are looking at the HD end.
If you want to know more read Rich Seifert's book (which I have not read but I am pretty convinced is The Business). Rich is on comp.dcom.lans.ethernet.
Port CrcAlign-Err Dropped-Bad-Pkts Collisions Symbol-Err Gi3/19 0 0 28 0
Port Undersize Oversize Fragments Jabbers Gi3/19 0 0 42 0
Port Single-Col Multi-Col Late-Col Excess-Col Gi3/19 16 12 0 0
Port Deferred-Col False-Car Carri-Sen Sequence-Err Gi3/19 632 0 0 14
Here is one that is OK. cat4000-i5s-mz.122-25.EWA5.bin CORE2#sh int fa 3/48 FastEthernet3/48 is up, line protocol is up (connected) 0 output errors, 12249 collisions, 0 interface resets
Most descriptions talk about collision detection from the point of view of one station, and extend the detection to multiple stations only with respect to the explanation of the relationship between the minimum packet size and the collision detection period.
Once one knows how collision detection works, and how full and half duplex differ, it is theoretically possible to make the jump to how a half duplex signal would interact with a full duplex signal on the same segment, but I doubt that many people do so just by reasoning.
What I suspect is that -most- people read about ethernet and don't immediately understand everything they read, and they go and experiment with it and see what happens in practice, and go back and re-read, experiment more [possibly over the period of years], read more... repeating until eventually they have a fairly good grasp of how everything goes together. For most people, it isn't a constant growth, I think: reading and experimentation can lead to confusion of in their mental model, and sometimes things have to be -unlearned- because a wrong approximation was learned along the way (wrong deduction or wrong information read.)
Thus, I suspect that for -most- people, the way it goes with duplex problems is that unless they get lucky and read about the matter first, that they encounter the problem and flail around trying to solve it, accidently or by configuration comparison hit upon the solution, and -then- reflect upon it and say to themselves "Oh, of course! Why didn't I think of that before?!?". Sort of like, "I've always known it worked that way, but I just didn't think about it." ;-)
One -could- get an accurate and useful mental model of duplex operations (and malfunctions) purely through book-learning, but I think that for nearly everyone, the reality is that understanding ethernet requires a hefty dose of experience.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.