Guest Posted July 31, 2002 Report Share Posted July 31, 2002 We just moved to a brand new building with brand new gigabit network. I can no longer get network backups for any of my clients. My server has os 9.1 Mac and the clients are for the most part win2k, win98, pcs and a few mac 9. Every backup it's the same thing, trouble reading files, error 519 network communication failed. We moved from static ips to dhcp from the old to the new building. I can see the clients over the network the backup starts and then drops with the above error. I am at wits end. I have replaced the tape drive, updated my client and server backup software, I have had clients turn off all anti virus on backup nights, I have tried new tapes I have checked the apple site for ethernet software patches and frankly I don't know what else to do. I have never had this problem before, I've gotten weird errors consistently when my drive was too close to my monitor, but my drive is way away from the monitor. Thing is in the old building with our crappy 10mbps speed and rj11 to rj45 cabling my backup worked like a charm. The major difference is brand new speedy wiring, dhcp and using 255.255.252.0 for the gateway. Help! Link to comment Share on other sites More sharing options...
AmyJ Posted August 1, 2002 Report Share Posted August 1, 2002 From the Knowledgebase: www.dantz.com/index.php3?SCREEN=knowledgebase_article&id=186 NO. 415 TROUBLESHOOTING ERROR 519 This note describes actions for you to take when you encounter network communication failure (error 519) with Retrospect. The note is divided into the following sections: - Introduction - How To Use This Document - Troubleshooting Roadmap - Network Integrity - Troubleshooting Client Computers - Troubleshooting The Backup Computer - Known Problems Introduction Error 519 means Retrospect had established a network connection with another computer and was communicating through that connection when something caused the connection to be severed. This error is one of Retrospect’s most challenging errors to troubleshoot because networks involve a large number of variables. Causes of error 519 range from a simple software conflict on an individual workstation to a faulty network component that does not cause trouble during normal (non-backup, less intensive) use. Weak links can exist in the software or hardware level, on the backup computer or the client computer, or in the infrastructure of your network. This document aims to help you narrow down what might at first seem like an unwieldy problem to solve. How To Use This Document Read the Troubleshooting Roadmap below for an understanding of where to begin. If you want to scan quickly through causes of this error that might be solved immediately, review the "Known Problems" section at the end of this document. It lists issues specific to certain software and hardware configurations. This will help you eliminate the known problems first, before you go into deeper levels of troubleshooting. If none of the known issues apply to you then try to determine whether you should focus your troubleshooting on the backup computer, the client computers, or your network. To determine this, read the "Troubleshooting Roadmap" and "Network Integrity" sections of this document. If you are certain the problem lies with the client computer or the backup computer, skip to the sections entitled, "Troubleshooting Client Computers" or "Troubleshooting The Backup Computer." We recommend you read this entire document for a complete overview. Troubleshooting Roadmap Eliminate the Human Factor Some obvious ways for you or another person to cause error 519 during an operation are to put to sleep a notebook computer, to unplug a computer’s network cabling, and to crash or restart a computer. These human actions are often the cause of network failures during work hours. During nights, weekends, or other periods when the client computers are not in use by people, you should track network failures over a period of time and gather information to examine in order to resolve the problem. Identify the Scope Before you can solve a 519 error, you need to determine the scope of the problem. The first step is to find out whether the 519 error is isolated to one computer or occurs with multiple computers. You can determine this in part by reviewing the Retrospect operations log. From the log, create a network map, noting whether the 519 errors occur on random computers or specific computers. Look for patterns. Does a particular computer produce error 519 each time? Does it only happen to clients on a certain network segment? Do these computers have any commonality like version of operating system, computer model, or network card? If there does not seem to be a pattern or if it seems random, start by troubleshooting the backup computer or network integrity. If, after reviewing the log, you determine the 519 errors are associated with one or more specific clients, you should follow the troubleshooting tips in the "Troubleshooting Client Computers" section of this document. Evaluate Network Integrity When evaluating the integrity of your network, it is important to understand the different levels of connectivity and stress which can be tested. You must quantify the connectivity by testing network connections, from simple to complex. Start simply by using a utility to "ping" a client computer, which tests only the most basic connectivity between two computers. A more stressful test is to use Apple’s file sharing or Microsoft Windows networking to connect to other computers and copy files over the network, which tests basic throughput for a short period of time. Among the most stressful of network activities is network backup, which can reveal weak links in your network infrastructure not readily apparent during less stressful activities. Network backups often sustain continuous network throughput with a large and fast stream of packets for long periods of time. You might be able to copy files to and from a network workstation using file sharing, yet copying those same files from that same workstation through its Retrospect client software may produce error 519. This proves only that networking is not completely broken; it does not prove Retrospect or its client software is at fault. For example, a Macintosh may use AppleTalk for file sharing connections but use TCP/IP for Retrospect client connections. These different protocols use entirely different system software components. When troubleshooting network failures, it helps to have "the big picture" of your network. A "map" of your network layout would be helpful. This map can be a diagram displaying the logical location of routers and hubs, trouble-free workstations on your network nodes, and problematic workstations which are producing error 519. Note on your diagram whether or not hubs are switched. The act of creating a diagram like this may itself be a useful troubleshooting aid. For example, the visual representation of your network may show you that all problematic workstations are on a single network branch or hub. You need to be familiar with network hardware components like transceivers, hubs, and routers. For example, if clients on a certain node or segment of your network are the only ones producing error 519, use Retrospect on a computer on the same side of the router as the problematic clients to determine whether the router is involved. Much of your troubleshooting necessarily involves this kind of process of elimination. There are software programs and hardware devices you can use to monitor your network for traffic, collisions, or network utilization which could provide clues about the causes of the connection failures. Get the help of a network administrator if these tools are not readily available to you. If these tools are beyond your experience and you have exhausted as much of the other basic troubleshooting steps in this document as you could, it may be necessary to get help from a network consultant. Troubleshooting Client Computers When troubleshooting the client computer, the first step is to determine whether the problem is with the computer’s software or with its network hardware. On Mac OS-Based Computers 1. Review the "Known Problems" section at the end of this document. If that does not help, proceed with the following list of items. 2. Check for software conflicts. Start by limiting extensions and control panels on the client Macintosh. Using an extension management utility or the Extensions Manager control panel, set only the operating system’s base extensions plus the Retrospect Client control panel to load. Virus checking or file encryption utilities may cause problems. Restart the client Macintosh and try to back up again. 3. Ensure there are no unnecessary activities such as disk optimization, screen savers, or memory-intensive or processing-intensive applications running on the client during the backup. Also, verify there is not an energy saver that turns off the client computer during the backup. 4. Change the time of the script execution or rearrange the backup order of the clients. Backing up the client computer at a different time may access the computer when it is not busy. If backups work at other times, review what is happening at the original time on your network or on this client. 5. For proper TCP/IP backups of a Macintosh client, you should change a default setting in the TCP/IP control panel. Open the TCP/IP control panel and choose User Mode from the Edit menu. Select the Advanced user mode and click OK. Click the Options button, uncheck the "Load only when needed" checkbox, and click OK. Close the TCP/IP control panel and save changes. 6. There are considerable network-related improvements to be gained from using Mac OS version 8.6 or later. (See "Known Problems" below.) However, for older 68K Macs and other situations which require using an older version of the Mac OS, we recommend the following minimum configuration for both the backup Macintosh and the client computer: System 7.6.1 or later and Open Transport 1.1.2 or later. Apple made significant changes to the "Ethernet (built-in)" driver with System 7.6.1 which fixed many TCP/IP networking issues. 7. Run Disk First Aid, which checks for directory corruption. Then run the hard drive formatter’s test function. Test functions such as "Test Disk" in Apple’s Drive Setup look for bad blocks which could cause hangs or backup failures. Be sure not to run tests that will erase data. Pay attention to warnings. 8. Connect the machine to a different port on the hub. Swap ports and cables with a nearby client that is not experiencing network trouble or producing errors. 9. Try a third-party Ethernet card. This can sometimes help isolate the problem to a problematic interface. Check with the manufacturer or vendor of the client’s Ethernet card or interface and find out whether you have the most recent drivers, and whether the drivers are compatible with your system software. 10. Try new transceivers, connectors, and a network cable. 11. Disconnect all external SCSI peripherals from the client computer and try backing up the internal hard drive. SCSI problems can cause network disconnections or hangs. 12. Install a copy of the Retrospect application on a different Macintosh. Try a backup from this Mac to see if the original backup computer was causing the problem. 13. Reinstall the networking software and drivers and trash any network-related preferences. Try a clean installation of system software. 14. Try defragmenting the hard disk with Norton Utilities or some other defragmenting software. Never defragment without a good backup! 15. Try to back up through a direct connection between the host and client computer. A crossover Ethernet cable between the backup Mac and a problem client allows you to do this. On Windows-Based Computers 1. Review the "Known Problems" section at the end of this document. If that does not help, proceed with the following list of items. 2. If you are using Windows 95 and have recently installed new software on the client computer, check the Winsock version and TCP/IP configurations. The Winsock.dll, made by Microsoft not a third party, should be in your Windows directory. Windows 95 users who experience Net Retry errors and/or error 519 should install the Winsock 2.0 Update, available free from Microsoft at: http://www.microsoft.com/windows95/downloads/contents/wuadmintools/'>http://www.microsoft.com/windows95/downloads/contents/wuadmintools/ s_wunetworkingtools/w95sockets2/default.asp This is not an issue with Windows 98. 3. Verify TCP/IP settings are correct and proper for the client computer. 4. Ensure there are no unnecessary activities such as disk optimization, screen savers, or memory-intensive or processing-intensive applications running on the client during the backup. Also, verify there is not an energy saver that turns off the client computer during the backup. 5. Change the time of the script execution or rearrange the backup order of the clients. Backing up the client computer at a different time may access the computer when it is not busy. If backups work at other times, review what is happening at the original time on your network or on this client. 6. Run disk utilities such as Scandisk on the volumes associated with this client computer. 7. Verify there are current versions of the network drivers on the client computer. In addition, if it is a laptop, it may have a different boot setup (Hardware Profile) while it is docked. If it can only be backed up while docked, then it may be loading different drivers when running as a stand-alone portable. 8. Connect the machine to a different port on the hub. Swap ports and cables with a nearby client that is not experiencing network trouble or producing errors. 9. On a Windows client confirm that your Ethernet card and network hardware are certified by Microsoft and listed on the Microsoft hardware compatibility list (HCL) at: http://www.microsoft.com/isapi/hwtest/hcl.idc 10. Try another Ethernet card. This can sometimes help isolate the problem to a problematic hardware component. Make sure you have the most recent version of the Ethernet drivers, and that the drivers are compatible with your operating system. 11. Try new transceivers, connectors, and a network cable. 12. Install the latest service pack for your operating system. If you have recently installed new software, the service pack may also need to be reinstalled. 13. Reinstall networking software and drivers. Try a clean installation of the operating system. 14. Try to back up with a direct connection between the host and client computer. A crossover Ethernet cable between the backup computer and a problem client allows you to do this. For more information on troubleshooting Windows client related errors such as –1028, 541, and 519, see Technical Note 413, Retrospect Client for Windows Troubleshooting, available on the Dantz web site at http://www.dantz.com/index.php3?SCREEN=tn413 Troubleshooting The Backup Computer 1. Review the "Known Problems" section at the end of this document. If that does not help, proceed with the following list of items. 2. For proper TCP/IP backups from a backup Macintosh, you should change the default setting in the TCP/IP control panel. - Open the TCP/IP control panel and choose User Mode from the Edit menu. - Select the Advanced user mode and click OK. - Click the Options button, uncheck the "Load only when needed" checkbox, and click OK. - Close the TCP/IP control panel and save changes. 3. Ensure there are no unnecessary activities such as disk optimization, screen savers, or memory-intensive or processing -intensive applications running on the client during the backup. This includes things like mail servers, gateways, web hosting, virus checking programs, and other CPU- and resource-intensive activities. It is generally fine to run file serving software on the same computer as Retrospect but keep in mind the more you ask your server to do, the more likely you will run into problems or conflicts. 4. Connect the machine to a different port on the hub. Swap ports and cables with a nearby client that is not experiencing network trouble or producing errors. 5. Try new transceivers, connectors, and a network cable. 6. Verify you have current versions of the network drivers on the backup computer. 7. Reinstall the networking software and drivers and trash any network-related preferences. Try a clean installation of the operating system. 8. SCSI problems can affect CPU performance and cause network disconnections or hangs. Disconnect all external SCSI peripherals from the computer except the backup device and verify the SCSI bus is properly terminated. Then try backing up client computers. If the problem involves the backup drive itself, test another backup drive for comparison or, as in the next step, move the drive to another computer to see if the problems follow the backup drive. 9. Install a copy of Retrospect on a different computer. Try a backup from this computer to see if the original backup computer was causing the problem. Known Problems On Mac OS Computers 1. Networking problem with pre-G3 PCI-based Macs Technical Note #414 on our web site describes an issue with on board Ethernet on certain Mac and Mac clone models, available at: http://www.dantz.com/index.php3?SCREEN=technotes Dantz found a problem with built-in Ethernet on all non-G3 PCI-based Mac OS computers. The problem tends to occur during large data transfers on a busy network. The symptoms are error 519 followed by complete loss of all networking on affected computers. Affected computers may also crash while restarting or shutting down after the network failure. While Retrospect can trigger the problem during network backups, it is not the ultimate cause. The networking problem also occurs with the Finder and AppleShare IP during large data transfers on busy networks. Solutions One solution is to upgrade to Mac OS 8.6. The Apple Enet extension (version 2.1.2) included with Mac OS 8.6 fixes the problem. Mac OS 8.6 Update is a free update for Mac OS 8.5 customers and it is available from: http://asu.info.apple.com If you have computers which are not officially supported by Mac OS 8.6 (for example, Mac clones) or you do not have enough memory or disk space to run Mac OS 8.6, you have two choices: - Install and use third-party Ethernet cards, which do not have this networking problem. - Use Mac OS 8.1, remove its 'Ethernet (Built-In)' extension and replace it with the new 'Apple Enet' extension from Mac OS 8.6. Though this combination is not supported by Apple, our extensive testing found the Apple Enet extension (version 2.1.2) solves the problem on affected computers running Mac OS 8.1. Following is a list of computers known to be affected by this networking problem. Apple Power Macintosh 7200, 7215, 7300, 7500, 7600, 8200, 8500, 8515, 8600, 9500, 9515, 9600 Workgroup Server 7250, 7350, 8550, 9650 DayStar Genesis MP, Millennium Power Computing PowerCenter, PowerCenter Pro, PowerCurve, PowerTower, PowerTower Pro, PowerWave UMAX/SuperMac J700, S900, S910 2. Power Macintosh 7200/90 Although this model falls into the category of "pre-G3 PCI-Based Macs," there are some 7200/90 logic boards which may cause additional Ethernet problems, which can cause error 519. The 7200/90 owner should contact his or her Apple support provider with the machine’s serial number. The problem has been isolated to the 7200/90 system logic board, and is limited to 7200/90 computers with a serial number lower than "XX544XXXXXXX." 3. Asante Print 8, Asante Microprint, and Dayna Miniprint Asante Print 8, Asante Microprint, and Dayna Miniprint may cause numerous communication problems with clients, servers, and shared volumes because the devices do not support ADSP. Such devices should be used only with printers, and not as general networking devices. 4. PowerBook 3400s lose network communications during TCP/IP backup In the middle of a TCP/IP backup, a PowerBook 3400 may stop communicating on the network. Retrospect reports error 519 and the PowerBook’s networking ability fails completely, losing all TCP/IP and AppleTalk functionality. Apple has provided a fix at: ftp://ftp.apple.com/Apple.Support.Area/Apple.Software.Updates/US/Macintosh/ Unsupported/PB_3400_Modem_Driver_Update.img.hqx 5. Macintosh TCP/IP clients don’t renew DHCP leases while waiting for shutdown When a Mac OS TCP/IP client has a DHCP-supplied IP address and its lease expires while the client is waiting for shutdown, the Mac does not renew its IP lease and continues using its old IP address. This can lead to a conflict when the DHCP server, thinking the IP address is now available, leases the IP address to a different computer. The workaround is to leave DHCP-served Mac OS computers idle in the Finder instead of in the Retrospect Client "waiting for backup..." mode and uncheck "Load only when needed" in the TCP/IP control panel. This problem does not affect Windows clients. On Windows Computers 1. A bug in Windows 95 causes network backups to fail if less than 1 MB of data is copied This bug can happen when using Windows 95, Service Pack 1, and Windows 95 OSR2. The Winsock 2.0 installer program fixes the issue by updating Vnbt.386 to version 4.10.1658; 87,765 bytes. The Winsock 2.0 Update is available free from Microsoft at: http://www.microsoft.com/windows95/downloads/contents/wuadmintools/ s_wunetworkingtools/w95sockets2/default.asp Whenever a Windows 95 client experiences 519 errors, it is a good idea to update to Winsock 2.0. Winsock 2.0 fixes more than one issue. These issues are fixed in Windows 98 and NT. ©1999 Dantz Development Corporation. Although reasonable care has been taken to ensure its accuracy, this information is supplied without warranty. Link to comment Share on other sites More sharing options...
Thomasj Posted August 5, 2002 Report Share Posted August 5, 2002 Hi, we had the same problem after changing our network speed to 100 Mbit and some new switches. After changing all ports on the switch to auto speed it works fine. thomas Link to comment Share on other sites More sharing options...
Lorraine Posted August 11, 2002 Report Share Posted August 11, 2002 I had a similar problem that occurred seemingly out of nowhere, from one day to the next. All the backups were fine, then on one floor all the Macs started generating error 519s. The building is 100Base-T. I ruled out issues with the Retrospect server and the workstations, even moving one of the Macs to another floor and the problem went away for that one. I discovered by accident when one of the Macs was placed on a 10Base-T minihub to share its port with another workstation, that the error 519s went away for that Mac. Management decided it didn't want the network admins to spend any more time trying to troubleshoot the problem (they must have changed something, and may have been daunted by the troubleshooting article I brought to their attention, which was posted into this thread above) so it was decided that all the Macs on that floor would be slowed-down to 10Base-T by installing minihubs at the workstations. This worked-around the problem so they could forget about it. Of course the Mac users weren't happy about this, but since I'm only desktop support there was nothing I could do myself to help them. . .except install more minihubs. Link to comment Share on other sites More sharing options...
Guest Posted August 12, 2002 Report Share Posted August 12, 2002 Michele- This happens more often than it should. Here's the three main culprits I've found: 1. Cisco or similar managed switches. Various features on these babies can wreak all kinds of havoc. See Cisco's and Apple's site for more information on these various issues. 2. The server: one of the only common elements in the whole equation here is your server. If there's anything at all wrong with its network interface, that'll produce exactly the results you're seeing. 3. (Most Common) IP subnetting problems, particularly when you have multiple class C IP subnets and are trying to backup across them. To find out if what you have is an IP problem, change your Mac clients to use Appletalk. If suddenly everything works fine, you can start working on the IP issue. Try getting the server and clients on the same subnet, if they're not already. Best, CML Link to comment Share on other sites More sharing options...
jcmccain Posted May 7, 2003 Report Share Posted May 7, 2003 I've run into this same problem after our company upgraded to 100baseT hubs. I'm using Retrospect for Windows version 5. Has anyone using a new version had this problem? Jesse Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.