 |
 |
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 *Matthew Beckwell* - Director of Network Operations Advanced Integrated Technologies Technical Support: 1-800-300-5408 Office: 1-952-829-5511 x204 E-Mail: [log in to unmask] 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< > >> > >> > >> > >> > >> >