Re: Re: Re: Re: File Comparison

[sunadmn]

ok I will give you a sample of the files, what these files are , are logs from the output of the namedxfer daemon within bind 9.2.2. What I am seeing is that I am have a large lack of transfers to a single server in Atl, GA and I can not get my network Nazi's here at work to do anymore digging as they say their switch is fine. What I want to do is take the log and split it into three files one for each "Master Server" so ns1, ns2, and ns3.mycompany.com from these three files I want to compare the three to find out when and where I have degridation on my network so I can go back to the NetEng group with hard evidence that there is a network issue.
Here is a small exert from a parsed file for a single server.
Aug 06 15:00:36.747 xfer-out: info: client 68.168.192.17#50840: transfer of '112.23.67.in-addr.arpa/IN': AXFR started
Aug 06 16:00:36.326 xfer-out: info: client 68.168.192.17#50963: transfer of '129.23.67.in-addr.arpa/IN': AXFR started
Aug 06 16:00:36.829 xfer-out: info: client 68.168.192.17#50964: transfer of '131.23.67.in-addr.arpa/IN': AXFR started
Aug 06 16:00:36.840 xfer-out: info: client 68.168.192.17#50965: transfer of '130.23.67.in-addr.arpa/IN': AXFR started
Aug 06 16:00:37.327 xfer-out: info: client 68.168.192.17#50966: transfer of '128.23.67.in-addr.arpa/IN': AXFR started
Aug 06 16:06:09.468 xfer-out: info: client 68.168.192.17#50978: transfer of '78.168.68.in-addr.arpa/IN': AXFR-style IXFR started
Aug 06 16:12:06.719 xfer-out: info: client 68.168.192.17#50989: transfer of 'colememorial.com/IN': AXFR-style IXFR started
Aug 06 16:15:44.581 xfer-out: info: client 68.168.192.17#50999: transfer of 'charlescolehospital.com/IN': AXFR-style IXFR started
Aug 06 16:20:25.301 xfer-out: info: client 68.168.192.17#51010: transfer of 'coudersporthospital.com/IN': AXFR-style IXFR started

[waswas-fng]

Given that data set I do not see how you are going to make a case for a network issue. The most I could see that data set implying is that there may be a differance in the number of IXFR/AXFR started on two different servers -- where that difference comes from is not stated by that data. Could one of the servers be overloaded and not accepting or initiating transfers? could the named be compiled differently on one of the servers or the config file be different? could the kernel on the server be a different revision/patch level/compile options different? It may be a better option to look at network data instead of application data to pinpoint network issues.. IMHO.

-Waswas

[Anonymous Monk]

I have had my sun onsite guys look at the box and they can find nothing wrong and the servers are the same from head to toe including all applications. these were all installed from a Flash archive ( jump start ) and the Bind install is a package I built and installed on all servers. I have some network data ( MRTG reports from the switch ) , but they are not really showing me much only that I have some spikes during the day where a large amount of traffic is forced. With that said I think I will have to prove to them that there is an issue, but they always push the blame onto my shoulders. Real pain if you ask me, but it's a job LOL.

[waswas-fng]

You may want to force bind into full debug mode (the logs get big very quickly so have them on a large disk slice) and also run SAR to log system performance paramiters to show that the system is not being taxed. Solaris also comes with snoop which will let you dump packets so you can see retries and other network issues (and have proof) although I would sugest geting ethereal which can take tcpdump output or live snoops and parse out many protocols and to session level breakdown. You may get it at http://www.ethereal.com/ or there is a Solaris packaged version at www.sunfreeware.com. In any case I expect you really need better proof than the "well they dont start transfers as much as server X,Y,Z do see look at the logs" to prove network issues. Make the local sun guys work and prove to you that it is a network issue, as far as your posts have stated they have yet to...

-Waswas