[clug] Internode: Does customer-to-customer data count to monthly total?

Paul TBBle Hampson Paul.Hampson at Pobox.com
Sat Oct 7 03:52:45 GMT 2006

On Fri, Oct 06, 2006 at 08:19:36PM +1000, Neil Symons wrote:
> On 10/4/06, Paul Wayper <paulway at mabula.net> wrote:

> Most ISPs run their usage monitoring off RADIUS accounting (which is the
> total traffic used in a session or periodic measurements from a login
> session).

> For an ISP to monitor usage between different peers, they would have to use
> some form of IP accounting and with a bit of tricky work, either keep
> customers on a static IP address or by leasing an IP address giving the
> illusion that the IP given is dynamic so they can match IP records to a
> specific customer login ID with some effort.

> If you know of any other types of usage monitoring methods, please enlighten
> us [especially me :-)  ]

What I used to do (and am considering implementing again) was have an
IPtables tree with a table per IP address and then a table per account,
and the RADIUS server's account start/stop packets would trigger an
add or remove rule from the IP address to the account table.

Every ten minutes an iptables -vLZ gives the current totals for the
customers and clears it, and you just update your records from those

I only stopped using it because we stopped using a Linux box as a
router, and instead I was processing netflow data from a Cisco box.

It did however come at a CPU cost, which I was glad (at the time) to
stop paying on our core router.

In the latter setup, RADIUS was used to manage a symlink tree from IP
addresses to accounts, and every time a customer connected or
disconnected I'd SIGHUP the (slightly modified) netflowd to close and
reopen files, hence refollowing the (modified) symlinks.

I could then process the tree every ten minutes, and get nice,
repeatable and verifiable (as opposed to the older system) data out.

Mind you, it stored a _lot_ of data (about 5gB a month, and that's not
for a very big ISP) and the flow processing chewed up massive CPU time
every ten minutes (my SSH sessions would stop responding) which I
improved by increasing frequency to five minutes, so the dataset was
smaller. It's not a scalable system, you can't effectively distribute

The latter system also had accuracy problems I never tracked down (it
was only operating for three or four months) so I don't recommend that

My current plan is to use the port-mirroring features on our
core switch to duplicate external traffic off to a dedicated
machine, and reimplement the IPTables thingy, maybe adding some
marking support to enable on-/off-peak data differentiation with
a higher level of accuracy than I have right now.

Right now, we use RADIUS accounting, because I had about two days
to get it running.

I will say that the disadvantage of external-link billing is that
you end up billing for things that get blocked at a firewall level,
and I think _that_ was one of the sources of the above-mentioned
inaccuracies, as our upstream provider was blocking windows SMB
ports but still reporting the traffic in the netflows, hence making
our RADIUS results lower than the external data.

Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson at Pobox.Com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20061007/89b43962/attachment.bin

More information about the linux mailing list