[nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field

Anthony Cennami narziss at cdardn.net
Thu Nov 20 23:45:04 UTC 2003

This too is a discussion argued a number of times previously. 
Personally, I prefer the architecture where one port belongs to one 
VLAN; this is obviously not appropriate in all situations, but it is in 

Nothing in this world is free, and the bandwidth that a customer uses 
across my network is not either, regardless if it's in between their own 
two servers.  In instances where a customer has multiple machines which 
require communication between one another, it is held at the customers 
discretion to purchase a private switch and second NIC(s), so our 
billing system remains ignorant, or get billed for the traffic.

If you are someone who enjoys living dangerously, there are also a 
variety of Flow based accounting systems and Probes which would allow 
you to bill based on the flow/IP accounting, rather than SNMP on your 
access devices.  This can be done either through your choice Layer 3 
device or a third-party promiscuous probe.

I'm sure that everybody here has their own idea on best how to do this, 
and what is 'right' for them; my argument is only that falsifying data 
through propagation from multi layer switching does not at all seem to 
be the best way.

Christopher L. Morrow wrote:
> On Thu, 20 Nov 2003, Anthony Cennami wrote:
>>If you want to bill accurately, bill off the Layer 2 ports; that's what
>>is always churning the traffic.  I've not looked at the accuracy on a
>>scientific level, but I've never found what I believed to be a serious
>>discrepency when billing/polling the physical ports.
> What about the cases where the customer has more than 1 port on your
> switch, you must then aggregate the traffic from N ports, discount the
> data between the local hosts and only bill for the actual up/down from the
> switch to the core, no?
> That seems complex, of course perhaps only 1 port per customer makes some
> sense in these cases too, eh?

More information about the NANOG mailing list