On Wed, Apr 26, 2017 at 11:52:16AM +0000, John Unger wrote:

Jeremy, why are we doing these moves during the day? This does not make sense to me?

One factor was that Cologix needs to be involved in the fiber moves from the old cabinet to the new cabinet big enough to hold the new switch, and if done at night, MICE would have had to pay for at least 3 full nights of overtime tech worker to be there coordinating the fiber moves. -- Doug McIntyre <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

On Wed, Apr 26, 2017 at 8:07 AM, Andrew Hoyos <hoyosa@gmail.com> wrote:

As an aside, thanks Jeremy for doing all this move work, it's not a small effort and definitely appreciated.

I concur. This is greatly appreciated by us as well. Thank you. Ben Wiechman Network Engineer IV Direct: 320.256.0184 Cell: 320.247.3224 ben.wiechman@arvig.com 150 Second Street SW | Perham, MN 56573 | arvig.com

Along with the others who have chimed in so far, CNS also appreciates what Jeremy (and the rest of the volunteer team) has done on this migration! Thanks! Dean From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Mike Johnston Sent: Wednesday, April 26, 2017 8:34 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 3 Moves On 2017-04-26 08:28, Ben Wiechman wrote: On Wed, Apr 26, 2017 at 8:07 AM, Andrew Hoyos <hoyosa@gmail.com <mailto:hoyosa@gmail.com> > wrote: As an aside, thanks Jeremy for doing all this move work, it's not a small effort and definitely appreciated. I concur. This is greatly appreciated by us as well. Thank you. I will also concur. Thank you Jeremy for your hard work! It is MUCH appreciated. Mike Johnston Wikstrom Telephone Company _____ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> &A=1

I do agree that filtering BGP prior to the move is a great thing to do. I know we attempted it in the past, and we had some issues getting it to work properly. Now that we are on the Arista, I have tested it and it seems to work well. I plan on utilizing it on all future maintenance on the Arista switch. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Wednesday, April 26, 2017 8:08 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 3 Moves On Apr 26, 2017, at 6:52 AM, John Unger <john@VAULTAS.COM> wrote:

Jeremy, why are we doing these moves during the day? This does not make sense to me? Having been in this industry for over 35 years this is just crazy? Nobody does maintenance during the day?

If you are worried about impact, shut down *your* MICE peering sessions to affected parties before the maintenance starts. I would suggest that perhaps we look into filtering BGP (tcp/179) with an ACL prior to maintenance start on those specific ports being moved. Many other IXs are doing this for maintenance as a way to gracefully take things down, and let bilateral and RS sessions time out without killing active traffic. As we've noticed, not all members being moved are bothering to shut down sessions prior, which causes impact to/from those members. (i.e.: https://ripe67.ripe.net/presentations/374-WH-IXPMaintReduce.pdf) A small minority of members are also doing BFD which can lessen impact here. If your gear supports it, I'd suggest looking into as a way to minimize impact of things like this.

Yesterday's maintenance caused our switch to have problems and we were not even part of the move??

You're on the Mankato remote switch. That was listed in the maintenance notification as being affected.

Is MICE issuing credits for outages??

Surely, you're joking, right? -- As an aside, thanks Jeremy for doing all this move work, it's not a small effort and definitely appreciated.

-----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jeremy Lumby Sent: Tuesday, April 25, 2017 1:20 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 3 Moves

The maintenance is now starting

-----Original Message----- From: Jeremy Lumby [mailto:jlumby@mnvoip.com] Sent: Saturday, April 15, 2017 6:03 PM To: MICE Discuss Subject: Arista Round 3 Moves

I am planning on doing round 3 of moves to the Arista switch on the afternoon of 4/25/17 beginning at 1PM. The following connections to the main switch will be moved:

Netflix (Will simultaneously upgrade to 2x100G) Google Hurricane Electric CNS (remote switch feed) Neutral Path (remote switch feed) Vast Broadband DCN Charter Broadband Visions Jaguar Yahoo SDN TDS CloudFlare Fastly Mankato Networks (remote switch feed) MN VoIP (remote switch feed)

I suggest that all members listed above, as well as the members connected to the remote switches above shutdown BGP by 12:00PM CST to avoid dropped packets while being moved. Please leave the interface up so that we can test link, as well as the ability to ping the interface IP. Additional notice will be sent immediately before and after the maintenance.

Jeremy Lumby Minnesota VoIP 9217 17th Ave S Suite 216 Bloomington, MN 55425 Main: 612-355-7740 x211 Direct: 612-392-6814 EFax: 952-873-7425 jlumby@mnvoip.com

-- Andrew Hoyos hoyosa@gmail.com

On Apr 26, 2017, at 9:19 AM, Mike Horwath <drechsau@Geeks.ORG> wrote:

On Wed, Apr 26, 2017 at 08:07:45AM -0500, Andrew Hoyos wrote:

...

I would suggest that perhaps we look into filtering BGP (tcp/179) with an ACL prior to maintenance start on those specific ports being moved. Many other IXs are doing this for maintenance as a way to gracefully take things down, and let bilateral and RS sessions time out without killing active traffic. As we've noticed, not all members being moved are bothering to shut down sessions prior, which causes impact to/from those members. (i.e.: https://ripe67.ripe.net/presentations/374-WH-IXPMaintReduce.pdf)

Don't even need ACLs.

Just take down the route servers for the 2 hour period.

Bilateral are unaffected and they can arrange things anyway with their peers.

I’d disagree. The maintenance currently taking place affects more than just the route servers. Plenty of people are doing bi-lateral peering on MICE, and that *IS* affected by maintenance events like these. Adding an ACL to the port ensures graceful shutdown/end of traffic, rather than an abrupt drop and hold timer fun. I’d much rather that someone running the maintenance and in control of the ultimate link up/down events be the one deciding when things are starting/ending and re-enabling traffic gracefully.

Adding another step to the process creates more complications as well, and another point of failure if you screw up along the way.

Disagree, adding an ACL to a port is pretty trivial. Add (pre-existing) ACL to port 10 minutes before maintenance starts. Remove when complete. Script up into copy/paste thing with port numbers for bonus points and less changes of failure.

Clean shutdown of bird is easier, quicker, and will for sure make the multilateral peering not be further affected by bouncing repeatedly.

Yes, great for MLPA, but not for bilateral. Lastly, In this *specific* case, this presents issues with other members ports who are *NOT* affected by the maintenance and a loss of traffic for them if they are doing MLPA. Why break everyone and cause a total route server outage, when it’s not necessary at all? Yesterday’s maintenance only affected a portion of members. ACL’s on member ports would be the cleanest way to minimize outage duration for all members with the least impact to the IX as a whole.

On Wed, Apr 26, 2017 at 9:34 AM, Andrew Hoyos <hoyosa@gmail.com> wrote:

...

Clean shutdown of bird is easier, quicker, and will for sure make the multilateral peering not be further affected by bouncing repeatedly.

Yes, great for MLPA, but not for bilateral.

Lastly, In this *specific* case, this presents issues with other members ports who are *NOT* affected by the maintenance and a loss of traffic for them if they are doing MLPA. Why break everyone and cause a total route server outage, when it’s not necessary at all? Yesterday’s maintenance only affected a portion of members. ACL’s on member ports would be the cleanest way to minimize outage duration for all members with the least impact to the IX as a whole.

Sadly, I can't thumbs-up this post as I can on FB... -Tk

Forcing an issue is going to happen when the port goes down. The point is the ACL can make it more graceful for those directly affected and also those indirectly affected by the port going down by ensuring all BGP connections (MLPA and bilateral) are terminated with the directly affected members before the link goes down for the directly affected members. In this context: directly affected member = those whose path to the main fabric are going to be physically moved (includes downstream members on an extension switch that is being moved) indirectly affected member = everyone else who are not going to have their own path to the fabric go down I am not sure who would intentionally prefer a less graceful option of losing all/most MICE connectivity. The addition of very short lived ACL's on the exchange fabric ports for directly affected members does not preclude members from implementing their own proactive measures; people are certainly free to heed the announcement that they are going to be directly affected and pre-emptively shutdown all of their own BGP sessions at whatever time they want in advance and re-activate them anytime they choose afterwards be it minutes, hours or days later. The addition of the exchange enacted ACLs will help minimize the impact to the indirectly affected members who have bilateral peering with directly affected members. ________________________________________ From: MICE Discuss [MICE-DISCUSS@LISTS.IPHOUSE.NET] on behalf of Mike Horwath [drechsau@GEEKS.ORG] Sent: Wednesday, April 26, 2017 6:03 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 3 Moves On Wed, Apr 26, 2017 at 09:34:21AM -0500, Andrew Hoyos wrote:

I???d disagree. The maintenance currently taking place affects more than just the route servers. Plenty of people are doing bi-lateral peering on MICE, and that *IS* affected by maintenance events like these.

Right - but that's for the bilateral peers to work on. Forcing the issue by adding an ACL that they may not have asked for seems kind of .. intruding.

Adding an ACL to the port ensures graceful shutdown/end of traffic, rather than an abrupt drop and hold timer fun. I???d much rather that someone running the maintenance and in control of the ultimate link up/down events be the one deciding when things are starting/ending and re-enabling traffic gracefully.

I don't know if everyone accepts that. I'm playing devils advocate only.

...

Clean shutdown of bird is easier, quicker, and will for sure make the multilateral peering not be further affected by bouncing repeatedly.

Yes, great for MLPA, but not for bilateral.

Bilateral users are already adding to their complication by having many more peers than just going multilateral.

Why break everyone and cause a total route server outage, when it???s not necessary at all? Yesterday???s maintenance only affected a portion of members. ACL???s on member ports would be the cleanest way to minimize outage duration for all members with the least impact to the IX as a whole.

That member would have still been affected and would not have helped reduce the noise. -- Mike Horwath, reachable via drechsau@Geeks.ORG

On Thu, Apr 27, 2017 at 12:00 PM, Richard Laager <rlaager@wiktel.com> wrote:

Thanks for the great explanation.

I wanted to reiterate a couple things:

This ACL approach is standard practice at SIX. We know it works on the Arista switch. The plan is to use it there moving forward.

Can confirm, method as outlined is sound and reasonable for MADIX and MKEIX, both 'semi distributed' and resemble MICE (conceptually, obv not in bits/sec scaling). -Tk

Doug, Please do go ahead and expand passive BFD. Everyone on one route server followed by the second route server a few days later should be fine. -- Richard

On Apr 26, 2017, at 10:51, Doug McIntyre <merlyn@IPHOUSE.NET> wrote:

...

On Wed, Apr 26, 2017 at 09:19:39AM -0500, Mike Horwath wrote: Bilateral are unaffected and they can arrange things anyway with their peers.

I think there is a lot more bilateral BGP going on across MICE than you think. While I probably go talk to anybody, I have 11 unilateral peers on MICE besides the two route servers.

I think BFD for BGP would do a lot more good than BGP filtering if people would implement it.

Speaking of that, I have passive BFD testing on route server #1 for quite some time. I've heard of zero problems.

I would like to go more widespread than the test people (ie. offer it to every member connection on route server #1)

Since it is passive, the member end drives it, if they do it, the route server will do it, if they don't, nothing else happens. I'd also like to roll out passive BFD as default for new members.

-- Doug McIntyre <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

John, There are several factors as to why this is done during the day. It all goes back to your 35 years of experience in the industry. The fact is that over 99% of the industry is for profit. Not only has MICE always aimed for nonprofit status, they are also 100% volunteer based. I have been volunteering for MICE since they came to be 7 years ago. Also up until this last year MICE did not charge any fees, and now the fee is so minimal, and not even completely mandatory, it is just more than enough to cover the maintenance contract on the switch. When everything is 100% volunteer, it is difficult enough to get volunteers, let alone ones willing to show up in the middle of the night. Cologix was kind enough to offer to move all cross connects for free as long as it was done during normal business hours. Members always had the option to pay Cologix to move their cross connect in the middle of the night. As far as I know no one took Cologix up on that. I feel the main reason is since we are all multi-homed running BGP, as long as enough notice is given, BGP can be gracefully shutdown prior to the maintenance, and there are no real issues. I am sorry that your equipment did not perform as expected. The remote switch you are connected to was part of the maintenance, and the maintenance notification did state that all members connected to the remote switches listed should shutdown BGP ahead of time as well. As for a refund, whenever I run into a potential member looking for a service level agreement, I point out how all service agreements in the industry offer you a portion of what you paid depending on the duration of the outage. Since MICE has been free for the last 7 years, any portion would still be 0. Jeremy -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of John Unger Sent: Wednesday, April 26, 2017 6:52 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 3 Moves Jeremy, why are we doing these moves during the day? This does not make sense to me? Having been in this industry for over 35 years this is just crazy? Nobody does maintenance during the day? Yesterday's maintenance caused our switch to have problems and we were not even part of the move?? Is MICE issuing credits for outages?? -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jeremy Lumby Sent: Tuesday, April 25, 2017 1:20 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 3 Moves The maintenance is now starting -----Original Message----- From: Jeremy Lumby [mailto:jlumby@mnvoip.com] Sent: Saturday, April 15, 2017 6:03 PM To: MICE Discuss Subject: Arista Round 3 Moves I am planning on doing round 3 of moves to the Arista switch on the afternoon of 4/25/17 beginning at 1PM. The following connections to the main switch will be moved: Netflix (Will simultaneously upgrade to 2x100G) Google Hurricane Electric CNS (remote switch feed) Neutral Path (remote switch feed) Vast Broadband DCN Charter Broadband Visions Jaguar Yahoo SDN TDS CloudFlare Fastly Mankato Networks (remote switch feed) MN VoIP (remote switch feed) I suggest that all members listed above, as well as the members connected to the remote switches above shutdown BGP by 12:00PM CST to avoid dropped packets while being moved. Please leave the interface up so that we can test link, as well as the ability to ping the interface IP. Additional notice will be sent immediately before and after the maintenance. Jeremy Lumby Minnesota VoIP 9217 17th Ave S Suite 216 Bloomington, MN 55425 Main: 612-355-7740 x211 Direct: 612-392-6814 EFax: 952-873-7425 jlumby@mnvoip.com

On Wed, Apr 26, 2017 at 11:52:16AM +0000, John Unger wrote:

Jeremy, why are we doing these moves during the day? This does not make sense to me? Having been in this industry for over 35 years this is just crazy? Nobody does maintenance during the day?

Which industry? Because the Internet industry isn't 35 years old. Many people do maintenance during the day. So many. It's a 24x7 world now and for many businesses the time of day for work doesn't necessarily follow the sun.

Yesterday's maintenance caused our switch to have problems and we were not even part of the move??

Are you direct connected or are you via remote switch? If you are via remote switch then did your switch operator notify you?

Is MICE issuing credits for outages??

Planned don't count. And no SLA means .. no 'credit'. If you are via remote switch then you should take it up with them and not the community as a whole. But beyond that snark: this is volunteer work and as such Jeremy is already taking time out of his business day to do things for this group. Jeremy - you have my heartfelt thanks. You're doing this alone and you're doing this instead of taking the time to build your business further. I'd buy you a beer if we ever saw each other IRL. -- Mike Horwath, reachable via drechsau@Geeks.ORG

The maintenance has completed, please let me know if you are experiencing any errors. -----Original Message----- From: Jeremy Lumby [mailto:jlumby@mnvoip.com] Sent: Tuesday, May 09, 2017 12:51 PM To: MICE Discuss Subject: RE: Arista Round 4 Moves - FINAL Just a quick reminder that maintenance will begin in 10 Minutes -----Original Message----- From: Jeremy Lumby [mailto:jlumby@mnvoip.com] Sent: Tuesday, April 25, 2017 8:20 PM To: MICE Discuss Subject: Arista Round 4 Moves - FINAL I am planning on doing the final round of moves to the Arista switch on the afternoon of 5/9/2017 beginning at 1PM. The second route server will be moved to the new cabinet, as well as the following connections to the main switch will also be moved: Great Plains Acentek Consolidated Communications Long Lines HBC Savage UW System Radio Link LTD Broadband Integra Inteliquent Hoyos Consulting Visionary (Mammoth) Code42 Emergent HCMC Unggoy I suggest that all members listed above shutdown BGP by 12:00PM CST to avoid dropped packets while being moved. Please leave the interface up so that we can test link, as well as the ability to ping the interface IP. Additional notice will be sent immediately before and after the maintenance. Jeremy Lumby Minnesota VoIP 9217 17th Ave S Suite 216 Bloomington, MN 55425 Main: 612-355-7740 x211 Direct: 612-392-6814 EFax: 952-873-7425 jlumby@mnvoip.com

Yes this is awesome!! Thanks for all of the efforts!! Jeremy, I recall before there was some discussions around some small amount of packet loss when traffic moved across a certain path from one member to another and it seemed one of the Juniper components was most likely the involved: stacking cables, a particular switch, or something. Without checking the list archives, I believe you were involved in identifying some of this, some of which was improved by re-working a bit of the fabric topology. Since the Arista moves are basically all done, I am curious to hear if any of that previous packet loss is still happening now that many of the previous fabric components are decommissioned. Also, not urgent but I think it would be great if the technical page details could be updated at some point: config details, exchange topology diagram, etc. ________________________________________ From: MICE Discuss [MICE-DISCUSS@LISTS.IPHOUSE.NET] on behalf of Mike Horwath [drechsau@GEEKS.ORG] Sent: Tuesday, May 09, 2017 6:25 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 4 Moves - FINAL On Tue, May 09, 2017 at 04:11:00PM -0500, Jeremy Lumby wrote:

The maintenance has completed, please let me know if you are experiencing any errors.

THANKS! -- Mike Horwath, reachable via drechsau@Geeks.ORG

We had some reports of a small percentage on traffic through MICE to/from Charter during the early stages of the move. With the previously noted issues in mind we monitored the situation a bit. The loss is gone now, and we haven't seen any additional since. Ben Wiechman Network Engineer IV Direct: 320.256.0184 Cell: 320.247.3224 ben.wiechman@arvig.com 150 Second Street SW | Perham, MN 56573 | arvig.com On Wed, May 10, 2017 at 10:32 AM, Justin Krejci <JKrejci@usinternet.com> wrote:

Yes this is awesome!! Thanks for all of the efforts!!

Jeremy, I recall before there was some discussions around some small amount of packet loss when traffic moved across a certain path from one member to another and it seemed one of the Juniper components was most likely the involved: stacking cables, a particular switch, or something. Without checking the list archives, I believe you were involved in identifying some of this, some of which was improved by re-working a bit of the fabric topology. Since the Arista moves are basically all done, I am curious to hear if any of that previous packet loss is still happening now that many of the previous fabric components are decommissioned.

Also, not urgent but I think it would be great if the technical page details could be updated at some point: config details, exchange topology diagram, etc.

________________________________________ From: MICE Discuss [MICE-DISCUSS@LISTS.IPHOUSE.NET] on behalf of Mike Horwath [drechsau@GEEKS.ORG] Sent: Tuesday, May 09, 2017 6:25 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 4 Moves - FINAL

On Tue, May 09, 2017 at 04:11:00PM -0500, Jeremy Lumby wrote:

...

The maintenance has completed, please let me know if you are experiencing any errors.

THANKS!

-- Mike Horwath, reachable via drechsau@Geeks.ORG

I may be very biased but I would love to see that picture very much. If you had Emmet standing on top of the 7504, I think we could work with that ;-) Corey Hines Systems Engineer Arista Networks m 612-209-6550 o 408-547-8075 chines@arista.com TAC: support@arista.com www.arista.com Arista EOS: A Tale of Opposite Architectures <https://www.youtube.com/watch?v=Hfwr6sY27hA&authuser=1> Download the EOS Configuration Manual <https://www.arista.com/assets/data/docs/Manuals/EOS-4.15.4F-Manual.pdf> Install vEOS-lab for testing & training <https://eos.arista.com/running-veos-on-esxi-5-5/> On Wed, May 10, 2017 at 11:25 AM, Justin Krejci <JKrejci@usinternet.com> wrote:

That is great news. Not to sound too cliché but the Lego Movie song is playing in my head now.... Everything is awesome!

Maybe a photo of the MICE Arista could be posted to the website. Who doesn't want some SFW nerd porn.

------------------------------ *From:* MICE Discuss [MICE-DISCUSS@LISTS.IPHOUSE.NET] on behalf of Ben Wiechman [ben.wiechman@ARVIG.COM] *Sent:* Wednesday, May 10, 2017 10:39 AM

*To:* MICE-DISCUSS@LISTS.IPHOUSE.NET *Subject:* Re: [MICE-DISCUSS] Arista Round 4 Moves - FINAL

We had some reports of a small percentage on traffic through MICE to/from Charter during the early stages of the move. With the previously noted issues in mind we monitored the situation a bit. The loss is gone now, and we haven't seen any additional since.

Ben Wiechman Network Engineer IV Direct: 320.256.0184 <(320)%20256-0184> Cell: 320.247.3224 <(320)%20247-3224> ben.wiechman@arvig.com

150 Second Street SW | Perham, MN 56573 | arvig.com

On Wed, May 10, 2017 at 10:32 AM, Justin Krejci <JKrejci@usinternet.com> wrote:

...

Yes this is awesome!! Thanks for all of the efforts!!

Jeremy, I recall before there was some discussions around some small amount of packet loss when traffic moved across a certain path from one member to another and it seemed one of the Juniper components was most likely the involved: stacking cables, a particular switch, or something. Without checking the list archives, I believe you were involved in identifying some of this, some of which was improved by re-working a bit of the fabric topology. Since the Arista moves are basically all done, I am curious to hear if any of that previous packet loss is still happening now that many of the previous fabric components are decommissioned.

Also, not urgent but I think it would be great if the technical page details could be updated at some point: config details, exchange topology diagram, etc.

________________________________________ From: MICE Discuss [MICE-DISCUSS@LISTS.IPHOUSE.NET] on behalf of Mike Horwath [drechsau@GEEKS.ORG] Sent: Tuesday, May 09, 2017 6:25 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Arista Round 4 Moves - FINAL

On Tue, May 09, 2017 at 04:11:00PM -0500, Jeremy Lumby wrote:

...

The maintenance has completed, please let me know if you are experiencing any errors.

THANKS!

-- Mike Horwath, reachable via drechsau@Geeks.ORG

------------------------------

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 May 10, 2017, at 10:32, Justin Krejci <JKrejci@USINTERNET.COM> wrote:

Also, not urgent but I think it would be great if the technical page details could be updated at some point: config details, exchange topology diagram, etc.

I removed the Juniper 10G stack from the participants page. We still have the Juniper 1G stack, so the Juniper config details there are still relevant. Jeremy, can you send me the Arista config off-list, or at least the portion that is equivalent to the Juniper and Cisco sections on: http://micemn.net/technical.html Mike Johnston from Wiktel will be updating the diagram soon (probably Friday). -- Richard