From owner-freebsd-isp Sun Mar 12 14:47: 0 2000 Delivered-To: freebsd-isp@freebsd.org Received: from nara.off.connect.com.au (nara.off.connect.com.au [192.94.41.40]) by hub.freebsd.org (Postfix) with ESMTP id E372137B941 for ; Sun, 12 Mar 2000 14:46:55 -0800 (PST) (envelope-from darius@connect.com.au) Received: from connect.com.au (darius@localhost) by nara.off.connect.com.au with ESMTP id JAA14119 (8.8.8/IDA-1.7); Mon, 13 Mar 2000 09:46:05 +1100 (EST) Message-ID: <200003122246.JAA14119@nara.off.connect.com.au> To: Rowan Crowe Cc: freebsd-isp@freebsd.org, aussie-isp@aussie.net From: Kevin Littlejohn Reply-To: Kevin Littlejohn Subject: Re: [Oz-ISP] tagging IP packets travelling over internal network In-reply-to: Your message of "Sat, 11 Mar 2000 18:03:06 +1100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14113.952901165.1@connect.com.au> Date: Mon, 13 Mar 2000 09:46:05 +1100 Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>> Rowan Crowe wrote > Hi all, > > (sent to both freebsd-isp, a FreeBSD ISP mailing list, and aussie-isp, a > generic Australian ISP mailing list) > > I'm just about to move to a teired pricing system which offers different > rates for server (proxy/news/email), national direct, and international > direct, which will be calculated based on where the packet entered my > network - eg if it comes via Telstra then it's considered national. > > The problem with this is that I have to account at 4 different inbound > points, and something central has to collect this data from the individual > points and apply them to a single account. Assuming you're using cisco routers, Lincoln has I believe already suggested netflow as a data collection system. That's a good suggestion - netflow will report traffic 'flows' - data between two points over a certain timeframe - and will report byte counts and packet counts. If you're working on all traffic through a FreeBSD box or similar, I'd recommend putting some thought into building something that outputs in flows, rather than bytecounts - you'll find that's a good way to manage large volumes of traffic data. Tagging packets in some way may be theoretically doable, but I'd not be sure how and it'd increase the size of all your packets = artificially inflating bytecounts. The things to watch out for in a system like this are that you're counting traffic only once (remarkably fun to get right), and that you're throwing away traffic between places you don't care about while counting traffic between places you do care about (eg. if you suddenly manage to route all outbound from your local peering point out via telstra for them, you don't want your accounting system to have a heart attack ;) Also, there's some fun things to do with different interfaces etc., which you'll discover as you go. If you are setting something like this up, keep half a mind on using it as a traffic management tool, also - there's a lot of good data that can be collected from something like this, it can make managing certain classes of problems a bit easier. Incidentally (plug ;), if you're taking traffic from CCA, we can provide fairly good breakdowns, to individual network and sometimes individual IP, of what class of traffic your IP numbers are doing. ie. if you've got a particular /24 you're interested in, we can probably provide national/ international breakdowns for that /24 by itself. I believe our sales critters are announcing the web pages for that RSN... KevinL (who really should put together some docco on the techie side of CCA's traffic counting system sometime) --------------- qnevhf@obsu.arg.nh --------------- Kevin Littlejohn, Technical Architect, Connect.com.au Don't let the Govt censor our access to the 'net - http://www.efa.org.au/Campaigns/stop.html ---------- telnet mud.bofh.net.au 5000 ----------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message