From everton@lab.ipaccess.diveo.net.br Mon Nov 3 11:23:22 2003
From: everton@lab.ipaccess.diveo.net.br (Everton da Silva Marques)
Date: Mon, 3 Nov 2003 09:23:22 -0200
Subject: [flow-tools] flow-capture: option to preserve inherited umask
Message-ID: <20031103112322.GA23122@netflow.ipaccess.diveo.net.br>
--ibTvN161/egqYuK8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
I need to run flow-capture in daemon mode but
preserving the inherited umask.
The attached patch adds the -u switch to
flow-capture, in order to preserve the
inherited umask.
Thanks,
Everton
--ibTvN161/egqYuK8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="flow-capture-preserve-umask.diff"
diff -u -r flow-tools-0.66-orig/docs/flow-capture.1.in flow-tools-0.66/docs/flow-capture.1.in
--- flow-tools-0.66-orig/docs/flow-capture.1.in 2002-12-11 21:17:44.000000000 -0200
+++ flow-tools-0.66/docs/flow-capture.1.in 2003-11-03 08:51:55.000000000 -0200
@@ -155,6 +155,8 @@
Load tags from \fBtag_name\fP
.IP "-T\fI active_def\fP|\fIactive_def,active_def\&.\&.\&.\fP" 10
Use \fIactive_def\fP as the active tag definition(s)\&.
+.IP "-u" 10
+Preserve inherited umask\&.
.IP "-V\fI pdu_version\fP" 10
Use \fIpdu_version\fP format output\&.
.PP
diff -u -r flow-tools-0.66-orig/src/flow-capture.c flow-tools-0.66/src/flow-capture.c
--- flow-tools-0.66-orig/src/flow-capture.c 2003-04-02 15:03:01.000000000 -0300
+++ flow-tools-0.66/src/flow-capture.c 2003-11-03 09:08:28.000000000 -0200
@@ -167,6 +167,7 @@
char *filter_fname, *filter_active;
int stat_interval, stat_next, child_status;
int v_flag;
+ int preserve_umask = 0;
time_startup = time((time_t)0L);
@@ -235,7 +236,7 @@
/* pidfile */
pidfile = CAPTURE_PIDFILE;
- while ((i = getopt(argc, argv, "A:b:c:C:d:De:E:f:F:hm:n:N:p:S:t:T:V:w:z:R:"))
+ while ((i = getopt(argc, argv, "A:b:c:C:d:De:E:f:F:hm:n:N:p:S:t:T:u:V:w:z:R:"))
!= -1)
switch (i) {
@@ -336,6 +337,10 @@
tag_fname = optarg;
break;
+ case 'u': /* preserve inherited umask */
+ preserve_umask = 1;
+ break;
+
case 'T': /* active tags */
tag_active = optarg;
/* required for fttag_eval() */
@@ -431,7 +436,9 @@
exit (0); /* parent */
}
- umask(0022);
+ if (!preserve_umask)
+ umask(0022);
+
setsid();
for (n = 0; n < 16; ++n)
close (n);
@@ -1366,7 +1373,7 @@
fprintf(stderr, " [-C comment] [-c flow_clients] [-d debug_level] [-D daemonize]\n");
fprintf(stderr, " [-e expire_count] [-E expire_size[bKMG]] [-m privacy_mask]\n");
fprintf(stderr, " [-n rotations] [-N nesting_level] [-p pidfile ] [-R rotate_program]\n");
- fprintf(stderr, " [-S stat_interval] [-t tag_fname] [-T tag_active] [-V pdu_version]\n");
+ fprintf(stderr, " [-S stat_interval] [-t tag_fname] [-T tag_active] [-u] [-V pdu_version]\n");
fprintf(stderr, " [-z z_level] -w workdir localip/remoteip/port\n");
fprintf(stderr, "Signals:\n");
fprintf(stderr, " SIGHUP - close and rotate current file\n");
--ibTvN161/egqYuK8--
From stroperyliad@yahoo.com Wed Nov 5 16:17:01 2003
From: stroperyliad@yahoo.com (johann lafer)
Date: Wed, 5 Nov 2003 08:17:01 -0800 (PST)
Subject: [flow-tools] Newbie understand problem flow-filter | flow-stat
Message-ID: <20031105161701.50246.qmail@web21501.mail.yahoo.com>
--0-780073001-1068049021=:49980
Content-Type: text/plain; charset=us-ascii
Hi,
i really do have a understand problem and hope someone can help me.
I need the following reports:
-Top N Talkers (inbound/outbound/both direction(s)) -> the hosts that transmit the most data on the network
-Top N Conversation (in/out/both dir) -> the hosts that transmit the most data between each other
- Top N Application (in/out/both dir) -> the applications that put the most data in the network
First i created a flow.acl
!permit anything
ip access-list standart location1 permit a.b.c.d 0.0.0.255
ip acces-slist standard location1 deny any
then i am running
flow-cat ft* | flow-filter -f flow.acl -Slocation1 | flow-stat -f9 -S2
but does this really show me the top talkers (outbound) sortet by octets?
And whats about
flow-cat ft* | flow-filter -f flow.acl -Dlocation1 | flow-stat -f8 -S2
Does this really show inbound talkers? But how do i get top talkers for both directions?
For Top N Converstation i changed flow-stat -f8 /-f9 to -f10. But again the problem with both directions.
Top N Applications i have not tried. A hint would be useful.
Thanks
Janno
---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
--0-780073001-1068049021=:49980
Content-Type: text/html; charset=us-ascii
Hi,
i really do have a understand problem and hope someone can help me.
I need the following reports:
-Top N Talkers (inbound/outbound/both direction(s)) -> the hosts that transmit the most data on the network
-Top N Conversation (in/out/both dir) -> the hosts that transmit the most data between each other
- Top N Application (in/out/both dir) -> the applications that put the most data in the network
First i created a flow.acl
!permit anything
ip access-list standart location1 permit a.b.c.d 0.0.0.255
Does this really show inbound talkers? But how do i get top talkers for both directions?
For Top N Converstation i changed flow-stat -f8 /-f9 to -f10. But again the problem with both directions.
Top N Applications i have not tried. A hint would be useful.
Thanks
Janno
Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard
--0-780073001-1068049021=:49980--
From Greg.Volk@edwardjones.com Wed Nov 5 16:55:56 2003
From: Greg.Volk@edwardjones.com (Greg.Volk@edwardjones.com)
Date: Wed, 05 Nov 2003 10:55:56 -0600
Subject: [flow-tools] Newbie understand problem flow-filter | flow-stat
Message-ID:
--Boundary_(ID_98dzrBBkFEl4gQcEHMmw6Q)
Content-type: text/plain; charset=US-ASCII; NAME=BDY.TXT
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=BDY.TXT;
Creation-Date="Wed, 5 Nov 2003 10:55:55 -0600"
>
> -Top N Talkers (inbound/outbound/both direction(s)) -> the hosts
> that transmit the most data on the network
> -Top N Conversation (in/out/both dir) -> the hosts that transmit
> the most data between each other
> - Top N Application (in/out/both dir) -> the applications that
> put the most data in the network
>
> First i created a flow.acl
>
> !permit anything
> ip access-list standart location1 permit a.b.c.d 0.0.0.255
> ip acces-slist standard location1 deny any
>
> then i am running
>
> flow-cat ft* | flow-filter -f flow.acl -Slocation1 | flow-stat -f9 -S2
>
Your first mistake is using flow-filter. Use flow-nfilter. Here is a
quick walk through regarding how to do this...
I have a file called test.ftr. It contains the following lines...
###begin test.ftr
filter-primitive private
type ip-address-prefix
permit 10.0.0.0/8
permit 172.16.0.0/12
permit 192.168.0.0/16
default deny
filter-definition privateip
match src-ip-addr private
or
match dst-ip-addr private
###end test.ftr
The object of test.ftr is to filter on private address space, and
throw all flow data that doesn't contain source or dest private
addresses away. So I use this filter as follows:
flow-cat ft-v07.2003-11-04.090001-0600 | flow-nfilter -f test.ftr -F
privateip | flow-print | more
And I should get a list of flows filtered for private source & dest
addresses.
If I want a top src/dest talkers report for this filtered data,
sorted by bytes, I'll do:
flow-cat ft-v07.2003-11-04.090001-0600 | flow-nfilter -f test.ftr -F
privateip | flow-stat -f10 -S3
It would be even better to use flow-report, but I haven't gotten
around to that yet.
> but does this really show me the top talkers (outbound) sortet by
octets?
>
>
That will depend on a number of things - what subnet(s) are you
interested
in, and are you receiving data from multiple routers? If you are getting
data from multiple routers, then you'll need to filter on Xaddr _prior_
to
filtering by subnets (more pipes).
>
> Top N Applications i have not tried. A hint would be useful.
>
Try...
flow-cat ft-v07.2003-11-04.090001-0600 | flow-nfilter -f test.ftr -F
privateip | flow-stat -f7
with the correct -S column.
--Boundary_(ID_98dzrBBkFEl4gQcEHMmw6Q)
Content-type: application/ms-tnef; NAME=WINMAIL.DAT
Content-transfer-encoding: base64
Content-disposition: attachment; filename=WINMAIL.DAT
eJ8+IpY6AQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N
aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA
ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABAEMAAABSRTogW2Zsb3ctdG9vbHNdIE5l
d2JpZSB1bmRlcnN0YW5kIHByb2JsZW0gZmxvdy1maWx0ZXIgfCBmbG93LXN0YXQAihgBA5AG
ABAAAAABAAAAQAA5AIB5y6+9o8MBEQUBA5AGADwAAAABAAAAHgBypQggBgAAAAAAwAAAAAAA
AEYAAAAAg4UAAAEAAAATAAAAODkwNTQzOTE2LTA1MTEyMDAzAAAcBwEDkAYALAAAAAEAAAAe
AHOlCCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAKgMBA5AGACwAAAABAAAA
HgB0pQggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAACoDAQOQBgAsAAAAAQAA
AB4AdaUIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAqAwEDkAYAJAAAAAEA
AAADAHalCCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAPACAQOQBgAkAAAAAQAAAAMAd6UI
IAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAA6gIBA5AGACQAAAABAAAAAwB4pQggBgAAAAAA
wAAAAAAAAEYAAAAAEIUAAAAAAADqAgEDkAYAJAAAAAEAAAALAHmlCCAGAAAAAADAAAAAAAAA
RgAAAAAOhQAAAAAAAPECAQOQBgAkAAAAAQAAAAMAeqUIIAYAAAAAAMAAAAAAAABGAAAAAAGF
AAAAAAAA3QIBA5AGACQAAAABAAAACwB7pQggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAADr
AgEDkAYALAAAAAEAAAAeAHylCCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAA
6QMBA5AGACQAAAABAAAAAwB9pQggBgAAAAAAwAAAAAAAAEYAAAAAUoUAACdqAQDDAwEDkAYA
DAAAAAEAAAADAN4/r28AAD8CAQOQBgAUAAAAAQAAAB4AQhABAAAAAQAAAAAAAABzAAEDkAYA
SAAAAAEAAAACATEAAQAAADUAAAAyMDAzMTEwNTE2MTcwMS41MDI0Ni5xbWFpbChhKXdlYjIx
NTAxLm1haWwueWFob28uY29tAAAAAA0PAQOQBgAMAAAAAQAAAAsAAgABAAAADwABA5AGAAwA
AAABAAAAAwAuAAAAAAAyAAEDkAYAUAAAAAEAAAAeAHAAAQAAAD8AAABbZmxvdy10b29sc10g
TmV3YmllIHVuZGVyc3RhbmQgcHJvYmxlbSBmbG93LWZpbHRlciB8IGZsb3ctc3RhdAAAaBgB
A5AGABgAAAABAAAAHgA9AAEAAAAFAAAAUkU6IAAAAABTAQEDkAYAIAAAAAEAAAACAQswAQAA
ABAAAACgnWS3ZA/YEb7NALDQpiKAVwgBA5AGAAwAAAABAAAAAwAGEDvFFAk3AQEDkAYADAAA
AAEAAAADAAcQrwYAANAAAQOQBgAMAAAAAQAAAAMAEBACAAAAJgABA5AGAAwAAAABAAAAAwAR
EAEAAAAmAAEDkAYAeAAAAAEAAAAeAAgQAQAAAGUAAAAtVE9QTlRBTEtFUlMoSU5CT1VORC9P
VVRCT1VORC9CT1RIRElSRUNUSU9OKFMpKS1USEVIT1NUU1RIQVRUUkFOU01JVFRIRU1PU1RE
QVRBT05USEVORVRXT1JLLVRPUE5DT05WAAAAAI0dAQOQBgAoAAAAAQAAAAIBcQABAAAAFgAA
AAHDo72vmbdknbAPZBHYvs0AsNCmIoAAAA8MAQOQBgAMAAAAAQAAAAMACVkBAAAAZwABA5AG
AAwAAAABAAAAAwCAEP////+QBAEJAAQAAgAAAAAAAAABA5AGAAwAAAABAAAACwAjAAAAAAAv
AAEDkAYADAAAAAEAAAALACkAAAAAADUAAQSQBgDsAQAAAQAAABIAAAAeAAEwAQAAAA0AAAAn
Zmxvdy10b29scycAAAAAAgH/DwEAAABCAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAEAZmxv
dy10b29scwBTTVRQAGZsb3ctdG9vbHNAc3BsaW50ZXJlZC5uZXQAAAADABUMAQAAAAMAADAA
AAAAHgACMAEAAAAFAAAAU01UUAAAAAAeABoMAQAAAAsAAABHcmVnIFZvbGsAAAACARkMAQAA
ADsAAAAAAAAAjVVM0Ow8Ec6B/wgACbEDegEAAAALAAAAAAAAADEdVm9sax4yHUdyZWceNR1J
Ux42HU1BSUwxAAAeAAMwAQAAABoAAABmbG93LXRvb2xzQHNwbGludGVyZWQubmV0AAAAAgEL
MAEAAAAfAAAAU01UUDpGTE9XLVRPT0xTQFNQTElOVEVSRUQuTkVUAAADAP9fAAAAAAMA/V8B
AAAAHgD2XwEAAAALAAAAZmxvdy10b29scwAAAgH3XwEAAABCAAAAAAAAAIErH6S+oxAZnW4A
3QEPVAIAAAEAZmxvdy10b29scwBTTVRQAGZsb3ctdG9vbHNAc3BsaW50ZXJlZC5uZXQAAAAL
AA8OAAAEgAMA/g8GAAAAAwAAOQAAAAALAEA6AAAAAAMAcToAAAAAj2M=
--Boundary_(ID_98dzrBBkFEl4gQcEHMmw6Q)--
From rjd@merit.edu Thu Nov 6 18:37:35 2003
From: rjd@merit.edu (Russell Dwarshuis)
Date: Thu, 6 Nov 2003 13:37:35 -0500 (EST)
Subject: [flow-tools] Problems compiling flow-tools
Message-ID:
Hello, I'm trying to upgrade flow-tools but configure is dieing on a zlib
test. Seems it can't find it. I think I had this problem with the older
version and solved it by setting an environmental variable specifying the
path to zlib, but now I can't remember what the variable name was. I
tried LD_LIBRARY_PATH unsuccessfully.
Any help would be appreciated. Thanks,
-Russell Dwarshuis
From wyu@ateneo.edu Fri Nov 7 00:15:31 2003
From: wyu@ateneo.edu (Horatio B. Bogbindero)
Date: Fri, 7 Nov 2003 08:15:31 +0800
Subject: [flow-tools] Problems compiling flow-tools
In-Reply-To:
References:
Message-ID: <1068164131.3faae42308c7d@mail.ateneo.edu>
Quoting Russell Dwarshuis :
> Hello, I'm trying to upgrade flow-tools but configure is dieing on a zlib
> test. Seems it can't find it. I think I had this problem with the older
> version and solved it by setting an environmental variable specifying the
> path to zlib, but now I can't remember what the variable name was. I
> tried LD_LIBRARY_PATH unsuccessfully.
>
if you are using linux:
1. edit the /etc/ld.so.conf and add the path to your proper zlib libraries
2. type 'ldconfig'
3. ./configure
4. make
5. make install
...OR...
1. export LDFLAGS=/path/to/zlib -lz
2. ./configure
3. make
4. make install
good luck!
-----------------------------------------------
William Emmanuel S. Yu
Ateneo Campus Network Group (AteneoCNG)
email : wyu at ateneo dot edu
web : http://CNG.ateneo.net/cng/wyu/
phone : +63(2)4266001-4186
GPG : http://CNG.ateneo.net/cng/wyu/wyy.pgp
From mhunter@ack.Berkeley.EDU Fri Nov 7 22:42:04 2003
From: mhunter@ack.Berkeley.EDU (Mike Hunter)
Date: Fri, 7 Nov 2003 14:42:04 -0800
Subject: [flow-tools] flow scripts for peer to peer users?
Message-ID: <20031107224203.GA16760@ack.Berkeley.EDU>
Hey everybody,
I have a feeling one of you might have some fancy scripts in place that
try to pick out peer-to-peer file sharing users. This is my personal list
of p2p ports:
1214 kazaa
4662 ednky
6346 gtela
6667 irc
6699 winmx
6881 b-tor
6882 b-tor
6883 b-tor
Just curious to see what good stuff was out there before I write my own.
Obviously this won't catch people with kazaa on port 80 (not uncommon!)
but it's better than nothing.
Thanks and have a good weekend,
Mike
From booloo@ucsc.edu Fri Nov 7 23:44:35 2003
From: booloo@ucsc.edu (Mark Boolootian)
Date: Fri, 7 Nov 2003 15:44:35 -0800
Subject: [flow-tools] flow scripts for peer to peer users?
In-Reply-To: <20031107224203.GA16760@ack.Berkeley.EDU>
References: <20031107224203.GA16760@ack.Berkeley.EDU>
Message-ID: <20031107234434.GB9969@root.ucsc.edu>
> Just curious to see what good stuff was out there before I write my own.
> Obviously this won't catch people with kazaa on port 80 (not uncommon!)
> but it's better than nothing.
KaZaA isn't using fixed ports any longer so you'll likely miss more data
than you'll catch using port 1214. I don't have any useful resources for
port numbers. You could try poking around on http://p2p.internet2.edu.
From vuori@geo0-hel-fi.magenta.net Mon Nov 10 23:10:50 2003
From: vuori@geo0-hel-fi.magenta.net (Valtteri Vuorikoski)
Date: 10 Nov 2003 23:10:50 +0000
Subject: [flow-tools] flow scripts for peer to peer users?
In-Reply-To: Mike Hunter's message of "Fri, 7 Nov 2003 14:42:04 -0800"
References: <20031107224203.GA16760@ack.Berkeley.EDU>
Message-ID:
With just netflow data, it's probably difficult to catch all p2p. If
you're serious about monitoring those, I saw a product called ROMmon
in action at a LAN party a while ago. There was (I think) a PC with a
GigE card watching all the external traffic (~500-600Mbps IIRC), which
included recognition of the major p2p apps based on looking inside the
packets (directconnect was the most popular at the time).
A Juniper router's policer was dynamically configured based on the
data, giving near real-time rate limiting of p2p traffic. In addition
to traffic graphs, reports from the "field" indicated rather
impressive results.
--
Valtteri Vuorikoski
MagentaSites Oy
From darkfibre@gmx.de Tue Nov 11 11:55:04 2003
From: darkfibre@gmx.de (Marco Decker)
Date: Tue, 11 Nov 2003 12:55:04 +0100 (MET)
Subject: [flow-tools] Spedd of flow-send
Message-ID: <32534.1068551704@www21.gmx.net>
hi, i got some problem with sending flows to a analyzing station. i capture
flows with flow-capture
and store the flows in a folder. in this folder are now the stored flows
from 2 weeks collecting.
i send the flows with flow-cat ./ | flow-send 0/xxx.xxx.xxx.xxxx./2055 to
the analyzing station.
it needs more than 2 hours till all datas been send. the files are stored in
intervals of 5 minutes and
have a sice of 40 kb. the cpu of the station where flow-send was running is
on 99 % idle also
the reciving analyzing station. is it possible to hurry up the tranmission ?
thanks for your answers
marco
--
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
Jetzt kostenlos anmelden unter http://www.gmx.net
+++ GMX - die erste Adresse für Mail, Message, More! +++
From stroperyliad@yahoo.com Thu Nov 13 17:05:17 2003
From: stroperyliad@yahoo.com (johann lafer)
Date: Thu, 13 Nov 2003 09:05:17 -0800 (PST)
Subject: [flow-tools] flow-cat error
Message-ID: <20031113170517.51616.qmail@web21502.mail.yahoo.com>
--0-1896015185-1068743117=:49022
Content-Type: text/plain; charset=us-ascii
Trying to run
flow-cat /var/netflow/ft/saved/ft-v05.2003* | flow-print -f5
i get the following error
-bash: /usr/local/netflow/bin/flow-cat: Argument list too long
Any hints
Thanks
---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
--0-1896015185-1068743117=:49022
Content-Type: text/html; charset=us-ascii
-bash: /usr/local/netflow/bin/flow-cat: Argument list too long
Any hints
Thanks
Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard
--0-1896015185-1068743117=:49022--
From mhunter@ack.Berkeley.EDU Thu Nov 13 17:20:58 2003
From: mhunter@ack.Berkeley.EDU (Mike Hunter)
Date: Thu, 13 Nov 2003 09:20:58 -0800
Subject: [flow-tools] flow-cat error
In-Reply-To: <20031113170517.51616.qmail@web21502.mail.yahoo.com>
References: <20031113170517.51616.qmail@web21502.mail.yahoo.com>
Message-ID: <20031113172058.GB26145@ack.Berkeley.EDU>
On Nov 13, "johann lafer" wrote:
> Trying to run
>
> flow-cat /var/netflow/ft/saved/ft-v05.2003* | flow-print -f5
>
> i get the following error
>
> -bash: /usr/local/netflow/bin/flow-cat: Argument list too long
The error is actually with bash and not with flow-cat.
"/var/netflow/ft/saved/ft-v05.2003*" is matching so many files that it's
over-flowing the shell.
Try running the command under tcsh, sh, csh, ksh, zsh, and whatever else
you can come up with. You could also increase bash's argument list size,
but I don't know how to do that without knowing what OS you're using.
Mike
From jrockwell@ChoiceOneCom.Com Fri Nov 14 19:09:41 2003
From: jrockwell@ChoiceOneCom.Com (Rockwell, John)
Date: Fri, 14 Nov 2003 14:09:41 -0500
Subject: [flow-tools] Compiling Flow-Tools .66 on Solaris 2.8
Message-ID: <990A175D26546C4A95A6715F25CAB97D05689C13@ROCHEXC3.choiceonecom.com>
Having compile issues under Solaris 2.8 which seem to be related to
yacc... Any ideas?
Making all in src
make[1]: Entering directory `/export/home1/panoptis/flow-tools/src'
bison -y -d `test -f 'aclyacc.y' || echo './'`aclyacc.y
aclyacc.y:267: type clash (`' `ext_entry') on default action
aclyacc.y:274: type clash (`' `ext_entry') on default action
aclyacc.y:288: type clash (`' `c') on default action
aclyacc.y:289: type clash (`' `c') on default action
aclyacc.y:305: type clash (`' `c') on default action
aclyacc.y:306: type clash (`' `c') on default action
aclyacc.y:312: type clash (`' `c') on default action
aclyacc.y:313: type clash (`' `c') on default action
aclyacc.y:337: type clash (`' `c') on default action
aclyacc.y:338: type clash (`' `c') on default action
aclyacc.y:341: type clash (`' `c') on default action
aclyacc.y:342: type clash (`' `c') on default action
make[1]: *** [aclyacc.c] Error 1
make[1]: Leaving directory `/export/home1/panoptis/flow-tools/src'
make: *** [all-recursive] Error 1
John E. Rockwell
Network Engineer, Data Level II Operations
Team Leader, Network Security
Choice One Communications
100 Chestnut Street
Rochester, New York 14604
585-697-2162 (Office)
585-452-3604 (Pager)
From jrockwell@ChoiceOneCom.Com Fri Nov 14 21:25:57 2003
From: jrockwell@ChoiceOneCom.Com (Rockwell, John)
Date: Fri, 14 Nov 2003 16:25:57 -0500
Subject: [flow-tools] RE: Compiling Flow-Tools .66 on Solaris 2.8
Message-ID: <990A175D26546C4A95A6715F25CAB97D05689C14@ROCHEXC3.choiceonecom.com>
Please disregard, This turned out to be an issue with the --prefix
configure option being pointed back at sourcedir.
--JER
> -----Original Message-----
> From: Rockwell, John
> Sent: Friday, November 14, 2003 2:10 PM
> To: 'flow-tools@splintered.net'
> Subject: Compiling Flow-Tools .66 on Solaris 2.8
>
>
> Having compile issues under Solaris 2.8 which seem to be related to
> yacc... Any ideas?
>
> Making all in src
> make[1]: Entering directory `/export/home1/panoptis/flow-tools/src'
> bison -y -d `test -f 'aclyacc.y' || echo './'`aclyacc.y
> aclyacc.y:267: type clash (`' `ext_entry') on default action
> aclyacc.y:274: type clash (`' `ext_entry') on default action
> aclyacc.y:288: type clash (`' `c') on default action
> aclyacc.y:289: type clash (`' `c') on default action
> aclyacc.y:305: type clash (`' `c') on default action
> aclyacc.y:306: type clash (`' `c') on default action
> aclyacc.y:312: type clash (`' `c') on default action
> aclyacc.y:313: type clash (`' `c') on default action
> aclyacc.y:337: type clash (`' `c') on default action
> aclyacc.y:338: type clash (`' `c') on default action
> aclyacc.y:341: type clash (`' `c') on default action
> aclyacc.y:342: type clash (`' `c') on default action
> make[1]: *** [aclyacc.c] Error 1
> make[1]: Leaving directory `/export/home1/panoptis/flow-tools/src'
> make: *** [all-recursive] Error 1
>
> John E. Rockwell
> Network Engineer, Data Level II Operations
> Team Leader, Network Security
> Choice One Communications
> 100 Chestnut Street
> Rochester, New York 14604
> 585-697-2162 (Office)
> 585-452-3604 (Pager)
>
>
From wyu@ateneo.edu Sat Nov 15 12:18:43 2003
From: wyu@ateneo.edu (Horatio B. Bogbindero)
Date: Sat, 15 Nov 2003 20:18:43 +0800
Subject: [flow-tools] Compiling Flow-Tools .66 on Solaris 2.8
In-Reply-To: <990A175D26546C4A95A6715F25CAB97D05689C13@ROCHEXC3.choiceonecom.com>
References: <990A175D26546C4A95A6715F25CAB97D05689C13@ROCHEXC3.choiceonecom.com>
Message-ID: <1068898723.3fb619a3a29fc@mail.ateneo.edu>
try forcing it to use byacc instead of bison. i also encounter
this problem in Linux.
Quoting "Rockwell, John" :
>
> Having compile issues under Solaris 2.8 which seem to be related to
> yacc... Any ideas?
>
> Making all in src
> make[1]: Entering directory `/export/home1/panoptis/flow-tools/src'
> bison -y -d `test -f 'aclyacc.y' || echo './'`aclyacc.y
> aclyacc.y:267: type clash (`' `ext_entry') on default action
> aclyacc.y:274: type clash (`' `ext_entry') on default action
> aclyacc.y:288: type clash (`' `c') on default action
> aclyacc.y:289: type clash (`' `c') on default action
> aclyacc.y:305: type clash (`' `c') on default action
> aclyacc.y:306: type clash (`' `c') on default action
> aclyacc.y:312: type clash (`' `c') on default action
> aclyacc.y:313: type clash (`' `c') on default action
> aclyacc.y:337: type clash (`' `c') on default action
> aclyacc.y:338: type clash (`' `c') on default action
> aclyacc.y:341: type clash (`' `c') on default action
> aclyacc.y:342: type clash (`' `c') on default action
> make[1]: *** [aclyacc.c] Error 1
> make[1]: Leaving directory `/export/home1/panoptis/flow-tools/src'
> make: *** [all-recursive] Error 1
>
> John E. Rockwell
> Network Engineer, Data Level II Operations
> Team Leader, Network Security
> Choice One Communications
> 100 Chestnut Street
> Rochester, New York 14604
> 585-697-2162 (Office)
> 585-452-3604 (Pager)
>
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
-----------------------------------------------
William Emmanuel S. Yu
Ateneo Campus Network Group (AteneoCNG)
email : wyu at ateneo dot edu
web : http://CNG.ateneo.net/cng/wyu/
phone : +63(2)4266001-4186
GPG : http://CNG.ateneo.net/cng/wyu/wyy.pgp
From Chitman Kaur "
This is a multipart mime message
--Next_1068905827---0-203.199.83.38-22113
Content-type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
=0AHi all =0AI am trying to run flowscan (CUFLow) with flow-tools and=
i am getting the following error.... =0A =0A/var/netflow/ft/ft-v05.2=
003-11-15.185506+0530: Invalid index in cflowd flow file: 0xCF100103! Versi=
on 5 flow-export is required with *all* fields being saved. =0A =0AAn=
y ideas what to do..... =0A =0AChitman=0A
=0A=0A=0A
=0A=0A
--Next_1068905827---0-203.199.83.38-22113
Content-type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi all=0AI am trying to run flowscan (CUFLow) with flow-tools and i am gett=
ing the following error....=0A=0A/var/netflow/ft/ft-v05.2003-11-15.185506+0=
530: Invalid index in cflowd flow file: 0xCF100103! Version 5 flow-export i=
s required with *all* fields being saved.=0A=0AAny ideas what to do.....=0A=
=0AChitman=0A=0A
--Next_1068905827---0-203.199.83.38-22113--
From Chitman Kaur "
This is a multipart mime message
--Next_1068912353---0-203.199.83.37-13926
Content-type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
=0Ahey guys... =0AI got the solution... :) =0AI was using the wron=
g Cflow file... =0AThanks a lot.... :) =0AChitman =0A =0AOn Sat=
, 15 Nov 2003 Chitman Kaur wrote : =0A>Hi all =0A>I am tr=
ying to run flowscan (CUFLow) with flow-tools and i am getting the followin=
g error.... =0A> =0A>/var/netflow/ft/ft-v05.2003-11-15.185506+0=
530: Invalid index in cflowd flow file: 0xCF100103! Version 5 flow-export i=
s required with *all* fields being saved. =0A> =0A>Any ideas wh=
at to do..... =0A> =0A>Chitman =0A> =0A=0A
=0A=0A=
=0A
=0A=0A
--Next_1068912353---0-203.199.83.37-13926
Content-type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
hey guys...=0AI got the solution... :)=0AI was using the wrong Cflow file..=
.=0AThanks a lot.... :)=0AChitman=0A=0AOn Sat, 15 Nov 2003 Chitman Kaur wr=
ote :=0A>Hi all=0A>I am trying to run flowscan (CUFLow) with flow-tools and=
i am getting the following error....=0A>=0A>/var/netflow/ft/ft-v05.2003-11=
-15.185506+0530: Invalid index in cflowd flow file: 0xCF100103! Version 5 f=
low-export is required with *all* fields being saved.=0A>=0A>Any ideas what=
to do.....=0A>=0A>Chitman=0A>=0A=0A=0A
--Next_1068912353---0-203.199.83.37-13926--
From nlaskovi@cs.sfu.ca Sat Nov 15 23:57:14 2003
From: nlaskovi@cs.sfu.ca (Nenad Laskovic)
Date: Sat, 15 Nov 2003 15:57:14 -0800
Subject: [flow-tools] Number of flow in one udp session
Message-ID: <00a501c3abd4$33e52ea0$1a073cc7@fas.sfu.ca>
Hi,
I've just started to use flow-tools, and there is a couple of things that I
can't figure it out.
There is Netflow of one voip session
Start End Sif SrcIPaddress SrcP DIf
DstIPaddress DstP P Fl Pkts Octets
1113.12:26:41.018 1113.12:27:42.718 3 192.168.210.20 17360 1
192.168.156.244 17432 17 0 2076 123990
1113.12:27:43.534 1113.12:28:47.110 3 192.168.210.20 17360 1
192.168.156.244 17432 17 0 2281 135910
1113.12:28:47.547 1113.12:29:48.827 3 192.168.210.20 17360 1
192.168.156.244 17432 17 0 1407 83318
1113.12:29:48.847 1113.12:30:58.675 3 192.168.210.20 17360 1
192.168.156.244 17432 17 0 984 57843
1113.12:31:00.848 1113.12:32:01.280 3 192.168.210.20 17360 2
192.168.156.244 17432 17 0 1378 81787
1113.12:33:02.508 1113.12:34:12.404 3 192.168.210.20 17360 2
192.168.156.244 17432 17 0 1504 88891
1113.12:34:12.425 1113.12:35:13.385 3 192.168.210.20 17360 1
192.168.156.244 17432 17 0 1886 112267
1113.12:36:22.014 1113.12:37:28.490 3 192.168.210.20 17360 2
192.168.156.244 17432 17 0 2262 134865
1113.12:37:30.870 1113.12:38:34.290 3 192.168.210.20 17360 2
192.168.156.244 17432 17 0 2258 134872
1113.12:38:34.307 1113.12:39:45.139 3 192.168.210.20 17360 2
192.168.156.244 17432 17 0 2655 158122
1113.12:39:45.303 1113.12:40:52.459 3 192.168.210.20 17360 1
192.168.156.244 17432 17 0 2314 137130
1113.12:40:52.740 1113.12:41:51.676 3 192.168.210.20 17360 1
192.168.156.244 17432 17 0 1776 105876
1113.12:43:04.020 1113.12:43:07.648 3 192.168.210.20 17360 2
192.168.156.244 17432 17 0 117 6887
Why there is some many different flows, when all parameters (IP addresses,
ports, protocol, Dif and Sif) are the same? Dif field is changed a couple of
times, but still there are few groups which all fields are the same.
Beside "no traffic" time out (which in this case 15sec) and Netflow cache
overflow, what are could be reasons for flow ending that caused splitting of
this session in so many flows?
Second thing, there is time difference between tcpdump traffic traces and
Netflow for the same traffic. For this particular case Netflow recorded that
last packet is
sent in 12:43:07, while tcpdump says that time of last packet is 13:07:05.
Here is line from tcpdump.
13:07:05.072609 192.168.210.20.17360 > 192.168.156.244.17840: [no cksum] udp
32 (ttl 250, id 40572, len 60)
For some other cases there is no differences between Netflow and tcpdump
data. In PPT presentation from
www.net.ohio-state.edu/security/talks/2000/2000-12-06_osu-flow-tools_lisa/
osu-flow-tools.ppt Mark Fullmer stated that flow
could be delayed by 30 minutes from start of traffic. What is reason for
that delay?
thank you in advance,
Nenad
From darkfibre@gmx.de Tue Nov 18 11:52:44 2003
From: darkfibre@gmx.de (Marco Decker)
Date: Tue, 18 Nov 2003 12:52:44 +0100 (MET)
Subject: [flow-tools] (no subject)
Message-ID: <16511.1069156364@www39.gmx.net>
I have a question about using flow-tools with my sql. I found an option to
put the captured flows with
flow-tools into a mysql database, but i didn´t found an option to get these
flows back from the
mysql database. how can i get the flows back to work with them ?
Thank you for your answer
Marco
--
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
Jetzt kostenlos anmelden unter http://www.gmx.net
+++ GMX - die erste Adresse für Mail, Message, More! +++
From Chitman Kaur "
This is a multipart mime message
--Next_1069213918---0-203.199.83.32-31609
Content-type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
=0AHi All =0ACan I configure flow-tools to get information from two p=
orts .... =0ADoes anyone have idea about how much of load can flow-tool=
s handle..... =0AThanks =0AChitman=0A
=0A=0A=0A
=0A=0A
--Next_1069213918---0-203.199.83.32-31609
Content-type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi All=0ACan I configure flow-tools to get information from two ports .... =
=0ADoes anyone have idea about how much of load can flow-tools handle.....=
=0AThanks=0AChitman=0A=0A
--Next_1069213918---0-203.199.83.32-31609--
From mhunter@ack.Berkeley.EDU Wed Nov 19 17:55:02 2003
From: mhunter@ack.Berkeley.EDU (Mike Hunter)
Date: Wed, 19 Nov 2003 09:55:02 -0800
Subject: [flow-tools] ports
In-Reply-To: <20031119035158.31612.qmail@webmail32.rediffmail.com>
References: <20031119035158.31612.qmail@webmail32.rediffmail.com>
Message-ID: <20031119175501.GC27231@ack.Berkeley.EDU>
On Nov 19, "Chitman Kaur " wrote:
> Hi All
> Can I configure flow-tools to get information from two ports ....
If you're talking about two UDP ports on the collection machine, you can
simply fire off two instances of flow-capture. All you have to do is tell
flow-capture which local address+port to listen on.
> Does anyone have idea about how much of load can flow-tools handle.....
flow-tools itself will deal with however much data you throw at it. On my
3 xenon, it took 3.5 seconds to do a quick summary (flow-stat -f 0) of
data representing 9.5 gigs of traffic.
Mike
From Chitman Kaur "
This is a multipart mime message
--Next_1069329210---0-203.199.83.27-29096
Content-type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
=0AThanks :) =0AI fired two instances of flow-capture ..... =0A=0AOn Wed, 19 Nov 2003 Mike Hunter wrote : =0A>On Nov 19, "Chit=
man Kaur " wrote: =0A> =0A> > Hi All =0A> > Ca=
n I configure flow-tools to get information from two ports .... =0A><=
BR>=0A>If you're talking about two UDP ports on the collection machine, =
you can =0A>simply fire off two instances of flow-capture. All =
you have to do is tell =0A>flow-capture which local address+port to l=
isten on. =0A> =0A> > Does anyone have idea about how much o=
f load can flow-tools handle..... =0A> =0A>flow-tools itself wi=
ll deal with however much data you throw at it. On my =0A>3 xen=
on, it took 3.5 seconds to do a quick summary (flow-stat -f 0) of =0A>=
;data representing 9.5 gigs of traffic. =0A> =0A>Mike =0A>=
; =0A>_______________________________________________ =0A>flow-=
tools@splintered.net =0A>http://www.splintered.net/sw/flow-tools =
=0A=0A
=0A=0A=0A
=0A=0A
--Next_1069329210---0-203.199.83.27-29096
Content-type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Thanks :)=0AI fired two instances of flow-capture .....=0A=0AOn Wed, 19 Nov=
2003 Mike Hunter wrote :=0A>On Nov 19, "Chitman Kaur " wrote:=0A>=0A> > Hi=
All=0A> > Can I configure flow-tools to get information from two ports ...=
.=0A>=0A>If you're talking about two UDP ports on the collection machine, y=
ou can=0A>simply fire off two instances of flow-capture. All you have to d=
o is tell=0A>flow-capture which local address+port to listen on.=0A>=0A> > =
Does anyone have idea about how much of load can flow-tools handle.....=0A>=
=0A>flow-tools itself will deal with however much data you throw at it. On=
my=0A>3 xenon, it took 3.5 seconds to do a quick summary (flow-stat -f 0) =
of=0A>data representing 9.5 gigs of traffic.=0A>=0A>Mike=0A>=0A>___________=
____________________________________=0A>flow-tools@splintered.net=0A>http:/=
/www.splintered.net/sw/flow-tools=0A=0A=0A
--Next_1069329210---0-203.199.83.27-29096--
From Chitman Kaur "
This is a multipart mime message
--Next_1069329288---0-203.199.83.27-30996
Content-type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
=0AHi All, =0AHas anyone worked with sflow ? =0AIs it better than =
netflow .... =0AChitman =0A=0A
=0A=0A=0A
=0A=
=0A
--Next_1069329288---0-203.199.83.27-30996
Content-type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi All,=0AHas anyone worked with sflow ?=0AIs it better than netflow ....=
=0AChitman=0A=0A=0A
--Next_1069329288---0-203.199.83.27-30996--
From z.ori@morehead-st.edu Thu Nov 20 17:18:27 2003
From: z.ori@morehead-st.edu (Zoltan Ori)
Date: Thu, 20 Nov 2003 12:18:27 -0500
Subject: [flow-tools] sflow
In-Reply-To: <20031120115449.31058.qmail@webmail17.rediffmail.com>
References: <20031120115449.31058.qmail@webmail17.rediffmail.com>
Message-ID: <200311201218.28629.z.ori@morehead-st.edu>
sflow is different from netflow. sflow agents are implemented on certain=20
hardware (see www.sflow.org for a list). From the sflow packages I have=20
perused, I find that they use netflow for accounting/billing. So, sflow=20
doesn't seem to be a replacement for netflow.
I don't own any of the hardware that supports sflow and don't plan on=20
purchasing it just for that capability. I find that flow-tools has been v=
ery=20
effective in making my network 'visible'.
Regards,
Zoltan
=20
On Thursday 20 November 2003 06:54 am, Chitman Kaur wrote:
>
> Hi All,
> Has anyone worked with sflow ?
> Is it better than netflow ....
> Chitman
>
>
>
>
>
> HREF=3D"http://clients.rediff.com/signature/track_sig.asp"> SRC=3D"http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffma=
il.com
>/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0 HEIGHT=3D74 WIDTH=3D=
496>
From liao1k@cmich.edu Thu Nov 20 21:24:26 2003
From: liao1k@cmich.edu (Liao, Kexiao)
Date: Thu, 20 Nov 2003 16:24:26 -0500
Subject: [flow-tools] yywrap error while compile the source codes on AIX V5.2 gcc version 2.9-aix43-010414
Message-ID: <291B348BC59B47468C7824603C326082237549@cmail3.central.cmich.local>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C3AFAC.ACBA7A9D
Content-Type: multipart/alternative;
boundary="----_=_NextPart_002_01C3AFAC.ACBA7A9D"
------_=_NextPart_002_01C3AFAC.ACBA7A9D
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Dear Flow-tools member,
When I compile the flow-tools on the AIX V5.2 of gcc version
2.9-aix43-010414, there are some error messages:
=20
Target "all-am" is up to date.
Making all in src
gcc -g -Wall -g -Wall -o flow-filter -L../lib flow-filter.o
aclyacc.o acllex.o acl2.o -lft -lnsl -lz
ld: 0711-317 ERROR: Undefined symbol: .yywrap
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
collect2: ld returned 8 exit status
make: 1254-004 The error code from the last command is 1.
=20
=20
Stop.
make: 1254-004 The error code from the last command is 1.
=20
=20
Stop.
sh-2.05a$ lexit
exit
=20
Some of the commands like "flow-print" and "flow-capture" have been
created.
Attached is the typescript file during the compile process (using
"make"). Please give me some comments. Thanks.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Kexiao Liao=20
CMU Research Corporation=20
2625 Denison Dr.
Mount Pleasant, MI 48858=20
Phone 989-774-2424 , Fax 989-774-2416
http://www.thecenter.cmich.edu/=20
liao1k@cmich.edu
=20
=20
------_=_NextPart_002_01C3AFAC.ACBA7A9D
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Dear Flow-tools member,
When I compile the flow-tools on the AIX =
V5.2
of gcc version 2.9-aix43-010414, there are some error =
messages:
=00
------_=_NextPart_002_01C3AFAC.ACBA7A9D--
------_=_NextPart_001_01C3AFAC.ACBA7A9D
Content-Type: application/octet-stream;
name="typescript"
Content-Transfer-Encoding: base64
Content-Description: typescript
Content-Disposition: attachment;
filename="typescript"
U2NyaXB0IGNvbW1hbmQgaXMgc3RhcnRlZCBvbiBUaHUgTm92IDIwIDE1OjQ2OjI4IEVTVCAyMDAz
LgpzaC0yLjA1YSQgbWFrZQ0KTWFraW5nIGFsbCBpbiBsaWINCiAgICAgICAgbWFrZSAgYWxsLWFt
DQogICAgICAgIHNvdXJjZT0nZnRpby5jJyBvYmplY3Q9J2Z0aW8ubycgbGlidG9vbD1ubyAgZGVw
ZmlsZT0nLmRlcHMvZnRpby5QbycgdG1wZGVwZmlsZT0nLmRlcHMvZnRpby5UUG8nICBkZXBtb2Rl
PWdjYyAvYmluL3NoIC4uL2RlcGNvbXAgIGdjYyAtSS4gLUkuL2xpYiAtSS4gLUkuIC1JLiAgICAg
LWcgLVdhbGwgLWcgLVdhbGwgLWMgYHRlc3QgLWYgJ2Z0aW8uYycgfHwgZWNobyAnLi8nYGZ0aW8u
Yw0KICAgICAgICBzb3VyY2U9J2Z0c3dhcC5jJyBvYmplY3Q9J2Z0c3dhcC5vJyBsaWJ0b29sPW5v
ICBkZXBmaWxlPScuZGVwcy9mdHN3YXAuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2Z0c3dhcC5UUG8n
ICBkZXBtb2RlPWdjYyAvYmluL3NoIC4uL2RlcGNvbXAgIGdjYyAtSS4gLUkuL2xpYiAtSS4gLUku
IC1JLiAgICAgLWcgLVdhbGwgLWcgLVdhbGwgLWMgYHRlc3QgLWYgJ2Z0c3dhcC5jJyB8fCBlY2hv
ICcuLydgZnRzd2FwLmMNCiAgICAgICAgc291cmNlPSdmdGVuY29kZS5jJyBvYmplY3Q9J2Z0ZW5j
b2RlLm8nIGxpYnRvb2w9bm8gIGRlcGZpbGU9Jy5kZXBzL2Z0ZW5jb2RlLlBvJyB0bXBkZXBmaWxl
PScuZGVwcy9mdGVuY29kZS5UUG8nICBkZXBtb2RlPWdjYyAvYmluL3NoIC4uL2RlcGNvbXAgIGdj
YyAtSS4gLUkuL2xpYiAtSS4gLUkuIC1JLiAgICAgLWcgLVdhbGwgLWcgLVdhbGwgLWMgYHRlc3Qg
LWYgJ2Z0ZW5jb2RlLmMnIHx8IGVjaG8gJy4vJ2BmdGVuY29kZS5jDQogICAgICAgIHNvdXJjZT0n
ZnRkZWNvZGUuYycgb2JqZWN0PSdmdGRlY29kZS5vJyBsaWJ0b29sPW5vICBkZXBmaWxlPScuZGVw
cy9mdGRlY29kZS5QbycgdG1wZGVwZmlsZT0nLmRlcHMvZnRkZWNvZGUuVFBvJyAgZGVwbW9kZT1n
Y2MgL2Jpbi9zaCAuLi9kZXBjb21wICBnY2MgLUkuIC1JLi9saWIgLUkuIC1JLiAtSS4gICAgIC1n
IC1XYWxsIC1nIC1XYWxsIC1jIGB0ZXN0IC1mICdmdGRlY29kZS5jJyB8fCBlY2hvICcuLydgZnRk
ZWNvZGUuYw0KICAgICAgICBzb3VyY2U9J2Z0cHJvZi5jJyBvYmplY3Q9J2Z0cHJvZi5vJyBsaWJ0
b29sPW5vICBkZXBmaWxlPScuZGVwcy9mdHByb2YuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2Z0cHJv
Zi5UUG8nICBkZXBtb2RlPWdjYyAvYmluL3NoIC4uL2RlcGNvbXAgIGdjYyAtSS4gLUkuL2xpYiAt
SS4gLUkuIC1JLiAgICAgLWcgLVdhbGwgLWcgLVdhbGwgLWMgYHRlc3QgLWYgJ2Z0cHJvZi5jJyB8
fCBlY2hvICcuLydgZnRwcm9mLmMNCiAgICAgICAgc291cmNlPSdiaXQxMDI0LmMnIG9iamVjdD0n
Yml0MTAyNC5vJyBsaWJ0b29sPW5vICBkZXBmaWxlPScuZGVwcy9iaXQxMDI0LlBvJyB0bXBkZXBm
aWxlPScuZGVwcy9iaXQxMDI0LlRQbycgIGRlcG1vZGU9Z2NjIC9iaW4vc2ggLi4vZGVwY29tcCAg
Z2NjIC1JLiAtSS4vbGliIC1JLiAtSS4gLUkuICAgICAtZyAtV2FsbCAtZyAtV2FsbCAtYyBgdGVz
dCAtZiAnYml0MTAyNC5jJyB8fCBlY2hvICcuLydgYml0MTAyNC5jDQogICAgICAgIHNvdXJjZT0n
Zm10LmMnIG9iamVjdD0nZm10Lm8nIGxpYnRvb2w9bm8gIGRlcGZpbGU9Jy5kZXBzL2ZtdC5Qbycg
dG1wZGVwZmlsZT0nLmRlcHMvZm10LlRQbycgIGRlcG1vZGU9Z2NjIC9iaW4vc2ggLi4vZGVwY29t
cCAgZ2NjIC1JLiAtSS4vbGliIC1JLiAtSS4gLUkuICAgICAtZyAtV2FsbCAtZyAtV2FsbCAtYyBg
dGVzdCAtZiAnZm10LmMnIHx8IGVjaG8gJy4vJ2BmbXQuYw0KICAgICAgICBzb3VyY2U9J3N1cHBv
cnQuYycgb2JqZWN0PSdzdXBwb3J0Lm8nIGxpYnRvb2w9bm8gIGRlcGZpbGU9Jy5kZXBzL3N1cHBv
cnQuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL3N1cHBvcnQuVFBvJyAgZGVwbW9kZT1nY2MgL2Jpbi9z
aCAuLi9kZXBjb21wICBnY2MgLUkuIC1JLi9saWIgLUkuIC1JLiAtSS4gICAgIC1nIC1XYWxsIC1n
IC1XYWxsIC1jIGB0ZXN0IC1mICdzdXBwb3J0LmMnIHx8IGVjaG8gJy4vJ2BzdXBwb3J0LmMNCnN1
cHBvcnQuYzogSW4gZnVuY3Rpb24gYG1rcGF0aCc6DQpzdXBwb3J0LmM6NjUzOiB3YXJuaW5nOiBp
bXBsaWNpdCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbiBgc3Ryc2VwJw0Kc3VwcG9ydC5jOjY1Mzog
d2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEg
Y2FzdA0KICAgICAgICBzb3VyY2U9J2Z0ZmlsZS5jJyBvYmplY3Q9J2Z0ZmlsZS5vJyBsaWJ0b29s
PW5vICBkZXBmaWxlPScuZGVwcy9mdGZpbGUuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2Z0ZmlsZS5U
UG8nICBkZXBtb2RlPWdjYyAvYmluL3NoIC4uL2RlcGNvbXAgIGdjYyAtSS4gLUkuL2xpYiAtSS4g
LUkuIC1JLiAgICAgLWcgLVdhbGwgLWcgLVdhbGwgLWMgYHRlc3QgLWYgJ2Z0ZmlsZS5jJyB8fCBl
Y2hvICcuLydgZnRmaWxlLmMNCmZ0ZmlsZS5jOiBJbiBmdW5jdGlvbiBgZnRmaWxlX3BhdGhuYW1l
JzoNCmZ0ZmlsZS5jOjQyMjogd2FybmluZzogaW1wbGljaXQgZGVjbGFyYXRpb24gb2YgZnVuY3Rp
b24gYHNucHJpbnRmJw0KICAgICAgICBzb3VyY2U9J2Z0dGx2LmMnIG9iamVjdD0nZnR0bHYubycg
bGlidG9vbD1ubyAgZGVwZmlsZT0nLmRlcHMvZnR0bHYuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2Z0
dGx2LlRQbycgIGRlcG1vZGU9Z2NjIC9iaW4vc2ggLi4vZGVwY29tcCAgZ2NjIC1JLiAtSS4vbGli
IC1JLiAtSS4gLUkuICAgICAtZyAtV2FsbCAtZyAtV2FsbCAtYyBgdGVzdCAtZiAnZnR0bHYuYycg
fHwgZWNobyAnLi8nYGZ0dGx2LmMNCiAgICAgICAgc291cmNlPSdmdG1hcC5jJyBvYmplY3Q9J2Z0
bWFwLm8nIGxpYnRvb2w9bm8gIGRlcGZpbGU9Jy5kZXBzL2Z0bWFwLlBvJyB0bXBkZXBmaWxlPScu
ZGVwcy9mdG1hcC5UUG8nICBkZXBtb2RlPWdjYyAvYmluL3NoIC4uL2RlcGNvbXAgIGdjYyAtSS4g
LUkuL2xpYiAtSS4gLUkuIC1JLiAgICAgLWcgLVdhbGwgLWcgLVdhbGwgLWMgYHRlc3QgLWYgJ2Z0
bWFwLmMnIHx8IGVjaG8gJy4vJ2BmdG1hcC5jDQpmdG1hcC5jOiBJbiBmdW5jdGlvbiBgZnRtYXBf
aWZhbGlhc19uZXcyJzoNCmZ0bWFwLmM6MTI0OiB3YXJuaW5nOiBpbXBsaWNpdCBkZWNsYXJhdGlv
biBvZiBmdW5jdGlvbiBgc3Ryc2VwJw0KZnRtYXAuYzoxMjQ6IHdhcm5pbmc6IGFzc2lnbm1lbnQg
bWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0bWFwLmM6IEluIGZ1
bmN0aW9uIGBmdG1hcF9sb2FkJzoNCmZ0bWFwLmM6MzcxOiB3YXJuaW5nOiBhc3NpZ25tZW50IG1h
a2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdG1hcC5jOiBJbiBmdW5j
dGlvbiBgcGFyc2VfaWZuYW1lJzoNCmZ0bWFwLmM6NDk0OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1h
a2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdG1hcC5jOjUwNjogd2Fy
bmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2Fz
dA0KZnRtYXAuYzo1MTg6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGlu
dGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0bWFwLmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9pZmFsaWFz
JzoNCmZ0bWFwLmM6NTUzOiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBp
bnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdG1hcC5jOjU2NTogd2FybmluZzogYXNzaWdubWVudCBt
YWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRtYXAuYzo1Nzc6IHdh
cm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNh
c3QNCiAgICAgICAgc291cmNlPSdmdHJlYy5jJyBvYmplY3Q9J2Z0cmVjLm8nIGxpYnRvb2w9bm8g
IGRlcGZpbGU9Jy5kZXBzL2Z0cmVjLlBvJyB0bXBkZXBmaWxlPScuZGVwcy9mdHJlYy5UUG8nICBk
ZXBtb2RlPWdjYyAvYmluL3NoIC4uL2RlcGNvbXAgIGdjYyAtSS4gLUkuL2xpYiAtSS4gLUkuIC1J
LiAgICAgLWcgLVdhbGwgLWcgLVdhbGwgLWMgYHRlc3QgLWYgJ2Z0cmVjLmMnIHx8IGVjaG8gJy4v
J2BmdHJlYy5jDQogICAgICAgIHNvdXJjZT0nZnRlcnIuYycgb2JqZWN0PSdmdGVyci5vJyBsaWJ0
b29sPW5vICBkZXBmaWxlPScuZGVwcy9mdGVyci5QbycgdG1wZGVwZmlsZT0nLmRlcHMvZnRlcnIu
VFBvJyAgZGVwbW9kZT1nY2MgL2Jpbi9zaCAuLi9kZXBjb21wICBnY2MgLUkuIC1JLi9saWIgLUku
IC1JLiAtSS4gICAgIC1nIC1XYWxsIC1nIC1XYWxsIC1jIGB0ZXN0IC1mICdmdGVyci5jJyB8fCBl
Y2hvICcuLydgZnRlcnIuYw0KZnRlcnIuYzogSW4gZnVuY3Rpb24gYGZ0ZXJyX2luZm8nOg0KZnRl
cnIuYzoxMDY6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0aW9uIGB2c25w
cmludGYnDQpmdGVyci5jOjEwOTogd2FybmluZzogaW1wbGljaXQgZGVjbGFyYXRpb24gb2YgZnVu
Y3Rpb24gYHNucHJpbnRmJw0KICAgICAgICBzb3VyY2U9J2Z0Y2hhc2guYycgb2JqZWN0PSdmdGNo
YXNoLm8nIGxpYnRvb2w9bm8gIGRlcGZpbGU9Jy5kZXBzL2Z0Y2hhc2guUG8nIHRtcGRlcGZpbGU9
Jy5kZXBzL2Z0Y2hhc2guVFBvJyAgZGVwbW9kZT1nY2MgL2Jpbi9zaCAuLi9kZXBjb21wICBnY2Mg
LUkuIC1JLi9saWIgLUkuIC1JLiAtSS4gICAgIC1nIC1XYWxsIC1nIC1XYWxsIC1jIGB0ZXN0IC1m
ICdmdGNoYXNoLmMnIHx8IGVjaG8gJy4vJ2BmdGNoYXNoLmMNCiAgICAgICAgc291cmNlPSdmdHN5
bS5jJyBvYmplY3Q9J2Z0c3ltLm8nIGxpYnRvb2w9bm8gIGRlcGZpbGU9Jy5kZXBzL2Z0c3ltLlBv
JyB0bXBkZXBmaWxlPScuZGVwcy9mdHN5bS5UUG8nICBkZXBtb2RlPWdjYyAvYmluL3NoIC4uL2Rl
cGNvbXAgIGdjYyAtSS4gLUkuL2xpYiAtSS4gLUkuIC1JLiAgICAgLWcgLVdhbGwgLWcgLVdhbGwg
LWMgYHRlc3QgLWYgJ2Z0c3ltLmMnIHx8IGVjaG8gJy4vJ2BmdHN5bS5jDQogICAgICAgIHNvdXJj
ZT0ncmFkaXguYycgb2JqZWN0PSdyYWRpeC5vJyBsaWJ0b29sPW5vICBkZXBmaWxlPScuZGVwcy9y
YWRpeC5QbycgdG1wZGVwZmlsZT0nLmRlcHMvcmFkaXguVFBvJyAgZGVwbW9kZT1nY2MgL2Jpbi9z
aCAuLi9kZXBjb21wICBnY2MgLUkuIC1JLi9saWIgLUkuIC1JLiAtSS4gICAgIC1nIC1XYWxsIC1n
IC1XYWxsIC1jIGB0ZXN0IC1mICdyYWRpeC5jJyB8fCBlY2hvICcuLydgcmFkaXguYw0KICAgICAg
ICBzb3VyY2U9J2Z0dGFnLmMnIG9iamVjdD0nZnR0YWcubycgbGlidG9vbD1ubyAgZGVwZmlsZT0n
LmRlcHMvZnR0YWcuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2Z0dGFnLlRQbycgIGRlcG1vZGU9Z2Nj
IC9iaW4vc2ggLi4vZGVwY29tcCAgZ2NjIC1JLiAtSS4vbGliIC1JLiAtSS4gLUkuICAgICAtZyAt
V2FsbCAtZyAtV2FsbCAtYyBgdGVzdCAtZiAnZnR0YWcuYycgfHwgZWNobyAnLi8nYGZ0dGFnLmMN
CmZ0dGFnLmM6IEluIGZ1bmN0aW9uIGBmdHRhZ19sb2FkJzoNCmZ0dGFnLmM6Mjc0OiB3YXJuaW5n
OiBpbXBsaWNpdCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbiBgc3Ryc2VwJw0KZnR0YWcuYzoyNzQ6
IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBh
IGNhc3QNCmZ0dGFnLmM6Mjg4OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJv
bSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdHRhZy5jOjMxMTogd2FybmluZzogYXNzaWdubWVu
dCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnR0YWcuYzogSW4g
ZnVuY3Rpb24gYHBhcnNlX2FjdGlvbic6DQpmdHRhZy5jOjM5Nzogd2FybmluZzogYXNzaWdubWVu
dCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnR0YWcuYzogSW4g
ZnVuY3Rpb24gYHBhcnNlX2FjdGlvbl90eXBlJzoNCmZ0dGFnLmM6NDU4OiB3YXJuaW5nOiBhc3Np
Z25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdHRhZy5j
OiBJbiBmdW5jdGlvbiBgcGFyc2VfYWN0aW9uX21hdGNoJzoNCmZ0dGFnLmM6NjI3OiB3YXJuaW5n
OiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpm
dHRhZy5jOjYzNjogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdl
ciB3aXRob3V0IGEgY2FzdA0KZnR0YWcuYzo2NTY6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMg
cG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0dGFnLmM6IEluIGZ1bmN0aW9u
IGBwYXJzZV9kZWYnOg0KZnR0YWcuYzo5MTE6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9p
bnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0dGFnLmM6IEluIGZ1bmN0aW9uIGBw
YXJzZV9kZWZfZXhwb3J0ZXInOg0KZnR0YWcuYzoxMDEyOiB3YXJuaW5nOiBhc3NpZ25tZW50IG1h
a2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdHRhZy5jOiBJbiBmdW5j
dGlvbiBgcGFyc2VfZGVmX2lucHV0X2ZpbHRlcic6DQpmdHRhZy5jOjEwNTA6IHdhcm5pbmc6IGFz
c2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0dGFn
LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9kZWZfb3V0cHV0X2ZpbHRlcic6DQpmdHRhZy5jOjEwOTE6
IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBh
IGNhc3QNCmZ0dGFnLmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9kZWZfYWN0aW9uJzoNCmZ0dGFnLmM6
MTEzNTogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRo
b3V0IGEgY2FzdA0KICAgICAgICBzb3VyY2U9J2Z0ZmlsLmMnIG9iamVjdD0nZnRmaWwubycgbGli
dG9vbD1ubyAgZGVwZmlsZT0nLmRlcHMvZnRmaWwuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2Z0Zmls
LlRQbycgIGRlcG1vZGU9Z2NjIC9iaW4vc2ggLi4vZGVwY29tcCAgZ2NjIC1JLiAtSS4vbGliIC1J
LiAtSS4gLUkuICAgICAtZyAtV2FsbCAtZyAtV2FsbCAtYyBgdGVzdCAtZiAnZnRmaWwuYycgfHwg
ZWNobyAnLi8nYGZ0ZmlsLmMNCmZ0ZmlsLmM6IEluIGZ1bmN0aW9uIGBmdGZpbF9sb2FkJzoNCmZ0
ZmlsLmM6MjUxNDogd2FybmluZzogaW1wbGljaXQgZGVjbGFyYXRpb24gb2YgZnVuY3Rpb24gYHN0
cnNlcCcNCmZ0ZmlsLmM6MjUxNDogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZy
b20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRmaWwuYzoyNTI4OiB3YXJuaW5nOiBhc3NpZ25t
ZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdGZpbC5jOjI1
NTE6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91
dCBhIGNhc3QNCmZ0ZmlsLmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9kZWZpbml0aW9uJzoNCmZ0Zmls
LmM6Mjg2MDogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3
aXRob3V0IGEgY2FzdA0KZnRmaWwuYzogSW4gZnVuY3Rpb24gYHBhcnNlX2RlZmluaXRpb25fbWF0
Y2gnOg0KZnRmaWwuYzoyOTI5OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJv
bSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdGZpbC5jOjI5Mzc6IHdhcm5pbmc6IGFzc2lnbm1l
bnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0ZmlsLmM6IElu
IGZ1bmN0aW9uIGBwYXJzZV9wcmltaXRpdmVfdHlwZV9pcF9tYXNrJzoNCmZ0ZmlsLmM6MzgxMDog
d2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEg
Y2FzdA0KZnRmaWwuYzogSW4gZnVuY3Rpb24gYHBhcnNlX3ByaW1pdGl2ZV90eXBlX3RhZ19tYXNr
JzoNCmZ0ZmlsLmM6Mzg2OTogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20g
aW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRmaWwuYzogSW4gZnVuY3Rpb24gYHBhcnNlX3ByaW1p
dGl2ZV90eXBlX2NvdW50ZXInOg0KZnRmaWwuYzo0MDEzOiB3YXJuaW5nOiBhc3NpZ25tZW50IG1h
a2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdGZpbC5jOiBJbiBmdW5j
dGlvbiBgcGFyc2VfcHJpbWl0aXZlX3R5cGVfdGltZSc6DQpmdGZpbC5jOjQxNzI6IHdhcm5pbmc6
IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0
ZmlsLmM6NDE4Mjogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdl
ciB3aXRob3V0IGEgY2FzdA0KZnRmaWwuYzo0MTg3OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2Vz
IHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdGZpbC5jOjQxOTI6IHdhcm5p
bmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QN
CmZ0ZmlsLmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9wcmltaXRpdmVfdHlwZV9kb3VibGUnOg0KZnRm
aWwuYzo0Mjc2OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2Vy
IHdpdGhvdXQgYSBjYXN0DQpmdGZpbC5jOiBJbiBmdW5jdGlvbiBgcGFyc2VfcHJpbWl0aXZlJzoN
CmZ0ZmlsLmM6NDM4MDogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50
ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRmaWwuYzogSW4gZnVuY3Rpb24gYHBhcnNlX3ByaW1pdGl2
ZV90eXBlJzoNCmZ0ZmlsLmM6NDQ1ODogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVy
IGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRmaWwuYzogSW4gZnVuY3Rpb24gYHBhcnNl
X3ByaW1pdGl2ZV9kZWZhdWx0JzoNCmZ0ZmlsLmM6NDYzOTogd2FybmluZzogYXNzaWdubWVudCBt
YWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRmaWwuYzogSW4gZnVu
Y3Rpb24gYHBhcnNlMl9wcmltaXRpdmVfcGVybWl0ZGVueSc6DQpmdGZpbC5jOjQ3ODI6IHdhcm5p
bmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QN
CmZ0ZmlsLmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9wcmltaXRpdmVfbWFzayc6DQpmdGZpbC5jOjQ4
OTQ6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91
dCBhIGNhc3QNCiAgICAgICAgc291cmNlPSdmdHN0YXQuYycgb2JqZWN0PSdmdHN0YXQubycgbGli
dG9vbD1ubyAgZGVwZmlsZT0nLmRlcHMvZnRzdGF0LlBvJyB0bXBkZXBmaWxlPScuZGVwcy9mdHN0
YXQuVFBvJyAgZGVwbW9kZT1nY2MgL2Jpbi9zaCAuLi9kZXBjb21wICBnY2MgLUkuIC1JLi9saWIg
LUkuIC1JLiAtSS4gICAgIC1nIC1XYWxsIC1nIC1XYWxsIC1jIGB0ZXN0IC1mICdmdHN0YXQuYycg
fHwgZWNobyAnLi8nYGZ0c3RhdC5jDQpmdHN0YXQuYzogSW4gZnVuY3Rpb24gYGZ0c3RhdF9sb2Fk
JzoNCmZ0c3RhdC5jOjI3NzY6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0
aW9uIGBzdHJzZXAnDQpmdHN0YXQuYzoyNzc2OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBv
aW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdHN0YXQuYzoyNzkwOiB3YXJuaW5n
OiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpm
dHN0YXQuYzoyODEzOiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRl
Z2VyIHdpdGhvdXQgYSBjYXN0DQpmdHN0YXQuYzogSW4gZnVuY3Rpb24gYHBhcnNlX3JwdCc6DQpm
dHN0YXQuYzozNDIwOiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRl
Z2VyIHdpdGhvdXQgYSBjYXN0DQpmdHN0YXQuYzogSW4gZnVuY3Rpb24gYHBhcnNlX3JwdF90eXBl
JzoNCmZ0c3RhdC5jOjM0ODQ6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9t
IGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0c3RhdC5jOiBJbiBmdW5jdGlvbiBgcGFyc2VfcnB0
X2ZpbHRlcic6DQpmdHN0YXQuYzozNTQ2OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50
ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdHN0YXQuYzogSW4gZnVuY3Rpb24gYHBh
cnNlX3JwdF90YWdfbWFzayc6DQpmdHN0YXQuYzozNTkyOiB3YXJuaW5nOiBhc3NpZ25tZW50IG1h
a2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdHN0YXQuYzozNjAyOiB3
YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBj
YXN0DQpmdHN0YXQuYzogSW4gZnVuY3Rpb24gYHBhcnNlX3JwdF9zY2FsZSc6DQpmdHN0YXQuYzoz
NjM2OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhv
dXQgYSBjYXN0DQpmdHN0YXQuYzogSW4gZnVuY3Rpb24gYHBhcnNlX3JwdF9pcF9zcmNfYWRkcl9m
bXQnOg0KZnRzdGF0LmM6MzY2Njogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZy
b20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRzdGF0LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9y
cHRfaXBfZHN0X2FkZHJfZm10JzoNCmZ0c3RhdC5jOjM3MjM6IHdhcm5pbmc6IGFzc2lnbm1lbnQg
bWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0c3RhdC5jOiBJbiBm
dW5jdGlvbiBgcGFyc2VfcnB0X291dF9mb3JtYXQnOg0KZnRzdGF0LmM6MzgyODogd2FybmluZzog
YXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRz
dGF0LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9ycHRfb3V0X3NvcnQnOg0KZnRzdGF0LmM6Mzg2OTog
d2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEg
Y2FzdA0KZnRzdGF0LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9ycHRfb3V0X3JlY29yZHMnOg0KZnRz
dGF0LmM6Mzk2NTogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdl
ciB3aXRob3V0IGEgY2FzdA0KZnRzdGF0LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9ycHRfb3V0X3Rh
bGx5JzoNCmZ0c3RhdC5jOjM5OTU6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBm
cm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0c3RhdC5jOiBJbiBmdW5jdGlvbiBgcGFyc2Vf
cnB0X291dF9maWVsZHMnOg0KZnRzdGF0LmM6NDA0Mzogd2FybmluZzogYXNzaWdubWVudCBtYWtl
cyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRzdGF0LmM6IEluIGZ1bmN0
aW9uIGBwYXJzZV9ycHRfb3V0X29wdGlvbnMnOg0KZnRzdGF0LmM6NDE3MDogd2FybmluZzogYXNz
aWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRzdGF0
LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9ycHRfb3V0X3RpbWUnOg0KZnRzdGF0LmM6NDI4Mzogd2Fy
bmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2Fz
dA0KZnRzdGF0LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9kZWYnOg0KZnRzdGF0LmM6NDMyOTogd2Fy
bmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2Fz
dA0KZnRzdGF0LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9kZWZfZmlsdGVyJzoNCmZ0c3RhdC5jOjQz
OTA6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91
dCBhIGNhc3QNCmZ0c3RhdC5jOiBJbiBmdW5jdGlvbiBgcGFyc2VfZGVmX3RhZyc6DQpmdHN0YXQu
Yzo0NDM3OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdp
dGhvdXQgYSBjYXN0DQpmdHN0YXQuYzogSW4gZnVuY3Rpb24gYHBhcnNlX2RlZl9tYXNrJzoNCmZ0
c3RhdC5jOjQ0ODM6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVn
ZXIgd2l0aG91dCBhIGNhc3QNCmZ0c3RhdC5jOiBJbiBmdW5jdGlvbiBgcGFyc2VfZGVmX3RpbWVf
c2VyaWVzJzoNCmZ0c3RhdC5jOjQ1Mjk6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRl
ciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0c3RhdC5jOiBJbiBmdW5jdGlvbiBgcGFy
c2VfZGVmX3JlcG9ydCc6DQpmdHN0YXQuYzo0NTcxOiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2Vz
IHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdHN0YXQuYzogSW4gZnVuY3Rp
b24gYHBhcnNlX2luY2x1ZGVfdGFnJzoNCmZ0c3RhdC5jOjQ2MjA6IHdhcm5pbmc6IGFzc2lnbm1l
bnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0c3RhdC5jOiBJ
biBmdW5jdGlvbiBgcGFyc2VfaW5jbHVkZV9maWx0ZXInOg0KZnRzdGF0LmM6NDY1MTogd2Fybmlu
ZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0K
ZnRzdGF0LmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9pbmNsdWRlX21hc2snOg0KZnRzdGF0LmM6NDY4
Mjogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0
IGEgY2FzdA0KICAgICAgICBzb3VyY2U9J2dldGRhdGUuYycgb2JqZWN0PSdnZXRkYXRlLm8nIGxp
YnRvb2w9bm8gIGRlcGZpbGU9Jy5kZXBzL2dldGRhdGUuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2dl
dGRhdGUuVFBvJyAgZGVwbW9kZT1nY2MgL2Jpbi9zaCAuLi9kZXBjb21wICBnY2MgLUkuIC1JLi9s
aWIgLUkuIC1JLiAtSS4gICAgIC1nIC1XYWxsIC1nIC1XYWxsIC1jIGB0ZXN0IC1mICdnZXRkYXRl
LmMnIHx8IGVjaG8gJy4vJ2BnZXRkYXRlLmMNCiAgICAgICAgc291cmNlPSdmdHhmaWVsZC5jJyBv
YmplY3Q9J2Z0eGZpZWxkLm8nIGxpYnRvb2w9bm8gIGRlcGZpbGU9Jy5kZXBzL2Z0eGZpZWxkLlBv
JyB0bXBkZXBmaWxlPScuZGVwcy9mdHhmaWVsZC5UUG8nICBkZXBtb2RlPWdjYyAvYmluL3NoIC4u
L2RlcGNvbXAgIGdjYyAtSS4gLUkuL2xpYiAtSS4gLUkuIC1JLiAgICAgLWcgLVdhbGwgLWcgLVdh
bGwgLWMgYHRlc3QgLWYgJ2Z0eGZpZWxkLmMnIHx8IGVjaG8gJy4vJ2BmdHhmaWVsZC5jDQpmdHhm
aWVsZC5jOiBJbiBmdW5jdGlvbiBgZnR4ZmllbGRfcGFyc2UnOg0KZnR4ZmllbGQuYzoxMTQ6IHdh
cm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0aW9uIGBzdHJzZXAnDQpmdHhmaWVs
ZC5jOjExNDogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3
aXRob3V0IGEgY2FzdA0KICAgICAgICBzb3VyY2U9J2Z0bWFzay5jJyBvYmplY3Q9J2Z0bWFzay5v
JyBsaWJ0b29sPW5vICBkZXBmaWxlPScuZGVwcy9mdG1hc2suUG8nIHRtcGRlcGZpbGU9Jy5kZXBz
L2Z0bWFzay5UUG8nICBkZXBtb2RlPWdjYyAvYmluL3NoIC4uL2RlcGNvbXAgIGdjYyAtSS4gLUku
L2xpYiAtSS4gLUkuIC1JLiAgICAgLWcgLVdhbGwgLWcgLVdhbGwgLWMgYHRlc3QgLWYgJ2Z0bWFz
ay5jJyB8fCBlY2hvICcuLydgZnRtYXNrLmMNCmZ0bWFzay5jOiBJbiBmdW5jdGlvbiBgZnRtYXNr
X2xvYWQnOg0KZnRtYXNrLmM6MTg2OiB3YXJuaW5nOiBpbXBsaWNpdCBkZWNsYXJhdGlvbiBvZiBm
dW5jdGlvbiBgc3Ryc2VwJw0KZnRtYXNrLmM6MTg2OiB3YXJuaW5nOiBhc3NpZ25tZW50IG1ha2Vz
IHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQgYSBjYXN0DQpmdG1hc2suYzoyMDA6IHdhcm5p
bmc6IGFzc2lnbm1lbnQgbWFrZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QN
CmZ0bWFzay5jOjIyMzogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50
ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRtYXNrLmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9kZWZpbml0
aW9uJzoNCmZ0bWFzay5jOjM3OTogd2FybmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZy
b20gaW50ZWdlciB3aXRob3V0IGEgY2FzdA0KZnRtYXNrLmM6IEluIGZ1bmN0aW9uIGBwYXJzZV9k
ZWZpbml0aW9uX3ByZWZpeCc6DQpmdG1hc2suYzo0NTQ6IHdhcm5pbmc6IGFzc2lnbm1lbnQgbWFr
ZXMgcG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCmZ0bWFzay5jOjQ3OTogd2Fy
bmluZzogYXNzaWdubWVudCBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2Fz
dA0KICAgICAgICBzb3VyY2U9J2Z0dmFyLmMnIG9iamVjdD0nZnR2YXIubycgbGlidG9vbD1ubyAg
ZGVwZmlsZT0nLmRlcHMvZnR2YXIuUG8nIHRtcGRlcGZpbGU9Jy5kZXBzL2Z0dmFyLlRQbycgIGRl
cG1vZGU9Z2NjIC9iaW4vc2ggLi4vZGVwY29tcCAgZ2NjIC1JLiAtSS4vbGliIC1JLiAtSS4gLUku
ICAgICAtZyAtV2FsbCAtZyAtV2FsbCAtYyBgdGVzdCAtZiAnZnR2YXIuYycgfHwgZWNobyAnLi8n
YGZ0dmFyLmMNCiAgICAgICAgcm0gLWYgbGliZnQuYQ0KICAgICAgICBhciBjcnUgbGliZnQuYSBm
dGlvLm8gZnRzd2FwLm8gZnRlbmNvZGUubyAgZnRkZWNvZGUubyBmdHByb2YubyBiaXQxMDI0Lm8g
IGZtdC5vIHN1cHBvcnQubyBmdGZpbGUubyAgZnR0bHYubyBmdG1hcC5vIGZ0cmVjLm8gZnRlcnIu
byAgZnRjaGFzaC5vIGZ0c3ltLm8gcmFkaXgubyAgZnR0YWcubyBmdGZpbC5vIGZ0c3RhdC5vICBn
ZXRkYXRlLm8gZnR4ZmllbGQubyBmdG1hc2subyAgZnR2YXIubyANCiAgICAgICAgcmFubGliIGxp
YmZ0LmENClRhcmdldCAiYWxsLWFtIiBpcyB1cCB0byBkYXRlLg0KTWFraW5nIGFsbCBpbiBzcmMN
CiAgICAgICAgZ2NjIC1nIC1XYWxsIC1nIC1XYWxsICAgLW8gZmxvdy1maWx0ZXIgLUwuLi9saWIg
Zmxvdy1maWx0ZXIubyBhY2x5YWNjLm8gIGFjbGxleC5vIGFjbDIubyAtbGZ0ICAgLWxuc2wgLWx6
IA0KbGQ6IDA3MTEtMzE3IEVSUk9SOiBVbmRlZmluZWQgc3ltYm9sOiAueXl3cmFwDQpsZDogMDcx
MS0zNDUgVXNlIHRoZSAtYmxvYWRtYXAgb3IgLWJub3F1aWV0IG9wdGlvbiB0byBvYnRhaW4gbW9y
ZSBpbmZvcm1hdGlvbi4NCmNvbGxlY3QyOiBsZCByZXR1cm5lZCA4IGV4aXQgc3RhdHVzDQptYWtl
OiAxMjU0LTAwNCBUaGUgZXJyb3IgY29kZSBmcm9tIHRoZSBsYXN0IGNvbW1hbmQgaXMgMS4NCg0K
DQpTdG9wLg0KbWFrZTogMTI1NC0wMDQgVGhlIGVycm9yIGNvZGUgZnJvbSB0aGUgbGFzdCBjb21t
YW5kIGlzIDEuDQoNCg0KU3RvcC4NCnNoLTIuMDVhJCBscyBzY3IHCCAICCAICCAICCAICCAICCAI
ZXhpdA0KZXhpdA0KClNjcmlwdCBjb21tYW5kIGlzIGNvbXBsZXRlIG9uIFRodSBOb3YgMjAgMTU6
NDY6NTggRVNUIDIwMDMuCg==
------_=_NextPart_001_01C3AFAC.ACBA7A9D--
From spork@bway.net Fri Nov 21 03:35:44 2003
From: spork@bway.net (Charles Sprickman)
Date: Thu, 20 Nov 2003 22:35:44 -0500 (EST)
Subject: [flow-tools] reporting top ASes
Message-ID:
Hi,
I'm new to flow-tools/netflow... I just installed yesterday, so please go
easy on me.
What motivated me to get this going is to try and determine where our
inbound traffic is coming from. We have two upstreams, and regardless of
how much I prepend on the one we want to relegate to backup use, we still
get 50-60% of inbound via that link.
Right now, I'm looking at something like this:
flow-cat -p ft-v05.2003-11-20.* | flow-filter -i3 | flow-stat -f19 -S3 -p
-P
Which I believe means to filter for only the (transit) interface I'm
interested in, then show me the source AS and sort by bytes.
This is giving me a good start (I see a few standouts with this), but I'm
wondering if there are some additional tools that could post-process this
and tell me more about the path. The upstream in question (HE.net) buys
transit from Above and WCG, and I want to find out how much of my traffic
is coming direct from HE and how much is leaking in from Above and/or WCG.
As far as I know, netflow doesn't record the path, so I'm kind of stuck,
but I'm assuming there must be something out there to do this...
Thanks,
Charles
From emanners@realprod.acns.fsu.edu Thu Nov 20 17:03:20 2003
From: emanners@realprod.acns.fsu.edu (Edson Manners)
Date: Thu, 20 Nov 2003 12:03:20 -0500
Subject: [flow-tools] Exporting flows from a 6509
Message-ID: <1069347799.934.16.camel@realprod.acns.fsu.edu>
Any one here exporting flows from a 6509?
I have just enabled NDE on my 6509 using this cisco web page. I am
collecting the flow on a RH 7.3 box running flow-capture ver 0.64
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a00800f4ffa.html#20485
When I run "show mls nde" I get:
Netflow Data Export enabled
Exporting flows to 1xx.xx.xx.xxx (9997)
Exporting flows from 1xx.xx.xx.xxx (53866)
Version: 7
Include Filter not configured
Exclude Filter not configured
Total Netflow Data Export Packets are:
14742 packets, 0 no packets, 397775 records
Total Netflow Data Export Send Errors:
IPWRITE_NO_FIB = 0
IPWRITE_ADJ_FAILED = 0
IPWRITE_PROCESS = 0
IPWRITE_ENQUEUE_FAILED = 0
IPWRITE_IPC_FAILED = 0
IPWRITE_MTU_FAILED = 0
IPWRITE_ENCAPFIX_FAILED = 0
And I can't see anything wrong with that.
Whe I run "show ip flow export" i get:
Flow export is enabled
Exporting flows to 1xx.xx.xxx.xxx (9997)
Exporting using source interface Loopback0
Version 5 flow records, origin-as
35502729 flows exported in 1209119 udp datagrams
0 flows failed due to lack of export packet
0 export packets were sent up to process level
0 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup failures
0 export packets were dropped enqueuing for the RP
0 export packets were dropped due to IPC rate limiting
That looks good too
But in my flow file I get the following. Make note of the bunch of V7
flows from the Layer 3-switched PFC with 0.0.0.0 source adresses. I had
NDE running before without the PFC exporting V7 flows and never got
those 0.0.0.0 source addresses.
Has anyone else here experienced anything like this? If not would anyone
mind giving me a few pointers as to how they set up NDE on their 6509.
Thanks a lot.
[root@bfs-test 2003-11-20]# flow-print < tmp-v07.2003-11-20.114501-0500
| more
srcIP dstIP router_sc prot
srcPort dstPort octets packets
0/0 68.35.227.73/0 1xx.xx.xx.xxx 0
0 0 67111 528
0/0 1xx.xx.xxx.xx/0 1xx.xx.xx.xxx 0
0 0 216096 398
0/0 216.22.100.39/0 1xx.xx.xx.xxx 0
0 0 11674 76
0/0 1xx.xxx.1.136/0 1xx.xx.xx.xxx 0
0 0 180 3
68.92.229.25/15 1xx.1xx.2.195/24 0.0.0.0 1
0 2048 180 3
68.92.229.25/15 1xx.1xx.2.196/24 0.0.0.0 1
0 2048 180 3
*IP addresses have been x'ed out to protect the innocent
From jrockwell@ChoiceOneCom.Com Fri Nov 21 13:39:26 2003
From: jrockwell@ChoiceOneCom.Com (Rockwell, John)
Date: Fri, 21 Nov 2003 08:39:26 -0500
Subject: [flow-tools] reporting top ASes
Message-ID: <990A175D26546C4A95A6715F25CAB97D05689C3C@ROCHEXC3.choiceonecom.com>
You may want to look at FlowScan, it acts as a post-processor for
Netflow packets. There are a number of modules out there for it, one of
which I'm sure will provide you with the functionality that you seek. The
base SubNetIO and CampusIO plugins also provide support for AS reporting.
FlowScan can be found at:
http://net.doit.wisc.edu/~plonka/FlowScan/
A couple of links to FlowScan modules:
http://carrierin.sourceforge.net/CarrierIn.html
http://users.telenet.be/jurgen.kobierczynski/
http://www.columbia.edu/acis/networks/advanced/CUFlow/
John E. Rockwell
Network Engineer, Data Level II Operations
Team Leader, Network Security
Choice One Communications
100 Chestnut Street
Rochester, New York 14604
585-697-2162 (Office)
585-452-3604 (Pager)
-----Original Message-----
From: Charles Sprickman [mailto:spork@bway.net]
Sent: Thursday, November 20, 2003 10:36 PM
To: flow-tools@splintered.net
Subject: [flow-tools] reporting top ASes
Hi,
I'm new to flow-tools/netflow... I just installed yesterday, so please go
easy on me.
What motivated me to get this going is to try and determine where our
inbound traffic is coming from. We have two upstreams, and regardless of
how much I prepend on the one we want to relegate to backup use, we still
get 50-60% of inbound via that link.
Right now, I'm looking at something like this:
flow-cat -p ft-v05.2003-11-20.* | flow-filter -i3 | flow-stat -f19 -S3 -p
-P
Which I believe means to filter for only the (transit) interface I'm
interested in, then show me the source AS and sort by bytes.
This is giving me a good start (I see a few standouts with this), but I'm
wondering if there are some additional tools that could post-process this
and tell me more about the path. The upstream in question (HE.net) buys
transit from Above and WCG, and I want to find out how much of my traffic
is coming direct from HE and how much is leaking in from Above and/or WCG.
As far as I know, netflow doesn't record the path, so I'm kind of stuck,
but I'm assuming there must be something out there to do this...
Thanks,
Charles
_______________________________________________
flow-tools@splintered.net
http://www.splintered.net/sw/flow-tools
From mborchers@igillc.com Fri Nov 21 16:03:37 2003
From: mborchers@igillc.com (Mark Borchers)
Date: Fri, 21 Nov 2003 10:03:37 -0600
Subject: [flow-tools] reporting top ASes
In-Reply-To:
Message-ID: <002a01c3b049$094d2de0$d3181e43@Traveler>
If I understand the question correctly, your solution lies
not in how you invoke flow-tools, but rather how you configure
your exporter.
Netflow has a "peer-as" and an "origin-as" option. If you
configure your router to export origin-as information, you
can analyze the traffic on the interface of interest and
see how much is actually sourcing from HE, and compare
that to the aggregate volume on the interface.
> -----Original Message-----
> This is giving me a good start (I see a few standouts with
> this), but I'm wondering if there are some additional tools
> that could post-process this and tell me more about the path.
> The upstream in question (HE.net) buys transit from Above
> and WCG, and I want to find out how much of my traffic is
> coming direct from HE and how much is leaking in from Above
> and/or WCG.
>
> As far as I know, netflow doesn't record the path, so I'm
> kind of stuck, but I'm assuming there must be something out
> there to do this...
>
> Thanks,
>
> Charles
>
> _______________________________________________
> flow-tools@splintered.net http://www.splintered.net/sw/flow-tools
>
From mborchers@igillc.com Fri Nov 21 16:19:43 2003
From: mborchers@igillc.com (Mark Borchers)
Date: Fri, 21 Nov 2003 10:19:43 -0600
Subject: [flow-tools] reporting top ASes
In-Reply-To: <002a01c3b049$094d2de0$d3181e43@Traveler>
Message-ID: <002b01c3b04b$49337250$d3181e43@Traveler>
P.S. This is not an exact science and is not likely to
be anytime soon. For example, downstream AS's from HE
will not show up in such an analysis.
> -----Original Message-----
> From: flow-tools-admin@splintered.net
> [mailto:flow-tools-admin@splintered.net] On Behalf Of Mark Borchers
> Sent: Friday, November 21, 2003 10:04 AM
> To: 'Charles Sprickman'; flow-tools@splintered.net
> Subject: RE: [flow-tools] reporting top ASes
>
>
> If I understand the question correctly, your solution lies
> not in how you invoke flow-tools, but rather how you
> configure your exporter.
>
> Netflow has a "peer-as" and an "origin-as" option. If you
> configure your router to export origin-as information, you
> can analyze the traffic on the interface of interest and
> see how much is actually sourcing from HE, and compare
> that to the aggregate volume on the interface.
>
> > -----Original Message-----
> > This is giving me a good start (I see a few standouts with
> > this), but I'm wondering if there are some additional tools
> > that could post-process this and tell me more about the path.
> > The upstream in question (HE.net) buys transit from Above
> > and WCG, and I want to find out how much of my traffic is
> > coming direct from HE and how much is leaking in from Above
> > and/or WCG.
> >
> > As far as I know, netflow doesn't record the path, so I'm
> > kind of stuck, but I'm assuming there must be something out
> > there to do this...
> >
> > Thanks,
> >
> > Charles
> >
> > _______________________________________________
> > flow-tools@splintered.net http://www.splintered.net/sw/flow-tools
> >
>
>
>
> _______________________________________________
> flow-tools@splintered.net http://www.splintered.net/sw/flow-tools
>
From vlad f kropachew Sun Nov 23 12:41:46 2003
From: vlad f kropachew (vlad f kropachew)
Date: Sun, 23 Nov 2003 15:41:46 +0300
Subject: [flow-tools] some php scripts
Message-ID: <1602557128.20031123154146@ratel.ru>
Hllo everyone. i have make small php script for filter/analyze flow
files in near-realtime, produced by flow-capture utility. i
think, they be useful for any system administrator. in my
configuration, i just sniff flows sended by router to billing system,
and retransfer it to servers with flow-capture running.
http://www.ratel.ru/flow/
--
Best regards,
vlad mailto:konsul@ratel.ru
From alexis@attla.net.ar Mon Nov 24 00:47:54 2003
From: alexis@attla.net.ar (Alexis)
Date: Sun, 23 Nov 2003 21:47:54 -0300
Subject: [flow-tools] Creating a "pseudo" dynamic time primitive
Message-ID: <006001c3b224$99031a30$0200000a@heretic>
I've searching and reading this mailing list archives but i didnt found the
answer.
I need to define a primitive (ive been trying too but it didnt work) , that
filter the last 5 minutes from now.
I mean, every time i hit the filter, i need (NOW-5MIN)
Im doing this by now, creating from a script a primitive like gt _time-5_
and then
flow-cat /flows/today | flow-report ..... where the report calls the filter
that has this primitive and others.
Any help?
Thanks in advance.
--
A man in black on a snow white horse,
A pointless life has run its course,
The red rimmed eyes, the tears still run
As he fades into the setting sun
From risto.vaarandi@eyp.ee Mon Nov 24 13:21:21 2003
From: risto.vaarandi@eyp.ee (Risto Vaarandi)
Date: Mon, 24 Nov 2003 15:21:21 +0200
Subject: [flow-tools] Software NetFlow probes
Message-ID: <3FC205D1.7030502@eyp.ee>
hi all,
first of all please accept my apologies since this question is slightly
off-topic. I am looking for a free software NetFlow probe that could be
used together with flow-tools. The most popular choice seems to be ntop
(http://www.ntop.org) which also has a support for NetFlow. I have made
some tests with ntop+flow-tools and my setup works quite fine. However,
ntop has some downsides - it generates a NetFlow record only when a TCP
connection is closed, therefore you can't see connections that are still
active among the statistics. The other thing is that aside from NetFlow
support ntop implements a large set of other features which can't be
switched off and which all consume some CPU time.
Therefore, I started to look for another software implementation of
NetFlow probe and found some relevant projects:
fprobe (http://sourceforge.net/projects/fprobe), softflowd
(http://www.mindrot.org/softflowd.html), and Flow Probe
(http://psi.home.ro/flow/).
However, the homepages of these tools contain no information how many
sites are actually using them and if they have been successfully used
with flow-tools. Does anyone in this list have any experience with the
tools mentioned above (either positive or negative)?
Also, if you know some other good software implementation of NetFlow
probe, please let me know.
tia,
risto
From jloiacon@csc.com Mon Nov 24 18:54:48 2003
From: jloiacon@csc.com (Joe Loiacono)
Date: Mon, 24 Nov 2003 13:54:48 -0500
Subject: [flow-tools] Software NetFlow probes
Message-ID:
I don't believe either ntop or flow-tools is responsible for your not
seeing active TCP connections. Netflow itself will not export a flow until
it has expired (very criteria), so I think you won't see open connections
for that reason.
Joe
Risto Vaarandi
cc:
Sent by: Subject: [flow-tools] Software NetFlow probes
flow-tools-admin
11/24/2003 08:21
AM
hi all,
first of all please accept my apologies since this question is slightly
off-topic. I am looking for a free software NetFlow probe that could be
used together with flow-tools. The most popular choice seems to be ntop
(http://www.ntop.org) which also has a support for NetFlow. I have made
some tests with ntop+flow-tools and my setup works quite fine. However,
ntop has some downsides - it generates a NetFlow record only when a TCP
connection is closed, therefore you can't see connections that are still
active among the statistics. The other thing is that aside from NetFlow
support ntop implements a large set of other features which can't be
switched off and which all consume some CPU time.
Therefore, I started to look for another software implementation of
NetFlow probe and found some relevant projects:
fprobe (http://sourceforge.net/projects/fprobe), softflowd
(http://www.mindrot.org/softflowd.html), and Flow Probe
(http://psi.home.ro/flow/).
However, the homepages of these tools contain no information how many
sites are actually using them and if they have been successfully used
with flow-tools. Does anyone in this list have any experience with the
tools mentioned above (either positive or negative)?
Also, if you know some other good software implementation of NetFlow
probe, please let me know.
tia,
risto
_______________________________________________
flow-tools@splintered.net
http://www.splintered.net/sw/flow-tools
From billf@mu.org Mon Nov 24 23:56:25 2003
From: billf@mu.org (Bill Fumerola)
Date: Mon, 24 Nov 2003 15:56:25 -0800
Subject: [flow-tools] Software NetFlow probes
In-Reply-To:
References:
Message-ID: <20031124235625.GX91301@elvis.mu.org>
On Mon, Nov 24, 2003 at 01:54:48PM -0500, Joe Loiacono wrote:
> I don't believe either ntop or flow-tools is responsible for your not
> seeing active TCP connections. Netflow itself will not export a flow until
> it has expired (very criteria), so I think you won't see open connections
> for that reason.
vendor J's software netflow is sampled and has no concept of connections
or flows.
vendor C's switch^Wrouter has timers that expire flows (pronounced "MLS
entries") based on both age and inactivity.
it's up to the implementation and it appears ntop has chosen poorly.
--
- bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org
From securityguy@ikano.com Tue Nov 25 02:38:39 2003
From: securityguy@ikano.com (Robert S. Galloway)
Date: Mon, 24 Nov 2003 19:38:39 -0700
Subject: [flow-tools] Software NetFlow probes
In-Reply-To: <3FC205D1.7030502@eyp.ee>
Message-ID: <200311241938545.SM03060@pendleton>
Hi Risto,
What kind of information are you hoping to get from your flow exports? Take
a look at my doc: http://www.linuxgeek.org/netflow-howto.php. It uses
flow-tools with FlowScan and CUFlow. You can also look at a live setup at
http://flows.ikano.com.
Thanks,
Robert S. Galloway
Chief Network Security Engineer
IKANO Communications
...the Internet branding company
Official Data Networking Services Provider for the
Salt Lake Olympic Winter Games of 2002
securityguy@ikano.com
801-415-8089
-----Original Message-----
From: flow-tools-admin@splintered.net
[mailto:flow-tools-admin@splintered.net] On Behalf Of Risto Vaarandi
Sent: Monday, November 24, 2003 6:21 AM
To: flow-tools@splintered.net
Subject: [flow-tools] Software NetFlow probes
hi all,
first of all please accept my apologies since this question is slightly
off-topic. I am looking for a free software NetFlow probe that could be
used together with flow-tools. The most popular choice seems to be ntop
(http://www.ntop.org) which also has a support for NetFlow. I have made
some tests with ntop+flow-tools and my setup works quite fine. However,
ntop has some downsides - it generates a NetFlow record only when a TCP
connection is closed, therefore you can't see connections that are still
active among the statistics. The other thing is that aside from NetFlow
support ntop implements a large set of other features which can't be
switched off and which all consume some CPU time.
Therefore, I started to look for another software implementation of
NetFlow probe and found some relevant projects:
fprobe (http://sourceforge.net/projects/fprobe), softflowd
(http://www.mindrot.org/softflowd.html), and Flow Probe
(http://psi.home.ro/flow/).
However, the homepages of these tools contain no information how many
sites are actually using them and if they have been successfully used
with flow-tools. Does anyone in this list have any experience with the
tools mentioned above (either positive or negative)?
Also, if you know some other good software implementation of NetFlow
probe, please let me know.
tia,
risto
_______________________________________________
flow-tools@splintered.net
http://www.splintered.net/sw/flow-tools
From maf@splintered.net Tue Nov 25 06:13:19 2003
From: maf@splintered.net (Mark Fullmer)
Date: Tue, 25 Nov 2003 01:13:19 -0500
Subject: [flow-tools] flow-stat -f 0 dumps core for 0 flow flow files (v .66)
In-Reply-To: <20031030213513.GA24482@ack.Berkeley.EDU>
References: <20031030213513.GA24482@ack.Berkeley.EDU>
Message-ID: <76D5BCC3-1F0E-11D8-840E-000A95DA1C38@splintered.net>
It's fixed in 0.67, but you really should use flow-report.
A few of the calculations for -f0 in flow-stat are still
not correct, specifically the averages.
mark
On Oct 30, 2003, at 4:35 PM, Mike Hunter wrote:
> I guess I shouldn't be flow-stating flow files with no flows, but
> somebody
> forgot to tell my script that :)
>
> Yes, I know flow-report is better and I will use it in future
> development.
>
> Mike
>
> (gdb) set args -f 0 <~/tmp.flow
> (gdb) open /usr/local/bin/flow-stat
> Undefined command: "open". Try "help".
> (gdb) file /usr/local/bin/flow-stat
> Reading symbols from /usr/local/bin/flow-stat...Deprecated bfd_read
> called
> at
> /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/
> dbxread.c
> line 2627 in elfstab_build_psymtabs
> Deprecated bfd_read called at
> /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
> line 933 in fill_symbuf
> done.
> (gdb) run
> Starting program: /usr/local/bin/flow-stat -f 0 <~/tmp.flow
> # --- ---- ---- Report Information --- --- ---
> #
> # Fields: Total
> # Symbols: Disabled
> # Sorting: None
> # Name: Overall Summary
> #
> # Args: /usr/local/bin/flow-stat -f 0
> #
>
> Program received signal SIGFPE, Arithmetic exception.
> 0x80753d1 in __udivdi3 ()
> (gdb) bt
> #0 0x80753d1 in __udivdi3 ()
> #1 0x804a73d in format0 (args=0xbfbff97c) at flow-stat.c:625
> #2 0x8049791 in main (argc=3, argv=0xbfbffb70) at flow-stat.c:457
> (gdb)
> #0 0x80753d1 in __udivdi3 ()
> #1 0x804a73d in format0 (args=0xbfbff97c) at flow-stat.c:625
> #2 0x8049791 in main (argc=3, argv=0xbfbffb70) at flow-stat.c:457
> (gdb) Quit
> (gdb) quit
> The program is running. Exit anyway? (y or n) y
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
>
From maf@splintered.net Tue Nov 25 06:30:39 2003
From: maf@splintered.net (Mark Fullmer)
Date: Tue, 25 Nov 2003 01:30:39 -0500
Subject: [flow-tools] Patch to ftrec.c to convert v1005 flows to v5
In-Reply-To:
References:
Message-ID:
Thanks, will be in 0.67.
The whole notion of fixed flow formats will be going
away soon to support v9 and IPFIX. It's a big change but
will add a lot more flexibility.
mark
On Oct 24, 2003, at 7:57 AM, Valtteri Vuorikoski wrote:
>
> flow-xlate is currently unable to convert v1005 flows to other formats,
> and additionally crashes when this is attempted. The following patch
> fixes this (to some degree) and adds support for converting v1005 flows
> to v5.
>
> Ideally ftrec_xlate() would return an indication of failure instead of
> just bailing out, but I wasn't sure of the wider implications for
> other users of the library of changing this.
>
> *** ftrec.c.old Fri Oct 24 10:53:37 2003
> --- ftrec.c Fri Oct 24 11:01:34 2003
> ***************
> *** 72,77 ****
> --- 72,80 ----
> void ftrec_xlate_7to1005(struct fts3rec_v7 *rec_v7,
> struct fts3rec_v1005 *rec_v1005);
>
> + void ftrec_xlate_1005to5(struct fts3rec_v1005 *rec_v1005,
> + struct fts3rec_v5 *rec_v5);
> +
> /*
> * function ftrec_compute_mask
> *
> ***************
> *** 209,214 ****
> --- 212,221 ----
> else if (out_ftv->d_version == 1005)
> return ftrec_xlate_7to1005;
>
> + } else if (in_ftv->d_version == 1005) {
> +
> + if (out_ftv->d_version == 5)
> + return ftrec_xlate_1005to5;
> }
>
> return (void*)0L;
> ***************
> *** 228,233 ****
> --- 235,242 ----
> void (*func)(void *in_rec, void *out_rec);
>
> func = ftrec_xlate_func(in_ftv, out_ftv);
> + if (!func)
> + return; /* XXX: should provide a return code */
> func(in_rec, out_rec);
>
> } /* ftrec_xlate */
> ***************
> *** 710,715 ****
> --- 719,756 ----
>
> } /* ftrec_xlate_7to1005 */
>
> + void ftrec_xlate_1005to5(struct fts3rec_v1005 *rec_v1005,
> + struct fts3rec_v5 *rec_v5)
> + {
> + bzero(rec_v5, sizeof (struct fts3rec_v5));
> +
> + rec_v5->unix_secs = rec_v1005->unix_secs;
> + rec_v5->unix_nsecs = rec_v1005->unix_nsecs;
> + rec_v5->sysUpTime = rec_v1005->sysUpTime;
> + rec_v5->exaddr = rec_v1005->exaddr;
> + rec_v5->srcaddr = rec_v1005->srcaddr;
> + rec_v5->dstaddr = rec_v1005->dstaddr;
> + rec_v5->nexthop = rec_v1005->nexthop;
> + rec_v5->input = rec_v1005->input;
> + rec_v5->output = rec_v1005->output;
> + rec_v5->dPkts = rec_v1005->dPkts;
> + rec_v5->dOctets = rec_v1005->dOctets;
> + rec_v5->First = rec_v1005->First;
> + rec_v5->Last = rec_v1005->Last;
> + rec_v5->srcport = rec_v1005->srcport;
> + rec_v5->dstport = rec_v1005->dstport;
> + rec_v5->prot = rec_v1005->prot;
> + rec_v5->tos = rec_v1005->tos;
> + rec_v5->tcp_flags = rec_v1005->tcp_flags;
> + rec_v5->engine_type = rec_v1005->engine_type;
> + rec_v5->engine_id = rec_v1005->engine_id;
> + rec_v5->src_mask = rec_v1005->src_mask;
> + rec_v5->dst_mask = rec_v1005->dst_mask;
> + rec_v5->src_as = rec_v1005->src_as;
> + rec_v5->dst_as = rec_v1005->dst_as;
> +
> + } /* flow_xlate_1005to5 */
> +
> /*
> * function fts3rec_compute_offsets
> *
>
> --
> Valtteri Vuorikoski
> MagentaSites Oy
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
>
From maf@splintered.net Tue Nov 25 06:42:26 2003
From: maf@splintered.net (Mark Fullmer)
Date: Tue, 25 Nov 2003 01:42:26 -0500
Subject: [flow-tools] or-{dst,src} not working in 0.66
In-Reply-To:
References:
Message-ID: <88645682-1F12-11D8-840E-000A95DA1C38@splintered.net>
Yes, this was definitely incorrect. Fixed in 0.67.
thanks,
mark
On Oct 10, 2003, at 4:17 PM, Valtteri Vuorikoski wrote:
>
> The constants in ftlib.h representing set-{dst,src} and or-{dst,src}
> are such that the tag action always ends up being "set". I didn't
> notice anything in the list archives about the issue. The attached
> patch fixes this, and hopefully doesn't break much else (lightly
> tested so far).
>
> Otherwise, flow-tools has been an impressively useful package so
> far.
>
> *** ftlib.h.old Fri Oct 10 19:38:34 2003
> --- ftlib.h Fri Oct 10 20:13:47 2003
> ***************
> *** 540,552 ****
>
> #define FT_TAG_TYPE_MATCH_NEXTHOP 0x100
>
> ! #define FT_TAG_SET_DST_TAG 0x101
> ! #define FT_TAG_SET_SRC_TAG 0x202
> ! #define FT_TAG_SET_TAG 0x303
>
> ! #define FT_TAG_OR_DST_TAG 0x110
> ! #define FT_TAG_OR_SRC_TAG 0x220
> ! #define FT_TAG_OR_TAG 0x330
>
> struct fttag {
> FT_SLIST_HEAD(defshead, fttag_def) defs; /* list of definitions */
> --- 540,552 ----
>
> #define FT_TAG_TYPE_MATCH_NEXTHOP 0x100
>
> ! #define FT_TAG_SET_DST_TAG 0x001
> ! #define FT_TAG_SET_SRC_TAG 0x002
> ! #define FT_TAG_SET_TAG 0x003
>
> ! #define FT_TAG_OR_DST_TAG 0x004
> ! #define FT_TAG_OR_SRC_TAG 0x008
> ! #define FT_TAG_OR_TAG 0x00C
>
> struct fttag {
> FT_SLIST_HEAD(defshead, fttag_def) defs; /* list of definitions */
>
> --
> Valtteri Vuorikoski
> MagentaSites Oy
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
>
From francisco.rivas@ifxnw.cl Tue Nov 25 12:56:44 2003
From: francisco.rivas@ifxnw.cl (Francisco Rivas)
Date: Tue, 25 Nov 2003 09:56:44 -0300
Subject: [flow-tools] or-{dst,src} not working in 0.66
In-Reply-To: <88645682-1F12-11D8-840E-000A95DA1C38@splintered.net>
References:
<88645682-1F12-11D8-840E-000A95DA1C38@splintered.net>
Message-ID: <1069765003.2571.11.camel@frivas.ifxnw.cl>
hi,
could yo tell me please, what kind of behavior is affected by this
bug?????
I'm doing some testings with flow-tools, and I'm using several filters
(with flow-nfilter) that uses the src-dst matching. This affects that??
thanks a lot!
Francisco R.
On Tue, 2003-11-25 at 03:42, Mark Fullmer wrote:
> Yes, this was definitely incorrect. Fixed in 0.67.
>
> thanks,
> mark
>
> On Oct 10, 2003, at 4:17 PM, Valtteri Vuorikoski wrote:
>
> >
> > The constants in ftlib.h representing set-{dst,src} and or-{dst,src}
> > are such that the tag action always ends up being "set". I didn't
> > notice anything in the list archives about the issue. The attached
> > patch fixes this, and hopefully doesn't break much else (lightly
> > tested so far).
> >
> > Otherwise, flow-tools has been an impressively useful package so
> > far.
> >
> > *** ftlib.h.old Fri Oct 10 19:38:34 2003
> > --- ftlib.h Fri Oct 10 20:13:47 2003
> > ***************
> > *** 540,552 ****
> >
> > #define FT_TAG_TYPE_MATCH_NEXTHOP 0x100
> >
> > ! #define FT_TAG_SET_DST_TAG 0x101
> > ! #define FT_TAG_SET_SRC_TAG 0x202
> > ! #define FT_TAG_SET_TAG 0x303
> >
> > ! #define FT_TAG_OR_DST_TAG 0x110
> > ! #define FT_TAG_OR_SRC_TAG 0x220
> > ! #define FT_TAG_OR_TAG 0x330
> >
> > struct fttag {
> > FT_SLIST_HEAD(defshead, fttag_def) defs; /* list of definitions */
> > --- 540,552 ----
> >
> > #define FT_TAG_TYPE_MATCH_NEXTHOP 0x100
> >
> > ! #define FT_TAG_SET_DST_TAG 0x001
> > ! #define FT_TAG_SET_SRC_TAG 0x002
> > ! #define FT_TAG_SET_TAG 0x003
> >
> > ! #define FT_TAG_OR_DST_TAG 0x004
> > ! #define FT_TAG_OR_SRC_TAG 0x008
> > ! #define FT_TAG_OR_TAG 0x00C
> >
> > struct fttag {
> > FT_SLIST_HEAD(defshead, fttag_def) defs; /* list of definitions */
> >
> > --
> > Valtteri Vuorikoski
> > MagentaSites Oy
> >
> > _______________________________________________
> > flow-tools@splintered.net
> > http://www.splintered.net/sw/flow-tools
> >
> >
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
From risto.vaarandi@eyp.ee Tue Nov 25 15:22:18 2003
From: risto.vaarandi@eyp.ee (Risto Vaarandi)
Date: Tue, 25 Nov 2003 17:22:18 +0200
Subject: [flow-tools] Software NetFlow probes
References:
Message-ID: <3FC373AA.80405@eyp.ee>
Joe Loiacono wrote:
> I don't believe either ntop or flow-tools is responsible for your not
> seeing active TCP connections.
I didn't say in my email that flow-tools is responsible for that - it is
impossible for a reporting tool to generate reports from data that have
not been made available to it.
> Netflow itself will not export a flow until
> it has expired (very criteria), so I think you won't see open connections
> for that reason.
There are several NetFlow probe implementations which export flow data
describing long-lasting connections that are still open. And I was just
curious whether anyone has ever used flow-tools with a decent NetFlow
probe package that has the same capability and that runs on a UNIX box.
br,
risto
>
> Joe
>
>
>
> Risto Vaarandi
> @eyp.ee> cc:
> Sent by: Subject: [flow-tools] Software NetFlow probes
> flow-tools-admin
>
>
> 11/24/2003 08:21
> AM
>
>
>
>
>
>
> hi all,
>
> first of all please accept my apologies since this question is slightly
> off-topic. I am looking for a free software NetFlow probe that could be
> used together with flow-tools. The most popular choice seems to be ntop
> (http://www.ntop.org) which also has a support for NetFlow. I have made
> some tests with ntop+flow-tools and my setup works quite fine. However,
> ntop has some downsides - it generates a NetFlow record only when a TCP
> connection is closed, therefore you can't see connections that are still
> active among the statistics. The other thing is that aside from NetFlow
> support ntop implements a large set of other features which can't be
> switched off and which all consume some CPU time.
>
> Therefore, I started to look for another software implementation of
> NetFlow probe and found some relevant projects:
> fprobe (http://sourceforge.net/projects/fprobe), softflowd
> (http://www.mindrot.org/softflowd.html), and Flow Probe
> (http://psi.home.ro/flow/).
>
> However, the homepages of these tools contain no information how many
> sites are actually using them and if they have been successfully used
> with flow-tools. Does anyone in this list have any experience with the
> tools mentioned above (either positive or negative)?
>
> Also, if you know some other good software implementation of NetFlow
> probe, please let me know.
>
> tia,
> risto
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
>
>
>
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
From vuori@geo0-hel-fi.magenta.net Tue Nov 25 15:22:27 2003
From: vuori@geo0-hel-fi.magenta.net (Valtteri Vuorikoski)
Date: 25 Nov 2003 15:22:27 +0000
Subject: [flow-tools] or-{dst,src} not working in 0.66
In-Reply-To: Francisco Rivas's message of "Tue, 25 Nov 2003 09:56:44 -0300"
References:
<88645682-1F12-11D8-840E-000A95DA1C38@splintered.net>
<1069765003.2571.11.camel@frivas.ifxnw.cl>
Message-ID:
Francisco Rivas writes:
> hi,
>
> could yo tell me please, what kind of behavior is affected by this
> bug?????
> I'm doing some testings with flow-tools, and I'm using several filters
> (with flow-nfilter) that uses the src-dst matching. This affects that??
This affects tagging of flows, now matching. So flow-tag and
flow-capture with the -T flag are affected.
--
Valtteri Vuorikoski
MagentaSites Oy
From maf@splintered.net Tue Nov 25 17:01:18 2003
From: maf@splintered.net (Mark Fullmer)
Date: Tue, 25 Nov 2003 12:01:18 -0500
Subject: [flow-tools] or-{dst,src} not working in 0.66
In-Reply-To: <1069765003.2571.11.camel@frivas.ifxnw.cl>
References: <88645682-1F12-11D8-840E-000A95DA1C38@splintered.net> <1069765003.2571.11.camel@frivas.ifxnw.cl>
Message-ID:
The or-src and or-dst options in flow-tag will behave as
set-src and set-dst. It's not an nfilter problem.
mark
mark
On Nov 25, 2003, at 7:56 AM, Francisco Rivas wrote:
> hi,
>
> could yo tell me please, what kind of behavior is affected by this
> bug?????
> I'm doing some testings with flow-tools, and I'm using several filters
> (with flow-nfilter) that uses the src-dst matching. This affects that??
>
> thanks a lot!
>
> Francisco R.
>
>
> On Tue, 2003-11-25 at 03:42, Mark Fullmer wrote:
>> Yes, this was definitely incorrect. Fixed in 0.67.
>>
>> thanks,
>> mark
>>
>> On Oct 10, 2003, at 4:17 PM, Valtteri Vuorikoski wrote:
>>
>>>
>>> The constants in ftlib.h representing set-{dst,src} and or-{dst,src}
>>> are such that the tag action always ends up being "set". I didn't
>>> notice anything in the list archives about the issue. The attached
>>> patch fixes this, and hopefully doesn't break much else (lightly
>>> tested so far).
>>>
>>> Otherwise, flow-tools has been an impressively useful package so
>>> far.
>>>
>>> *** ftlib.h.old Fri Oct 10 19:38:34 2003
>>> --- ftlib.h Fri Oct 10 20:13:47 2003
>>> ***************
>>> *** 540,552 ****
>>>
>>> #define FT_TAG_TYPE_MATCH_NEXTHOP 0x100
>>>
>>> ! #define FT_TAG_SET_DST_TAG 0x101
>>> ! #define FT_TAG_SET_SRC_TAG 0x202
>>> ! #define FT_TAG_SET_TAG 0x303
>>>
>>> ! #define FT_TAG_OR_DST_TAG 0x110
>>> ! #define FT_TAG_OR_SRC_TAG 0x220
>>> ! #define FT_TAG_OR_TAG 0x330
>>>
>>> struct fttag {
>>> FT_SLIST_HEAD(defshead, fttag_def) defs; /* list of definitions
>>> */
>>> --- 540,552 ----
>>>
>>> #define FT_TAG_TYPE_MATCH_NEXTHOP 0x100
>>>
>>> ! #define FT_TAG_SET_DST_TAG 0x001
>>> ! #define FT_TAG_SET_SRC_TAG 0x002
>>> ! #define FT_TAG_SET_TAG 0x003
>>>
>>> ! #define FT_TAG_OR_DST_TAG 0x004
>>> ! #define FT_TAG_OR_SRC_TAG 0x008
>>> ! #define FT_TAG_OR_TAG 0x00C
>>>
>>> struct fttag {
>>> FT_SLIST_HEAD(defshead, fttag_def) defs; /* list of definitions
>>> */
>>>
>>> --
>>> Valtteri Vuorikoski
>>> MagentaSites Oy
>>>
>>> _______________________________________________
>>> flow-tools@splintered.net
>>> http://www.splintered.net/sw/flow-tools
>>>
>>>
>>
>>
>> _______________________________________________
>> flow-tools@splintered.net
>> http://www.splintered.net/sw/flow-tools
>>
>
From Chitman Kaur "
This is a multipart mime message
--Next_1069907654---0-203.199.83.28-29407
Content-type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
=0AHi All =0AI had posted a message before but it does not seem to ha=
ve come so I am asking this again... =0AI am using flow-tools with flows=
can.... and have added 4 routers to it.....I noticed that my flow which are=
comming are less than expected so I checked the /var/log/messages and saw =
LOTS of following entries.... =0A---------------------------------------=
-------------------------------- =0ANov 27 09:29:54 devel flow-capture[8=
675]: ftpdu_seq_check(): src_ip=3Dxxx.xxx.xxx.xxx dst_ip=3Dxxx.xxx.xxx.xxx =
d_version=3D5 expecting=3D7338654 received=3D7338684 lost=3D30 =0A------=
----------------------------------------------------------------- =0AI a=
m also getting the following entry in between..... =0A =0A-----------=
------------------------------------------------------------ =0ANov 27 0=
9:30:00 devel flow-capture[8675]: STAT: now=3D1069905600 startup=3D10694060=
72 src_ip=3Dxxx.xxx.xxx.xxx dst_ip=3Dxxx.xxx.xxx.xxx d_ver=3D5 pkts=3D26577=
0 flows=3D7973100 lost=3D2248740 reset=3D330 filter_drops=3D0 =0A-------=
---------------------------------------------------------------- =0AWhat=
is the reason for this missed flows.... =0ARegards =0AChitman=0A
=
=0A=0A=0A
=0A=0A
--Next_1069907654---0-203.199.83.28-29407
Content-type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi All=0AI had posted a message before but it does not seem to have come so=
I am asking this again...=0AI am using flow-tools with flowscan.... and ha=
ve added 4 routers to it.....I noticed that my flow which are comming are l=
ess than expected so I checked the /var/log/messages and saw LOTS of follow=
ing entries....=0A---------------------------------------------------------=
--------------=0ANov 27 09:29:54 devel flow-capture[8675]: ftpdu_seq_check(=
): src_ip=3Dxxx.xxx.xxx.xxx dst_ip=3Dxxx.xxx.xxx.xxx d_version=3D5 expectin=
g=3D7338654 received=3D7338684 lost=3D30=0A--------------------------------=
---------------------------------------=0AI am also getting the following e=
ntry in between.....=0A=0A-------------------------------------------------=
----------------------=0ANov 27 09:30:00 devel flow-capture[8675]: STAT: no=
w=3D1069905600 startup=3D1069406072 src_ip=3Dxxx.xxx.xxx.xxx dst_ip=3Dxxx.x=
xx.xxx.xxx d_ver=3D5 pkts=3D265770 flows=3D7973100 lost=3D2248740 reset=3D3=
30 filter_drops=3D0=0A-----------------------------------------------------=
------------------=0AWhat is the reason for this missed flows....=0ARegards=
=0AChitman=0A=0A
--Next_1069907654---0-203.199.83.28-29407--
From securityguy@ikano.com Thu Nov 27 05:42:59 2003
From: securityguy@ikano.com (Robert S. Galloway)
Date: Wed, 26 Nov 2003 22:42:59 -0700
Subject: [flow-tools] Missed flows
In-Reply-To: <20031127043429.29781.qmail@webmail18.rediffmail.com>
Message-ID: <200311262243990.SM03060@pendleton>
This is a multi-part message in MIME format.
------=_NextPart_000_0003_01C3B46E.A5142930
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
I was just looking through the log files on one of my flow collectors and I
saw the same messages. Anyone know what they mean and should I be worried
about them?
Robert S. Galloway
Chief Network Security Engineer
IKANO Communications
...the Internet branding company
Official Data Networking Services Provider for the
Salt Lake Olympic Winter Games of 2002
securityguy@ikano.com
801-415-8089
_____
From: flow-tools-admin@splintered.net
[mailto:flow-tools-admin@splintered.net] On Behalf Of Chitman Kaur
Sent: Wednesday, November 26, 2003 9:34 PM
To: flow-tools@splintered.net
Subject: [flow-tools] Missed flows
Hi All
I had posted a message before but it does not seem to have come so I am
asking this again...
I am using flow-tools with flowscan.... and have added 4 routers to it.....I
noticed that my flow which are comming are less than expected so I checked
the /var/log/messages and saw LOTS of following entries....
-----------------------------------------------------------------------
Nov 27 09:29:54 devel flow-capture[8675]: ftpdu_seq_check():
src_ip=xxx.xxx.xxx.xxx dst_ip=xxx.xxx.xxx.xxx d_version=5 expecting=7338654
received=7338684 lost=30
-----------------------------------------------------------------------
I am also getting the following entry in between.....
-----------------------------------------------------------------------
Nov 27 09:30:00 devel flow-capture[8675]: STAT: now=1069905600
startup=1069406072 src_ip=xxx.xxx.xxx.xxx dst_ip=xxx.xxx.xxx.xxx d_ver=5
pkts=265770 flows=7973100 lost=2248740 reset=330 filter_drops=0
-----------------------------------------------------------------------
What is the reason for this missed flows....
Regards
Chitman
------=_NextPart_000_0003_01C3B46E.A5142930
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
I was just looking through the log =
files
on one of my flow collectors and I saw the same messages. Anyone know =
what they
mean and should I be worried about them?
Robert S. Galloway
Chief Network Security Engineer
IKANO Communications
...the Internet branding company
Official Data Networking Services Provider for =
the
Salt Lake Olympic Winter Games of 2002
securityguy@ikano.com
801-415-8089
From:
flow-tools-admin@splintered.net [mailto:flow-tools-admin@splintered.net] =
On Behalf Of Chitman Kaur Sent: Wednesday, November =
26, 2003
9:34 PM To: =
flow-tools@splintered.net Subject: [flow-tools] =
Missed flows
Hi All
I had posted a message before but it does not seem to have come so I am =
asking
this again...
I am using flow-tools with flowscan.... and have added 4 routers to =
it.....I
noticed that my flow which are comming are less than expected so I =
checked the
/var/log/messages and saw LOTS of following entries....
-----------------------------------------------------------------------
Nov 27 09:29:54 devel flow-capture[8675]: ftpdu_seq_check():
src_ip=3Dxxx.xxx.xxx.xxx dst_ip=3Dxxx.xxx.xxx.xxx d_version=3D5 =
expecting=3D7338654
received=3D7338684 lost=3D30
-----------------------------------------------------------------------
I am also getting the following entry in between.....
-----------------------------------------------------------------------
Nov 27 09:30:00 devel flow-capture[8675]: STAT: now=3D1069905600
startup=3D1069406072 src_ip=3Dxxx.xxx.xxx.xxx dst_ip=3Dxxx.xxx.xxx.xxx =
d_ver=3D5
pkts=3D265770 flows=3D7973100 lost=3D2248740 reset=3D330 =
filter_drops=3D0
-----------------------------------------------------------------------
What is the reason for this missed flows....
Regards
Chitman
------=_NextPart_000_0003_01C3B46E.A5142930--
From francisco.rivas@ifxnw.cl Thu Nov 27 14:24:10 2003
From: francisco.rivas@ifxnw.cl (Francisco Rivas)
Date: Thu, 27 Nov 2003 11:24:10 -0300
Subject: [flow-tools] DDos detection with NetFlow/Flow-Tools?
Message-ID: <1069943049.13338.31.camel@atlas.ifxnw.cl>
Hi all,
Anyone knows about how to implement DDos detection, based on the flows
obtained from the routers??? Is there any proyect (open source) that
might be useful for this??
I've been looking at Panoptis (http://panoptis.sourceforge.net/), but I
want to know if there is something similar...
thanks for all..!!!
--
--
Francisco Rivas Catalan
Network Engineer
IFX Networks
francisco.rivas@ifxnw.cl
(56) 2 3744500
From o.onorato@katamail.com Thu Nov 27 14:38:57 2003
From: o.onorato@katamail.com (Orlando Onorato)
Date: Thu, 27 Nov 2003 15:38:57 +0100
Subject: [flow-tools] format flow description
Message-ID: <00e701c3b4f4$319787a0$61af0a0a@Accenture.com>
This is a multi-part message in MIME format.
------=_NextPart_000_00E4_01C3B4FC.928C1C80
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I've some problems with format flow descriptin.
Particularly I not be able to do:
1) View header description of datagramm generated.
2) View all fields of flow description (e.g. nexthop field.
Can you help me?=20
Thank you very much.
Orlando Onorato
------=_NextPart_000_00E4_01C3B4FC.928C1C80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi, I've some problems with format flow=20
descriptin.
Particularly I not be able to do: 1) View header=20
description of datagramm generated. 2) View all fields of flow =
description=20
(e.g. nexthop field.
Can you help me? Thank you very=20
much.
Orlando Onorato
------=_NextPart_000_00E4_01C3B4FC.928C1C80--
From billf@mu.org Thu Nov 27 20:28:19 2003
From: billf@mu.org (Bill Fumerola)
Date: Thu, 27 Nov 2003 12:28:19 -0800
Subject: [flow-tools] format flow description
In-Reply-To: <00e701c3b4f4$319787a0$61af0a0a@Accenture.com>
References: <00e701c3b4f4$319787a0$61af0a0a@Accenture.com>
Message-ID: <20031127202819.GE91301@elvis.mu.org>
On Thu, Nov 27, 2003 at 03:38:57PM +0100, Orlando Onorato wrote:
> 1) View header description of datagramm generated.
dunno what you mean here, but increasing the debug level will show the
header of the flow file. if you want to see ip or udp header information
from the actual netflow packet, i'd suggest tcpdump.
> 2) View all fields of flow description (e.g. nexthop field.
flow-export
--
- bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org
From Mike.Reaves@aig.com Fri Nov 28 05:09:23 2003
From: Mike.Reaves@aig.com (Reaves, Mike)
Date: Fri, 28 Nov 2003 00:09:23 -0500
Subject: [flow-tools] import NF data
Message-ID:
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C3B56D.C967ED80
Content-Type: text/plain;
charset="iso-8859-1"
Has anyone continued to run the Cisco NetFlow collector, exported the data,
imported the data into flow tools and produced reports.
I like CSCOnfc, I like the FlowTools reports.
Mike Reaves
Senior Network System Engineer
Network System Management Group
AIG Technologies Inc.
Livingston Data Center, Livingston, New Jersey
973-533-3750 work
973-703-9729 mobile
------_=_NextPart_001_01C3B56D.C967ED80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Has anyone continued to run the Cisco NetFlow collector, =
exported the
data, imported the data into flow tools and produced =
reports.
I like CSCOnfc, I like the FlowTools =
reports.
=
<=
b>Mike =
Reaves
Senior
Network System Engineer
Network
System Management Group
AIG
Technologies Inc.
Livingston
Data Center, Livingston, New Jersey
973-533-3750
work
973-703-9729
mobile
=
------_=_NextPart_001_01C3B56D.C967ED80--
From hhg@data.is Fri Nov 28 05:26:55 2003
From: hhg@data.is (Hallgrimur H. Gunnarsson)
Date: Fri, 28 Nov 2003 05:26:55 +0000
Subject: [flow-tools] import NF data
In-Reply-To:
References:
Message-ID: <20031128052655.GA5557@data.is>
On 28.11.2003 "Reaves, Mike" wrote:
> Has anyone continued to run the Cisco NetFlow collector, exported the data,
> imported the data into flow tools and produced reports.
> I like CSCOnfc, I like the FlowTools reports.
You could use flow-fanout for sending flows to both collectors, or you
could export flows at a later time with flow-send.
-- hhg
From o.onorato@katamail.com Fri Nov 28 13:18:57 2003
From: o.onorato@katamail.com (Orlando Onorato)
Date: Fri, 28 Nov 2003 14:18:57 +0100
Subject: [flow-tools] format flow description
References: <00e701c3b4f4$319787a0$61af0a0a@Accenture.com> <20031127202819.GE91301@elvis.mu.org>
Message-ID: <002001c3b5b2$2e7f80e0$61af0a0a@Accenture.com>
By means of flow-export I'm not able to view the Nexhop field,
although this filed there is in Netflow ver.5.
----- Original Message -----
From: "Bill Fumerola"
To: "Orlando Onorato"
Cc:
Sent: Thursday, November 27, 2003 9:28 PM
Subject: Re: [flow-tools] format flow description
> On Thu, Nov 27, 2003 at 03:38:57PM +0100, Orlando Onorato wrote:
>
> > 1) View header description of datagramm generated.
>
> dunno what you mean here, but increasing the debug level will show the
> header of the flow file. if you want to see ip or udp header information
> from the actual netflow packet, i'd suggest tcpdump.
>
> > 2) View all fields of flow description (e.g. nexthop field.
>
> flow-export
>
> --
> - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org
>
>
From billf@mu.org Sat Nov 29 01:08:01 2003
From: billf@mu.org (Bill Fumerola)
Date: Fri, 28 Nov 2003 17:08:01 -0800
Subject: [flow-tools] format flow description
In-Reply-To: <002001c3b5b2$2e7f80e0$61af0a0a@Accenture.com>
References: <00e701c3b4f4$319787a0$61af0a0a@Accenture.com> <20031127202819.GE91301@elvis.mu.org> <002001c3b5b2$2e7f80e0$61af0a0a@Accenture.com>
Message-ID: <20031129010801.GG91301@elvis.mu.org>
On Fri, Nov 28, 2003 at 02:18:57PM +0100, Orlando Onorato wrote:
> By means of flow-export I'm not able to view the Nexhop field,
> although this filed there is in Netflow ver.5.
works fine for me, you might want to check (possibly through [t]ethereal)
that the field is being set by your vendor.
otherwise, you'll have to provide more information if you truely think
this is a bug..
--
- bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org
From maf@splintered.net Sat Nov 29 01:20:48 2003
From: maf@splintered.net (Mark Fullmer)
Date: Fri, 28 Nov 2003 20:20:48 -0500
Subject: [flow-tools] format flow description
In-Reply-To: <002001c3b5b2$2e7f80e0$61af0a0a@Accenture.com>
References: <00e701c3b4f4$319787a0$61af0a0a@Accenture.com> <20031127202819.GE91301@elvis.mu.org> <002001c3b5b2$2e7f80e0$61af0a0a@Accenture.com>
Message-ID: <43B31182-220A-11D8-9AA7-000A95DA1C38@splintered.net>
It's there. Use flow-export -f2 (ASCII).
#:
unix_secs,unix_nsecs,sysuptime,exaddr,dpkts,doctets,first,last,engine_ty
pe,eng
ine_id,srcaddr,dstaddr,nexthop,input,output,srcport,dstport,prot,tos,tcp
_flags,s
rc_mask,dst_mask,src_as,dst_as
1018404899,502659552,3685185404,192.88.192.245,1,40,3685169372,368516937
2,4,0,12
9.137.254.5,129.21.7.49,192.88.192.33,40,25,56279,33508,17,0,16,16,16,20
126,4385
^^^^^^^^^^^^^
mark
On Nov 28, 2003, at 8:18 AM, Orlando Onorato wrote:
> By means of flow-export I'm not able to view the Nexhop field,
> although this filed there is in Netflow ver.5.
>
>
> ----- Original Message -----
> From: "Bill Fumerola"
> To: "Orlando Onorato"
> Cc:
> Sent: Thursday, November 27, 2003 9:28 PM
> Subject: Re: [flow-tools] format flow description
>
>
>> On Thu, Nov 27, 2003 at 03:38:57PM +0100, Orlando Onorato wrote:
>>
>>> 1) View header description of datagramm generated.
>>
>> dunno what you mean here, but increasing the debug level will show the
>> header of the flow file. if you want to see ip or udp header
>> information
>> from the actual netflow packet, i'd suggest tcpdump.
>>
>>> 2) View all fields of flow description (e.g. nexthop field.
>>
>> flow-export
>>
>> --
>> - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org
>>
>>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
From maf@splintered.net Sat Nov 29 01:24:41 2003
From: maf@splintered.net (Mark Fullmer)
Date: Fri, 28 Nov 2003 20:24:41 -0500
Subject: [flow-tools] Missed flows
In-Reply-To: <20031127043429.29781.qmail@webmail18.rediffmail.com>
References: <20031127043429.29781.qmail@webmail18.rediffmail.com>
Message-ID:
It's usually packet loss between the exporter and the collector.
Sometimes it's a busy collector, this can usually be fixed by turning
off compression.
mark
On Nov 26, 2003, at 11:34 PM, Chitman Kaur wrote:
> Hi All
> I had posted a message before but it does not seem to have come so I
> am asking this again...
> I am using flow-tools with flowscan.... and have added 4 routers to
> it.....I noticed that my flow which are comming are less than expected
> so I checked the /var/log/messages and saw LOTS of following
> entries....
> -----------------------------------------------------------------------
> Nov 27 09:29:54 devel flow-capture[8675]: ftpdu_seq_check():
> src_ip=xxx.xxx.xxx.xxx dst_ip=xxx.xxx.xxx.xxx d_version=5
> expecting=7338654 received=7338684 lost=30
> -----------------------------------------------------------------------
> I am also getting the following entry in between.....
>
> -----------------------------------------------------------------------
> Nov 27 09:30:00 devel flow-capture[8675]: STAT: now=1069905600
> startup=1069406072 src_ip=xxx.xxx.xxx.xxx dst_ip=xxx.xxx.xxx.xxx
> d_ver=5 pkts=265770 flows=7973100 lost=2248740 reset=330
> filter_drops=0
> -----------------------------------------------------------------------
> What is the reason for this missed flows....
> Regards
> Chitman
>
From maf@splintered.net Sat Nov 29 03:56:53 2003
From: maf@splintered.net (Mark Fullmer)
Date: Fri, 28 Nov 2003 22:56:53 -0500
Subject: [flow-tools] Creating a "pseudo" dynamic time primitive
In-Reply-To: <006001c3b224$99031a30$0200000a@heretic>
References: <006001c3b224$99031a30$0200000a@heretic>
Message-ID: <11470C02-2220-11D8-9AA7-000A95DA1C38@splintered.net>
Try "5 minutes ago"
mark
On Nov 23, 2003, at 7:47 PM, Alexis wrote:
> I've searching and reading this mailing list archives but i didnt
> found the
> answer.
>
>
> I need to define a primitive (ive been trying too but it didnt work) ,
> that
> filter the last 5 minutes from now.
>
> I mean, every time i hit the filter, i need (NOW-5MIN)
>
> Im doing this by now, creating from a script a primitive like gt
> _time-5_
> and then
>
>
> flow-cat /flows/today | flow-report ..... where the report calls the
> filter
> that has this primitive and others.
>
>
> Any help?
>
>
> Thanks in advance.
>
>
>
> --
> A man in black on a snow white horse,
> A pointless life has run its course,
> The red rimmed eyes, the tears still run
> As he fades into the setting sun
>
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
From maf@splintered.net Sat Nov 29 04:33:08 2003
From: maf@splintered.net (Mark Fullmer)
Date: Fri, 28 Nov 2003 23:33:08 -0500
Subject: [flow-tools] Creating a "pseudo" dynamic time primitive
In-Reply-To: <11470C02-2220-11D8-9AA7-000A95DA1C38@splintered.net>
References: <006001c3b224$99031a30$0200000a@heretic> <11470C02-2220-11D8-9AA7-000A95DA1C38@splintered.net>
Message-ID: <21CA14DB-2225-11D8-9AA7-000A95DA1C38@splintered.net>
FYI, I added the following text to the flow-nfilter man page. Similar
verbage is in flow-cat too.
TIME/DATE parsing
time-date parsing is implemented with getdate.y, a com-
monly used function to process free-form time date speci-
fications. Example usage borrowed from cvs:
1 month ago
2 hours ago
400000 seconds ago
last year
last Monday
yesterday
a fortnight ago
3/31/92 10:00:07 PST
January 23, 1987 10:05pm
22:00 GMT
mark
On Nov 28, 2003, at 10:56 PM, Mark Fullmer wrote:
>
> Try "5 minutes ago"
>
> mark
>
> On Nov 23, 2003, at 7:47 PM, Alexis wrote:
>
>> I've searching and reading this mailing list archives but i didnt
>> found the
>> answer.
>>
>>
>> I need to define a primitive (ive been trying too but it didnt work)
>> , that
>> filter the last 5 minutes from now.
>>
>> I mean, every time i hit the filter, i need (NOW-5MIN)
>>
>> Im doing this by now, creating from a script a primitive like gt
>> _time-5_
>> and then
>>
>>
>> flow-cat /flows/today | flow-report ..... where the report calls the
>> filter
>> that has this primitive and others.
>>
>>
>> Any help?
>>
>>
>> Thanks in advance.
>>
>>
>>
>> --
>> A man in black on a snow white horse,
>> A pointless life has run its course,
>> The red rimmed eyes, the tears still run
>> As he fades into the setting sun
>>
>>
>>
>> _______________________________________________
>> flow-tools@splintered.net
>> http://www.splintered.net/sw/flow-tools
>>
>
From maf@splintered.net Sat Nov 29 04:42:22 2003
From: maf@splintered.net (Mark Fullmer)
Date: Fri, 28 Nov 2003 23:42:22 -0500
Subject: [flow-tools] Exporting flows from a 6509
In-Reply-To: <1069347799.934.16.camel@realprod.acns.fsu.edu>
References: <1069347799.934.16.camel@realprod.acns.fsu.edu>
Message-ID: <6C262BE4-2226-11D8-9AA7-000A95DA1C38@splintered.net>
"set mls flow full"
See the flow-tools-examples man page for a little more information.
mark
On Nov 20, 2003, at 12:03 PM, Edson Manners wrote:
> Any one here exporting flows from a 6509?
> I have just enabled NDE on my 6509 using this cisco web page. I am
> collecting the flow on a RH 7.3 box running flow-capture ver 0.64
> http://www.cisco.com/en/US/products/hw/switches/ps708/
> products_configuration_guide_chapter09186a00800f4ffa.html#20485
>
> When I run "show mls nde" I get:
> Netflow Data Export enabled
> Exporting flows to 1xx.xx.xx.xxx (9997)
> Exporting flows from 1xx.xx.xx.xxx (53866)
> Version: 7
> Include Filter not configured
> Exclude Filter not configured
> Total Netflow Data Export Packets are:
> 14742 packets, 0 no packets, 397775 records
> Total Netflow Data Export Send Errors:
> IPWRITE_NO_FIB = 0
> IPWRITE_ADJ_FAILED = 0
> IPWRITE_PROCESS = 0
> IPWRITE_ENQUEUE_FAILED = 0
> IPWRITE_IPC_FAILED = 0
> IPWRITE_MTU_FAILED = 0
> IPWRITE_ENCAPFIX_FAILED = 0
> And I can't see anything wrong with that.
>
> Whe I run "show ip flow export" i get:
> Flow export is enabled
> Exporting flows to 1xx.xx.xxx.xxx (9997)
> Exporting using source interface Loopback0
> Version 5 flow records, origin-as
> 35502729 flows exported in 1209119 udp datagrams
> 0 flows failed due to lack of export packet
> 0 export packets were sent up to process level
> 0 export packets were dropped due to no fib
> 0 export packets were dropped due to adjacency issues
> 0 export packets were dropped due to fragmentation failures
> 0 export packets were dropped due to encapsulation fixup failures
> 0 export packets were dropped enqueuing for the RP
> 0 export packets were dropped due to IPC rate limiting
> That looks good too
>
> But in my flow file I get the following. Make note of the bunch of V7
> flows from the Layer 3-switched PFC with 0.0.0.0 source adresses. I had
> NDE running before without the PFC exporting V7 flows and never got
> those 0.0.0.0 source addresses.
>
> Has anyone else here experienced anything like this? If not would
> anyone
> mind giving me a few pointers as to how they set up NDE on their 6509.
> Thanks a lot.
>
> [root@bfs-test 2003-11-20]# flow-print < tmp-v07.2003-11-20.114501-0500
> | more
> srcIP dstIP router_sc prot
> srcPort dstPort octets packets
> 0/0 68.35.227.73/0 1xx.xx.xx.xxx 0
> 0 0 67111 528
> 0/0 1xx.xx.xxx.xx/0 1xx.xx.xx.xxx 0
> 0 0 216096 398
> 0/0 216.22.100.39/0 1xx.xx.xx.xxx 0
> 0 0 11674 76
> 0/0 1xx.xxx.1.136/0 1xx.xx.xx.xxx 0
> 0 0 180 3
> 68.92.229.25/15 1xx.1xx.2.195/24 0.0.0.0 1
> 0 2048 180 3
> 68.92.229.25/15 1xx.1xx.2.196/24 0.0.0.0 1
> 0 2048 180 3
>
> *IP addresses have been x'ed out to protect the innocent
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
From maf@splintered.net Sat Nov 29 04:52:02 2003
From: maf@splintered.net (Mark Fullmer)
Date: Fri, 28 Nov 2003 23:52:02 -0500
Subject: [flow-tools] Number of flow in one udp session
In-Reply-To: <00a501c3abd4$33e52ea0$1a073cc7@fas.sfu.ca>
References: <00a501c3abd4$33e52ea0$1a073cc7@fas.sfu.ca>
Message-ID:
There isn't much in the flow to indicate why it was exported. It may be
due to inactivity, a TCP FIN bit set, resource exhaustion, or other
hints
in the packet that will cause the netflow code to expire the record
quickly
such as a DNS transaction.
You can use flow-stat or flow-report to aggregate these small flows
together.
Flow-tools uses the time sent from the router. The delays in the export
(not the First and Last timestamp) are due to the router flow inactivity
timeout.
mark
On Nov 15, 2003, at 6:57 PM, Nenad Laskovic wrote:
> Hi,
>
> I've just started to use flow-tools, and there is a couple of things
> that I
> can't figure it out.
>
> There is Netflow of one voip session
>
> Start End Sif SrcIPaddress SrcP DIf
> DstIPaddress DstP P Fl Pkts Octets
>
> 1113.12:26:41.018 1113.12:27:42.718 3 192.168.210.20 17360 1
> 192.168.156.244 17432 17 0 2076 123990
> 1113.12:27:43.534 1113.12:28:47.110 3 192.168.210.20 17360 1
> 192.168.156.244 17432 17 0 2281 135910
> 1113.12:28:47.547 1113.12:29:48.827 3 192.168.210.20 17360 1
> 192.168.156.244 17432 17 0 1407 83318
> 1113.12:29:48.847 1113.12:30:58.675 3 192.168.210.20 17360 1
> 192.168.156.244 17432 17 0 984 57843
> 1113.12:31:00.848 1113.12:32:01.280 3 192.168.210.20 17360 2
> 192.168.156.244 17432 17 0 1378 81787
> 1113.12:33:02.508 1113.12:34:12.404 3 192.168.210.20 17360 2
> 192.168.156.244 17432 17 0 1504 88891
> 1113.12:34:12.425 1113.12:35:13.385 3 192.168.210.20 17360 1
> 192.168.156.244 17432 17 0 1886 112267
> 1113.12:36:22.014 1113.12:37:28.490 3 192.168.210.20 17360 2
> 192.168.156.244 17432 17 0 2262 134865
> 1113.12:37:30.870 1113.12:38:34.290 3 192.168.210.20 17360 2
> 192.168.156.244 17432 17 0 2258 134872
> 1113.12:38:34.307 1113.12:39:45.139 3 192.168.210.20 17360 2
> 192.168.156.244 17432 17 0 2655 158122
> 1113.12:39:45.303 1113.12:40:52.459 3 192.168.210.20 17360 1
> 192.168.156.244 17432 17 0 2314 137130
> 1113.12:40:52.740 1113.12:41:51.676 3 192.168.210.20 17360 1
> 192.168.156.244 17432 17 0 1776 105876
> 1113.12:43:04.020 1113.12:43:07.648 3 192.168.210.20 17360 2
> 192.168.156.244 17432 17 0 117 6887
>
> Why there is some many different flows, when all parameters (IP
> addresses,
> ports, protocol, Dif and Sif) are the same? Dif field is changed a
> couple of
> times, but still there are few groups which all fields are the same.
> Beside "no traffic" time out (which in this case 15sec) and Netflow
> cache
> overflow, what are could be reasons for flow ending that caused
> splitting of
> this session in so many flows?
>
> Second thing, there is time difference between tcpdump traffic traces
> and
> Netflow for the same traffic. For this particular case Netflow
> recorded that
> last packet is
> sent in 12:43:07, while tcpdump says that time of last packet is
> 13:07:05.
> Here is line from tcpdump.
>
> 13:07:05.072609 192.168.210.20.17360 > 192.168.156.244.17840: [no
> cksum] udp
> 32 (ttl 250, id 40572, len 60)
>
> For some other cases there is no differences between Netflow and
> tcpdump
> data. In PPT presentation from
> www.net.ohio-state.edu/security/talks/2000/2000-12-06_osu-flow-
> tools_lisa/
> osu-flow-tools.ppt Mark Fullmer stated that flow
> could be delayed by 30 minutes from start of traffic. What is reason
> for
> that delay?
>
> thank you in advance,
>
> Nenad
>
>
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
From maf@splintered.net Sat Nov 29 04:55:37 2003
From: maf@splintered.net (Mark Fullmer)
Date: Fri, 28 Nov 2003 23:55:37 -0500
Subject: [flow-tools] Spedd of flow-send
In-Reply-To: <32534.1068551704@www21.gmx.net>
References: <32534.1068551704@www21.gmx.net>
Message-ID: <45E62F16-2228-11D8-9AA7-000A95DA1C38@splintered.net>
Is you analyzing station running flow-tools or some other software? If
its the former use FTP, rsync, SCP, etc to move the flow files around.
Flow-send is only required when exporting flow-tools files to some other
software which expects the data in Cisco Netflow format. In general=20
it's
not a good way to move data around because NetFlow is UDP with no=20
retransmissions
or congestion control.
mark
On Nov 11, 2003, at 6:55 AM, Marco Decker wrote:
> hi, i got some problem with sending flows to a analyzing station. i=20
> capture
> flows with flow-capture
> and store the flows in a folder. in this folder are now the stored=20
> flows
>> from 2 weeks collecting.
>
> i send the flows with flow-cat ./ | flow-send 0/xxx.xxx.xxx.xxxx./2055=20=
> to
> the analyzing station.
> it needs more than 2 hours till all datas been send. the files are=20
> stored in
> intervals of 5 minutes and
> have a sice of 40 kb. the cpu of the station where flow-send was=20
> running is
> on 99 % idle also
> the reciving analyzing station. is it possible to hurry up the=20
> tranmission ?
>
> thanks for your answers
>
> marco
>
> --=20
> NEU F=DCR ALLE - GMX MediaCenter - f=FCr Fotos, Musik, Dateien...
> Fotoalbum, File Sharing, MMS, Multimedia-Gru=DF, GMX FotoService
>
> Jetzt kostenlos anmelden unter http://www.gmx.net
>
> +++ GMX - die erste Adresse f=FCr Mail, Message, More! +++
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
>
From maf@splintered.net Sat Nov 29 04:58:09 2003
From: maf@splintered.net (Mark Fullmer)
Date: Fri, 28 Nov 2003 23:58:09 -0500
Subject: [flow-tools] flow-tools logs
In-Reply-To: <200310302121.54765.lorins@assist.ro>
References: <200310302121.54765.lorins@assist.ro>
Message-ID:
It means you lost 30 flows, probably due to network congestion between
the exporter and collector.
(yea, I know it takes me forever reply to e-mail).
mark
On Oct 30, 2003, at 2:21 PM, Lorin Scraba wrote:
> Hello!
> I use flow-tools to log traffic from Cisco3600 and to draw some nice
> mrtg
> graphs. Everything seems ok but i get these messages in
> /var/log/messages:
> 6 dst_ip=172.25.1.1 d_version=5 expecting=343517402 received=343517432
> lost=30
> Oct 30 21:11:34 netwatch flow-capture[1093]: ftpdu_seq_check():
> src_ip=172.25.1.6 dst_ip=172.25.1.1 d_version=5 expecting=343519532
> received=343519562 lost=30
> Oct 30 21:11:57 netwatch flow-capture[1093]: ftpdu_seq_check():
> src_ip=172.25.1.6 dst_ip=172.25.1.1 d_version=5 expecting=343524272
> received=343524302 lost=30
> Oct 30 21:12:01 netwatch flow-capture[1093]: ftpdu_seq_check():
> src_ip=172.25.1.6 dst_ip=172.25.1.1 d_version=5 expecting=343525262
> received=343525292 lost=30
> Oct 30 21:12:13 netwatch flow-capture[1093]: ftpdu_seq_check():
> src_ip=172.25.1.
> What "lost=30" actually mean ?
> 10x in advance
> --
> +Lorin Scraba - Customer Service
> +s.c. ASSIST Software s.r.l.
> +phone no. 0230 - 524020
> -PGP:http://users.assist.ro/~lorins/lorin.gpg
> -BOFH excuse #280: Traceroute says that there is a routing problem in
> the
> backbone. It's not our problem.
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
>
From maf@splintered.net Sat Nov 29 05:35:09 2003
From: maf@splintered.net (Mark Fullmer)
Date: Sat, 29 Nov 2003 00:35:09 -0500
Subject: [flow-tools] error: data version or sub version changed / summary-counters report type
In-Reply-To: <20031029130908.H35921@snow.fingers.co.za>
References: <20031029130908.H35921@snow.fingers.co.za>
Message-ID:
You're mixing NetFlow versions.
Flow-capture should prevent you from doing this, so /path/to/flowfiles
probably has something like v8 and v5 types files in it.
mark
On Oct 29, 2003, at 6:15 AM, fingers wrote:
>
> match dst-ip-addr test-cidr
>
>
> my questions are:
>
> 1) what does "data version or sub version changed!" actually mean?
> 2) can anyone see anything inherently wrong with my configs?
>
> if i change the report type to type
> ip-source/destination-address/ip-source/destination-port i see exactly
> the
> traffic i'm looking for, yet with the type as 'summary-counters' i see
> nothing.
From maf@splintered.net Sat Nov 29 05:41:11 2003
From: maf@splintered.net (Mark Fullmer)
Date: Sat, 29 Nov 2003 00:41:11 -0500
Subject: [flow-tools] host accounting
In-Reply-To: <76481E8C-0A0A-11D8-ABB7-000393ADFFA8@sevenone.com>
References: <76481E8C-0A0A-11D8-ABB7-000393ADFFA8@sevenone.com>
Message-ID:
Unless you need to aggregate multiple IP addresses the tags aren't
necessary,
just use the 'ip-source-address' report.
Also you'll either want to remove your 'fields' line or add the
appropriate
key fields in.
On Oct 29, 2003, at 7:21 AM, matt baker wrote:
> Hello,
>
> Firstly I should say that I'm new to the use of flow-tools, so please
> forgive a possible obvious question. However looking through the
> archives I don't really see this being asked before.
>
> I am trying to account and produce a report for octets in/out for
> individual hosts on a subnet. Lets say the subnet is 192.168.71.0/24
> and I'm after:
> 192.168.71.1 InOctet OutOctet
> 192.168.71.2 InOctet OutOctet
> 192.168.71.3 InOctet OutOctet
> ..etc..
>
>
> Now i'm using the command line:
>
> flow-cat /flows/2003-10-29/ |
> flow-nfilter -f/usr/local/reports/ipdef -Ftest1 |
> flow-tag -t /usr/local/reports/tag -T HOST |
> flow-report -s /usr/local/reports/report -SInOut
>
>
> where:
>
> ipdef
> -------
> filter-primitive onesixeight
> type ip-address-mask
> permit 192.168.71.0 255.255.255.0
>
> filter-definition test1
> match ip-source-address onesixeight
>
>
> tag
> ----
> tag-definition HOST
> term
> action HOST-prefix
>
> tag-action HOST-prefix
> type src-prefix
> match 192.168.71.1/32 set-dst 0x010001
> match 192.168.71.2/32 set-dst 0x010002
> match 192.168.71.3/32 set-dst 0x010003
> match 192.168.71.4/32 set-dst 0x010004
> match 192.168.71.5/32 set-dst 0x010005
> match 192.168.71.6/32 set-dst 0x010006
>
> report
> --------
> stat-report InOut
> type source/destination-tag
> output
> format ascii
> path |/bin/cat
> fields +octets,+packets
> options +header, +xheader, +totals
>
> stat-definition InOut
> report InOut
>
>
> I've tried various report types, but I'm getting the feeling that i'm
> on the wrong track on how this is supposed to be done. Has anyone
> done this before? I'm figuring that once the match's are assigned a
> prefix that you can output based on the prefix. With some of the
> examples it appears I might need further filtering lines in place.
>
>
> thanks for any help,
>
> Regards,
>
> Matt
>
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
>
From maf@splintered.net Sat Nov 29 06:45:52 2003
From: maf@splintered.net (Mark Fullmer)
Date: Sat, 29 Nov 2003 01:45:52 -0500
Subject: [flow-tools] Merging flow-fanout flows removing duplicates
In-Reply-To: <20031016162720.GE17075@weisshuhn.de>
References: <20031016102925.GB17075@weisshuhn.de> <20031016120303.B76196@net.ohio-state.edu> <20031016162720.GE17075@weisshuhn.de>
Message-ID:
I just committed changes so that flow-fanout and flow-capture will
process
SIGTERM like SIGQUIT. Will be available in the next snapshot.
mark
On Oct 16, 2003, at 12:27 PM, Bernhard Weisshuhn wrote:
>
> While I have your attention: I'm running flow-capture as a service
> under daemontools (-D comes in handy for that). Standard method for
> daemontools to bring down a service (svc -d) is to send SIGTERM and
> then
> SIGCONT. flow-capture wants SIGQUIT to properly flush its outputfile
> before terminating, and daemontools svc has no switch to send QUIT.
> Any chance to see the SIGQUIT-Behaviour for SIGTERM too? Or INT
> perhaps?
> Using "svc -hd" (HUP,TERM,CONT) is probably too quick, the file does
> not get flushed or renamed.
>
> http://cr.yp.to/daemontools/svc.html
>
> Anyway, flow-tools are great!
>
> keep up the good work!
> Bernie
>
> _______________________________________________
> flow-tools@splintered.net
> http://www.splintered.net/sw/flow-tools
>
>