[nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field
Anthony Cennami
narziss at cdardn.net
Thu Nov 20 18:45:04 EST 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
mine.
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 cisco-nsp
mailing list