From owner-rtfm@auckland.ac.nz Mon Dec 10 14:22:18 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.191.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09443 for ; Mon, 10 Dec 2001 14:22:16 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id GAA21922; Tue, 11 Dec 2001 06:47:54 +1300 (NZDT) Received: from stimpy.networkrobots.com ([65.89.31.210]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id GAA21905 for ; Tue, 11 Dec 2001 06:47:44 +1300 (NZDT) Received: from vphalke (dhcp-2-172.networkrobots.com [192.168.2.172]) by stimpy.networkrobots.com (8.11.0/8.8.7) with SMTP id fBAHlgB26173 for ; Mon, 10 Dec 2001 09:47:43 -0800 From: "Vidya Phalke" To: Subject: Decopling Ruleset from Meter Reader Date: Mon, 10 Dec 2001 09:47:21 -0800 Message-ID: <00e701c181a2$b8703150$ac02a8c0@vphalke> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Logged: Logged by stimpy.networkrobots.com as fBAHlgB26173 at Mon Dec 10 09:47:43 2001 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Folks, at Network Robots, CA we are implementing Rtfm in our hardware as a mechanism for tracking flows. We seem to be looking at the meter+reader in a slightly different way and would appreciate your comments. In the current NetraMet implementation v4.3, the lifespan of a ruleset is attached to a reader. I, on the other hand, see the meter (NetraMet) and the reader (NeMaC) as two apps that fall under two totally different mgmt and maintenance domains (us versus customer !) The meter is part of the hardware element (snmp agent) and the reader is typically part of a BSS/OSS platform or a mediation system. This decoupling is important because as a hardware vendor we do not have the resources to collect and write files and do backups etc on our box. Once the decoupling is done, we get the following key requirement on the Rtfm agent, namely: The agent can not stop recording flow records simply because there is no reader. This is critical since the flow records are potentially meant for billing and the reader could be down for BSS/OSS upgrade. So the possible solutions are: 1. Leave the state of the reader as part of the MIB (as done in the current implementation of NeMaC) but do not delete the ruleset and flow records upon exiting NeMaC. 2. Install the ruleset separately and then ask NeMaC to read from that ruleset, from a specific time. #1 is not very elegant since it is keeping the state of a remote reader in its repository. #2 is clean because all the NeMaC user has to remember when shutting down NeMaC is the last timestamp (which can be saved locally) #2 makes the system more secure. The ruleset would need to be written via the private community, but the reading (i.e. NeMaC) will be done on the public community. (So only the ruleset savvy people on the customer site can install rules :) The only issue then remains is garbage collection, since we want to rotate out old flows when the flow table fills up. That can be done simply by fixing the way "old" flows are marked. -Vidya Phalke, PhD Senior NMS Engineer Network Robots, Inc. Pleasanton, CA http://www.networkrobots.com From owner-rtfm@auckland.ac.nz Fri Dec 14 08:53:49 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.191.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29388 for ; Fri, 14 Dec 2001 08:53:48 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA05869; Sat, 15 Dec 2001 01:29:31 +1300 (NZDT) Received: from s1.cip.ei.uni-stuttgart.de (root@s1.cip.ei.uni-stuttgart.de [129.69.174.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA05854 for ; Sat, 15 Dec 2001 01:29:28 +1300 (NZDT) Received: from l1 (IDENT:cpdm1568@l1.cip.ei.uni-stuttgart.de [129.69.174.11]) by s1.cip.ei.uni-stuttgart.de (8.9.3 (PHNE_22672)/8.8.3) with SMTP id NAA01028 for ; Fri, 14 Dec 2001 13:29:26 +0100 (MET) Received: by l1 (sSMTP sendmail emulation); Fri, 14 Dec 2001 13:29:26 +0100 Date: Fri, 14 Dec 2001 13:29:26 +0100 From: David Martinez Castellanos To: rtfm@auckland.ac.nz Subject: Problems with IPv6 Message-ID: <20011214132926.F20480@student.ei.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello everybody, I'm dealing with IPv6 and I cannot manage to make NeTraMet work. The problem it says is that the NeMac cannot open the snmp port. Can someone helpme?. I forget something?. Thank You for all David Martinez From owner-rtfm@auckland.ac.nz Fri Dec 14 12:30:36 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03603 for ; Fri, 14 Dec 2001 12:30:34 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA20362; Sat, 15 Dec 2001 05:00:11 +1300 (NZDT) Received: from caida.org (ipn.caida.org [192.172.226.30]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA20356 for ; Sat, 15 Dec 2001 05:00:10 +1300 (NZDT) Received: from localhost (nevil@localhost) by caida.org (8.9.3+Sun/8.9.1) with ESMTP id IAA07706; Fri, 14 Dec 2001 08:00:07 -0800 (PST) Date: Fri, 14 Dec 2001 08:00:06 -0800 (PST) From: Nevil Brownlee To: David Martinez Castellanos cc: rtfm@auckland.ac.nz Subject: Re: Problems with IPv6 In-Reply-To: <20011214132926.F20480@student.ei.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello David: The usual reason for messages like that is that there's already an SNMP agent running, which is using port 161. You can ask NeTraMet and NeMaC to use a different port using the -m option on both their command lines, e.g. ./NeTraMet -m 10161 -i eth0 -w write-com ./NeMaC -m 10161 -r test.rules -F test.fdf localhost write-com test I've had very few reports from IPv6 users, do please let me know how you get on - I'm keen to fix any v6 problems if/as you find them! Cheers, Nevil PS: I trust you're using the latest beta, i.e. beta-versions/NeTraMet44b11.tar.gz ? PPS: Has anyone tested NetFlowMet with the 44b11 release, please? ------------------------------------------------------------- Nevil Brownlee Internet Researcher Phone: (858) 534 8338 CAIDA, San Diego On Fri, 14 Dec 2001, David Martinez Castellanos wrote: > Hello everybody, > > I'm dealing with IPv6 and I cannot manage to make NeTraMet work. The problem > it says is that the NeMac cannot open the snmp port. From owner-rtfm@auckland.ac.nz Sat Dec 15 18:17:47 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08393 for ; Sat, 15 Dec 2001 18:17:46 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id KAA09365; Sun, 16 Dec 2001 10:57:21 +1300 (NZDT) Received: from lt.itss.auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id KAA09357; Sun, 16 Dec 2001 10:57:14 +1300 (NZDT) From: Nevil Brownlee Date: Sun, 16 Dec 2001 11:34:29 +0000 To: David Hausheer Subject: Re: Does NeTraMet provide variable flowDataStatus? Cc: rtfm@auckland.ac.nz In-Reply-To: <3C1A400F.F27530B1@tik.ee.ethz.ch> References: <3C1A400F.F27530B1@tik.ee.ethz.ch> Message-ID: Priority: NORMAL X-Mailer: Execmail for Linux 5.1 Build (9) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello David: > Does NeTraMet provide the flow-mib variable "flowDataStatus" of the flow > Table? > I tried to write a meter reader with a flow garbage collector, that > deletes a flow if the flowDataStatus variable is set to inactive(1). > However, it never got inactive flows, so the status was always > current(2) and the inactive flows were never deleted. > Do you know a solution for that? Thanks for your answer. The RFC 2720 MIB has a revision notice dated 971223 saying that flowDataStatus was deprecated because it contains no useful information. NeTraMet (as you've observed) always returns 2. The WG intent was that an RTFM meter should do the garbage collection, on the grounds that it has to be able to survive if all the current readers disappear. There was a question on a related topic on the rtfm list a while ago, maybe you could tell us a bit more about what you're wanting to do? 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 | +---------------------------------------------------------------------L From owner-rtfm@auckland.ac.nz Sun Dec 16 15:52:33 2001 Received: from mailhost.auckland.ac.nz ([130.216.191.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04609 for ; Sun, 16 Dec 2001 15:52:32 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id IAA20461; Mon, 17 Dec 2001 08:31:33 +1300 (NZDT) Received: from lt.itss.auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA20425; Mon, 17 Dec 2001 08:31:28 +1300 (NZDT) From: Nevil Brownlee Date: Mon, 17 Dec 2001 09:08:59 +0000 To: David Hausheer Subject: Re: Does NeTraMet provide variable flowDataStatus? Cc: rtfm@auckland.ac.nz In-Reply-To: <3C1CDEC3.29941B44@osola.com> References: <3C1CDEC3.29941B44@osola.com> <3C1A400F.F27530B1@tik.ee.ethz.ch> Message-ID: Priority: NORMAL X-Mailer: Execmail for Linux 5.1 Build (9) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello again David: > My plan is to write a meter reader that feeds a database with flow data, > using the CAS (Charging and Accounting System) Framework, that was > developed in our group. Individual flow data is treated as session > fragments. Session fragments are collected into session > characterizations. Every session fragment contains a flag saying whether > it's the first/last fragment of a session. But how can the reader know > whether a fragment was the last one? Well, it can have an internal > timeout for the flows, that is the same (or greater, to be sure) as for > the meter. But then you have some kind of "garbage collection" of flows > also in reader. So wouldn't it be simpler to just rely on the flow > status statement of the meter? I would suggest the meter sends some kind > of "dummy" flow data, with a flow status set to inactive(1). OK. I'll change the NeTraMet code to for the flow status object to test whether the flow is inactive, and return 1 if it is. That would indicate that the flow has become inactive, but has not yet been reclaimed by the meter's garbage collector. That will be in the NeTraMet 4.4 release, due out soon. 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 | +---------------------------------------------------------------------L