Re: [nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field
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. The reporting of the Layer 2 and 3 devices, virtual or otherwise appears to be correct; I argue that Cisco attempting to 'populate' the SVI counters with information they are actually not seeing would be 'breaking' the implementation. Remember folks, we're talking about multi layer switching/routing here; the SVI isn't processing all of the traffic and should not lie and say that it is. Hudson Delbert J Contr 61 CS/SCBN wrote:
cisco long ago made the decision that counting packets was NOT as important processing them. i've seen this thread in discussions about IOS since Version 9. they arent going to change the methodology right now because we need to bill off of it. why use the overhead involved with passing info about L2 to L3 if 'train is still moving the cattle'. who cares?
~v/r Del Hudson 61CS/SCBN - LAAFB NCC Network Architecture & Engineering Group delbert.hudson@losangeles.af.mil
-----Original Message----- From: Gert Doering [mailto:gert@greenie.muc.de] Sent: Thursday, November 20, 2003 1:43 PM To: Anthony Cennami Cc: Nanog Mailing list; Robert A. Hayden; cisco-nsp@puck.nether.net Subject: Re: [nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field
Hi,
On Thu, Nov 20, 2003 at 12:52:02PM -0500, Anthony Cennami wrote:
This is because in 1996 you were likely not dealing with 'Switch Routers'; today's 'routers' perform some form of flow switching/caching, meaning once the traffic enters the VLAN routed interface and an appropriate path is found it is sent down the the Layer 2 fabric.
This is all nice and shiny, but having shortcuts doesn't mean "the L2 fabric can't export the resulting numbers up to the L3 brain".
They just botched it. Counters and Cisco boxes seem to be fundamentally incompatible.
gert
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?
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?
participants (2)
-
Anthony Cennami -
Christopher L. Morrow