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<
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 <marty@AKAMAI.COM> 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<
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:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Friday, January 02, 2015 8:06 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <marty@AKAMAI.COM> 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<
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 hoyosa@gmail.com
On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby@MNVOIP.COM> 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:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Friday, January 02, 2015 8:06 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <marty@AKAMAI.COM> 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<
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: matthewb@aitech.net On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa@gmail.com> 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 hoyosa@gmail.com
On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby@MNVOIP.COM> 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:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Friday, January 02, 2015 8:06 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <marty@AKAMAI.COM> 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<
We’re all adults here, and more so, we’re supposed to be network professionals. If we believe that MICE is supposed to be production quality then it needs to be treated as such. Suggestion: any irregular/significant maintenance activity should be communicated at least five business days in advance and if there’s regular maintenance (configuration change) that should be done during a prescribed maintenance window (i.e. every Wednesday between 1 and 5 am). No one likes getting up at 2 am, but our staff does it regularly because things happen, despite our vendors’ claims to the contrary. Frank From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Matthew Beckwell Sent: Saturday, January 03, 2015 12:23 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? 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: matthewb@aitech.net<mailto:matthewb@aitech.net> On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa@gmail.com<mailto:hoyosa@gmail.com>> 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 hoyosa@gmail.com<mailto:hoyosa@gmail.com>
On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby@MNVOIP.COM<mailto:jlumby@MNVOIP.COM>> 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:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Richard Laager Sent: Friday, January 02, 2015 8:06 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> 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 <marty@AKAMAI.COM<mailto:marty@AKAMAI.COM>> 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<
________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
So am I correct in understanding that there was some kind of maintenance activity on Friday afternoon? Our MICE facing port was physically down between 13:38:54 and 13:40:05 on Friday. -Danny Danny Meister - Network Engineer, Level III Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2071 Direct Dial Twitter<http://twitter.com/AtomicData> | Facebook<http://www.facebook.com/AtomicDataCenters> | LinkedIn<http://www.linkedin.com/companies/atomic-data-centers> Safe. Simple. Smart. www.atomicdata.com<http://www.atomicdata.com/> From: Matthew Beckwell <matthewb@AITECH.NET<mailto:matthewb@AITECH.NET>> Reply-To: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> Date: Saturday, January 3, 2015 at 12:23 PM To: "MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>" <MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? 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: matthewb@aitech.net<mailto:matthewb@aitech.net> On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa@gmail.com<mailto:hoyosa@gmail.com>> 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 hoyosa@gmail.com<mailto:hoyosa@gmail.com>
On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby@MNVOIP.COM<mailto:jlumby@MNVOIP.COM>> 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:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Richard Laager Sent: Friday, January 02, 2015 8:06 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> 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 <marty@AKAMAI.COM<mailto:marty@AKAMAI.COM>> 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<
________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
Correct, inserting a hot swapable module essentially caused the 4200 switch to restart. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Danny Meister Sent: Saturday, January 03, 2015 10:28 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? So am I correct in understanding that there was some kind of maintenance activity on Friday afternoon? Our MICE facing port was physically down between 13:38:54 and 13:40:05 on Friday. -Danny Danny Meister – Network Engineer, Level III Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2071 Direct Dial Twitter | Facebook | LinkedIn Safe. Simple. Smart. www.atomicdata.com From: Matthew Beckwell <matthewb@AITECH.NET> Reply-To: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> Date: Saturday, January 3, 2015 at 12:23 PM To: "MICE-DISCUSS@LISTS.IPHOUSE.NET" <MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? 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: matthewb@aitech.net On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa@gmail.com> 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 hoyosa@gmail.com
On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby@MNVOIP.COM> 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:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Friday, January 02, 2015 8:06 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <marty@AKAMAI.COM> 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<
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
I agree we probably need to set some standards for maintenance going forward, regardless I'd like to thank Jeremy (or is in MN VOIP?) for the equipment donated to MICE as those modules are several thousand dollars a piece and we could really use every port we can get right now. On Sat, Jan 3, 2015 at 11:00 PM, Jeremy Lumby <jlumby@mnvoip.com> wrote:
Correct, inserting a hot swapable module essentially caused the 4200 switch to restart.
*From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf Of *Danny Meister *Sent:* Saturday, January 03, 2015 10:28 PM
*To:* MICE-DISCUSS@LISTS.IPHOUSE.NET *Subject:* Re: [MICE-DISCUSS] Statistics reporting for MICE?
So am I correct in understanding that there was some kind of maintenance activity on Friday afternoon? Our MICE facing port was physically down between 13:38:54 and 13:40:05 on Friday.
-Danny
*Danny Meister* – Network Engineer, Level III
Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2071 Direct Dial
Twitter <http://twitter.com/AtomicData> | Facebook <http://www.facebook.com/AtomicDataCenters> | LinkedIn <http://www.linkedin.com/companies/atomic-data-centers>
Safe. Simple. Smart. www.atomicdata.com
*From: *Matthew Beckwell <matthewb@AITECH.NET> *Reply-To: *MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> *Date: *Saturday, January 3, 2015 at 12:23 PM *To: *"MICE-DISCUSS@LISTS.IPHOUSE.NET" <MICE-DISCUSS@LISTS.IPHOUSE.NET> *Subject: *Re: [MICE-DISCUSS] Statistics reporting for MICE?
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: matthewb@aitech.net
On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa@gmail.com> 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 hoyosa@gmail.com
On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby@MNVOIP.COM> 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:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Friday, January 02, 2015 8:06 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <marty@AKAMAI.COM> 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<
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
I agree with the minimum of 24 hour notice to the list so that the members have the option of shutting down BGP ahead of time. I think if we make it much more complicated than that, then we discourage people from volunteering, and since MICE is 100% volunteer based, we would be doing ourselves a disservice. The donation was technically a personal one, however since I am a partial owner of MN VoIP, there is not much difference. I do want to reiterate my standing offer to anyone thinking about connecting to MICE, since I have not formally said it on the list. I am willing to provide free assistance to anyone interested in connecting to MICE, if it is a small entity that needs help with BGP, or a large one that does not have a local presence, and needs remote hands to get hooked up. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Brady Kittel Sent: Saturday, January 03, 2015 11:28 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? I agree we probably need to set some standards for maintenance going forward, regardless I'd like to thank Jeremy (or is in MN VOIP?) for the equipment donated to MICE as those modules are several thousand dollars a piece and we could really use every port we can get right now. On Sat, Jan 3, 2015 at 11:00 PM, Jeremy Lumby <jlumby@mnvoip.com> wrote: Correct, inserting a hot swapable module essentially caused the 4200 switch to restart. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Danny Meister Sent: Saturday, January 03, 2015 10:28 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? So am I correct in understanding that there was some kind of maintenance activity on Friday afternoon? Our MICE facing port was physically down between 13:38:54 and 13:40:05 on Friday. -Danny Danny Meister – Network Engineer, Level III Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2071 Direct Dial Twitter | Facebook | LinkedIn Safe. Simple. Smart. www.atomicdata.com From: Matthew Beckwell <matthewb@AITECH.NET> Reply-To: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> Date: Saturday, January 3, 2015 at 12:23 PM To: "MICE-DISCUSS@LISTS.IPHOUSE.NET" <MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? 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: matthewb@aitech.net On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa@gmail.com> 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 hoyosa@gmail.com
On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby@MNVOIP.COM> 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:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Friday, January 02, 2015 8:06 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <marty@AKAMAI.COM> 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<
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
On 01/02/2015 07:10 PM, Hannigan, Martin 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.
I think that each potential peer determines the value of an exchange based upon their situation and business dynamics. For providers like us that mainly serve "eyeball" customers, traffic "massiveness" is probably the most important value indicator. Generally speaking, if my cost/bit is cheaper or higher quality at an exchange than a transit provider, then the more "massive" the better! To the overwhelming majority of our members/customers it doesn't matter whether the traffic comes from one ASN or a thousand ASNs. I'd like to see us consider including ASN count and total routes/netblocks on the MICE website. I don't know how much "real world" value there is with the route/netblock count, but it looks nice for marketing purposes! We currently see 44 ASNs and ~62,700 netblocks at MICE. I think that these are great numbers for a relatively new exchange. Steve
On Jan 3, 2015, at 14:17, Steve Howard <showard@PAULBUNYAN.NET> wrote:
On 01/02/2015 07:10 PM, Hannigan, Martin 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.
I think that each potential peer determines the value of an exchange based upon their situation and business dynamics. For providers like us that mainly serve "eyeball" customers, traffic "massiveness" is probably the most important value indicator. Generally speaking, if my cost/bit is cheaper or higher quality at an exchange than a transit provider, then the more "massive" the better! To the overwhelming majority of our members/customers it doesn't matter whether the traffic comes from one ASN or a thousand ASNs.
Agreed. Aside from mass of traffic and ASNs, a good measure of success (for me) is creation of PNIs. That requires traffic + ASN + good xcon costs (like 0).
I'd like to see us consider including ASN count and total routes/netblocks on the MICE website. I don't know how much "real world" value there is with the route/netblock count, but it looks nice for marketing purposes!
We currently see 44 ASNs and ~62,700 netblocks at MICE. I think that these are great numbers for a relatively new exchange.
Steve
It's definitely a good start. And now with the other data centers being more visible, competitive places to do PNis too. Great stuff. Best, Martin
On Jan 3, 2015, at 16:34, Hannigan, Martin <marty@AKAMAI.COM> wrote:
On Jan 3, 2015, at 14:17, Steve Howard <showard@PAULBUNYAN.NET> wrote:
On 01/02/2015 07:10 PM, Hannigan, Martin 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.
I think that each potential peer determines the value of an exchange based upon their situation and business dynamics. For providers like us that mainly serve "eyeball" customers, traffic "massiveness" is probably the most important value indicator. Generally speaking, if my cost/bit is cheaper or higher quality at an exchange than a transit provider, then the more "massive" the better! To the overwhelming majority of our members/customers it doesn't matter whether the traffic comes from one ASN or a thousand ASNs.
Agreed. Aside from mass of traffic and ASNs, a good measure of success (for me) is creation of PNIs. That requires traffic + ASN + good xcon costs (like 0).
Just so the guys that need to make the graphs know what they are being asked for; are you asking for peer ASNs or origin ASNs reachable from the exchange? Or, maybe both now that I think of it. Happy 2015!!! -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
On Jan 3, 2015, at 21:12, David Farmer <farmer@UMN.EDU> wrote:
On Jan 3, 2015, at 16:34, Hannigan, Martin <marty@AKAMAI.COM> wrote:
On Jan 3, 2015, at 14:17, Steve Howard <showard@PAULBUNYAN.NET> wrote: On 01/02/2015 07:10 PM, Hannigan, Martin 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.
I think that each potential peer determines the value of an exchange based upon their situation and business dynamics. For providers like us that mainly serve "eyeball" customers, traffic "massiveness" is probably the most important value indicator. Generally speaking, if my cost/bit is cheaper or higher quality at an exchange than a transit provider, then the more "massive" the better! To the overwhelming majority of our members/customers it doesn't matter whether the traffic comes from one ASN or a thousand ASNs.
Agreed. Aside from mass of traffic and ASNs, a good measure of success (for me) is creation of PNIs. That requires traffic + ASN + good xcon costs (like 0).
Just so the guys that need to make the graphs know what they are being asked for; are you asking for peer ASNs or origin ASNs reachable from the exchange? Or, maybe both now that I think of it.
Happy 2015!!
Twasn't me, but I think it was route count and AS count 5m/day/week/year or whatever we do. Long term, AS churn would be great too. Stagnation detection is useful. Best, -M<
participants (10)
-
Andrew Hoyos -
Brady Kittel -
Danny Meister -
David Farmer -
Frank Bulk -
Hannigan, Martin -
Jeremy Lumby -
Matthew Beckwell -
Richard Laager -
Steve Howard