Currupt IOS image

[flagshipcreditcorp]

I am trying to understand what causes a currupt IOS image. I have 4506-e that needed to have supervisor replaced becuase the IOS was said to be currupt. I am trying to understand what some of the possiblities that could have caused this.

[Collin Clark]

There could be a couple of things, but the most common is using TFTP to transfer the image. It's uses UDP which is best effort. It's best to use a TCP based protocol for transfers. For example FTP, SCP, or even HTTP. Verifying the image is a good practice to get into as well. I wrote a quick how-to and you can view it here.

https://packetpros.com/cisco_kb/Hash.html

One thing that sounds strange is that you stated you need the Sup replaced because of bad IOS?? You can re-upload the image and boot from it, you don't need a new Sup.

Hope that helps.

[flagshipcreditcorp]

thanks collin.

The image was running for 9 months before the switch went down. Could this image run that long and still be corrupt.

The other theory that is being kick around is that surge could have done it. there were storms and we lost power for 5 seconds and then the switch stop working. Finally, I discovered that the switch was not a surge protector. Could this have led to the curruption?

[Collin Clark · Accepted solution]

Absolutely. The flash file system can become corrupt and I've seen that happen multiple times with power surges.

[CriscoSystems]

I knew UDP was the L4 protocol for TFTP, but does the TFTP application itself not have a spec for recovering missed segments?

I'm having megaprobs transferring some IOS images in my lab (stubborn nvalid checksum errors). They're just going via crossover cable from one box to another so I don't suspect dropped segments.

[Collin Clark]

TFTP does not have any checksum/recovery mechanisms. See if you get the same issue using FTP. If so then you may have something wrong with your cable.

[CriscoSystems]

Hmmm, so it's Cisco's -what, boostrap code? - that's complaining about the checksum?

I'll set up a networkette with my switch and some str8-thru cables, if the crossover cable is what you suspect.

Thanks.

[CriscoSystems]

Can anyone recommend a good FTP server?

I'm trying FileZilla at the moment and I want to incinerate it.

It keeps saying Connect to server? Except I want it to BE the server....

[Leo Laohoo]

Don't know about FTP server but I use either 3Cdaemon or TFTP32.

[Collin Clark]

I've been using BulletProof for years.

http://www.bpftpserver.com/

[Richard Burts]

Collin

It is not true that TFTP does not have an error checking and recovery mechanism. TFTP does have a mechanism that checks what is transmitted and does have a mechanism for retransmitting segments. It is not in UDP but it is provided in TFTP.

I would agree that it is better to use something like FTP to transfer images (and the motivation for FTP increases as the image gets larger). But the preference for FTP is based on its greater efficiency and not on a supposed lack of error recovery in TFTP.

HTH

Rick

[Collin Clark]

The recovery though is strictly at the source end is it not? The TFTP server checks for lost segments sent however, how could the client check for lost segments received?

[CriscoSystems]

I have noticed that 3CDaemon has FTP capabilities as well as TFTP so I've been using that.

The problem at this point is that Routers C and E are stuck in Rxboot mode, which - as best I can tell - only allows TFTP transfers into Flash.

I've had the same checksum problem now when copying from another router, copying from a PC using XP's TFTP service, using 3C, using crossover cable; using an Ethernet switch....

I believe the problem is localized to Router C. Could it be anything other than just a bad Flash SIMM?

[Richard Burts]

Collin

No the recovery is not strictly at the source end. The TFTP server sends an acknowledgement of each packet and if the source does not receive an acknowledgement for a packet then it will retransmit the packet.

HTH

Rick