From netramet-owner  Thu Feb  4 16:28:23 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id QAA01046
       for netramet-outgoing; Thu, 4 Feb 1999 16:20:56 +1300 (NZDT)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id QAA01005;
       Thu, 4 Feb 1999 16:20:34 +1300 (NZDT)
From: Nevil Brownlee <[email protected]>
To: Juergen Quittek <[email protected]>
Cc: [email protected]
Subject: Re: TCP_ATR, NeTraMet for IPv6?
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Date: Thu, 4 Feb 1999 16:31:05 +1300 (New Zealand Daylight Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk


Hello Juergen:

1) You are correct that 43b7 compiles properly if you define TCP_ATR
  in the makefiles.  I've just put 43b8 on the beta-versions directory,
  which fixes this problem.  Apart from TCP attributes, I'm working
  on implementing the ASN attributes in the linux and PC meters -
  stay tuned!

2) > Is somebody already working on porting NeTraMet to IPv6?
  > The code already contains some preparations IPv6. What would be
  > major issues for the port, if we do not define new attributes?

 There should be no issues - it will mean that the rule address length
 will expand to hold the 16-byte addresses (which will increase the
 meter's memory requirements), and it would probably be nice to have
 the SRL compiler recognise addresses in v6 format.  I'll try to do it
 in either 43b9 or 43b10.  However, I'll need one or two v6 test sites -
 would anyone who can help with this please send me a note .. :-?

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P


From netramet-owner  Thu Feb  4 16:35:19 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id QAA02980
       for netramet-outgoing; Thu, 4 Feb 1999 16:33:54 +1300 (NZDT)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id QAA02968;
       Thu, 4 Feb 1999 16:33:46 +1300 (NZDT)
From: Nevil Brownlee <[email protected]>
To: Simon Lane <[email protected]>
Cc: [email protected]
Subject: Re: NeTraMet OC3MON
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Date: Thu, 4 Feb 1999 16:44:18 +1300 (New Zealand Daylight Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk


Hello Simon:

> I am therefore starting to look at the OC3MON version of the meter.
> Ideally, I would like this on unix - for which I guess we use FreeBSD.
>
> My understanding of the requirements is a little vague at present, so I
> would be most greatful for some comments of the following points.
>
>   http://moat.nlanr.net.OC3mon-monitors specifies what appears to be a
>   relatively standard (but rack-mount) PC with two FORE PCA-200E ATM
>   cards. I would probably use a free standing PC instead - presumably,
>   the exact motherboard SCSI adapter etc are not critical?
>
>   I assume that to build the meter, I install FreeBSD (and compilers
>   etc) on the PC, then install the ATM Device Drivers as specified in
>   the Coral-1.1 Installation Notes.
>
>   Then I install Libpcap and NeTraMet in the usual way, compiling with
>   GNU-C. Presumably also, the Configure scripts detect the ATM cards,
>   and build the appropriate executables.
>
> Would welcome your comments on how easy this process has been in
> practice.

Right now there are very few (only one or two) sites running the OC3MON
version of NeTraMet, and they're doing it using the good old DOS OCxMON
meter.  If you care to try this, the release file is in the beta-versions
directory of the ftp site(s).

The CAIDA people are just starting to port the unix meter into the Coral
meter environment; this should be straightforward, and the procedure
you've set out above should work OK.  Real soon now my colleagues at
Waikato will have their Dag ATM cards available, with FreeBSD drivers.
At that point I'll do some testing of the Coral NeTraMet ...

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P


From netramet-owner  Fri Feb  5 00:06:26 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA29097
       for netramet-outgoing; Fri, 5 Feb 1999 00:05:35 +1300 (NZDT)
Received: from jess.glam.ac.uk (jess.glam.ac.uk [193.63.147.97])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id AAA29091
       for <[email protected]>; Fri, 5 Feb 1999 00:05:28 +1300 (NZDT)
Received: from [193.63.150.65] (helo=ems2.glam.ac.uk)
       by jess.glam.ac.uk with esmtp (Exim 2.11 #1)
       id 108MWt-0005mB-00
       for [email protected]; Thu, 4 Feb 1999 11:01:03 +0000
Received: by EMS2 with Internet Mail Service (5.5.2232.9)
       id <ZKL1JLSB>; Thu, 4 Feb 1999 11:07:16 -0000
Message-ID: <EB62C0C34246D111A39A00805FA6A855A24E82@EMS2>
From: "Shaw M M (ISaCS)" <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: NetFlowMet - Cisco Netflow version
Date: Thu, 4 Feb 1999 11:07:14 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [email protected]
Precedence: bulk

Hello,
We currently have Netflow version 1 available on a Cisco Catalyst 5000.
Has Netflow version 1 been found to be satisfactory for using NetFlowMet or
do we need to upgrade to either version 5 or 7?
Thankyou,


Malcolm M Shaw
Network Services Group
ISaCS
University of Glamorgan

[email protected]
Direct  01443 482940
FAX     01443 482424


From netramet-owner  Fri Feb  5 00:23:51 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA29843
       for netramet-outgoing; Fri, 5 Feb 1999 00:23:36 +1300 (NZDT)
Received: from mailgw.wm.net (mailgw.wm.net [194.18.224.214])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id AAA29837
       for <[email protected]>; Fri, 5 Feb 1999 00:23:30 +1300 (NZDT)
Received: from wmbro1si0112.wmdata.com (wmbro1si0112.wm.net [164.9.151.108])
       by mailgw.wm.net (8.9.1a/8.9.1) with ESMTP id MAA07758
       for <[email protected]>; Thu, 4 Feb 1999 12:23:49 +0100 (MET)
Received: by wmbro1si0112.wm.net with Internet Mail Service (5.5.2232.9)
       id <11RWGQHZ>; Thu, 4 Feb 1999 12:23:26 +0100
Message-ID: <[email protected]>
From: =?iso-8859-1?Q?F=E4ltman=2C_Mikael?= <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Platform recommendation
Date: Thu, 4 Feb 1999 12:23:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
       charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk

Hello !

We are just about to test NetRaMet.=20
Seems to me that it is a wonderful piece of work.
I have been running Linux (Debian and Redhat) for 3 years
so I have good knowledge of these systems.

Initially we want to use NetRaMet on FastEthernet and Ethernet.
What platform is recommended to use ?
Unix [Linux vs. FreeBSD], DOS ?
Are there any recommendations concerning NICs ?

We also want to test to connect NetRaMet between a Cisco router and
a FrameRelay switch (V.35 - 2 Mbits). The switch (Passport) and the =
routers
are
in the same building.
Is this possible ? Has anyone tested this ?


Thanks for any replay

---
Mikael F=E4ltman ([email protected])
Network Services
WM-data Infrastruktur AB, BOX 164, S-295 22 BROMOLLA


From netramet-owner  Fri Feb  5 01:51:27 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA02922
       for netramet-outgoing; Fri, 5 Feb 1999 01:50:56 +1300 (NZDT)
Received: from nosc.ja.net (nosc.ja.net [128.86.16.20])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id BAA02914
       for <[email protected]>; Fri, 5 Feb 1999 01:50:48 +1300 (NZDT)
Received: from nosc.ja.net by nosc.ja.net with Internet SMTP
         id <[email protected]>; Thu, 4 Feb 1999 12:50:31 +0000
To: "Shaw M M (ISaCS)" <[email protected]>
cc: "'[email protected]'" <[email protected]>
Subject: Re: NetFlowMet - Cisco Netflow version
In-reply-to: Your message of "Thu, 04 Feb 1999 11:07:14 GMT." <EB62C0C34246D111A39A00805FA6A855A24E82@EMS2>
Date: Thu, 04 Feb 1999 12:50:24 +0000
Message-ID: <[email protected]>
From: Kevin Hoadley <[email protected]>
Sender: [email protected]
Precedence: bulk

> We currently have Netflow version 1 available on a Cisco Catalyst 5000.
> Has Netflow version 1 been found to be satisfactory for using NetFlowMet or
> do we need to upgrade to either version 5 or 7?

It all rather depends what you want to do !

If you are just doing network/protocol/port number analysis, netflow version
1 export should be sufficient.

(I note that you are JANET user; the JANET transatlantic charging system
uses NetFlowMet with NetFlow version 1, whilst the LINX accounting uses
NetFlowMet with NetFlow version 5 export. Different applications, different
requirements -> different version of NetFlow)

Kevin Hoadley.

From netramet-owner  Fri Feb  5 23:31:56 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA02996
       for netramet-outgoing; Fri, 5 Feb 1999 23:25:46 +1300 (NZDT)
Received: from mailgw.wm.net (mailgw.wm.net [194.18.224.214])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id XAA02989
       for <[email protected]>; Fri, 5 Feb 1999 23:25:41 +1300 (NZDT)
Received: from wmbro1si0112.wmdata.com (wmbro1si0112.wm.net [164.9.151.108])
       by mailgw.wm.net (8.9.1a/8.9.1) with ESMTP id LAA01084
       for <[email protected]>; Fri, 5 Feb 1999 11:26:02 +0100 (MET)
Received: by wmbro1si0112.wm.net with Internet Mail Service (5.5.2232.9)
       id <11RWGQRX>; Fri, 5 Feb 1999 11:25:40 +0100
Message-ID: <[email protected]>
From: =?iso-8859-1?Q?F=E4ltman=2C_Mikael?= <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: FW: Platform recommendation
Date: Fri, 5 Feb 1999 11:25:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
       charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk

Since nobody care to answer mabe someone could point
me to a URL with this type of informtaion.

/Thanks

---
Mikael F=E4ltman ([email protected])
Network Services
WM-data Infrastruktur AB, BOX 164, S-295 22 BROMOLLA

> -----Original Message-----
> From: F=E4ltman, Mikael [SMTP:[email protected]]
> Sent: den 4 februari 1999 12:23
> To:   '[email protected]'
> Subject:      Platform recommendation
>=20
> Hello !
>=20
> We are just about to test NetRaMet.=20
> Seems to me that it is a wonderful piece of work.
> I have been running Linux (Debian and Redhat) for 3 years
> so I have good knowledge of these systems.
>=20
> Initially we want to use NetRaMet on FastEthernet and Ethernet.
> What platform is recommended to use ?
> Unix [Linux vs. FreeBSD], DOS ?
> Are there any recommendations concerning NICs ?
>=20
> We also want to test to connect NetRaMet between a Cisco router and
> a FrameRelay switch (V.35 - 2 Mbits). The switch (Passport) and the
> routers
> are
> in the same building.
> Is this possible ? Has anyone tested this ?
>=20
>=20
> Thanks for any replay
>=20
> ---
> Mikael F=E4ltman ([email protected])
> Network Services
> WM-data Infrastruktur AB, BOX 164, S-295 22 BROMOLLA

From netramet-owner  Mon Feb  8 09:03:14 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id IAA07138
       for netramet-outgoing; Mon, 8 Feb 1999 08:58:41 +1300 (NZDT)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id IAA07084;
       Mon, 8 Feb 1999 08:58:29 +1300 (NZDT)
From: Nevil Brownlee <[email protected]>
To: [email protected]
Cc: NeTraMet mailing list <[email protected]>
Subject: Re: Platform recommendation
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Date: Mon, 8 Feb 1999 09:10:34 +1300 (New Zealand Daylight Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk


Hello Mikael:

> Initially we want to use NetRaMet on FastEthernet and Ethernet.
> What platform is recommended to use ?
> Unix [Linux vs. FreeBSD], DOS ?
> Are there any recommendations concerning NICs ?

As usual, it all depends on what you're trying to do.

If you want to run several meters at different places around your network,
the DOS meter will be the cheapest.  I'd suggest a 166 Mhz Pentium or K6
machine with a 10/100 Ethernet card (the meter can handle up to four
Ethernet cards).  The only issue about choosing an Ethernet card is that
for DOS you need one which has a Packet Driver - my current favourite is
the DEC DE500, using the CRYNWR 21140 (tulip) Pakcte Driver.

If you only want one meter, and/or if you'd rather run the meter under
Unix so as to make it easier to maintain (i.e. install new meter releases)
then the Unix meter is propbably better.  I'd stick with whatever is your
favourite Unix system - I use Debian Linux for most of my testing, as
well as Solaris and Irix systems, recently there's been a lot of interest
in using NeTraMet on FreeBSD systems, and on DEC Unix on Alphas.  The
choice of Unix platform really doesn't matter very much.  As for
interface cards, as long as you have Unix/Linux drivers for it (which
will work properly with libpcap) again it doesn't matter.

You should use the 4.3 version of NeTraMet - the current level of this is
                                  *^*
in the beta-versions directory on the ftp sites.

> We also want to test to connect NetRaMet between a Cisco router and
> a FrameRelay switch (V.35 - 2 Mbits). The switch (Passport) and the routers
> are in the same building.
> Is this possible ? Has anyone tested this ?

You mean, tap the Frame Relay link and watch the frames passing by on it?
I haven't tried doing this, and I  don't know of anyone else doing so.
It would require a special Frame Relay driver on the meter to extract the
frames.  If you can identify packets going to/from the switch, e.g. by
their Source/Dest peer addresses, and there's somewhere else on your
network where you could put a meter so as to see the traffic going
through the switch, you could write a ruleset to select out the switch
traffic.  Failing that, maybe you could use Cisco's NetFlow to collect
data (using NetFlowMet) for the router's Frame Relay port ?

Hope this helps, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P


From netramet-owner  Mon Feb  8 12:57:15 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id MAA11247
       for netramet-outgoing; Mon, 8 Feb 1999 12:56:32 +1300 (NZDT)
Received: from mako.netlink.co.nz (mako.netlink.co.nz [202.20.93.10])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id MAA11238;
       Mon, 8 Feb 1999 12:56:27 +1300 (NZDT)
Received: from angel.office.netlink.net.nz (angel.office.netlink.net.nz [203.97.244.128]) by mako.netlink.co.nz (8.8.6/8.8.6)
        with ESMTP id MAA18926; Mon, 8 Feb 1999 12:56:27 +1300 (NZDT)
Received: from lemon.office.netlink.net.nz ([203.97.244.37]) by angel.office.netlink.net.nz with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
       id DQ8XXAYH; Mon, 8 Feb 1999 12:44:48 +1300
Date: Mon, 8 Feb 1999 12:56:26 +1300 (NZDT)
From: Daniel Ayers <[email protected]>
To: Nevil Brownlee <[email protected]>
cc: [email protected], NeTraMet mailing list <[email protected]>
Subject: Re: Platform recommendation
In-Reply-To: <[email protected]>
Message-ID: <Pine.GSO.4.00.9902081231280.11698-100000@lemon.office.netlink.net.nz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk


Nevil,

>From my experience, I need to take a dissenting view on some of your
recommendations about the best platform to use for NeTraMet.

> If you want to run several meters at different places around your network,
> the DOS meter will be the cheapest.

I don't recommend using the DOS meters over WANs, on busy networks or in
an environment where the quality of the collected data is paramount.
They're fine if all you want to do is work out the proportions of WWW,
mail, FTP, etc traffic in your traffic (ie. the proportions rather than
the absolute values are important, packet loss etc won't matter) then
that's OK.

We used DOS meters for a long time.  We had two sets of meters in each
location (primary and secondary - for redundancy).  The primary set was
collected from Wellington, the secondary from Auckland (redundancy again).
I've noticed that the greater the "distance" (topologically speaking,
particularly on WANs) between meter and collector, the worse the quality
of data.

Primary meters in Wellington (which were collected via Ethernet in
Wellington) always showed more traffic (and a better quality traffic
profile) than the secondary equivalent which was collected from Auckland
over (a very lightly-loaded 1.5mb) Frame Relay.

Solution: Run the UNIX meter and run NeTraMet and NeMaC on the same
machine.  This also prevents transient network problems (outages,
bottlenecks, routing problems) from breaking the system.

> If you only want one meter, and/or if you'd rather run the meter under
> Unix so as to make it easier to maintain (i.e. install new meter releases)
> then the Unix meter is propbably better.

I believe the UNIX solution is better, because:

1. You can run the meter and collector on the same machine, eliminating
the capacity/reliability of the intermediate network as a factor in data
quality.

2. You have better visibility of the meter - it's a process on your system
that you can look at, stop, restart, etc.

3. A good UNIX network stack tends to be more robust than its DOS
equivalent, and has better performance.

> I'd stick with whatever is your favourite Unix system - I use Debian
> Linux for most of my testing, as well as Solaris and Irix systems,
> recently there's been a lot of interest in using NeTraMet on FreeBSD
> systems, and on DEC Unix on Alphas.  The choice of Unix platform
> really doesn't matter very much.

I have to strongly disagree here.

Linux is not a good choice in a busy network environment.  Linux's
promiscuous network monitoring code is not very efficient.  The folks at
NFR (Network Flight Recorder, a system that monitors/records/analyses
network activity) have noticed problems with Linux's network tapping
ability and do not recommend its use in such applications.

For further information:

http://www.nfr.net/nfr/nfr-2.0.2-research/NFR_FAQ.html#linux

The general wisdom on this one is to use a BSD-derived system that
supports BPF (Berkely Packet Filters).

I'm still tuning our meters (P-II 350MHz running FreeBSD 2.2.8) and I'm
seeing a little bit of loss (0.015%) on our busiest network segments.  But
that is still much better than the loss levels for the old DOS meters.


Naturally, different people have different requirements from a tool like
NeTraMet.  In our situation, we bill from the collected data so it needs
to be (a) accurate and (b) complete.  We also have some pretty busy
segments.  My comments should be read in that context.  Someone who has
less stringent requirements can probably afford to be less careful about
the choice of platform they use.

Another point - if you deploy something like NeTraMet and you care about
the accuracy of the data it gives you, you need to check it carefully.
It's easy to "grab your favourite OS" (say, Linux) on a box with some
ordinary network card (eg. a 16 bit ISA NE2000 clone)  and set it up, and
believe the data it gives you.  Linux might not be keeping up with your
network, your card/driver combo might be lossy, there could be all sorts
of things wrong and you'd never know ...

NeTraMet is a great tool, but there is frequently a big difference between
"getting it going" and "producing accurate data".  There are lots of
gotchas.  Beware. :-)

D.


------------------------------------------------------------------------------
Daniel Ayers, B.Sc (Hons), M.Sc              Email: [email protected]
Network Security Specialist              DDI Phone: +64-4-916-5622
Netlink                                        Fax: +64-4-916-5300
23 Waring Taylor St, PO Box 5358            Mobile: +64-21-387-334
Wellington, New Zealand                        URL: http://www.netlink.co.nz


From netramet-owner  Mon Feb  8 22:58:53 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id WAA02498
       for netramet-outgoing; Mon, 8 Feb 1999 22:56:09 +1300 (NZDT)
Received: from mulder.pacific.co.nz (mulder.pacific.co.nz [203.97.86.3])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id WAA02493
       for <[email protected]>; Mon, 8 Feb 1999 22:56:06 +1300 (NZDT)
Received: from bart.emedia.co.nz.41.97.203.in-addr.arpa (onramp.gilmourmotors.co.nz [203.97.85.74])
       by mulder.pacific.co.nz (8.8.5/8.8.5) with SMTP id WAA16217
       for <[email protected]>; Mon, 8 Feb 1999 22:03:59 +1300
Received: by bart.emedia.co.nz.41.97.203.in-addr.arpa with Microsoft Mail
       id <[email protected]>; Mon, 8 Feb 1999 22:59:00 +1300
Message-ID: <[email protected]>
From: Andrew Frazer <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Any other way of measuring traffic with Netramet and Cisco?
Date: Mon, 8 Feb 1999 22:58:59 +1300
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Does any one know of, or has measured traffic with smaller Cisco Switches and routers (ie Cat 1900s or 2500 series routers? )



From netramet-owner  Tue Feb  9 04:19:36 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id EAA15272
       for netramet-outgoing; Tue, 9 Feb 1999 04:18:37 +1300 (NZDT)
Received: from riegeler.inm.de (ns.inm.de [195.20.81.35])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id EAA15266
       for <[email protected]>; Tue, 9 Feb 1999 04:18:32 +1300 (NZDT)
Received: from sol.inm.de (sol.inm.de [195.20.81.34])
       by riegeler.inm.de (8.9.1/8.9.1) with ESMTP id QAA11670
       for <[email protected]>; Mon, 8 Feb 1999 16:17:59 +0100
Received: from viagra.inm.de (viagra.inm.de [195.20.81.52])
       by sol.inm.de (8.9.1/8.9.1) with ESMTP id QAA14627
       for <[email protected]>; Mon, 8 Feb 1999 16:17:59 +0100 (CET)
Received: from inm.de ([195.20.81.220]) by viagra.inm.de
         (Netscape Messaging Server 3.5)  with ESMTP id AAA5A47;
         Mon, 8 Feb 1999 16:17:52 +0100
Message-ID: <[email protected]>
Date: Mon, 08 Feb 1999 16:17:45 +0100
From: Markus Fix <[email protected]>
Organization: INM
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Frazer <[email protected]>, [email protected]
Subject: Re: Any other way of measuring traffic with Netramet and Cisco?
References: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Andrew Frazer wrote:
>
> Does any one know of, or has measured traffic with smaller Cisco Switches
> and routers (ie Cat 1900s or 2500 series routers? )

Yes, we use this for cross referencing purposes here. We adapted the
perl
skripts of Roger Watt from the University of Waterloo.
You can find them at http://watserv1.uwaterloo.ca/~rwwatt/ip-accounting/
They read the CISCO accounting logs and create usage reports.
You won't be able to see protocol specific flows though. This was the
main
reason for us to switch to netramet.

Here a some sample output:
------------------------------------------------------------------
1999-02-07 link utilization:     328 MB total traffic for day

  link                      hours                      hours
 speed              MB       link              MB       link
  Mbps            sent    sending        received  receiving
 -----        --------  ---------        --------  ---------
 0.193              55        0.6             273        3.1

23 internal addresses, 346 external networks

external         %day      MB   sent    rcvd
-------------   -----   -----   ----   -----
194.64.25.0     77.77   254.7   18.9   235.8
194.195.240.0    4.76    15.6    2.0    13.6
206.184.92.0     2.04     6.7    0.1     6.6
62.0.0.0         1.56     5.1    4.5     0.6
194.25.2.0       0.49     1.6    1.5     0.1
195.126.151.0    0.39     1.3    1.2     0.1
198.41.0.0       0.34     1.1    0.1     1.0
141.2.0.0        0.29     1.0    0.7     0.2
150.216.0.0      0.30     1.0    0.9     0.0
195.20.82.0      0.32     1.0    0.4     0.6
192.203.230.0    0.26     0.9    0.1     0.8
193.0.14.0       0.27     0.9    0.1     0.8
202.12.27.0      0.27     0.9    0.1     0.8
209.185.222.0    0.26     0.9    0.4     0.4
198.32.64.0      0.23     0.8    0.1     0.7
205.188.154.0    0.23     0.7    0.6     0.1
209.249.159.0    0.20     0.7    0.6     0.0
152.163.0.0      0.19     0.6    0.6     0.1
193.158.131.0    0.17     0.6    0.5     0.1
193.158.141.0    0.18     0.6    0.5     0.1

internal                     %day      MB   sent    rcvd
-------------------------   -----   -----   ----   -----
ns                          82.53   270.3   23.8   246.5
www                          5.18    17.0   15.2     1.7
prozac                       3.22    10.6    0.1    10.4
erdinger                     2.37     7.7    0.7     7.0
www.radiox.de                1.83     6.0    5.7     0.3
www.mercedes.frankfurt.de    1.61     5.3    4.5     0.8
preview2                     1.00     3.3    2.8     0.4
sol                          0.73     2.4    0.5     1.9
anubis                       0.60     2.0    0.1     1.8
isis                         0.52     1.7    0.6     1.1
tuborg                       0.20     0.7    0.1     0.6
www.cyberscape.de            0.11     0.3    0.3     0.0
fagcomp                      0.07     0.2    0.2     0.0
angie                        0.01     0.0    0.0     0.0
dab                          0.00     0.0    0.0     0.0
exchange                     0.01     0.0    0.0     0.0
fag                          0.01     0.0    0.0     0.0
flens                        0.00     0.0    0.0     0.0
mars                         0.00     0.0    0.0     0.0
osiris                       0.01     0.0    0.0     0.0

subnet          %day      MB   sent    rcvd
-----------   ------   -----   ----   -----
195.20.81.0   100.00   327.5   54.8   272.8

orgunit    %day     MB    sent   rcvd
-------   -----   ----   -----   ----
100.00   327.5   54.8   272.8

-----------------------------------------------------------------------

Hope this helps.

-fix

--
Markus Fix (networks & security)        INM
[email protected] (PGP key on request)         Daimlerstrasse 32
http://www.inm.de/people/fix/           60314 Frankfurt a.M.,Germany
********** The best defense against logic is ignorance. ************

From netramet-owner  Tue Feb  9 16:59:32 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id QAA19561
       for netramet-outgoing; Tue, 9 Feb 1999 16:56:01 +1300 (NZDT)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id QAA19549
       for <netramet@auckland>; Tue, 9 Feb 1999 16:55:58 +1300 (NZDT)
From: Nevil Brownlee <[email protected]>
To: [email protected]
Subject: RE: Any other way of measuring traffic with Netramet and Cisco?
Message-ID: <[email protected]>
Date: Tue, 9 Feb 1999 17:08:13 +1300 (New Zealand Daylight Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk

--- Begin Forwarded Message ---
From: "Limor Schweitzer" <[email protected]>
To: <[email protected]>
Subject: RE: Any other way of measuring traffic with Netramet and Cisco?
Date: Mon, 8 Feb 1999 15:27:47 +0200
In-Reply-To: <[email protected]>

We've done measurements using MIB2, CISCO IOS Accounting and
NetFlow (also using other equipment and servers).
We have some results about to the differences
between MIB2 interface counters and NetFlow.
I'm not sure this is of interest to the group so
pls send me an email if you want more info.


Limor Schweitzer


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Andrew Frazer
> Sent: Monday, February 08, 1999 11:59 AM
> To: '[email protected]'
> Subject: Any other way of measuring traffic with Netramet and Cisco?
>
>
> Does any one know of, or has measured traffic with smaller Cisco
> Switches and routers (ie Cat 1900s or 2500 series routers? )
>
>
--- End Forwarded Message ---


From netramet-owner  Wed Feb 10 04:21:27 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id EAA23802
       for netramet-outgoing; Wed, 10 Feb 1999 04:19:39 +1300 (NZDT)
Received: from oscar.broadcom.ie (oscar.broadcom.ie [192.107.110.20])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id EAA23793
       for <[email protected]>; Wed, 10 Feb 1999 04:19:34 +1300 (NZDT)
Received: from broadcom.ie (pc43.broadcom.ie [192.107.110.143])
       by oscar.broadcom.ie (8.8.8/8.8.8) with ESMTP id PAA07756
       for <[email protected]>; Tue, 9 Feb 1999 15:16:58 GMT
Message-ID: <[email protected]>
Date: Tue, 09 Feb 1999 15:26:56 +0000
From: Adrian Newcombe <[email protected]>
Organization: Broadcom Eireann Research Ltd.
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: netramet-list <[email protected]>
Subject: Filtering flows on TOS Byte
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi,

Is it possible to classify flows based on the Type of
Service field in the IP header using NeTraMet? It doesn't
appear in the documentation. If not, is it planned to do so
?

Thanks,
Adrian.

--
Adrian Newcombe,
Lead Researcher,
Broadcom Eireann Research Ltd., Kestrel House,
Clanwilliam Place, Dublin 2, Ireland.
Voice   : +353 1 604 6000   Fax     : +353 1 676 1532
Email   : [email protected]   http://www.broadcom.ie/



From netramet-owner  Thu Feb 11 09:11:30 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id JAA25543
       for netramet-outgoing; Thu, 11 Feb 1999 09:08:28 +1300 (NZDT)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id JAA25507;
       Thu, 11 Feb 1999 09:08:14 +1300 (NZDT)
From: Nevil Brownlee <[email protected]>
To: Nicolai Guba <[email protected]>
Cc: NeTraMet mailing list <[email protected]>,
       RTFM Mailing list <[email protected]>
Subject: Re: Filtering flows on TOS Byte
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Date: Thu, 11 Feb 1999 09:20:38 +1300 (New Zealand Daylight Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk


Hello all:

Several people have asked recently about NeTraMet and the TOS byte ..

>   Adrian> Is it possible to classify flows based on the Type of
>   Adrian> Service field in the IP header using NeTraMet? It doesn't
>   Adrian> appear in the documentation. If not, is it planned to do so
>
>   Nicolai> I'd like to know too whether this is possible.
>
>   Matt> Is there a meter that can distinguish flows based on the
>   Matt> Differentiated Services Byte (or TOS or ...)?  I've been asked
>   Matt> to help the QBone folks here with measuring the QBone, and
>   Matt> being able to distinguish DiffServ flows would be really nifty.
>   Matt> From my quick scan of your "new attributes" document, "you"
>   Matt> have thought about this, since it mentions DS.

The answer is yes, as follows ..

I put it into the 'New Attributes' I-D as DiffServ emerged, and I put a
couple of days into implementing it last week.  The attribute is called
DSCodePoint and it's included in the 4.3b8 release (which is on the ftp
sites now).

Comment: Implementing this was non-trivial, since 'to' and 'from' flows
could easily use different codepoints. It would be nice to have
'toDScodepoint' and 'fromDScodepoint,' but that would require both
codepoints to be available in all 'to' and 'from' packets - and of course
it isn't!

4.3b8 is stable and reliable (I've been using it for several weeks now),
and I'm keen to help people get going with the DSCodePoint attribute.  If
anyone needs help with rulesets (SRL programs) for this, please send
details of what you're intending to do to the NeTraMet list, and I'll be
happy to help!

Over the last six months I've been working on TCP-valued attributes,
and these are included in 4.3b8.  I'm gathering experience in using them,
and intend to produce detailed documentation real soon now, which I'll
post to the RTFM and NeTraMet lists.

The development schedule for NeTraMet4.3 is
  4.3b9   Source/Dest ASN computed by the meter (making this available
          to the Unix and DOS meters, not just NetFLowMet)
  4.3b10  IPv6 implementation.

  4.3     Documentation update, including a new document, "Getting
          Started with NeTraMet."

It's hard to set dates for these, but I'm aiming to get 43b10 onto the
ftp sites before the end of March 99.

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P


From netramet-owner  Sun Feb 14 22:05:29 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id WAA05927
       for netramet-outgoing; Sun, 14 Feb 1999 22:02:19 +1300 (NZDT)
Received: from xacct.com ([207.232.39.209])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id WAA05919
       for <[email protected]>; Sun, 14 Feb 1999 22:02:12 +1300 (NZDT)
Received: from limor ([199.203.132.241])
       by xacct.com (8.8.7/8.8.7) with SMTP id LAA13305;
       Sun, 14 Feb 1999 11:01:27 +0200
From: "Limor Schweitzer" <[email protected]>
To: <[email protected]>
Subject: (Re) Any other way of measuring traffic with Netramet and Cisco?
Date: Sun, 14 Feb 1999 11:01:30 +0200
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
       charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [email protected]
Precedence: bulk


> > [mailto:[email protected]]On Behalf Of Andrew Frazer
> > Sent: Monday, February 08, 1999 11:59 AM
> > To: '[email protected]'
> > Subject: Any other way of measuring traffic with Netramet and Cisco?
> >
> > Does any one know of, or has measured traffic with smaller Cisco
> > Switches and routers (ie Cat 1900s or 2500 series routers? )
> >
> From: "Limor Schweitzer" <[email protected]>
> To: <[email protected]>
> Subject: RE: Any other way of measuring traffic with Netramet and Cisco?
> Date: Mon, 8 Feb 1999 15:27:47 +0200
> In-Reply-To: <[email protected]>
>
> We've done measurements using MIB2, CISCO IOS Accounting and
> NetFlow (also using other equipment and servers).
> We have some results about to the differences
> between MIB2 interface counters and NetFlow.
> I'm not sure this is of interest to the group so
> pls send me an email if you want more info.
>
>


I got quite a few "want more info" replies,
so I'm posting it on the list.
The following was written by Tal Givoly <[email protected]>.



Using XACCTusage at a major University on a border router, XACCT engineers
have compared interface traffic volume statistics collected from
NetFlow-enabled routers with that obtained from MIB-II ifentry counters. The
initial motiviation of this comparison was to determine if there was any
data loss from Netflow UDP datagram transmission to XACCTusage gatherers.
The results of tests at the university were confirmed at additional customer
installations as well as XACCT's engineering lab.  Overall, the behaviour
observed and described in this analysis was consistent across the various
test sites.

XACCTusage is based on a flexible, modular architecture that allows
installation of different modules to collect
accounting data from various network equipment and application servers.
There were three modules that are used in this comparison:

* Cisco IOS Accounting - Collects from Cisco IOS's IP Accounting feature.
Most Cisco routers support this feature, and it provides XDRs (XACCT Detail
Records) to be generated on sessions from Source IP to Destination IP,
including start, end, number of bytes and number of packets for each
session.
* Cisco NetFlow Switching - Collects data from NetFlow-enabled devices
(currently supporting V1 and V5 of NetFlow, but V7 and V8 are in late
stages of development). The data can further be filtered and aggregated
using many aggregation schemes with configurable parameters.
* MIB-II - A module that collects accounting data from any device
supporting SNMP MIB-II. Most routing devices support this interface and
allow collecting aggregate total bytes traversing an interface.

The Cisco IOS Accounting and the Cisco NetFlow Switching, count aggregated
IP traffic. Both reach the same figures when compared for
SourceIP-Destination IP traffic over a long-enough time frame. This is
required, since the NetFlow performs some inherent aggregation, and the
sampling of the IP-matrix causes some aggregations as well, the comparisons
we observed have not reached 100% accuracy, but they reach 99% accuracy over
sufficiently long time-frames. This discussion, therefore, deals with a
NetFlow/MIB-II comparison only, since IP Accounting cannot be compared with
MIB-II, because there is no information regarding interface, unless it is
turned on for only a single interface in question).

During inital trials it appeared that NetFlow would did account for all the
data that crosses the interface. This is logical, because NetFlow accounts
only for layer-3, while MIB-II counters include all layer-2 data. So
NetFlow, for instance, would not account for TCP retransmissions, nor would
it account for TCP/UDP headers, or TCP socket setup, while the MIB-II would
account for all these. Also, NetFlow accounts for IP data, in cases where
other protocols are used on the respective interface, MIB-II would account
for non-IP data, causing another difference in measurement to appear.

Our results showed that NetFlow always accounts for less data than actually
crosses the interface (obvious from our previous discussion), but that he
percentage it accounted for depended on the physical transport. If the link
was a serial T3 link, NetFlow would acocunt for ~95% of the data. If on the
other hand, the link was ATM or FDDI, the NetFlow-collected data would
account for ~80-85% of the data.

CAVEAT: Although we haven't conducted in-depth research to quantify the
precise causes of the differences, we suggest the following factors
logically explain the differences between MIB-II counters and Netflow
statistics:

* The type of the session (each session can have different overhead) - and
thus, the distribution of the sessions. DNS requests, HTTP sessions,
long/short FTP transfers, video-conferencing, VoIP, all have different
effect on the difference in the measurements.
* The congestion of the network - at any point. Since retransmissions of
TCP packets, caused, in part, due to congestion are not accounted for in
NetFlow, a congestion in any part of the network, warranting a retransmit
on the interface in question would be accounted for by MIB-II ifentry, but
not by NetFlow - causing an increase in difference between measurements.
* The interface type - IP over ATM has an inherent overhead that is more
substantial than IP used on T3 links, etc.
* Non-IP traffic - As mentioned above, this type of traffic is not
accounted for by NetFlow or IP Accounting, but is by MIB-II. If present on
the interface, it would affect the comparison.


---------------
More in-depth research on the subject is currently in progress.

Regards,

Limor Schwetizer
CTO
XACCT Technologies


From netramet-owner  Sun Feb 14 23:37:48 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA08224
       for netramet-outgoing; Sun, 14 Feb 1999 23:37:21 +1300 (NZDT)
Received: from fep2-orange.clear.net.nz (fep2-orange.clear.net.nz [203.97.32.2])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id XAA08219
       for <[email protected]>; Sun, 14 Feb 1999 23:37:19 +1300 (NZDT)
Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep2-orange.clear.net.nz (1.5/1.9) with ESMTP id XAA15364; Sun, 14 Feb 1999 23:36:05 +1300 (NZDT)
Received: (from jabley@localhost)
       by buddha.clear.net.nz (8.9.2/8.9.1) id XAA27523;
       Sun, 14 Feb 1999 23:36:05 +1300 (NZDT)
       (envelope-from jabley)
Date: Sun, 14 Feb 1999 23:36:05 +1300
From: Joe Abley <[email protected]>
To: Limor Schweitzer <[email protected]>
Cc: [email protected], [email protected], [email protected]
Subject: Re: (Re) Any other way of measuring traffic with Netramet and Cisco?
Message-ID: <[email protected]>
References: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
In-Reply-To: <[email protected]>; from Limor Schweitzer on Sun, Feb 14, 1999 at 11:01:30AM +0200
Sender: [email protected]
Precedence: bulk

Hi Limor,

On Sun, Feb 14, 1999 at 11:01:30AM +0200, Limor Schweitzer wrote:
>
> The following was written by Tal Givoly <[email protected]>.
>
>  [snip!]
>
> During inital trials it appeared that NetFlow would did account for all the
> data that crosses the interface. This is logical, because NetFlow accounts
> only for layer-3, while MIB-II counters include all layer-2 data. So
> NetFlow, for instance, would not account for TCP retransmissions, nor would
> it account for TCP/UDP headers, or TCP socket setup, while the MIB-II would
> account for all these.

Why do you say that NetFlow doesn't count packets which are TCP
retransmissions or TCP establishment/teardowns?

I _think_ (no, I _hope_ :) this is incorrect.

> [snip!]
>
> Our results showed that NetFlow always accounts for less data than actually
> crosses the interface (obvious from our previous discussion), but that he
> percentage it accounted for depended on the physical transport. If the link
> was a serial T3 link, NetFlow would acocunt for ~95% of the data. If on the
> other hand, the link was ATM or FDDI, the NetFlow-collected data would
> account for ~80-85% of the data.

Isn't this an encapsulation issue? The different figures you mention would
be accounted for by HDLC/PPP encapsulation in the case of the T3 line, and
(presumably) AAL5 encapsulation/incomplete cells in the case of ATM (I don't
know anything much about FDDI). The proportion you measured would be a
function of the average size of packet transmitted across the interface
and the average encapsulation overhead involved in the particular transport.

> CAVEAT: Although we haven't conducted in-depth research to quantify the
> precise causes of the differences, we suggest the following factors
> logically explain the differences between MIB-II counters and Netflow
> statistics:
>
> * The type of the session (each session can have different overhead) - and
> thus, the distribution of the sessions. DNS requests, HTTP sessions,
> long/short FTP transfers, video-conferencing, VoIP, all have different
> effect on the difference in the measurements.

Aren't you just effectively varying the packet size in these cases, so that
the proportion of the L2 frame which comprises L3 packet (given a constant
encapsulation overhead) varies?

> * The congestion of the network - at any point. Since retransmissions of
> TCP packets, caused, in part, due to congestion are not accounted for in
> NetFlow, a congestion in any part of the network, warranting a retransmit
> on the interface in question would be accounted for by MIB-II ifentry, but
> not by NetFlow - causing an increase in difference between measurements.

Again, I am _convinced_ that TCP retransmissions, establishment and
teardown traffic are not treated specially by NetFlow. It would be harder
for cisco to do than treating everything as a packet - and I can't see
any particular benefit in them doing it.

> * The interface type - IP over ATM has an inherent overhead that is more
> substantial than IP used on T3 links, etc.

Different encapsulations.

> * Non-IP traffic - As mentioned above, this type of traffic is not
> accounted for by NetFlow or IP Accounting, but is by MIB-II. If present on
> the interface, it would affect the comparison.

Regards,


Joe

From netramet-owner  Mon Feb 15 01:40:03 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA11157
       for netramet-outgoing; Mon, 15 Feb 1999 01:39:42 +1300 (NZDT)
Received: from mailgw.wm.net (mailgw.wm.net [194.18.224.214])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA11151
       for <[email protected]>; Mon, 15 Feb 1999 01:39:37 +1300 (NZDT)
Received: from wmbro1si0112.wmdata.com (wmbro1si0112.wm.net [164.9.151.108])
       by mailgw.wm.net (8.9.1a/8.9.1) with ESMTP id NAA08259
       for <[email protected]>; Sun, 14 Feb 1999 13:40:02 +0100 (MET)
Received: by wmbro1si0112.wm.net with Internet Mail Service (5.5.2232.9)
       id <1TV6XL5N>; Sun, 14 Feb 1999 13:39:37 +0100
Message-ID: <[email protected]>
From: =?iso-8859-1?Q?F=E4ltman=2C_Mikael?= <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: RE: (Re) Any other way of measuring traffic with Netramet and Cis
       co?
Date: Sun, 14 Feb 1999 13:39:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
       charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk

Very interesting. I can't see why this information wouldn't be of =
interest
for this group.
As I understand Ciscos IP accounting is that accounting can only be =
enabled
on a per interface basis and it only records outgoing traffic on these
interfaces. Is this correct ?
If so how does this affect NetFlow feature ?
To get correct ip accounting data then you must set up IP accounting on
several interfaces and correlate the data.=20
Any comments ?

> ---
> Mikael F=E4ltman ([email protected])
> Network Services
> WM-data Infrastruktur AB, BOX 164, S-295 22 BROMOLLA
>=20
>=20
> -----Original Message-----
> From: Limor Schweitzer [SMTP:[email protected]]
> Sent: den 14 februari 1999 10:02
> To:   [email protected]
> Subject:      (Re) Any other way of measuring traffic with Netramet and
> Cisco?
>=20
>=20
> > > [mailto:[email protected]]On Behalf Of Andrew Frazer
> > > Sent: Monday, February 08, 1999 11:59 AM
> > > To: '[email protected]'
> > > Subject: Any other way of measuring traffic with Netramet and =
Cisco?
> > >
> > > Does any one know of, or has measured traffic with smaller Cisco
> > > Switches and routers (ie Cat 1900s or 2500 series routers? )
> > >
> > From: "Limor Schweitzer" <[email protected]>
> > To: <[email protected]>
> > Subject: RE: Any other way of measuring traffic with Netramet and =
Cisco?
> > Date: Mon, 8 Feb 1999 15:27:47 +0200
> > In-Reply-To:
> <[email protected]>
> >
> > We've done measurements using MIB2, CISCO IOS Accounting and
> > NetFlow (also using other equipment and servers).
> > We have some results about to the differences
> > between MIB2 interface counters and NetFlow.
> > I'm not sure this is of interest to the group so
> > pls send me an email if you want more info.
> >
> >
>=20
>=20
> I got quite a few "want more info" replies,
> so I'm posting it on the list.
> The following was written by Tal Givoly <[email protected]>.
>=20
>=20
>=20
> Using XACCTusage at a major University on a border router, XACCT =
engineers
> have compared interface traffic volume statistics collected from
> NetFlow-enabled routers with that obtained from MIB-II ifentry =
counters.
> The
> initial motiviation of this comparison was to determine if there was =
any
> data loss from Netflow UDP datagram transmission to XACCTusage =
gatherers.
> The results of tests at the university were confirmed at additional
> customer
> installations as well as XACCT's engineering lab.  Overall, the =
behaviour
> observed and described in this analysis was consistent across the =
various
> test sites.
>=20
> XACCTusage is based on a flexible, modular architecture that allows
> installation of different modules to collect
> accounting data from various network equipment and application =
servers.
> There were three modules that are used in this comparison:
>=20
> * Cisco IOS Accounting - Collects from Cisco IOS's IP Accounting =
feature.
> Most Cisco routers support this feature, and it provides XDRs (XACCT
> Detail
> Records) to be generated on sessions from Source IP to Destination =
IP,
> including start, end, number of bytes and number of packets for each
> session.
> * Cisco NetFlow Switching - Collects data from NetFlow-enabled =
devices
> (currently supporting V1 and V5 of NetFlow, but V7 and V8 are in late
> stages of development). The data can further be filtered and =
aggregated
> using many aggregation schemes with configurable parameters.
> * MIB-II - A module that collects accounting data from any device
> supporting SNMP MIB-II. Most routing devices support this interface =
and
> allow collecting aggregate total bytes traversing an interface.
>=20
> The Cisco IOS Accounting and the Cisco NetFlow Switching, count =
aggregated
> IP traffic. Both reach the same figures when compared for
> SourceIP-Destination IP traffic over a long-enough time frame. This =
is
> required, since the NetFlow performs some inherent aggregation, and =
the
> sampling of the IP-matrix causes some aggregations as well, the
> comparisons
> we observed have not reached 100% accuracy, but they reach 99% =
accuracy
> over
> sufficiently long time-frames. This discussion, therefore, deals with =
a
> NetFlow/MIB-II comparison only, since IP Accounting cannot be =
compared
> with
> MIB-II, because there is no information regarding interface, unless =
it is
> turned on for only a single interface in question).
>=20
> During inital trials it appeared that NetFlow would did account for =
all
> the
> data that crosses the interface. This is logical, because NetFlow =
accounts
> only for layer-3, while MIB-II counters include all layer-2 data. So
> NetFlow, for instance, would not account for TCP retransmissions, nor
> would
> it account for TCP/UDP headers, or TCP socket setup, while the MIB-II
> would
> account for all these. Also, NetFlow accounts for IP data, in cases =
where
> other protocols are used on the respective interface, MIB-II would =
account
> for non-IP data, causing another difference in measurement to appear.
>=20
> Our results showed that NetFlow always accounts for less data than
> actually
> crosses the interface (obvious from our previous discussion), but =
that he
> percentage it accounted for depended on the physical transport. If =
the
> link
> was a serial T3 link, NetFlow would acocunt for ~95% of the data. If =
on
> the
> other hand, the link was ATM or FDDI, the NetFlow-collected data =
would
> account for ~80-85% of the data.
>=20
> CAVEAT: Although we haven't conducted in-depth research to quantify =
the
> precise causes of the differences, we suggest the following factors
> logically explain the differences between MIB-II counters and Netflow
> statistics:
>=20
> * The type of the session (each session can have different overhead) =
- and
> thus, the distribution of the sessions. DNS requests, HTTP sessions,
> long/short FTP transfers, video-conferencing, VoIP, all have =
different
> effect on the difference in the measurements.
> * The congestion of the network - at any point. Since retransmissions =
of
> TCP packets, caused, in part, due to congestion are not accounted for =
in
> NetFlow, a congestion in any part of the network, warranting a =
retransmit
> on the interface in question would be accounted for by MIB-II =
ifentry, but
> not by NetFlow - causing an increase in difference between =
measurements.
> * The interface type - IP over ATM has an inherent overhead that is =
more
> substantial than IP used on T3 links, etc.
> * Non-IP traffic - As mentioned above, this type of traffic is not
> accounted for by NetFlow or IP Accounting, but is by MIB-II. If =
present on
> the interface, it would affect the comparison.
>=20
>=20
> ---------------
> More in-depth research on the subject is currently in progress.
>=20
> Regards,
>=20
> Limor Schwetizer
> CTO
> XACCT Technologies

From netramet-owner  Mon Feb 15 20:24:10 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id UAA15498
       for netramet-outgoing; Mon, 15 Feb 1999 20:22:51 +1300 (NZDT)
Received: from eng.um.edu.mt (rohan.eng.um.edu.mt [193.188.36.7])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id UAA15487
       for <[email protected]>; Mon, 15 Feb 1999 20:22:43 +1300 (NZDT)
Received: (from dapisa@localhost)
       by eng.um.edu.mt (8.8.5/8.8.5) id HAA00618
       for [email protected]; Mon, 15 Feb 1999 07:58:23 +0100 (MET)
Date: Mon, 15 Feb 1999 07:58:23 +0100 (MET)
From: Deborah Pisani <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Netramet
Sender: [email protected]
Precedence: bulk


Hello,

    I would like to use some software for network monitoring.  I came upon
Netramet.  I would like to know whether it is possible for the meter to receive
all packets on the segment (ie. promiscuous mode), or whether the meter measuresonly packets which have to pass through the host on which it is installed.

    I would also be interested if someone using Netramet for LAN traffic
monitoring would tell me whether it is appropriate to use its results for
network modelling.

    Thanking you in anticipation.


                                                               Regards,






                                                               Deborah

From netramet-owner  Mon Feb 15 21:14:37 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id VAA17720
       for netramet-outgoing; Mon, 15 Feb 1999 21:14:20 +1300 (NZDT)
Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id VAA17711
       for <[email protected]>; Mon, 15 Feb 1999 21:14:17 +1300 (NZDT)
Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.11) with ESMTP id VAA15994; Mon, 15 Feb 1999 21:13:46 +1300 (NZDT)
Received: (from jabley@localhost)
       by buddha.clear.net.nz (8.9.2/8.9.1) id VAA08068;
       Mon, 15 Feb 1999 21:13:46 +1300 (NZDT)
       (envelope-from jabley)
Date: Mon, 15 Feb 1999 21:13:45 +1300
From: Joe Abley <[email protected]>
To: Deborah Pisani <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Netramet
Message-ID: <[email protected]>
References: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <[email protected]>; from Deborah Pisani on Mon, Feb 15, 1999 at 07:58:23AM +0100
Sender: [email protected]
Precedence: bulk

On Mon, Feb 15, 1999 at 07:58:23AM +0100, Deborah Pisani wrote:
>
>      I would like to use some software for network monitoring.  I came upon
> Netramet.  I would like to know whether it is possible for the meter to
> receive all packets on the segment (ie. promiscuous mode), or whether the
> meter measures only packets which have to pass through the host on which
> it is installed.

You certainly can configure the meter to listen to other stations' traffic
on an ethernet port - in fact, I believe this is the normal mode of operation
for the ethernet meter.

>      I would also be interested if someone using Netramet for LAN traffic
> monitoring would tell me whether it is appropriate to use its results for
> network modelling.

We used flow data produced by an ethernet NeTraMet meter to produce
international traffic reports for our customers for some time; we are
now using NetFlowMet to produce the same format flow files from NetFlow
records, which are fed into the same back-end.

Whether it is suitable for your application depends on exactly what data
your modelling application requires, and whether you can build a ruleset
that will capture suitable traffic data.


Joe


From netramet-owner  Mon Feb 15 23:10:11 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA23200
       for netramet-outgoing; Mon, 15 Feb 1999 23:07:34 +1300 (NZDT)
Received: from nosc.ja.net (nosc.ja.net [128.86.16.20])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id XAA23187
       for <[email protected]>; Mon, 15 Feb 1999 23:07:08 +1300 (NZDT)
Received: from nosc.ja.net by nosc.ja.net with Internet SMTP
         id <[email protected]>; Mon, 15 Feb 1999 10:06:03 +0000
To: Joe Abley <[email protected]>
cc: Limor Schweitzer <[email protected]>, [email protected],
       [email protected]
Subject: Re: (Re) Any other way of measuring traffic with Netramet and Cisco?
In-reply-to: Your message of "Sun, 14 Feb 1999 23:36:05 +1300." <[email protected]>
Date: Mon, 15 Feb 1999 10:05:54 +0000
Message-ID: <[email protected]>
From: Kevin Hoadley <[email protected]>
Sender: [email protected]
Precedence: bulk


(Somebody questioned the relevance of this thread to the netramet list ...
I think that's a fair comment to some extent, however the original message
did spread a certain amount of fear and supposition about NetFlow, which in
turn would appear to undermine the value of NetFlowMet).

> > data that crosses the interface. This is logical, because NetFlow accounts
> > only for layer-3, while MIB-II counters include all layer-2 data. So
> > NetFlow, for instance, would not account for TCP retransmissions, nor would
> > it account for TCP/UDP headers, or TCP socket setup, while the MIB-II would
> > account for all these.
>
> Why do you say that NetFlow doesn't count packets which are TCP
> retransmissions or TCP establishment/teardowns?
>
> I _think_ (no, I _hope_ :) this is incorrect.

Just to reinforce this, this almost certainly cannot be true:

 - it would require a NetFlow router to store and process an enormous
volume of data

 - with load-balancing, discounting retransmissions is simply impossible,
since a router cannot be guarenteed to see all the packets of a TCP flow,
and thus cannot track teh sequence numbers.

> > Our results showed that NetFlow always accounts for less data than actually
> > crosses the interface (obvious from our previous discussion), but that he
> > percentage it accounted for depended on the physical transport. If the link
> > was a serial T3 link, NetFlow would acocunt for ~95% of the data. If on the
> > other hand, the link was ATM or FDDI, the NetFlow-collected data would
> > account for ~80-85% of the data.
>
> Isn't this an encapsulation issue? The different figures you mention would
> be accounted for by HDLC/PPP encapsulation in the case of the T3 line, and
> (presumably) AAL5 encapsulation/incomplete cells in the case of ATM (I don't
> know anything much about FDDI). The proportion you measured would be a
> function of the average size of packet transmitted across the interface
> and the average encapsulation overhead involved in the particular transport.

Absolutely - you might well see a similar effect trying NeTraMet with and
without the -l option (?? - whatever the option is that controls whether or
not the link layer headers are counted) - different applications would see
different levels of overhead, due to different average packet sizes.

Kevin Hoadley.

From netramet-owner  Tue Feb 16 02:01:01 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA29796
       for netramet-outgoing; Tue, 16 Feb 1999 02:00:00 +1300 (NZDT)
Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.26])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA29789
       for <[email protected]>; Tue, 16 Feb 1999 01:59:54 +1300 (NZDT)
Received: from univie.ac.at (aal5.cc.univie.ac.at [131.130.2.236])
         by mailbox.univie.ac.at (8.8.8/8.8.4) with ESMTP
         id NAA24784; Mon, 15 Feb 1999 13:59:50 +0100
Message-ID: <[email protected]>
Date: Mon, 15 Feb 1999 12:59:49 +0000
From: Harald Michl <[email protected]>
Organization: University of Vienna
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586)
MIME-Version: 1.0
To: netramet <[email protected]>
Subject: NetFlowMet: NF version 256 ???
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hello!
I just got the NeTraMet Package 4.2.1 (Linux binaries and
sources) and have the same problem with both versions with NetFlowMet.

When I start NetFlowMet I only get the following output:

[root@xyz meter]# NetFlowMet
NetFlowMet: Network Meter v4.2.1
Running on xyz.cc.univie.ac.at, port udp-9996
1252:19  nf_read(udp-9996): NF version 256 ???
1252:20  nf_read(udp-9996): NF version 256 ???
1252:21  nf_read(udp-9996): NF version 256 ???
1252:24  nf_read(udp-9996): NF version 256 ???
1252:25  nf_read(udp-9996): NF version 256 ???


If I change the netflow version on the cisco to version 5 I get 1280 instead of
256. It seems to me that the value NetFlowMet recognizes is shifted eight bits
to the left.
I found the same problem in the mailing archive of November 1998, but there was
no solution posted to the list.

Did perhaps anyone had the same problem and knows what to do?

regards
Harald

--
 Harald Michl                   :  e-mail: [email protected]
 Computer Center - ACOnet       :  Tel: +43 1 4277 - 140 33
 Vienna University              :  Fax: +43 1 4277 - 9 140
 Universitaetsstrasse 7         :
 A-1010 Vienna, Austria, Europe :  PGP public key ID 0x507C08E0

From netramet-owner  Fri Feb 19 16:07:39 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id QAA15218
       for netramet-outgoing; Fri, 19 Feb 1999 16:00:52 +1300 (NZDT)
Received: from hedgehog.highway1.com.au (hedgehog.highway1.com.au [203.7.224.11])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id QAA15208
       for <[email protected]>; Fri, 19 Feb 1999 16:00:46 +1300 (NZDT)
Received: from laforge.highway1.com.au (laforge.highway1.com.au [203.23.222.133])
       by hedgehog.highway1.com.au (8.8.8/8.8.8) with SMTP id KAA00444
       for <[email protected]>; Fri, 19 Feb 1999 10:49:22 +0800 (WST)
Message-Id: <[email protected]>
X-Sender: [email protected]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 19 Feb 1999 11:00:01 +0800
To: [email protected]
From: "Philip J. May" <[email protected]>
Subject: rules.manage example file problem?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email protected]
Precedence: bulk

I have installed both NeTraMet422.tar.gz and NeTraMet43b9.tar.gz on a sparc
running solaris 2.5.1. Both install perfectly. When I goto use the rule
from examples/rules/rules.manage even without editing it the output is not
what I expect it to be.

Looks like this;

4 5 10272  1 0.0.0.0 0.0.0.0  6 25 1074  245 0  14700 0
4 6 10272  1 0.0.0.0 0.0.0.0  6 80 2185  3 3  247 747
4 7 10272  1 0.0.0.0 0.0.0.0  6 3251 80  10 11  600 5418
4 8 10272  1 0.0.0.0 0.0.0.0  6 8067 80  15 22  900 12788
4 9 10273  1 0.0.0.0 0.0.0.0  6 23 1719  24 34  3416 2040
4 10 10273  1 0.0.0.0 0.0.0.0  6 2455 80  33 28  1980 38383
4 11 10273  1 0.0.0.0 0.0.0.0  1 0 0  16 0  964 0
4 12 10274  1 0.0.0.0 0.0.0.0  6 8070 80  5 13  538 7099


The 0.0.0.0 addresses are obviously not correct. Any ideas why this would
be? The example rule set is perfect for my requirements.

Thanks in advance.
----------------------------
Philip J. May
Highway 1 (Aust) Pty Ltd
ph: +61 8 9370 4584
email: [email protected]
----------------------------

From netramet-owner  Fri Feb 19 18:28:15 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id SAA04821
       for netramet-outgoing; Fri, 19 Feb 1999 18:26:33 +1300 (NZDT)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id SAA04813;
       Fri, 19 Feb 1999 18:26:29 +1300 (NZDT)
From: Nevil Brownlee <[email protected]>
To: "Philip J. May" <[email protected]>
Cc: [email protected]
Subject: Re: rules.manage example file problem?
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Date: Fri, 19 Feb 1999 18:42:50 +1300 (New Zealand Daylight Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk

Hello Philip:

> I have installed both NeTraMet422.tar.gz and NeTraMet43b9.tar.gz on a sparc
> running solaris 2.5.1. Both install perfectly. When I goto use the rule
> from examples/rules/rules.manage even without editing it the output is not
> what I expect it to be.

The ruleset rules.manage is full of New Zealand IP addresses, which of
course you're not seeing.   If it doesn't find such addresses, every
packet finished up going to the label t_bad, which doesn't save the
PeerAddresses - hence they finish up as 0.0.0.0, i.e. they were never set!

rules.manage was intended as an example of how to use subroutines to
classify traffic into site / local / international, rather than as one
which was directly useful.  For getting started with NeTraMet you could
be better off with srl/nifty.srl - you have to compile it to produce a
'rules' file (src/srl examples/srl/nifty.rules) but you should find it
much easier to understand and write rulesets using SRL!

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P


From netramet-owner  Sat Feb 20 03:35:08 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id DAA26332
       for netramet-outgoing; Sat, 20 Feb 1999 03:33:28 +1300 (NZDT)
Received: from oscar.broadcom.ie (oscar.broadcom.ie [192.107.110.20])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id DAA26320;
       Sat, 20 Feb 1999 03:33:18 +1300 (NZDT)
Received: from broadcom.ie (pc43.broadcom.ie [192.107.110.143])
       by oscar.broadcom.ie (8.8.8/8.8.8) with ESMTP id OAA23226;
       Fri, 19 Feb 1999 14:31:14 GMT
Message-ID: <[email protected]>
Date: Fri, 19 Feb 1999 14:40:52 +0000
From: Adrian Newcombe <[email protected]>
Organization: Broadcom Eireann Research Ltd.
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Nevil Brownlee <[email protected]>
CC: netramet-list <[email protected]>
Subject: Re: Filtering flows on TOS Byte
References: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi Nevil,

Thanks for the reply. I have installed the software and it appears to work.
It at least identifies flows on the basis of the DSCodePoint. However, I am
having difficulty in writing an SRL ruleset to classify flows on the basis of
the values of the DSCodePoint. srl appears to be unhappy when I try to
compare the value of the DSCP. As an example, if I run the following through
srl.


> #
>   if SourcePeerType == IP  save, {
> #
> #
>   if DSCodePoint == 0 & D0
>         store FlowKind :='B';
>   save DSCodePoint;
>   count;
> }
> #
>
> else ignore;  # Not an IP packet
>
> set 14;
> FORMAT
>         firsttime " " DSCodePoint FlowKind " " topdus frompdus " # " tooctets fr
> omoctets;
> STATISTICS;
>
srl prints the following error :


> Nevil's SRL compiler, version 4.3
> 15:25:46 Fri 19 Feb 1999: Compiling test.srl
>         test.srl    8:   if DSCodePoint == 0 & D0
>                                           ^
>            ERROR >>>>  Statement expected
>
> test.srl compiled: 1 errors and 0 warnings
>
What am I doing wrong here ?
I'd like to classify the flows on the basis of the first three bits of the
DSCP.


Also, is there an updated version of the MIB which includes the DSCodePoint
in the FlowDataEntry table ? If I point a MIB browser at NeTraMet, I get back
some objects which are not described in the MIB description. These include
object with an OID of FlowDataEntry.118 . Is this the DSCodePoint ?

Thanks in advance!
Adrian.

Nevil Brownlee wrote:

>
>
> 4.3b8 is stable and reliable (I've been using it for several weeks now),
> and I'm keen to help people get going with the DSCodePoint attribute.  If
> anyone needs help with rulesets (SRL programs) for this, please send
> details of what you're intending to do to the NeTraMet list, and I'll be
> happy to help!
>



--
Adrian Newcombe,
Lead Researcher,
Broadcom Eireann Research Ltd., Kestrel House,
Clanwilliam Place, Dublin 2, Ireland.
Voice   : +353 1 604 6000   Fax     : +353 1 676 1532
Email   : [email protected]   http://www.broadcom.ie/



From netramet-owner  Mon Feb 22 12:54:13 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id MAA23539
       for netramet-outgoing; Mon, 22 Feb 1999 12:42:45 +1300 (NZDT)
Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id MAA23518;
       Mon, 22 Feb 1999 12:42:34 +1300 (NZDT)
From: Nevil Brownlee <[email protected]>
To: Adrian Newcombe <[email protected]>
Cc: [email protected]
Subject: Re: Filtering flows on TOS Byte
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Date: Mon, 22 Feb 1999 12:59:13 +1300 (New Zealand Daylight Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk


Hello Adrian:

> What am I doing wrong here ?

Nothing! Your program showed up two bugs in the SRL compiler.  1) I
hadn't told it how to get a value foe DSCodepoint, and 2) it didn't
notice that a number starting with 'D' was in hex.  The patches to fix
these are attached below.

> I'd like to classify the flows on the basis of the first three bits of the
> DSCP.

The DSCodePoint attribute has exactly that as its value - i.e. I get it
by taking the old TOS byte and shifting it right two bits, yielding a
6-bit number.  You therefore need to AND it with 0x38 rather than 0xD0.

  if SourcePeerType == IP  save, {
#      if DSCodePoint == 0 & D0
     if DSCodePoint == 0 & 0x38  # True if none of these bits are on
        store FlowKind := 'B';
     save DSCodePoint;
     count;
     }
  else ignore;  # Not an IP packet

In the resulting flow data file, flows with none of those three bits on
will have FlowKind set to 'B', the others will have FlowKind set to 0
(the default value).  Of course all the flows will have the DSCodePoint
value as it was observed in the packet.

> Also, is there an updated version of the MIB which includes the
> DSCodePoint in the FlowDataEntry table ? If I point a MIB browser at
> NeTraMet, I get back some objects which are not described in the MIB
> description. These include object with an OID of FlowDataEntry.118 .
> Is this the DSCodePoint ?

Ah.  Right now there isn't, and yes, 118 is the attribute value for
DSCodePoint.  I'm working on a revised version of the MIB, and will
include it in the 43b10 release, real soon now ...

Thanks for the feedback, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P

RCS file: /usr/local/cvs/cvsroot/NeTraMet/src/srl/srl_scan.c,v
retrieving revision 1.1.1.1.2.4
diff -r1.1.1.1.2.4 srl_scan.c
1c1
< /* 1510, Thu 19 Nov 98
---
> /* 1113, Mon 21 Feb 99
831c831,834
<    else nextchar();
---
>    else {
>       if (isalpha(ic)) hex = 1;
>       nextchar();
>       }
953a957
>    case FTDSCODEPOINT:
1043a1048
>    case FTDSCODEPOINT:

----------------- end of patches ----------------


From netramet-owner  Mon Feb 22 22:04:11 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id WAA13951
       for netramet-outgoing; Mon, 22 Feb 1999 22:01:54 +1300 (NZDT)
Received: from eng.um.edu.mt (rohan.eng.um.edu.mt [193.188.36.7])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id WAA13941
       for <[email protected]>; Mon, 22 Feb 1999 22:01:34 +1300 (NZDT)
Received: (from dapisa@localhost)
       by eng.um.edu.mt (8.8.5/8.8.5) id JAA16244
       for [email protected]; Mon, 22 Feb 1999 09:57:27 +0100 (MET)
Date: Mon, 22 Feb 1999 09:57:27 +0100 (MET)
From: Deborah Pisani <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: UDP statistics
Sender: [email protected]
Precedence: bulk


Hello,

       Can anyone please tell me whether the Netramet log files log the UDP
byte and packet counts for each source and destination pair?

       Thanking you in anticipation.


                                                                       Regards,




                                                                       Deborah

From netramet-owner  Fri Feb 26 14:05:04 1999
Received: by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id NAA28682
       for netramet-outgoing; Fri, 26 Feb 1999 13:58:54 +1300 (NZDT)
Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66])
       by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA28667
       for <[email protected]>; Fri, 26 Feb 1999 13:58:48 +1300 (NZDT)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp.nortel.com;
         Thu, 25 Feb 1999 19:58:34 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8)
         id <FR10BFLJ>; Thu, 25 Feb 1999 19:58:31 -0500
Message-ID: <[email protected]>
From: "Tony Zoght" <[email protected]>
To: "NeTraMet NewsGroup (E-mail)" <[email protected]>
Subject: Anybody using a 3c509 NIC
Date: Thu, 25 Feb 1999 19:58:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
X-Orig: <[email protected]>
Sender: [email protected]
Precedence: bulk

Hi there,

    Is there anybody out there using a 3COM 3c509 successfully with
NeTraMet ?
  If there is, I will be very interested to hear from them.
Thanks in advance,

>           Tony Zoght @ SEAL
> Software Engineering Analysis Lab
>
> * [email protected]
*(613) 765 - 3015
>    ESN   395 - 3015
* fax: (ESN) 395 - 4962
>         (613) 765 - 4962
>
>
>
>

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.