I'm with Andrew on his suggestion of either a formalized or gentlemen's agreement for a "heads up" with these types of activities.

We experienced at least a partial outage (i.e. UDP Packet Loss) over MICE between 13:38:47 and 13:40:02 on Friday.

I know this activity wasn't supposed to be service impacting-- but accidents and unexpected things happen.

A heads up would give conservative members the opportunity to re-route in a controlled manner (if they desire).  My personal preference would be a 24 hour notice so I could take action the night before, but I'll take what I can get (even if it's only an hour).

~Matthew

On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <[log in to unmask]> wrote:

I may have missed something, but I don’t recall seeing any email chatter about this happening. Unsure what the normal ops/maintenance protocol is, but I’d say when doing stuff like below (module adds/swaps), at least a heads up to mice-discuss would be in order for the benefit of all the members. Or given the growth of MICE, perhaps it’s time the steering committee should formalize something there. Thoughts from other folks?

As far as the graphs, we should look at fixing the RRD files to remove that spike with the wacky/erroneous values so things look proper still. I’d be happy to help with that if anyone needs a hand. I think there may even be a Cacti plugin that does that, IIRC.

--
Andrew Hoyos
[log in to unmask]



> On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <[log in to unmask]> wrote:
>
> The huge Cacti traffic spike coincided with adding a 4 port fiber module to the 4200 switch.  Juniper claimed it was hot swappable, however the issues were more than they eluded to.
>
> This came about since I donated some modules to hold MICE over until a more permanent hardware upgrade can be picked.  The good news is the 4500 now has 4 additional SFP+ ports, and the 4200 now has 4 SFP ports.  This will allow some of the members that are at 1G that needed a fiber handoff to be moved to the 4200 freeing up additional 10G ports in the 4500.
>
> -----Original Message-----
> From: MICE Discuss [mailto:[log in to unmask]] On Behalf Of Richard Laager
> Sent: Friday, January 02, 2015 8:06 PM
> To: [log in to unmask]
> Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE?
>
> I was going to say that I thought we were doing exactly that at http://micemn.net but when I pulled up the website to verify, I see that something is very wrong with the graph.
>
> Did anyone change something in Cacti recently?
>
> --
> Richard
>
>> On Jan 2, 2015, at 7:10 PM, Hannigan, Martin <[log in to unmask]> wrote:
>>
>>
>>
>> FYI,
>>
>> http://micelg.usinternet.com/export/graph_385.html shows in+out where http://micelg.usinternet.com/export/graph_384.html shows in/out. Which one should we use?
>>
>> I'd like to suggest that MICE follow OIX-1 with respect to agg and other stats:
>>
>> "The IXP MUST publish on a publicly available website the total sum of
>> all incoming and outgoing traffic in bps from all connected networks
>> on the public peering VLAN. The traffic sum MUST include the traffic on customer facing ports only and MUST be made up of 5 min average traffic measurements. A distinction MUST be made between the traffic on the public peering VLAN and any other interconnection service."
>>
>> Traffic "massiveness" isn't as important as how many ASNs are connected. Traffic is an unpredictable and unreliable indicator of an exchanges size and value. ASN counts are much more granular for potential peers to build a case to join.
>>
>>
>> Best,
>>
>> -M<
>>
>>
>>
>>
>>