http://blog.gmane.org/gmane.network.argus hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.network.argus/8467 <pre>Hello, I see the man page for ra, but it seems lacking for some DSR value output. For instance, there are somethings that aren't implicit, but appear like they should/were intended to be. Specifically, I see this with 'dir's possible values. The cases if confusion are &lt;? And ?&gt;. How can argus "not" know the direction of the transaction "sort of?" Thanks, Matt </pre> Matt Brown 2012-05-25T01:00:08 http://comments.gmane.org/gmane.network.argus/8464 <pre>Gentle people, We are now in a period where I'm fixing gotcha's after the official release of argus-3.0.6. We now have two sets of fixes, a set of memory leaks and, now, a set of fixes for cygwin. This looks to be the only issues right now. The next round of released code will be argus-clients-3.0.6.1, and because these are show stopper problems, I'll officially release this next version soon. Until I hear from the list, my strategy for testing is to put up a single patch file that represents the 3.0.6 to 3.0.6.1 upgrade, patch-argus-clients-3-0-6-1.diff, and to provide an accompanying argus-clients-3.0.6.1.tar.gz file. These are only on the developers side of the site. When all is well and good, I'll move these two files to the stable side of the server. As a result, I've uploaded patch-argus-clients-3-0-6-1-diff to the developers site, and a new argus-clients-3.0.6.1.tar.gz. The patch file should be applied to the original argus-clients-3.0.6 distribution. But, you can apply it to a previously patch distribution, if that is your preference. Just type carriage return in response to patch's complaints about a previously patched chunk. Again I will release these final tarfiles and patches tomorrow being Thur if no other issues come up. http://qosient.com/argus/dev/argus-clients-3.0.6.1.tar.gz http://qosient.com/argus/dev/patch-argus-clients-3-0-6-1-diff Please send any comments / opinions / complaints / whatever to either me or the list !!!! Hope all is most excellent !!!!!! Carter </pre> Carter Bullard 2012-05-09T17:05:44 http://comments.gmane.org/gmane.network.argus/8462 <pre>When I use this filter on the command line it works as expected but when applied in the -F argus.conf I get all sorts of stuff that I does not match the filter? argus-3.0.6. Makes no difference if I put the filter on the FILTER = or the ARGUS_OUTPUT_FILE. ARGUS_OUTPUT_FILE=/home/sensors/data/wireless/argus/user-data "tcp and src net ( 172.23.0.0/16 or 172.24.0.0/18 ) and not dst net ( 172.23.0.0/16 or 172.24.0.0/18 ) and dst port 80" see attached file... I've used this before often so I am very puzzled - on another sensor I have an identical config but with a ( 130.216.0.0/16 ) rather than the 172 addresses. Clearly I'm doing something stupid, but what? Any ideas? Russell PS: sample of captured flows with -F argus-user-data.conf (attached) 12:12:31.589938 e tcp 207.46.61.90.80 ?&gt; 130.216.181.194.57572 1 60 RST 12:12:31.766180 e tcp 74.125.237.102.443 ?&gt; 130.216.215.70.1629 1 60 RST 12:12:31.810594 e tcp 203.97.30.168.80 ?&gt; 130.216.211.104.64352 1 60 RST 12:12:32.025105 e tcp 67.195.186.237.80 ?&gt; 130.216.180.70.63388 1 60 RST 12:12:32.055496 e tcp 108.166.124.101.8081 ?&gt; 130.216.185.49.49962 1 60 RST 12:12:32.284281 e tcp 203.167.141.160.80 ?&gt; 130.216.45.214.50546 1 60 RST 12:12:32.128061 e tcp 203.167.141.160.80 ?&gt; 130.216.235.214.3909 1 60 RST 12:12:32.313530 e tcp 74.125.237.103.443 ?&gt; 130.216.215.70.1630 2 120 RST 12:12:32.407612 e tcp 157.56.52.37.443 ?&gt; 130.216.138.119.55450 1 60 RST 12:12:32.419595 e tcp 203.97.30.166.443 ?&gt; 130.216.138.180.56112 2 120 RST 12:12:33.058135 e tcp 203.167.141.160.80 ?&gt; 130.216.64.209.49393 1 60 RST 12:12:33.125684 e tcp 193.1.122.17.80 ?&gt; 130.216.109.13.1509 1 60 RST 12:12:33.216804 e tcp 96.7.131.235.80 ?&gt; 130.216.73.113.62942 1 60 RST 12:12:32.840228 e tcp 203.97.30.172.80 ?&gt; 130.216.211.104.64353 1 60 RST sample from sudo /usr/sbin/argus -w data/wireless/argus/user-data -i eth1 - tcp and src net \( 172.23.0.0/16 or 172.24.0.0/18 \) and not dst net \( 172.23.0.0/16 or 172.24.0.0/18 \) and dst port 80 12:30:11.657737 e tcp 172.23.210.58.52203 ?&gt; 205.251.203.89.80 16 1056 CON 12:30:11.657816 e tcp 172.23.200.226.50630 ?&gt; 208.117.254.157.80 43 4484 CON 12:30:11.658591 e tcp 172.23.63.238.62230 ?&gt; 119.31.253.194.80 6 396 CON 12:30:11.658597 e tcp 172.23.189.245.63528 ?&gt; 203.167.141.154.80 4 288 CON 12:30:11.658740 e tcp 172.23.51.133.56828 ?&gt; 91.121.5.64.80 72 5732 CON 12:30:11.659003 e tcp 172.23.191.23.49648 ?&gt; 208.43.117.186.80 105 151586 CON 12:30:11.659135 e tcp 172.23.97.109.54534 ?&gt; 183.60.157.73.80 36 2410 CON 12:30:11.659852 e tcp 172.24.12.211.52737 ?&gt; 205.196.120.161.80 50 3054 CON 12:30:11.659857 e tcp 172.24.12.211.52681 ?&gt; 205.196.122.242.80 51 3060 CON 12:30:11.659868 e tcp 172.24.12.211.52750 ?&gt; 199.91.152.194.80 43 2670 CON 12:30:11.659870 e tcp 172.24.12.211.52761 ?&gt; 199.91.152.194.80 38 2316 CON 12:30:11.660339 e tcp 172.23.151.151.38450 ?&gt; 188.132.173.12.80 22 1452 FIN </pre> Russell Fulton 2012-05-09T00:47:05 http://comments.gmane.org/gmane.network.argus/8461 <pre>Gentle people, I have uploaded a new patch-all-memory-leak-clients-3-0-6.diff to the developers site, which adds a memory leak fix for radium, when it is configured to generate geo labels for flows its processing. This fixes all known memory leak issues in argus-clients-3.0.6. I've updated a new argus-clients-3.0.6.1.tar.gz with these new memory leak fixes. If you could give these a try on your systems, that would be great. I will release these final tarfiles and patches tomorrow or Thur. http://qosient.com/argus/dev/argus-clients-3.0.6.1.tar.gz http://qosient.com/argus/dev/patch-all-memory-leak-clients-3-0-6.diff Apply the patch by being in the parent directory that contains argus-clients-3.0.6, and then: % patch -p0 &lt; patch-memory-leak-clients-3-0-6.diff For those that have a patch that is sensitive to RCS, SCCS, Perforce, whatever, try: % patch -g0 -p0 &lt; patch-memory-leak-clients-3-0-6.diff The you will just need to make, as there are no configure.ac changes. % cd argus-clients-3.0.6; make The patch will upgrade argus-clients-3.0.6 to argus-clients-3.0.6.1. If you had already patch your files, you should still be able to use the new patch file to add the changes. It may complain a bit about already having the patch, but that would be fine. Carter </pre> Carter Bullard 2012-05-08T22:11:41 http://comments.gmane.org/gmane.network.argus/8460 <pre>Gentle people, I have uploaded argus-clients-3.0.6.1 to the developers site, and I have uploaded a patch, for those that like patches, that fixes the reported problems with rabins and rastream. The fixes addresses the "-f racluster.conf" issues with rabins.1, as well as the memory leak problems with long term use of rabins and rastream, which occur primarily with ARGUS_EVENT records. Apply the patch by being in the parent directory that contains argus-clients-3.0.6, and then: % patch -p0 &lt; patch-memory-leak-clients-3-0-6.diff For those that have a patch that is sensitive to RCS, SCCS, Perforce, whatever, try: % patch -g0 -p0 &lt; patch-memory-leak-clients-3-0-6.diff The you will just need to make, as there are no configure.ac changes. % cd argus-clients-3.0.6; make The patch will upgrade argus-clients-3.0.6 to argus-clients-3.0.6.1. If you use rastream.1, you will want to upgrade to argus-3.0.6.1. For those that want to use rabins.1 with the "-f racluster.conf", you will also need to upgrade. Please take a look at these, and if you have any issues, please holler !!!! I'll be "releasing" argus-clients-3.0.6.1 after the patch has gone through some testing, possibly at the end of the week. http://qosient.com/argus/dev/argus-clients-3.0.6.1.tar.gz If you encounter any problems, don't hesitate to email to the list !!!! Hope all is most excellent !!!!! Carter Carter Bullard CEO/President QoSient, LLC 150 E. 57th Street Suite 12D New York, New York 10022 +1 212 588-9133 Phone +1 212 588-9134 Fax </pre> Carter Bullard 2012-05-07T16:45:31 http://comments.gmane.org/gmane.network.argus/8459 <pre>Gentle people, We've got a memory leak in the newest versions of rabins.1 and rastream.1. I'm working on them now, but I have confirmed that long lived rastream processes do collection the memory. If you are using rastream.1, please consider testing the patches when I make them available. Should have a fix for you later tomorrow, which I will send to the list. Hope all is most excellent, Carter</pre> Carter Bullard 2012-05-02T22:57:16 http://comments.gmane.org/gmane.network.argus/8450 <pre>Hi, Is rabins supposed to be able to work with a racluster.conf file? The man page doesn't specifically say that it does, nor does rabins give "-f" as a usage option when you ask for --help. However: - the man page does say that rabins incorporates functions of racluster, - experimentation shows that rabins does do *something* with an racluster.conf style file when '-f xx.conf' is used. It's just that the something that it does with it doesn't really match what I'd think it should do. - I do see some code in rabins referencing the flow model file, but I haven't tried to follow it very far. If the answer is "yes" then I may have followup questions and examples, probably produced by operator error. If "no," then never mind. :-) Yours, -mm- BTW, the racluster.conf (racluster(5)) man page has some holes in it; there are some paragraphs that just end mid- </pre> Mark E. Mallett 2012-04-23T18:46:52 http://comments.gmane.org/gmane.network.argus/8449 <pre>Gentle people, We've released argus-3.0.6 and its clients. There were slight modifications to the previous tarfiles that were uploaded in the last few days. One significant change regarding aggregation was inserted, making field preservation the default, and minor tweaking to man pages. While argus-3.0.6 is predominately a bug fix release, there are hundreds of improvements, so please do consider upgrading. Please give a round of applause to all involved in making this one of the best efforts to improve argus. Of course if you discover any issues, please send email to the list !!! Now on to argus-3.0.7.1. Hope all is most excellent, Carter </pre> Carter Bullard 2012-04-18T18:49:30 http://comments.gmane.org/gmane.network.argus/8446 <pre>hi Carter, You mentioned that you have fixed bugs in the rasqlinsert, as I'm using it extensively I would like to know if it is serious bugs otherwise I don't plan to update. </pre> CS Lee 2012-04-17T23:33:27 http://comments.gmane.org/gmane.network.argus/8445 <pre>hi David, If you are not going to extract data from suser and duser field, basically it is quite straightforward to get argus data into splunk, most of people only have problem with user data because it may contains anything like ,| and so forth. Cheers! </pre> CS Lee 2012-04-17T23:31:44 http://comments.gmane.org/gmane.network.argus/8442 <pre>Gentle people, We found a bug in rasqlinsert.1, that I have fixed in the release, so if you've been testing rasqlinsert and have been having problems, grab the current argus-clients-latest.tar.gz to see if it clears it up. This has been tested pretty well, so we're going to include the mods in the release, which should happen today. Hope all is most excellent, Carter </pre> Carter Bullard 2012-04-17T15:56:33 http://comments.gmane.org/gmane.network.argus/8440 <pre>Hi, I have started looking at feeding argus data into Splunk. I know that others have done this and have seen a few examples. It seems that CSV is one way to go, but that requires teaching Splunk about the column names (yes, there are workarounds). Would it be possible for another output mode, in key/value pair format? Something like the following: StartTime=01:23:45.000000|Flgs=g|Proto=tcp|SrcAddr=1.2.3.4 ... This is quite verbose, but is slightly more complete than CSV and feeds into other tools (especially Splunk) very well. As long as none of the fields contain an equals or pipe this shouldn't be a hard change to make. Is it worth writing a simple patch for? David </pre> David 2012-04-17T15:50:16 http://comments.gmane.org/gmane.network.argus/8438 <pre>I have a ra config file that looks like this: RA_TIME_FORMAT="%d %b %y %T" RA_FIELD_WIDTH=fixed RA_FIELD_SPECIFIER="stime,flgs,proto,saddr,sport,dir,daddr,dport,spkts,dpkts,sbytes,dbytes,state" In argus-clients 3.0.6 (and in 3.0.5.37) the output produced by running racluster with this ra config file looks like this: 15 Apr 12 2* N tcp xxx.xxx.131.135.5140 -&gt; xxx.xxx.59.174.46859 3 0 132 0 INT The only other version of argus-clients I have on the system is 3.0.5.23, and it does not have this problem. If I comment out the RA_FIELD_WIDTH=fixed, the date/time in the output is displayed correctly: 15 Apr 12 23:59:59 N tcp xxx.xxx.131.135.5140 -&gt; xxx.xxx.59.174.46859 3 0 132 0 INT Commenting out the RA_TIME_FORMAT fixes it, but I don't want the default time format: 23:59:59.379756 N tcp xxx.xxx.131.135.5140 -&gt; xxx.xxx.59.174.46859 3 0 132 0 INT Is this a bug or something that changed in the newer 3.0.5 releases and propagated into 3.0.6? </pre> Mike Iglesias 2012-04-16T23:23:00 http://comments.gmane.org/gmane.network.argus/8437 <pre>Gentle people, I've moved the unofficial, official argus-3.0.6 tarfiles up to the dev server. http://qosient.com/argus/dev/argus-3.0.6.tar.gz http://qosient.com/argus/dev/argus-clients-3.0.6.tar.gz These will be officially released Mon/Tue of next week, if no show stoppers are found. I believe the SUSE folks should be very happy, if not, we'll make a few changes, but the intent is for these files to be the official release of argus-3.0.6. The changes from 3.0.6.rc[1-2] are that these have all the changes for licensing, man page mods, and a bug fix. argus, itself, had a seg fault issue when poor parameters were passed for the "-e" option. I modified the man page just a bit to reflect the changes in commandline -e use (need to escape the double quotes when setting source id to a string). Thanks for all the help, and we're very close !!!! Have a great weekend, Carter </pre> Carter Bullard 2012-04-13T20:31:39 http://comments.gmane.org/gmane.network.argus/8429 <pre>Gentle people, Rc2 versions of argus[-clients]-3.0.6 are now on the dev server. The changes, as mentioned before, are limited to man page modifications and the use of stdout when using the "-h" option, rather than stderr. http://qosient.com/argus/dev/argus-latest-tar.gz http://qosient.com/argus/dev/argus-clients-latest-tar.gz This will be the last release candidates for 3.0.6 before release. Any show stopper problems will be fixed, but rc2 code is now frozen. Please review this as the official release tar packages. We should release Friday, if all is well. Thanks for all the help !!!! Carter</pre> Carter Bullard 2012-04-10T12:42:35 http://comments.gmane.org/gmane.network.argus/8427 <pre>hello, according to information on the Argus homepage, the software is distributed under GPLv3. However, during legal review, we found several source files with license headers that contradict this. For example, from argus-3.0.4/argus/ArgusLcp.c : * THE ACCOMPANYING PROGRAM IS PROPRIETARY SOFTWARE OF QoSIENT, LLC, * AND CANNOT BE USED, DISTRIBUTED, COPIED OR MODIFIED WITHOUT * EXPRESS PERMISSION OF QoSIENT, LLC. and on argus-clients side, argus-clients-3.0.4.1/include/argus/cons_out.h : * Permission to use, copy, modify, and distribute this software and * its documentation is restricted to personal use only. Use, sale * or retransmission of this software for commercial purposes, * including but not limited to use as a commerical product or * in support of a commercial endeavor requires licensing from Carter * Bullard. There are other problematic files with similar license headers: argus-3.0.4/bin/argusbug argus-clients-3.0.4.1/clients/raconvert.h This unfortunately means that we cannot include Argus in the SUSE distribution. [1] I presume that those license headers are an oversight, because both the website and COPYING files clearly state that the software is under GPLv3. Could you please have a look at this and remove the license headers, or clarify the licensing conditions? thanks Jan p.s.: Also, as noted in [1], several files contain a GPL-incompatible BSD 4-clause license header. [1] https://bugzilla.novell.com/show_bug.cgi?id=739260 </pre> Jan Matějek 2012-04-06T17:08:03 http://comments.gmane.org/gmane.network.argus/8426 <pre>Gentle people, We've made a lot of changes to the rc1 versions, based on input from the CMU associated groups, and from a number of individuals. Most changes are limited to the man pages, or to simple things, like using stout for "-h" output, and consistent printing of mar records. The new man pages are now on the web site. You can get there from the Argus main page, ' Documentation ' -&gt; 'manuals'. These pdf's are the actual man pages from the new distributions. Please take a look at these, if you are seeing problems with man pages. Thanks, and I'm looking for a release date of Friday, next week. Hope all is most excellent, Carter</pre> Carter Bullard 2012-04-05T16:56:03 http://comments.gmane.org/gmane.network.argus/8425 <pre>Gentle people, We finally fixed the last gottcha bug in argus-3.0.5.x, and I've uploaded the release candidates for argus-3.0.6. The web site has been updated with all new content, examples, sample data, new man pages,, etc……. So, please consider these new tarballs as the release candidates. If you could give them a test run, sanity check, and the like, that would be most excellent. I'd like to release next week, if possible, assuming not too much needs to be done to get the candidates releasable. http://qosient.com/argus/dev/argus-3.0.6.rc1.tar.gz http://qosient.com/argus/dev/argus-clients-3.0.6.rc1.tar.gz Thanks for all the massive help. Very glad that we're to this point. We'll start argus-3.0.7.1 developers versions, almost immediately after the release. If you would like to start thinking about what we should be adding, like netflowV9, complete sflow support, TLS replacement for SASL, and more analytics, all are welcome suggestions. Hope all is most excellent, Carter </pre> Carter Bullard 2012-04-04T04:08:45 http://comments.gmane.org/gmane.network.argus/8423 <pre>Hello all, I am having issues with the '-e' option in ARGUS. I run the following command: argus -e 200 -w /tmp/testfile and I get this in the ra output: 0.0.0.100,2012-04-02,14:52:15,2012-04-02,14:52:15,0.000000,192.168.198.137,192.168.198.1,6,22,53215,212,106,106,2,1,1,&lt;?&gt;,1,11, e As you can see the Argus Identifier is coming out as an IP address: 0.0.0.100 not 100 which I would like. I think something changed from the older versions. In my python script I run the following command and pass some variables to the command: arguscommand = "/usr/local/sbin/argus -e "+capID+" -F "+SCRIPTS+"/argus.conf -r "+cleancapturefile+" -w "+argusoutfile+" - ip" Prior to updating to the 3.0.4 version the command above would save the identifier to the record. Anyone else seeing a change in the format?? Or am I doing something wrong? mab </pre> Mark Bartlett 2012-04-02T18:59:18 http://comments.gmane.org/gmane.network.argus/8417 <pre>On the same machine and my sasl issues argus dies after a few hour running sometimes a few minutes: Mar 29 16:03:04 mon263595 argus[32019]: 29 Mar 12 16:03:04.949222 started Mar 29 16:03:04 mon263595 argus[32019]: 29 Mar 12 16:03:04.967252 ArgusGetInterfaceStatus: interface eth3 is up Mar 29 16:34:21 mon263595 kernel: argus[32019]: segfault at 0000000000000060 rip 0000000000434b14 rsp 00007ffff4dde2c0 error 4 [rful011&lt; at &gt;mon263595 ~]$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) Argus Version 3.0.2 </pre> Russell Fulton 2012-03-29T18:05:37 http://comments.gmane.org/gmane.network.argus/8415 <pre>Gentle people, In anticipation of Anonymous crushing the internet, I've been sniffing around my archives looking for evidence of Anonymous practice runs, and did see a significant DNS perturbation on March 8th here in NYC. Did anyone capture a curious DNS outage at your site around 2012/03/08.22:35:00 - 2012/03/08.23:45:00 EST? I experienced a number of North American DNS servers "going away", where they just stopped responding, but no other traffic seems to have been affected. Need some additional verification before I will move past the hypothesis stage. Would be interesting to know if anyone else saw a sudden loss of responsiveness from exterior DNS servers in this time period. I noticed that google.com was hammered pretty good, so focusing on google.com DNS resolution maybe informational. If you are capturing user data, so that you can grep for specific DNS queries, try this query (all times here are EST5EDT4): ra -t 2012/03/08.22:35-2012/03/08.23:45 -R 2012/03/08 -e google.com - udp and port domain If you were affected, you would see a significant number of DNS queries that had no responses (dst pkts eq 0). A more scientific report can be generated using rahisto.1. You can calculate the frequency distribution of transaction times for all DNS going to google.com's CIDR block: rahisto -H dur 20:0-0.1 -r 03/08 03/09 - udp and port domain and net 216.239.0.0/18 Here are my results for the entire day of 03/07: rahisto -H dur 20:0-0.1 -r 2012/03/07 - udp and port domain and net 216.239.0.0/18 N = 492 mean = 0.029719 stddev = 0.014173 max = 0.096320 min = 0.000000 median = 0.028108 95% = 0.053595 mode = 0.000000 Class Interval Freq Rel.Freq Cum.Freq 1 0.000000e+00 7 1.4228% 1.4228% 2 5.000000e-03 0 0.0000% 1.4228% 3 1.000000e-02 71 14.4309% 15.8537% 4 1.500000e-02 76 15.4472% 31.3008% 5 2.000000e-02 21 4.2683% 35.5691% 6 2.500000e-02 87 17.6829% 53.2520% 7 3.000000e-02 117 23.7805% 77.0325% 8 3.500000e-02 18 3.6585% 80.6911% 9 4.000000e-02 5 1.0163% 81.7073% 10 4.500000e-02 0 0.0000% 81.7073% 11 5.000000e-02 74 15.0407% 96.7480% 12 5.500000e-02 8 1.6260% 98.3740% 13 6.000000e-02 2 0.4065% 98.7805% 14 6.500000e-02 2 0.4065% 99.1870% 15 7.000000e-02 2 0.4065% 99.5935% 16 7.500000e-02 1 0.2033% 99.7967% 17 8.000000e-02 0 0.0000% 99.7967% 18 8.500000e-02 0 0.0000% 99.7967% 19 9.000000e-02 0 0.0000% 99.7967% 20 9.500000e-02 1 0.2033% 100.0000% Here are my results for the entire day of 03/08: rahisto -H dur 20:0-0.1 -R 2012/03/08 - udp and port domain and net 216.239.0.0/18 N = 1046 mean = 0.021668 stddev = 0.019670 max = 0.092698 min = 0.000000 median = 0.018990 95% = 0.053714 mode = 0.000000 Class Interval Freq Rel.Freq Cum.Freq 1 0.000000e+00 355 33.9388% 33.9388% 2 5.000000e-03 0 0.0000% 33.9388% 3 1.000000e-02 68 6.5010% 40.4398% 4 1.500000e-02 103 9.8470% 50.2868% 5 2.000000e-02 23 2.1989% 52.4857% 6 2.500000e-02 104 9.9426% 62.4283% 7 3.000000e-02 199 19.0249% 81.4532% 8 3.500000e-02 22 2.1033% 83.5564% 9 4.000000e-02 7 0.6692% 84.2256% 10 4.500000e-02 9 0.8604% 85.0860% 11 5.000000e-02 123 11.7591% 96.8451% 12 5.500000e-02 10 0.9560% 97.8011% 13 6.000000e-02 7 0.6692% 98.4704% 14 6.500000e-02 2 0.1912% 98.6616% 15 7.000000e-02 3 0.2868% 98.9484% 16 7.500000e-02 4 0.3824% 99.3308% 17 8.000000e-02 5 0.4780% 99.8088% 18 8.500000e-02 0 0.0000% 99.8088% 19 9.000000e-02 2 0.1912% 100.0000% 20 9.500000e-02 0 0.0000% 100.0000% From a daily report, you see on the 8th a shift of 1.4% failed transactions to 33.9%. The incident lasted about an hour, and here is my rahisto.1 run during the event. 99.7% failure. rahisto -H dur 20:0-0.1 -r 2012/03/08 -t 2012/03/08.22:35-2012/03/08.23:45 - \ udp and port domain and net 216.239.0.0/18 N = 335 mean = 0.000245 stddev = 0.004471 max = 0.081955 min = 0.000000 median = 0.000000 95% = 0.000000 mode = 0.000000 Class Interval Freq Rel.Freq Cum.Freq 1 0.000000e+00 334 99.7015% 99.7015% 2 5.000000e-03 0 0.0000% 99.7015% 3 1.000000e-02 0 0.0000% 99.7015% 4 1.500000e-02 0 0.0000% 99.7015% 5 2.000000e-02 0 0.0000% 99.7015% 6 2.500000e-02 0 0.0000% 99.7015% 7 3.000000e-02 0 0.0000% 99.7015% 8 3.500000e-02 0 0.0000% 99.7015% 9 4.000000e-02 0 0.0000% 99.7015% 10 4.500000e-02 0 0.0000% 99.7015% 11 5.000000e-02 0 0.0000% 99.7015% 12 5.500000e-02 0 0.0000% 99.7015% 13 6.000000e-02 0 0.0000% 99.7015% 14 6.500000e-02 0 0.0000% 99.7015% 15 7.000000e-02 0 0.0000% 99.7015% 16 7.500000e-02 0 0.0000% 99.7015% 17 8.000000e-02 1 0.2985% 100.0000% 18 8.500000e-02 0 0.0000% 100.0000% 19 9.000000e-02 0 0.0000% 100.0000% 20 9.500000e-02 0 0.0000% 100.0000% What I saw was most of my external DNS servers went away for about an hour. Most everything else worked fine, such as existing long lived flows, were unaffected. But web pages that were dependent on DNS resolution to complete were stalled. Hope all is most excellent, Carter </pre> Carter Bullard 2012-03-28T13:47:22 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.argus