- mice-discuss - lists.micemn.net

Re: Peering With Apple

by Ben Wiechman

Thanks for the follow up. I have a contact and see there are additional clarifications on the communication process on perringdb that I originally missed somehow. Thanks again. On Dec 1, 2015 7:00 PM, "Reid Fishler" <rfishler(a)he.net> wrote: > I have one, and I will talk to her when I return. They are in freeze for > the holiday now anyhow. > > Reid > > On Tue, Dec 1, 2015 at 1:23 PM, Ben Wiechman <ben.wiechman(a)arvig.com> > wrote: > >> Does anyone have a peering contact for Apple? We've sent a number of >> requests to the address listed on peeringdb.com and haven't received a >> response. >> >> > > > -- > Reid Fishler > Director > Hurricane Electric > +1-510-580-4178 > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Dec. 2, 2015

Re: Peering With Apple

by Justin Krejci

You may very well have info I do not in this regard but their Peering DB page says this "Apple is on change management freeze until 1-Dec-15" Which would indicate their freeze is about to thaw or perhaps already has. -----Original Message----- From: Reid Fishler [rfishler(a)HE.NET] Received: Tuesday, 01 Dec 2015, 7:00PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] Subject: Re: [MICE-DISCUSS] Peering With Apple I have one, and I will talk to her when I return. They are in freeze for the holiday now anyhow. Reid On Tue, Dec 1, 2015 at 1:23 PM, Ben Wiechman <ben.wiechman(a)arvig.com<mailto:ben.wiechman@arvig.com>> wrote: Does anyone have a peering contact for Apple? We've sent a number of requests to the address listed on peeringdb.com<http://peeringdb.com> and haven't received a response. -- Reid Fishler Director Hurricane Electric +1-510-580-4178 ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 2, 2015

Re: Peering With Apple

by Reid Fishler

I have one, and I will talk to her when I return. They are in freeze for the holiday now anyhow. Reid On Tue, Dec 1, 2015 at 1:23 PM, Ben Wiechman <ben.wiechman(a)arvig.com> wrote: > Does anyone have a peering contact for Apple? We've sent a number of > requests to the address listed on peeringdb.com and haven't received a > response. > > -- Reid Fishler Director Hurricane Electric +1-510-580-4178

Dec. 2, 2015

Re: Peering With Apple

by Ben Wiechman

I have received a follow-up communication from Apple. Thanks for all who responded. Ben Wiechman Network Engineer IV | Arvig Direct: 320.256.0184 Cell: 320.247.3224 Office: 320.256.7471 ben.wiechman(a)arvig.com On Tue, Dec 1, 2015 at 12:57 PM, Ben Wiechman <ben.wiechman(a)arvig.com> wrote: > We reached out on the indicated peering@ address with no response. I > didn't see the second contact. > > Appreciate it. > > > Ben Wiechman > Network Engineer IV | Arvig > Direct: 320.256.0184 > Cell: 320.247.3224 > Office: 320.256.7471 > ben.wiechman(a)arvig.com > > On Tue, Dec 1, 2015 at 12:53 PM, Hannigan, Martin <marty(a)akamai.com> > wrote: > >> >> >> Ben, >> >> clue-store> finger as714(a)peeringdb.com | grep peering@ >> Policy Peering Review Team peering(a)group.apple.com email only >> >> clue-store> finger as714(a)peeringdb.com | grep renst >> Policy Ren Provo renster(a)apple.com email only >> >> Ren Provo is typically out in front of Apple peering. If one of those >> doesn’t do it, not sure how to help. >> >> Best, >> >> -M< >> >> >> >> On Dec 1, 2015, at 1:23 PM, Ben Wiechman <ben.wiechman(a)ARVIG.COM> wrote: >> >> Does anyone have a peering contact for Apple? We've sent a number of >> requests to the address listed on peeringdb.com and haven't received a >> response. >> >> >> >> ------------------------------ >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >> > >

Dec. 1, 2015

Re: Peering With Apple

by Ben Wiechman

We reached out on the indicated peering@ address with no response. I didn't see the second contact. Appreciate it. Ben Wiechman Network Engineer IV | Arvig Direct: 320.256.0184 Cell: 320.247.3224 Office: 320.256.7471 ben.wiechman(a)arvig.com On Tue, Dec 1, 2015 at 12:53 PM, Hannigan, Martin <marty(a)akamai.com> wrote: > > > Ben, > > clue-store> finger as714(a)peeringdb.com | grep peering@ > Policy Peering Review Team peering(a)group.apple.com email only > > clue-store> finger as714(a)peeringdb.com | grep renst > Policy Ren Provo renster(a)apple.com email only > > Ren Provo is typically out in front of Apple peering. If one of those > doesn’t do it, not sure how to help. > > Best, > > -M< > > > > On Dec 1, 2015, at 1:23 PM, Ben Wiechman <ben.wiechman(a)ARVIG.COM> wrote: > > Does anyone have a peering contact for Apple? We've sent a number of > requests to the address listed on peeringdb.com and haven't received a > response. > > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Dec. 1, 2015

Re: Peering With Apple

by Hannigan, Martin

Ben, clue-store> finger as714(a)peeringdb.com | grep peering@ Policy Peering Review Team peering(a)group.apple.com email only clue-store> finger as714(a)peeringdb.com | grep renst Policy Ren Provo renster(a)apple.com email only Ren Provo is typically out in front of Apple peering. If one of those doesn’t do it, not sure how to help. Best, -M< > On Dec 1, 2015, at 1:23 PM, Ben Wiechman <ben.wiechman(a)ARVIG.COM> wrote: > > Does anyone have a peering contact for Apple? We've sent a number of requests to the address listed on peeringdb.com and haven't received a response.

Dec. 1, 2015

Peering With Apple

by Ben Wiechman

Does anyone have a peering contact for Apple? We've sent a number of requests to the address listed on peeringdb.com and haven't received a response.

Dec. 1, 2015

Re: BGP communities on Route Servers

by Andrew Hoyos

> On Nov 25, 2015, at 12:42 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > > If you want to supply BIRD magic to do that, it would be appreciated. Check these functions (bgp_out_comm and bgp_out) out here: https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base… <https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base…> That seems like it would work in this specific case, along with extended community support for the 32-bit ASNs. Announce a route only to a certain peer: 53679:<peer-asn> Announce a route to all peers: 53679:53679 Block announcement of a route to a certain peer: 0:<peer-asn> Block announcement of a route to all peers: 0:53679 I’d be happy to be a guinea pig, or help implement. I’m not sure of the current RS config, but I’d imagine this would be easily adaptable into the current config. There are also some examples there of enforcing first ASN and filtering RFC1918 junk, which if we’re not already doing, might be wise. Thanks, Andrew

Nov. 30, 2015

Re: VM donation- change control/graph data backup

by Doug McIntyre

On Tue, Nov 17, 2015 at 12:13:20PM -0600, Andrew Hoyos wrote: > > On Nov 17, 2015, at 11:20 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > > > > On Tue, Nov 17, 2015 at 09:38:16AM -0600, Andrew Hoyos wrote: > >> I’d like to offer up a VM donation located in Madison, WI to at least run RANCID to grab config backups of the IX switches, as well as a backup target for any data (graphs, route-server config, etc). I guess nobody else spoke up, but I'd say sure, redundancy is always good most likely. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Nov. 26, 2015

Re: BGP communities on Route Servers

by Doug McIntyre

On Tue, Nov 24, 2015 at 09:18:34PM -0600, Andrew Hoyos wrote: > Some time ago, I recall a discussion and/or email thread about BGP action communities on the route servers (i.e.: don’t advertise to certain peers, prepends, etc). > Are these in place, and if so, documented anywhere? If not, could I volunteer some cycles to get in place? No, we haven't come up with the BIRD configs to support that. There was just one specific case setup and done. If you want to supply BIRD magic to do that, it would be appreciated. Some areas identified already as sticking points have been 32-bit AS's do need to be supported (We do have at least one member with a 32-bit AS). Otherwise, it looks like BIRD should be able to do it. We are running a fairly up-to-date version. The main impetuous before was to prevent route distribution to such-and-such CDN so they don't overload your pipe. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Nov. 25, 2015

Re: BGP communities on Route Servers

by Mike Horwath

On Tue, Nov 24, 2015 at 10:33:01PM -0600, Richard Laager wrote: > I believe something is implemented, at least on a test basis for > certain members. I don't think it's been fully implemented for > everyone and documented. If you have time to do this then I commend you and would love to see the output. 666:<asn> - drop routes 12345:<asn> - add routes with passphrase 1:<asn> - default NULL route - cause there can be only ... -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Nov. 25, 2015

Re: BGP communities on Route Servers

by Richard Laager

I believe something is implemented, at least on a test basis for certain members. I don't think it's been fully implemented for everyone and documented. -- Richard

Nov. 25, 2015

Re: BGP communities on Route Servers

by Mike Horwath

On Tue, Nov 24, 2015 at 09:18:34PM -0600, Andrew Hoyos wrote: > Hi folks, > > Some time ago, I recall a discussion and/or email thread about BGP > action communities on the route servers (i.e.: don???t advertise to > certain peers, prepends, etc). > Are these in place, and if so, documented anywhere? If not, could I > volunteer some cycles to get in place? > > I looked through the archives a bit, and poked on the website, but > didn???t see anything. I don't think this went anywhere but as a discussion. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Nov. 25, 2015

BGP communities on Route Servers

by Andrew Hoyos

Hi folks, Some time ago, I recall a discussion and/or email thread about BGP action communities on the route servers (i.e.: don’t advertise to certain peers, prepends, etc). Are these in place, and if so, documented anywhere? If not, could I volunteer some cycles to get in place? I looked through the archives a bit, and poked on the website, but didn’t see anything. Thanks, Andrew — Andrew Hoyos Hoyos Consulting LLC ofc: +1 608 616 9950 andrew(a)hoyosconsulting.com http://www.hoyosconsulting.com

Nov. 25, 2015

NorthernLights GigaPoP maintenance 11/22 8 am

by Colin Murphy

Hello, Sending out a heads up that the NorthernLights GigaPoP/University of Minnesota connection to MICE will be down for maintenance this Sunday from 8 am to 9 am. I will be relocating our two 10 gig links to MICE to a new router. If there are any questions or issues please let me know. Thanks, Colin Murphy Network Engineer Office of Information Technology University of Minnesota NorthernLights GigaPoP Desk: 612-626-0870

Nov. 20, 2015

Re: MICE UG 18 - Minutes

by Richard Laager

I'm looking for some input/consensus on what we should post on the website. Keeping in mind that by "website", I'm thinking "publicly available". We don't have any sort of logins on the website, nor am I volunteering to go down that rabbit hole. 1) Do we want the approved minutes on the website? If so, I have UG 17 & UG 18, but if Shaun, Jay, etc. have older ones handy, I'll put those up too. 2) Do we want the _proposed_ minutes on the website? 3) Do we want the attendance list on the website? 4) Would you prefer the original file formats (.docx, .xlsx) or is it important that I convert them to HTML? 5) The website currently has a zip file with the articles of incorporation, etc. from 2012. It's not linked from anywhere, though. Delete it or link it? 6) Do we want the updated articles/bylaws, etc. on the website? If so, I'll need a copy. -- Richard

Nov. 18, 2015

Re: VM donation- change control/graph data backup

by Shaun Carlson

I agree with the MICE-TECH list just to protect some of the configuration discussion. Perhaps we could say that any member can request the history at any time? I also think we would have to be sure to post planned changes, or at least notifications, to the discuss list as we do now. s *Shaun Carlson*Senior Manager of Information Technology | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com On Tue, Nov 17, 2015 at 12:13 PM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: > > On Nov 17, 2015, at 11:20 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > > > > On Tue, Nov 17, 2015 at 09:38:16AM -0600, Andrew Hoyos wrote: > >> I’d like to offer up a VM donation located in Madison, WI to at least > run RANCID to grab config backups of the IX switches, as well as a backup > target for any data (graphs, route-server config, etc). > > > > Sure. Although I do have some backups of the main switch/bird configs > located here > > in my location (not at 511, but still Minneapolis). I have considered > > adding the configs I touch to my RANCID, but didn't find enough value I > suppose. > > I think one of the things that was touched on in the meeting yesterday was > change control. RANCID diffs running on a 15/30 minute basis could be a > cheap verification. > Probably even from multiple places wouldn’t hurt. > > > I already had a tech list setup (MICE-TECH), but then I started > > thinking about who should have access to what, and what should be an > > archive (public? Semi-public?) of tech discussions, vs. something that > > may have a little sensitive value (ie. config snippets with SNMP > > communities, CoPP firewall rules, etc.). vs. most of it (ie. BGP setup > > & questions/problems). > > I’d support this, and would happily participate in these discussions. > Maybe just a members only list, added only by someone in some official > capacity? > Private archives would solve some issue there, and RANCID will by default, > redact passwords/community strings. >

Nov. 17, 2015

Re: VM donation- change control/graph data backup

by Andrew Hoyos

> On Nov 17, 2015, at 11:20 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > > On Tue, Nov 17, 2015 at 09:38:16AM -0600, Andrew Hoyos wrote: >> I’d like to offer up a VM donation located in Madison, WI to at least run RANCID to grab config backups of the IX switches, as well as a backup target for any data (graphs, route-server config, etc). > > Sure. Although I do have some backups of the main switch/bird configs located here > in my location (not at 511, but still Minneapolis). I have considered > adding the configs I touch to my RANCID, but didn't find enough value I suppose. I think one of the things that was touched on in the meeting yesterday was change control. RANCID diffs running on a 15/30 minute basis could be a cheap verification. Probably even from multiple places wouldn’t hurt. > I already had a tech list setup (MICE-TECH), but then I started > thinking about who should have access to what, and what should be an > archive (public? Semi-public?) of tech discussions, vs. something that > may have a little sensitive value (ie. config snippets with SNMP > communities, CoPP firewall rules, etc.). vs. most of it (ie. BGP setup > & questions/problems). I’d support this, and would happily participate in these discussions. Maybe just a members only list, added only by someone in some official capacity? Private archives would solve some issue there, and RANCID will by default, redact passwords/community strings.

Nov. 17, 2015

Re: VM donation- change control/graph data backup

by Doug McIntyre

On Tue, Nov 17, 2015 at 09:38:16AM -0600, Andrew Hoyos wrote: > I’d like to offer up a VM donation located in Madison, WI to at least run RANCID to grab config backups of the IX switches, as well as a backup target for any data (graphs, route-server config, etc). Sure. Although I do have some backups of the main switch/bird configs located here in my location (not at 511, but still Minneapolis). I have considered adding the configs I touch to my RANCID, but didn't find enough value I suppose. I already had a tech list setup (MICE-TECH), but then I started thinking about who should have access to what, and what should be an archive (public? Semi-public?) of tech discussions, vs. something that may have a little sensitive value (ie. config snippets with SNMP communities, CoPP firewall rules, etc.). vs. most of it (ie. BGP setup & questions/problems). So I didn't really move forward too much in having people use it. I had thought of doing RANCID into the MICE-TECH list, but again, archives and access to them came up in my mind as problematic things. What are others' thoughts? -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Nov. 17, 2015

Re: VM donation- change control/graph data backup

by Justin Krejci

Currently the cacti graph data is all physically stored in Minnetonka in the US Internet data center, where the server lives. We have a dedicated VM instance currently for the MICE cacti server. This server (rrd files, mysql data, etc) is backed up to our own internal server backup system. Adding additional MICE services to this VM are definitely acceptable: rancid, syslog, etc. if so requested by MICE. This is perhaps getting deeper into implementation design than is appropriate at this point in the discussion but I suggest syslog data be sent and stored locally to the exchange to minimize the potential for data loss in the event of a network issue. Adding a secondary external syslog server might make sense too, such as to the Hoyos referenced VM offer, to the USI cacti server, etc. It could even be stored on a dedicated machine within the MICE network and then copied off site as well: syslog can do this in real time, other files/data could be rsynced or similar on the same backup job, a traditional backup application could be used, etc. ________________________________________ From: MICE Discuss [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] on behalf of Andrew Hoyos [hoyosa(a)GMAIL.COM] Sent: Tuesday, November 17, 2015 9:38 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] VM donation- change control/graph data backup Hi folks, One of the things that was discussed in the meeting yesterday as change control and config backups. Perhaps along those same lines, we should think about also backing up the graph data somewhere. I’m not sure where any of this data physically lives right now, but perhaps it would make sense to put somewhere *other* than the 511 bldg. I’d like to offer up a VM donation located in Madison, WI to at least run RANCID to grab config backups of the IX switches, as well as a backup target for any data (graphs, route-server config, etc). Effort involved should be minimal, but we’d happily take point on getting RANCID set up and configured as well, and sending diffs to the technical committee, as well as whomever else might see value in seeing config changes happen (perhaps a list?) Let me know, and we’ll make it happen. -- Andrew Hoyos hoyosa(a)gmail.com

Nov. 17, 2015

VM donation- change control/graph data backup

by Andrew Hoyos

Hi folks, One of the things that was discussed in the meeting yesterday as change control and config backups. Perhaps along those same lines, we should think about also backing up the graph data somewhere. I’m not sure where any of this data physically lives right now, but perhaps it would make sense to put somewhere *other* than the 511 bldg. I’d like to offer up a VM donation located in Madison, WI to at least run RANCID to grab config backups of the IX switches, as well as a backup target for any data (graphs, route-server config, etc). Effort involved should be minimal, but we’d happily take point on getting RANCID set up and configured as well, and sending diffs to the technical committee, as well as whomever else might see value in seeing config changes happen (perhaps a list?) Let me know, and we’ll make it happen. -- Andrew Hoyos hoyosa(a)gmail.com

Nov. 17, 2015

Re: Website Version Control

by Mike Horwath

On Tue, Nov 17, 2015 at 12:41:26AM -0600, Richard Laager wrote: > I've put the website code here for now: > https://github.com/rlaager/mice-website Awesome, thanks! -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Nov. 17, 2015

Website Version Control

by Richard Laager

I've put the website code here for now: https://github.com/rlaager/mice-website Once we get non-profit status, I should be able to get a free github "organization" account for MICE. That would be more correct. -- Richard

Nov. 17, 2015

Re: Member SLA's

by Reid Fishler

Or, it would need to be a risk that the SLA vendor takes. Remember, the SLA vendor could, in the end, just remove the cross connect if they have access to the customers gear... Reid On Tue, Nov 17, 2015 at 12:52 AM, Richard Laager <rlaager(a)wiktel.com> wrote: > On 11/16/2015 07:19 PM, Nevin Lyne wrote: > >> why would this "SLA vendor" have access to make changes to the Exchanges >> equipment if the SLA vendor is not hired by the Exchange itself? >> > > I assume that, in order to _guarantee_ they could meet the SLA needs of > "Behemoth", the "SLA vendor" would have to employ someone (or better, > multiple someones) with admin access to the switches. > > Let's assume that none of the employers of the existing technical > committee members want to take on the role of "SLA vendor". Let's also > assume the "SLA vendor" doesn't hire any existing technical committee > members. For this to work, the "SLA vendor" would have to convince the MICE > board/membership to add new people (employees of "SLA vendor") to the > technical committee. > > -- > Richard > > -- Reid Fishler Director Hurricane Electric +1-510-580-4178

Nov. 17, 2015

Re: Member SLA's

by Richard Laager

On 11/16/2015 07:19 PM, Nevin Lyne wrote: > why would this "SLA vendor" have access to make changes to the Exchanges equipment if the SLA vendor is not hired by the Exchange itself? I assume that, in order to _guarantee_ they could meet the SLA needs of "Behemoth", the "SLA vendor" would have to employ someone (or better, multiple someones) with admin access to the switches. Let's assume that none of the employers of the existing technical committee members want to take on the role of "SLA vendor". Let's also assume the "SLA vendor" doesn't hire any existing technical committee members. For this to work, the "SLA vendor" would have to convince the MICE board/membership to add new people (employees of "SLA vendor") to the technical committee. -- Richard

Nov. 17, 2015