Traffic billing - L2 encap to include or not?
We all have our billing systems for traffic (bought, downloaded or home made, volume based or usage). We all got hit by fancy SNMP bugs of various vendors and we all suffer from the fact, that SNMP counters do not carry a time stamp, when they had been taken from the ASICs, causing a slight derivation. [...] Most systems (not the xflow based ones) do use IF-MIB::InOctets and IF-MIB::OutOctets or their HC counter parts to retrieve the number of transmitted bytes and do their calculation based on these numbers. What would you expect these counters to return, esp. on Ethernet? RFC2683 states ifXxxOctets The definitions of ifInOctets and ifOutOctets (and similarly, ifHCInOctets and ifHCOutOctets) specify that their values include framing characters. The media-specific MIB designer MUST specify any special conditions of the media concerning the inclusion of framing characters, especially with respect to frames with errors. The total number of octets transmitted out of/received on the interface, including framing characters." So, is L2 encapsulation (e.g. Ethernet) considered as framing characters or not? Cisco does count them (looks like they also count the FCS), while Juniper does not (at least not on their routers) with above MIBs. So who's right? Which brings me to the question: How do others handle this? Do your customers have to pay for the L2 encapsulation overhead or not? Does your (special) G T&C address this? Does your system adjust the numbers by adding/subtracting L2 enc overhead * number of transmitted packets? Or do you just live with it as it is (and hope, your provider uses J-counters to do their billing). Oh, it's Friday ... Markus PS1: And what about padding? IP packets could be smaller then the min ethernet frame size ... (think of some kind of DOS attacks) ... PS2: Oh, maybe someone could check on J switches - would be nice to know ... -- [E] Markus Weber <fvd@kpn.DE> [IRC] FvD [T] +49 69 96874-298 [F] -289 [KPN Eurorings B.V. Darmstädter Landstraße 184 D-60598 Frankfurt] [HRB56874 Amtsgericht Frankfurt Carolien Nijhuis+Louis Rustenhoven]
On Fri, Jun 12, 2009 at 03:32:42PM +0200, Weber, Markus wrote:
So, is L2 encapsulation (e.g. Ethernet) considered as framing characters or not?
Cisco does count them (looks like they also count the FCS), while Juniper does not (at least not on their routers) with above MIBs. So who's right?
Juniper doesn't do this on purpose, it is just an unfortunate consequence of a hardware architecture which has distributed framing ASICs at the PIC level. For most PICs, the L2 information is already stripped away before the packet reaches the hardware components that are capable of counting or otherwise processing the packets further. This is why you need a far more expensive IQ pic with special processing capabilities on the PIC itself to do things like MAC accounting. Cisco and "everyone else" include the L2 overhead AFAIK. It makes for plenty of confusion come billing time.
PS1: And what about padding? IP packets could be smaller then the min ethernet frame size ... (think of some kind of DOS attacks) ... PS2: Oh, maybe someone could check on J switches - would be nice to know ...
The MX uses essentially the same type of hardware as a T-series, but with an extra EZChip ASIC added to do some basic Ethernet framing. You actually pose a good question, it might be possible for them to count the L2 overhead in SNMP, but I'm not sure if they actually do it or not. EX is an entirely different architecture from traditional Juniper routers so I wouldn't even begin to guess. At any rate, this is a discussion better suited for juniper-nsp mailing list. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
participants (2)
-
Richard A Steenbergen -
Weber, Markus