Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Mar 2000 09:46:05 +1100
From:      Kevin Littlejohn <darius@connect.com.au>
To:        Rowan Crowe <rowan@sensation.net.au>
Cc:        freebsd-isp@freebsd.org, aussie-isp@aussie.net
Subject:   Re: [Oz-ISP] tagging IP packets travelling over internal network 
Message-ID:  <200003122246.JAA14119@nara.off.connect.com.au>
In-Reply-To: Your message of "Sat, 11 Mar 2000 18:03:06 %2B1100." <Pine.BSF.4.01.10003111752290.15891-100000@velvet.sensation.net.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
>>> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003122246.JAA14119>