[165690] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: common method to count traffic volume on IX

daemon@ATHENA.MIT.EDU (Stephen Fulton)
Wed Sep 18 19:12:46 2013

Date: Wed, 18 Sep 2013 19:10:35 -0400
From: Stephen Fulton <sf@lists.esoteric.ca>
To: nanog@nanog.org
In-Reply-To: <20130918225526.GE3108@burnout.tpb.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

 > Ding ding ding!  And that's why honest IXPs graph both, to show that
 > they have no packet loss on their inter-switch links.

It depends on what is being measured.  At TorIX we'll see deviations 
between in/out on our aggregate graph.  As we combine all peer ports to 
form the aggregate graph, any large deviations are almost always due to 
peers who have reached capacity limits on their port (which is not 
always port speed, btw, always include their transport behind the port). 
  Another common reason is the difference in measurement times across 
all ports.

http://www.torix.ca/stats.php

-- Stephen


On 18/09/2013 6:55 PM, Niels Bakker wrote:
> * bicknell@ufp.org (Leo Bicknell) [Wed 18 Sep 2013, 19:23 CEST]:
>> On Sep 17, 2013, at 3:15 PM, Niels Bakker <niels=nanog@bakker.net> wrote:
>>> I don't know of any IXP that does this.  Industry standard is as you
>>> and others wrote before: the 5-minute counter difference on all
>>> customer-facing ports, publishing both input and output bps and pps.
>>> I guess MRTG is to 'blame' for these values more than anything.
>>
>> Serious question, at an IXP shouldn't IN = OUT nearly perfectly?
>
> Ding ding ding!  And that's why honest IXPs graph both, to show that
> they have no packet loss on their inter-switch links.
>
> (Or, much more likely, measurement errors due to wrong config for the
> grapher)
>
>
>      -- Niels.
>


home help back first fref pref prev next nref lref last post