Sounds like more of a networking issue. You might consider some subnet routing of the traffic, so you don't blast it everywhere on your local subnet.
something like route add net 172.4.0.0/16 10.23.21.2 1 Where you are trying to get traffic for the 172.4.x.x subnet routed through a router/machine 10.23.21.2 ... LOL ... JC -----Original Message----- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED] Sent: Friday, June 11, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: Re: Possibly OT: How to diagnose 3494 ATL "communications" failures Well, after further analysis, this topic has had some strange twists. Per some suggestions, I had IBM replace the NIC in the LM. This had absolutely no effect on the problem. I have been discussing this issue with our networking folks. Their initial review showed massive amounts of BROADCAST traffic on this subnet, which is a private, GIG-E internal network, with connections to the outside world, primarily for TSM backups traffic. I updated ATAPE, which was a bit behind. I could not see anything in the history of changes, that would address this kind of situation. Now, my networking folks have put a sniffer on this private subnet. Image my suprise when the biggest causer of broadcast traffic, is the TSM AIX server, itself !!!!! They also said that the peak in broadcast traffic correlated to backup traffic from a box that is outside the private subnet (i.e. does not have a direct connection to the same switch). Anyone have any suggestions on why the TSM server would be doing this ? This is an AIX 5.1 TSM 5.2.1.3 system, that is *EXCLUSIVELY* used for TSM backups. Could this have anything to do with the HLADDRESS parms on the node definitions ? Possibly a bug that has been fixed in a later release of the TSM server ? *NOTHING* has changed on the AIX system for the past 6-months, when it comes to the AIX and TSM server software, itself ! The last upgrade was from AIX 4.3.3 to 5.1 and the TSM server, at the same time. Richard Sims <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 05/24/2004 07:41 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject Re: Possibly OT: How to diagnose 3494 ATL "communications" failur es >This hardware/system has been in place for years, without change. > >My bets are on a problem with the LM itself. > >This weekend, the connection died, again. No non-distruptive attempts to >restablish the connection with the LM, worked. Yes, both boxes could PING >each other. As I told IBM, this is *NOT* a connectivity issue, in the >lan/network sense. This is a "the LM is not responding as an LM". > >The only way we got it to work was to reinitialize the LAN ports from the >LM/ATL. Well, there has been change: it's gotten older! (I've become an expert on the subject.) You could be seeing the effects of a deteriorating network card or the like...which could be aggravated if the library is not on UPS or power that is otherwise conditioned. Watch out also if the library is not behind a firewall. I worry about these "embedded system" computers in that they rarely see any updates, and yet we know that "holes" in operating systems are periodically found. In the right network circumstances, odd behavior from such a system may be the result of someone trying to hack the box. me again, Richard Sims
