- mice-discuss - lists.micemn.net

Kansas City Internet eXchange peer and beer

by Brandon Mulligan

Greetings. The Kansas City Internet eXchange is holding a free peer and beer event on Tuesday October 16th. We welcome any network operators from the midwest region.

Oct. 4, 2018

Re: ADV: [MICE-DISCUSS] Anyone else seeing AS36040 (Google/Youtube) bouncing in and out this morning

by Darin Steffl

Looks like Google's traffic dropped from around 60G to under 20G tonight so they must be working on their peering to MICE? On Wed, Oct 3, 2018 at 12:20 PM Frank Bulk <fbulk(a)mypremieronline.com> wrote: > Thanks, I've sent a note to peering(a)google.com. > > Frank > > -----Original Message----- > From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug > McIntyre > Sent: Wednesday, October 03, 2018 11:39 AM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] ADV: [MICE-DISCUSS] Anyone else seeing AS36040 > (Google/Youtube) bouncing in and out this morning > > On Wed, Oct 03, 2018 at 04:12:04PM +0000, Frank Bulk wrote: > >Since 9:29 am a third-party service we use has been noticing that AS36040 > is coming and going. I assume that it's seeing it from MICE's router server > ... any way to confirm? > > 36040 does talk to the route servers, and the route hasn't been > up that long. I don't have any errors logged for 36040 though. > Just the route keeps getting injected and withdrawn. > 104.237.191.0/24 is withdrawn now from 36040. > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>

Oct. 4, 2018

Re: ADV: [MICE-DISCUSS] Anyone else seeing AS36040 (Google/Youtube) bouncing in and out this morning

by Frank Bulk

Thanks, I've sent a note to peering(a)google.com. Frank -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Wednesday, October 03, 2018 11:39 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] ADV: [MICE-DISCUSS] Anyone else seeing AS36040 (Google/Youtube) bouncing in and out this morning On Wed, Oct 03, 2018 at 04:12:04PM +0000, Frank Bulk wrote: >Since 9:29 am a third-party service we use has been noticing that AS36040 is coming and going. I assume that it's seeing it from MICE's router server ... any way to confirm? 36040 does talk to the route servers, and the route hasn't been up that long. I don't have any errors logged for 36040 though. Just the route keeps getting injected and withdrawn. 104.237.191.0/24 is withdrawn now from 36040. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 3, 2018

Re: ADV: [MICE-DISCUSS] Anyone else seeing AS36040 (Google/Youtube) bouncing in and out this morning

by Doug McIntyre

On Wed, Oct 03, 2018 at 04:12:04PM +0000, Frank Bulk wrote: >Since 9:29 am a third-party service we use has been noticing that AS36040 is coming and going. I assume that it's seeing it from MICE's router server ... any way to confirm? 36040 does talk to the route servers, and the route hasn't been up that long. I don't have any errors logged for 36040 though. Just the route keeps getting injected and withdrawn. 104.237.191.0/24 is withdrawn now from 36040. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 3, 2018

Anyone else seeing AS36040 (Google/Youtube) bouncing in and out this morning

by Frank Bulk

Since 9:29 am a third-party service we use has been noticing that AS36040 is coming and going. I assume that it's seeing it from MICE's router server ... any way to confirm? Frank

Oct. 3, 2018

Last call for Arista Training Day!

by John McLaughlin

Hello MICE Members: Interested in learning more about why Arista Networks is quickly becoming the preferred choice in the datacenter, hybrid clouded central offices? Please join Arista Networks for a no-cost, full day of training with hands-on labs, led by Arista Engineers. Minnet When and Where? Wednesday, October 3rd, 9:00AM - 4:00PM Minnetonka Executive Suites - Lake Superior Room <https://maps.google.com/?q=12800+WhiteWater+Drive+Minnetonka,+MN,+55343&ent…> 12800 WhiteWater Drive <https://maps.google.com/?q=12800+WhiteWater+Drive+Minnetonka,+MN,+55343&ent…> Minnetonka, MN, 55343 <https://maps.google.com/?q=12800+WhiteWater+Drive+Minnetonka,+MN,+55343&ent…> Topics include the following: Arista Corporate overview Extensible Operating System (EOS®) overview and CLI Multi-Chassis Aggregation (MLAG) and Virtual ARP (VARP) overview Building Multi-Tenant Services with EVPN and VXLAN Provisioning with Arista CloudVision® Portal (CVP) Arista eAPI Lunch will be provided. **Note: please bring a laptop to access virtual labs. John McLaughlin North Central Sales jmclaughlin(a)arista.com Cell# 612-816-9024 https://www.barrons.com/articles/worlds-best-ceos-growth-leaders-1527304583…

Oct. 1, 2018

Re: Nanog?

by David Farmer

I'll be at NAMOG and ARIN Sent from my iPhone > On Sep 30, 2018, at 12:05, Reid Fishler <rfishler(a)HE.NET> wrote: > > Whose coming? > This week, Vancouver. > > Reid > > > -- > 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

Sept. 30, 2018

Nanog?

by Reid Fishler

Whose coming? This week, Vancouver. Reid -- Reid Fishler Director Hurricane Electric +1-510-580-4178

Sept. 30, 2018

Re: South Front Networks, LLC Remote switch request

by Jay Hanke

In the event of congestion or other techinical issue that is not able to be resolved in the stacked configuration with Mn VoIP, It is the understanding of SFN that SFN would be required to establish direct links. On Fri, Sep 28, 2018, 5:56 PM Justin Krejci <JKrejci(a)usinternet.com> wrote: > This falls into the category of extreme nit picking but the remote switch > website document says this > > > "Operators are responsible for the costs of operating their remote switch > and the links to the core switch. They must monitor their traffic levels > and promptly add capacity to keep the links running congestion-free." > > > Under this wording, SFN would be responsible for the links to the core > switch which would actually be on the MN VoIP switch link in this context > and is something I would expect is not within SFN's ability to manage > seeing as how SFN, presumably, does not manage MN VoIP's equipment or > links. > > As I initially stated, this is more nit picking as I would personally > interpret the intent of the message on the website to be "remote switch > operator egress link(s) towards the core switch" in this context since the > SFN switch would have no links of its own to the core switch. I expect the > context of tiered remote switches like this was not originally considered > when the text was composed/agreed upon and if this topology is permitted, I > would suggest the website language be updated to reflect/consider this. > > With my described interpretation, I have no objections to the tiered > remote-remote-switch setup. If this request is accepted as written, I would > suggest MICE consider capping this tiered remote switch approach at 2 > deep (as in this case) as a max; I feel it would begin to get cumbersome to > manage/track the administrative relationships, troubleshooting, managing > the traffic graphing configurations, etc. My cap suggestion is just a > starting point off, not something I am adamantly positioned on and possibly > this would be better discussed in a separate thread. > > I would also think it wise to look at MICE's big brother SIX and see if > they have encountered this kind of scenario/request before and if so, what > their conclusions were. > > > > > ------------------------------ > *From:* MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of > Richard Laager <rlaager(a)WIKTEL.COM> > *Sent:* Friday, September 28, 2018 3:31 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] South Front Networks, LLC Remote switch > request > > I'm bringing this remote switch request to the discussion list per our > remote switch policy: > http://micemn.net/technical.html > > On 09/28/2018 09:25 AM, Jay Hanke wrote: > > South Front Networks requests approval to install a MICE Remote Switch in > SFN's Albert Lea Datacenter. > > South Front proposes the following: > 1) SFN will acquire a Juniper QFX5100 or Arista comparable switch > dedicated to MICE. > 2) SFN will acquire and pay for any required connectivity back to the MN > VoIP remote switch, MN VoIP and SFN remote switches will share the existing > 40 Gbps MICE link into the main fabric. Both SFN and MN VoIP agree to > upgrade capacity as needed on the uplink to the main switch. > 3) SFN will initially install 20 Gbps of capacity and will upgrade > capacity as needed per the board and technical committee requirements > 4) SFN agrees to enforce the MICE technical port rules > 5) SFN agrees to coordinate connections to the new remote switch > 6) SFN agrees to inform all prospective members that connections going to > the SFN MICE Remote switch are not connected directly to MICE. > 7) SFN agrees to perform any required configuration and troubleshooting > 8) SFN agrees to provide configuration access and snmp access to the MICE > technical committee to ease troubleshooting and to provide publicly > available graphing. > > Thanks! > > -- > Jay Hanke, President > South Front Networks > jayhanke(a)southfront.io > Phone 612-204-0000 > > -- > Richard > > > ------------------------------ > > 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 >

Sept. 29, 2018

South Front Networks, LLC Remote switch request

by Richard Laager

I think that SFN is responsible to ensure congestion-free capacity all the way back to the core switch. MN VoIP is separately responsible for ensuring congestion-free capacity from its remote to the core, but in the worst case scenario where MN VoIP failed to upgrade its links, I would argue that SFN still has a separate obligation to remedy the congestion to their switch, by switching to direct links if necessary. This is all hopefully theoretical, of course. This proposal has MN VoIP's cooperation and re-affirmed commitment to upgrade as needed. -- Richard

Sept. 29, 2018

Re: South Front Networks, LLC Remote switch request

by Justin Krejci

This falls into the category of extreme nit picking but the remote switch website document says this "Operators are responsible for the costs of operating their remote switch and the links to the core switch. They must monitor their traffic levels and promptly add capacity to keep the links running congestion-free." Under this wording, SFN would be responsible for the links to the core switch which would actually be on the MN VoIP switch link in this context and is something I would expect is not within SFN's ability to manage seeing as how SFN, presumably, does not manage MN VoIP's equipment or links. As I initially stated, this is more nit picking as I would personally interpret the intent of the message on the website to be "remote switch operator egress link(s) towards the core switch" in this context since the SFN switch would have no links of its own to the core switch. I expect the context of tiered remote switches like this was not originally considered when the text was composed/agreed upon and if this topology is permitted, I would suggest the website language be updated to reflect/consider this. With my described interpretation, I have no objections to the tiered remote-remote-switch setup. If this request is accepted as written, I would suggest MICE consider capping this tiered remote switch approach at 2 deep (as in this case) as a max; I feel it would begin to get cumbersome to manage/track the administrative relationships, troubleshooting, managing the traffic graphing configurations, etc. My cap suggestion is just a starting point off, not something I am adamantly positioned on and possibly this would be better discussed in a separate thread. I would also think it wise to look at MICE's big brother SIX and see if they have encountered this kind of scenario/request before and if so, what their conclusions were. ________________________________ From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Richard Laager <rlaager(a)WIKTEL.COM> Sent: Friday, September 28, 2018 3:31 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] South Front Networks, LLC Remote switch request I'm bringing this remote switch request to the discussion list per our remote switch policy: http://micemn.net/technical.html On 09/28/2018 09:25 AM, Jay Hanke wrote: South Front Networks requests approval to install a MICE Remote Switch in SFN's Albert Lea Datacenter. South Front proposes the following: 1) SFN will acquire a Juniper QFX5100 or Arista comparable switch dedicated to MICE. 2) SFN will acquire and pay for any required connectivity back to the MN VoIP remote switch, MN VoIP and SFN remote switches will share the existing 40 Gbps MICE link into the main fabric. Both SFN and MN VoIP agree to upgrade capacity as needed on the uplink to the main switch. 3) SFN will initially install 20 Gbps of capacity and will upgrade capacity as needed per the board and technical committee requirements 4) SFN agrees to enforce the MICE technical port rules 5) SFN agrees to coordinate connections to the new remote switch 6) SFN agrees to inform all prospective members that connections going to the SFN MICE Remote switch are not connected directly to MICE. 7) SFN agrees to perform any required configuration and troubleshooting 8) SFN agrees to provide configuration access and snmp access to the MICE technical committee to ease troubleshooting and to provide publicly available graphing. Thanks! -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io<mailto:jayhanke@southfront.io> Phone 612-204-0000 -- Richard ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 28, 2018

Re: South Front Networks, LLC Remote switch request

by Richard Laager

I'm bringing this remote switch request to the discussion list per our remote switch policy: http://micemn.net/technical.html On 09/28/2018 09:25 AM, Jay Hanke wrote: > South Front Networks requests approval to install a MICE Remote Switch > in SFN's Albert Lea Datacenter. > > South Front proposes the following: > 1) SFN will acquire a Juniper QFX5100 or Arista comparable switch > dedicated to MICE. > 2) SFN will acquire and pay for any required connectivity back to the > MN VoIP remote switch, MN VoIP and SFN remote switches will share the > existing 40 Gbps MICE link into the main fabric. Both SFN and MN VoIP > agree to upgrade capacity as needed on the uplink to the main switch. > 3) SFN will initially install 20 Gbps of capacity and will upgrade > capacity as needed per the board and technical committee requirements > 4) SFN agrees to enforce the MICE technical port rules > 5) SFN agrees to coordinate connections to the new remote switch > 6) SFN agrees to inform all prospective members that connections going > to the SFN MICE Remote switch are not connected directly to MICE. > 7) SFN agrees to perform any required configuration and troubleshooting > 8) SFN agrees to provide configuration access and snmp access to the > MICE technical committee to ease troubleshooting and to provide > publicly available graphing. > > Thanks! > > -- > Jay Hanke, President > South Front Networks > jayhanke(a)southfront.io <mailto:jayhanke@southfront.io> > Phone 612-204-0000 -- Richard

Sept. 28, 2018

Re: Role email accounts on the list

by Steve Howard

Sept. 28, 2018

Re: Role email accounts on the list

by Jay Hanke

As long as they don't open a new ticket for each email it's no problem for me. DISCUSS is the best place to know what's going for a NOC for MICE issues. On Fri, Sep 28, 2018 at 11:23 AM Mike Horwath <drechsau(a)geeks.org> wrote: > How do people feel about this? > > We just had someone join the list using a noc@ email address. > > -- > Mike Horwath, reachable via drechsau(a)Geeks.ORG > -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Sept. 28, 2018

Role email accounts on the list

by Mike Horwath

How do people feel about this? We just had someone join the list using a noc@ email address. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Sept. 28, 2018

Re: UG 29 Meeting & Election

by Dean Bahls

Hey, you still have to earn votes! Shaking hands, kissing babies, making campaign promises you can’t fulfill. Too bad we’ll miss out on the negative ads on WCCO…. Dean From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Reid Fishler Sent: Friday, September 28, 2018 9:30 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] UG 29 Meeting & Election I dont get to make a can with my own face, and make a speech? Darn! :-) Thanks everyone! Reid On Fri, Sep 28, 2018 at 9:52 AM Michael Hemphill <mikeh(a)coloconnect.net <mailto:mikeh@coloconnect.net> > wrote: Congrats Reid! You bring a global perspective to the board and along with your involvement with other exchanges you are invaluable to MICE. Thanks for your service to the MICE Community! Mike Mike Hemphill ColoConnect 612-812-5242 mikeh(a)ColoConnect.net <mailto:mikeh@ColoConnect.net> http://www.ColoConnect.net/ -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> ] On Behalf Of Richard Laager Sent: Friday, September 28, 2018 3:29 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] UG 29 Meeting & Election On 09/24/2018 10:48 PM, Richard Laager wrote: > A member pointed out that it is hard to instruct a proxy without knowing > the final slate of candidates. Accordingly, we will close nominations at > 5:00 PM Central on this Thursday, September 27. Following that, I will > send another email confirming the final slate of candidates. Having heard no other nominations, the final slate of candidates is: - Reid Fishler -- Richard -- 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 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> &A=1

Sept. 28, 2018

Re: UG 29 Meeting & Election

by Reid Fishler

I dont get to make a can with my own face, and make a speech? Darn! :-) Thanks everyone! Reid On Fri, Sep 28, 2018 at 9:52 AM Michael Hemphill <mikeh(a)coloconnect.net> wrote: > Congrats Reid! > You bring a global perspective to the board and along with your > involvement with other exchanges you are invaluable to MICE. > Thanks for your service to the MICE Community! > Mike > > Mike Hemphill > ColoConnect > 612-812-5242 > mikeh(a)ColoConnect.net > http://www.ColoConnect.net/ > > > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Richard Laager > Sent: Friday, September 28, 2018 3:29 AM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] UG 29 Meeting & Election > > On 09/24/2018 10:48 PM, Richard Laager wrote: > > A member pointed out that it is hard to instruct a proxy without knowing > > the final slate of candidates. Accordingly, we will close nominations at > > 5:00 PM Central on this Thursday, September 27. Following that, I will > > send another email confirming the final slate of candidates. > > Having heard no other nominations, the final slate of candidates is: > - Reid Fishler > > -- > Richard > -- Reid Fishler Director Hurricane Electric +1-510-580-4178

Sept. 28, 2018

Re: UG 29 Meeting & Election

by Michael Hemphill

Congrats Reid! You bring a global perspective to the board and along with your involvement with other exchanges you are invaluable to MICE. Thanks for your service to the MICE Community! Mike Mike Hemphill ColoConnect 612-812-5242 mikeh(a)ColoConnect.net http://www.ColoConnect.net/ -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Friday, September 28, 2018 3:29 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] UG 29 Meeting & Election On 09/24/2018 10:48 PM, Richard Laager wrote: > A member pointed out that it is hard to instruct a proxy without knowing > the final slate of candidates. Accordingly, we will close nominations at > 5:00 PM Central on this Thursday, September 27. Following that, I will > send another email confirming the final slate of candidates. Having heard no other nominations, the final slate of candidates is: - Reid Fishler -- Richard

Sept. 28, 2018

Re: UG 29 Meeting & Election

by Mike Horwath

On Fri, Sep 28, 2018 at 03:29:23AM -0500, Richard Laager wrote: > Having heard no other nominations, the final slate of candidates is: > - Reid Fishler Congrats! -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Sept. 28, 2018

Re: UG 29 Meeting & Election

by Richard Laager

On 09/24/2018 10:48 PM, Richard Laager wrote: > A member pointed out that it is hard to instruct a proxy without knowing > the final slate of candidates. Accordingly, we will close nominations at > 5:00 PM Central on this Thursday, September 27. Following that, I will > send another email confirming the final slate of candidates. Having heard no other nominations, the final slate of candidates is: - Reid Fishler -- Richard

Sept. 28, 2018

Re: Fwd: route server IRR objects: RIPE use for ARIN addresses deprecated, ARIN IRR & RPKI tutorials

by Jeremy Lumby

Even if you are not on an exchange that requires IRRs, I would highly recommend utilizing the tutorial for getting IRRs setup with ARIN if you do not already have them. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Tuesday, September 25, 2018 10:43 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Fwd: route server IRR objects: RIPE use for ARIN addresses deprecated, ARIN IRR & RPKI tutorials This is from the SeattleIX announce list. I'm forwarding it, with Chris's permission, in case this is relevant to anyone here. -------- Forwarded Message -------- Subject: route server IRR objects: RIPE use for ARIN addresses deprecated, ARIN IRR & RPKI tutorials Date: Tue, 25 Sep 2018 22:22:14 +0000 (UTC) From: Chris Caputo <ccaputo(a)seattleix.net> To: announce(a)seattleix.net tl;dr: - RIPE made changes which don't break anything now, but may in future. - I recommend you move your IRR records to the RIR which assigned or allocated your prefixes. - link to ARIN RPKI tutorial at bottom. Many of you that used RIPE to create your Internet Routing Registry (IRR) objects received an email from RIPE at the beginning of September about a change in their registry in which non-RIPE prefixes are now labeled with "source: RIPE-NONAUTH". This is part of an effort to improve the quality of IRR data for the purposes of reducing accidental or fraudulent BGP announcements. The idea being that the Regional Internet Registries (RIRs) know best who addresses have been assigned/allocated to. If you have your records at RIPE (or elsewhere and want to move to ARIN), I recommend you do the following: (note the example with my AS6456 will soon no longer work because I will be deleting my records at RIPE since they have been moved to ARIN) - First, determine your maintainer object name. This can be figured out by going to http://www.radb.net/query/ and running a query on your ASN or prefixes. For example, a query on my AS6456 reveals a RIPE maintainer "mnt-by" field "MAINT-ALTOPIA-RIPE". You may find you have multiple maintainers and multiple IRRs. Focus on the RIPE one if that is what you want to move. aut-num: AS6456 [...] mnt-by: MAINT-ALTOPIA-RIPE source: RIPE-NONAUTH - Using my "MAINT-ALTOPIA-RIPE" I can do an inverse query at RIPE to see all of my objects: $ whois -h whois.ripe.net -i mnt-by -B MAINT-ALTOPIA-RIPE aut-num: AS6456 as-name: ALTOPIA-6456 descr: Altopia AS 6456 [...] as-set: AS-ALTOPIA descr: Altopia Corporation members: AS6456 [...] route: 208.90.168.0/22 descr: ALTOPIA-V4-1 assigned by ARIN origin: AS6456 [...] route6: 2620:0:cf0::/48 descr: ALTOPIA-V6-1 assigned by ARIN origin: AS6456 [...] etc... - Save a copy of all of your objects so you can use the result to aide in your move to ARIN. - Refer to https://www.seattleix.net/irr-tutorial#arin for a new tutorial on how to get set up at ARIN's IRR. - Use http://irrexplorer.nlnog.net to visualize which IRRs are reporting your prefixes or ASN. - After all of your ARIN objects are moved to ARIN, work to delete your ARIN objects at RIPE or elsewhere as part of being tidy. Bonus! I also made an ARIN Resource Public Key Infrastructure (RPKI) tutorial. Turns out RPKI is pretty easy to configure, with respect to making it so your own ARIN prefixes are somewhat (*) protected from being announced by unauthorized ASNs. (*: with respect to networks running RPKI validators) - https://www.seattleix.net/irr-tutorial#arinrpki Feedback & corrections welcome! Chris

Sept. 26, 2018

Fwd: route server IRR objects: RIPE use for ARIN addresses deprecated, ARIN IRR & RPKI tutorials

by Richard Laager

This is from the SeattleIX announce list. I'm forwarding it, with Chris's permission, in case this is relevant to anyone here. -------- Forwarded Message -------- Subject: route server IRR objects: RIPE use for ARIN addresses deprecated, ARIN IRR & RPKI tutorials Date: Tue, 25 Sep 2018 22:22:14 +0000 (UTC) From: Chris Caputo <ccaputo(a)seattleix.net> To: announce(a)seattleix.net tl;dr: - RIPE made changes which don't break anything now, but may in future. - I recommend you move your IRR records to the RIR which assigned or allocated your prefixes. - link to ARIN RPKI tutorial at bottom. Many of you that used RIPE to create your Internet Routing Registry (IRR) objects received an email from RIPE at the beginning of September about a change in their registry in which non-RIPE prefixes are now labeled with "source: RIPE-NONAUTH". This is part of an effort to improve the quality of IRR data for the purposes of reducing accidental or fraudulent BGP announcements. The idea being that the Regional Internet Registries (RIRs) know best who addresses have been assigned/allocated to. If you have your records at RIPE (or elsewhere and want to move to ARIN), I recommend you do the following: (note the example with my AS6456 will soon no longer work because I will be deleting my records at RIPE since they have been moved to ARIN) - First, determine your maintainer object name. This can be figured out by going to http://www.radb.net/query/ and running a query on your ASN or prefixes. For example, a query on my AS6456 reveals a RIPE maintainer "mnt-by" field "MAINT-ALTOPIA-RIPE". You may find you have multiple maintainers and multiple IRRs. Focus on the RIPE one if that is what you want to move. aut-num: AS6456 [...] mnt-by: MAINT-ALTOPIA-RIPE source: RIPE-NONAUTH - Using my "MAINT-ALTOPIA-RIPE" I can do an inverse query at RIPE to see all of my objects: $ whois -h whois.ripe.net -i mnt-by -B MAINT-ALTOPIA-RIPE aut-num: AS6456 as-name: ALTOPIA-6456 descr: Altopia AS 6456 [...] as-set: AS-ALTOPIA descr: Altopia Corporation members: AS6456 [...] route: 208.90.168.0/22 descr: ALTOPIA-V4-1 assigned by ARIN origin: AS6456 [...] route6: 2620:0:cf0::/48 descr: ALTOPIA-V6-1 assigned by ARIN origin: AS6456 [...] etc... - Save a copy of all of your objects so you can use the result to aide in your move to ARIN. - Refer to https://www.seattleix.net/irr-tutorial#arin for a new tutorial on how to get set up at ARIN's IRR. - Use http://irrexplorer.nlnog.net to visualize which IRRs are reporting your prefixes or ASN. - After all of your ARIN objects are moved to ARIN, work to delete your ARIN objects at RIPE or elsewhere as part of being tidy. Bonus! I also made an ARIN Resource Public Key Infrastructure (RPKI) tutorial. Turns out RPKI is pretty easy to configure, with respect to making it so your own ARIN prefixes are somewhat (*) protected from being announced by unauthorized ASNs. (*: with respect to networks running RPKI validators) - https://www.seattleix.net/irr-tutorial#arinrpki Feedback & corrections welcome! Chris

Sept. 26, 2018

Re: UG 29 Meeting & Election

by Richard Laager

A member pointed out that it is hard to instruct a proxy without knowing the final slate of candidates. Accordingly, we will close nominations at 5:00 PM Central on this Thursday, September 27. Following that, I will send another email confirming the final slate of candidates. Currently, Reid Fishler is running. On 09/24/2018 03:35 AM, Richard Laager wrote: > The MICE UG 29 meeting will be held Wednesday, October 10, 3:00 pm, at > the 511 Building Cafeteria, 11th Avenue South, Minneapolis, MN. > > The agenda and draft UG 28 minutes are attached. > > The remote conferencing will be the same as before: > 952-562-5400 passcode MICE (6423). > > At this meeting, we will be holding an election for a board seat. > > The board consists of three seats with staggered terms, such that one > seat comes up for re-election each year (at the fall meeting). This > year, Reid's seat is up for election. > > Reid _is_ running for re-election. If anyone else is interested in > running, please nominate yourself. > > Voting will be done in person. If you will not be attending in person, > you must designate a proxy, in advance, in writing. The bylaws state > that you send that to the Chief Manager (me, Richard Laager), and > electronic means are acceptable. So a simple email is sufficient: > rlaager(a)wiktel.com or, if you prefer, chiefmanager(a)micemn.net > > If you are having trouble finding a proxy who will be there in person, > ask on the list or I can help you find someone. > -- Richard

Sept. 25, 2018

Re: UG 29 Meeting & Election

by Justin Krejci

Nobody from US Internet will be attending this MICE meeting due to Wispapalooza; when is the latest that nominees will be accepted for Reid's seat? I hope to send a proxy vote but don't yet know who the candidates are. ________________________________ From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Richard Laager <rlaager(a)WIKTEL.COM> Sent: Monday, September 24, 2018 3:35 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] UG 29 Meeting & Election The MICE UG 29 meeting will be held Wednesday, October 10, 3:00 pm, at the 511 Building Cafeteria, 11th Avenue South, Minneapolis, MN. The agenda and draft UG 28 minutes are attached. The remote conferencing will be the same as before: 952-562-5400 passcode MICE (6423). At this meeting, we will be holding an election for a board seat. The board consists of three seats with staggered terms, such that one seat comes up for re-election each year (at the fall meeting). This year, Reid's seat is up for election. Reid _is_ running for re-election. If anyone else is interested in running, please nominate yourself. Voting will be done in person. If you will not be attending in person, you must designate a proxy, in advance, in writing. The bylaws state that you send that to the Chief Manager (me, Richard Laager), and electronic means are acceptable. So a simple email is sufficient: rlaager(a)wiktel.com or, if you prefer, chiefmanager(a)micemn.net If you are having trouble finding a proxy who will be there in person, ask on the list or I can help you find someone. -- Richard

Sept. 24, 2018

UG 29 Meeting & Election

by Richard Laager

The MICE UG 29 meeting will be held Wednesday, October 10, 3:00 pm, at the 511 Building Cafeteria, 11th Avenue South, Minneapolis, MN. The agenda and draft UG 28 minutes are attached. The remote conferencing will be the same as before: 952-562-5400 passcode MICE (6423). At this meeting, we will be holding an election for a board seat. The board consists of three seats with staggered terms, such that one seat comes up for re-election each year (at the fall meeting). This year, Reid's seat is up for election. Reid _is_ running for re-election. If anyone else is interested in running, please nominate yourself. Voting will be done in person. If you will not be attending in person, you must designate a proxy, in advance, in writing. The bylaws state that you send that to the Chief Manager (me, Richard Laager), and electronic means are acceptable. So a simple email is sufficient: rlaager(a)wiktel.com or, if you prefer, chiefmanager(a)micemn.net If you are having trouble finding a proxy who will be there in person, ask on the list or I can help you find someone. -- Richard

Sept. 24, 2018

Arista Test Drive Training Wednesday, October 3rd

by John McLaughlin

Hello MICE Members: If you can join us for a day of free training please use the links below to register and review what an Arista Test Drive covers. https://solutions.arista.com/2018-09-atd-minnetonka-mn <https://solutions.arista.com/2018-09-atd-minnetonka-mn> https://solutions.arista.com/atd-training <https://solutions.arista.com/atd-training> ATD TRAINING What we offer: A curriculum designed to deliver world-class content and learning experience Small, intimate class sizes, led by our local engineers, for greater classroom interaction In addition to the schedule listed, we can add classes to fit your needs. Just tell us when and where, and we take care of the rest Please reach out to your Arista Account Manager or Training(a)Arista.com <mailto:Training@Arista.com> for more information! Thanks, -JMc John McLaughlin North Central Sales jmclaughlin(a)arista.com Cell# 612-816-9024 https://www.barrons.com/articles/worlds-best-ceos-growth-leaders-1527304583…

Sept. 23, 2018

Re: Power a pdu?

by Mike Horwath

On Fri, Sep 14, 2018 at 09:18:11PM +0000, Ryan Goldberg wrote: > Sorry for the OT, slap my hand if necessary. Far from OT. Glad you were taken care of! -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Sept. 15, 2018

Re: Power a pdu?

by Ryan Goldberg

I want to thank the folks that reached out. The always helpful Mr Lumby has saved me a headache. Thanks!! > On Sep 14, 2018, at 4:19 PM, Ryan Goldberg <RGoldberg(a)COMPUDYNE.COM> wrote: > > Borrow. Not power. > >> On Sep 14, 2018, at 4:18 PM, Ryan Goldberg <RGoldberg(a)COMPUDYNE.COM> wrote: >> >> Anyone at 511 and have 208v pdu with L6-30 in and a few c13 and c19 out? Ran into a sticky spot and could use one or two tonight. Can order and ship new to you or return in 2.5 weeks. >> >> Sorry for the OT, slap my hand if necessary. >> >> Ryan >> 218-390-5485 >

Sept. 14, 2018

Re: Power a pdu?

by Ryan Goldberg

Borrow. Not power. > On Sep 14, 2018, at 4:18 PM, Ryan Goldberg <RGoldberg(a)COMPUDYNE.COM> wrote: > > Anyone at 511 and have 208v pdu with L6-30 in and a few c13 and c19 out? Ran into a sticky spot and could use one or two tonight. Can order and ship new to you or return in 2.5 weeks. > > Sorry for the OT, slap my hand if necessary. > > Ryan > 218-390-5485

Sept. 14, 2018

Power a pdu?

by Ryan Goldberg

Anyone at 511 and have 208v pdu with L6-30 in and a few c13 and c19 out? Ran into a sticky spot and could use one or two tonight. Can order and ship new to you or return in 2.5 weeks. Sorry for the OT, slap my hand if necessary. Ryan 218-390-5485

Sept. 14, 2018

MICE Mailing Address

by Kayla Olsen

*This is a duplicate notice for some of you, please disregard if it's old news...* Greetings, The mailing address for MICE (Midwest Internet Cooperative Exchange) has changed. Please update your records to: Midwest Internet Cooperative Exchange PO Box 153 Mankato MN 56002-0153 http://micemn.net/ Thank you, Kayla Olsen MICE Treasurer

Sept. 10, 2018

Re: Routing of non-IX traffic

by Richard Laager

On 08/21/2018 02:08 PM, Richard Laager wrote: > On 08/21/2018 08:04 AM, Frank Bulk wrote: >> Since we already have a list of which MACs have proxy ARP on, I would >> suggest the MICE leadership team privately contact those MICE >> participants and ask them to turn off proxy ARP. > > Sure thing. I've emailed them all off-list. As of this afternoon, no MICE participants are doing proxy ARP. Thanks to those participants for responding quickly and reconfiguring their routers. Thanks to Matthew Beckwell for repeated testing to confirm the progress. -- Richard

Aug. 23, 2018

Re: Routing of non-IX traffic

by Richard Laager

On 08/21/2018 08:04 AM, Frank Bulk wrote: > Since we already have a list of which MACs have proxy ARP on, I would > suggest the MICE leadership team privately contact those MICE > participants and ask them to turn off proxy ARP. Sure thing. I've emailed them all off-list. -- Richard

Aug. 21, 2018

Re: Routing of non-IX traffic

by Frank Bulk

Since we already have a list of which MACs have proxy ARP on, I would suggest the MICE leadership team privately contact those MICE participants and ask them to turn off proxy ARP. Frank From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Andrew Hoyos Sent: Saturday, August 18, 2018 5:36 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Routing of non-IX traffic Relavent: https://ripe63.ripe.net/presentations/130-Proxy_ARP_RIPE_Nov2011.pdf Seems like quite a few participants on MICE with proxy ARP still on. I know some IX’s toss you in a quarantine VLAN for initial turn-up - maybe this is something that needs to start, so this sort of thing can be checked? — Andrew Hoyos hoyosa(a)gmail.com<mailto:hoyosa@gmail.com> On Aug 16, 2018, at 9:52 PM, Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: Thanks, Matthew, for explaining why ARP might be happening. Now that CNS has its proxy ARP turned off, it’s AS393639 that’s responding: SiouxCenter-Arista-North(s1)#traceroute ip www.yamaha-dealers.com<http://www.yamaha-dealers.com/> source et 3/24 traceroute to www.yamaha-dealers.com<http://www.yamaha-dealers.com/> (45.60.73.16), 30 hops max, 60 byte packets 1 AS393639.micemn.net<http://as393639.micemn.net/> (206.108.255.47) 13.936 ms 14.004 ms 13.998 ms 2 v415.core1.msp1.he.net<http://v415.core1.msp1.he.net/> (184.105.25.93) 14.146 ms 14.205 ms 14.274 ms 3 100ge13-1.core2.chi1.he.net<http://100ge13-1.core2.chi1.he.net/> (184.105.223.177) 22.533 ms 22.369 ms 22.538 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 *^CSiouxCenter-Arista-North(s1)# Can an ACL be created on the Arista that discards in/outbound ARP requests for the non-MICE address space? Frank From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of Steve Howard Sent: Thursday, August 16, 2018 9:32 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Routing of non-IX traffic I've disabled proxy arp on the CNS router... Has the behavior changed? On 08/16/2018 05:00 PM, Matthew Beckwell wrote: I'm getting similar behavior as Frank. Like Doug, I only have 45.60.73.0/24<http://45.60.73.0/24> from transit connections. So a traceroute from my MICE interface should ARP and die (I would think).... When I traceroute to 45.60.73.16-- my router sends out an ARP request, as expected. But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the order they came into my interface): 00:23:33:c6:a0:c0 206.108.255.50 Cooperative Network Services (CNS) 32609 e4:aa:5d:83:73:06 206.108.255.47 IVDesk 393639 88:43:e1:00:f2:10 206.108.255.18 Consolidated Communications 12042 b0:aa:77:33:7b:03 206.108.255.79 Gigamonster, LLC 31939 3c:08:f6:81:6e:a5 206.108.255.46 OneNetUSA 46131 00:1d:e5:c0:78:c3 206.108.255.5 Implex 21709 54:75:d0:e6:08:30 206.108.255.106 Nuvera Communications 23465 00:11:5d:82:6c:00 206.108.255.80 Future Technologies 26451 Proxy ARP (or something like it)? CNS seems to be consistently coming in first place when I clear my ARP entry. ~Matthew matthewb(a)aitech.net<mailto:matthewb@aitech.net> AS13746 On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: When I force a traceroute to originate from our MICE-facing connection, the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? To making things more interesting, Incapsula-destined traffic goes via Paul Bunyan. Here's just one example: traceroute to www.yamaha-dealers.com<http://www.yamaha-dealers.com/> (45.60.73.16), 30 hops max, 60 byte packets 1 AS32609.micemn.net<http://as32609.micemn.net/> (206.108.255.50) 14.059 ms 14.084 ms 14.076 ms 2 cns70.cnsllc.net<http://cns70.cnsllc.net/> (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms 3 fg30.ips.cnsllc.net<http://fg30.ips.cnsllc.net/> (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms 4 crss2.PaulBunyan.net<http://crss2.paulbunyan.net/> (205.149.159.197) 20.527 ms 20.562 ms 20.619 ms 5 cra.PaulBunyan.net<http://cra.paulbunyan.net/> (205.149.159.181) 23.398 ms fp233.ips.PaulBunyan.net<http://fp233.ips.paulbunyan.net/> (205.149.159.233) 22.669 ms cra.PaulBunyan.net<http://cra.paulbunyan.net/> (205.149.159.181) 23.393 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * SiouxCenter-Arista-North(s1) The reason I stumbled across this is because we've had more than a dozen customers over the last month complain about access to Incapsula-protected sites. Packet captures show TCP RSTs coming from the far side. Regards, Frank Bulk AS53347 ________________________________ 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

Aug. 21, 2018

Re: Direct peering to Yahoo! unstable over the last few days

by Frank Bulk

Thanks, Jeremy. I had always assumed Yahoo!'s gear was colo'd at MICE. Frank -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Saturday, August 18, 2018 11:29 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Direct peering to Yahoo! unstable over the last few days I can confirm the same on my router. I also happen to know that Yahoo is connected via a longhaul circuit into MICE. I have a wavelength with the same provider that would logically take the same path based on the same endpoint locations, and they have been having intermittent DC power issues in one of their huts for over a week now. They currently have an electrician on site to try to determine the intermittent piece of equipment. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Saturday, August 18, 2018 11:12 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Direct peering to Yahoo! unstable over the last few days Anyone else seeing the same as us? Aug 17 17:55:10 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.58 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:10 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 17 17:55:14 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.59 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:14 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 17 17:55:17 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 2001:504:27::2846:0:2 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:17 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 17 18:02:13 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 18:02:19 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 18:02:48 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:30:59 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:31:03 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:31:06 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:38:05 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:38:12 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:38:20 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 00:54:55 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 00:54:57 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 00:54:59 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 01:02:41 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 01:02:49 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 01:02:53 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:01:30 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:01:32 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:01:35 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:15:55 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:16:00 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:16:00 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:36:50 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:36:53 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:36:56 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:47:17 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:47:21 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:47:24 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established

Aug. 21, 2018

Re: Direct peering to Yahoo! unstable over the last few days

by Michael Hare

In short, yes, and at slightly different times than you it would seem. Things are stable here at this time. -Michael =============/================ Aug 15 13:27:17 :%DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 206.108.255.58 (External AS 10310) changed state from Established to Idle (event RecvNotify) (instance master) Aug 15 13:27:18 :%DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 2001:504:27::2846:0:1 (External AS 10310) changed state from Established to Idle (event RecvNotify) (instance master) Aug 17 11:01:07 :%DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 206.108.255.58 (External AS 10310) changed state from Established to Idle (event Stop) (instance master) Aug 17 11:01:07 :%DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 206.108.255.59 (External AS 10310) changed state from Established to Idle (event Stop) (instance master) Aug 17 11:01:08 :%DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 2001:504:27::2846:0:1 (External AS 10310) changed state from Established to Idle (event Stop) (instance master) Aug 17 11:01:08 :%DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 2001:504:27::2846:0:2 (External AS 10310) changed state from Established to Idle (event Stop) (instance master) > -----Original Message----- > From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of > Frank Bulk > Sent: Saturday, August 18, 2018 11:12 AM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] Direct peering to Yahoo! unstable over the last few > days > > Anyone else seeing the same as us? > > Aug 17 17:55:10 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor > 206.108.255.58 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 > bytes > Aug 17 17:55:10 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state Established event HoldTime new state Idle > Aug 17 17:55:14 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor > 206.108.255.59 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 > bytes > Aug 17 17:55:14 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state Established event HoldTime new state Idle > Aug 17 17:55:17 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor > 2001:504:27::2846:0:2 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) > 0 bytes > Aug 17 17:55:17 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new > state Idle > Aug 17 18:02:13 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 17 18:02:19 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 17 18:02:48 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event > RecvKeepAlive new state Established > > Aug 17 21:30:59 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state Established event HoldTime new state Idle > Aug 17 21:31:03 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new > state Idle > Aug 17 21:31:06 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state Established event HoldTime new state Idle > Aug 17 21:38:05 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 17 21:38:12 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event > RecvKeepAlive new state Established > Aug 17 21:38:20 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > > Aug 18 00:54:55 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state Established event HoldTime new state Idle > Aug 18 00:54:57 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new > state Idle > Aug 18 00:54:59 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state Established event HoldTime new state Idle > Aug 18 01:02:41 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 18 01:02:49 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 18 01:02:53 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event > RecvKeepAlive new state Established > > Aug 18 02:01:30 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state Established event HoldTime new state Idle > Aug 18 02:01:32 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state Established event HoldTime new state Idle > Aug 18 02:01:35 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new > state Idle > Aug 18 02:15:55 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 18 02:16:00 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 18 02:16:00 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event > RecvKeepAlive new state Established > > Aug 18 05:36:50 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state Established event HoldTime new state Idle > Aug 18 05:36:53 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new > state Idle > Aug 18 05:36:56 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state Established event HoldTime new state Idle > Aug 18 05:47:17 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 18 05:47:21 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 > (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established > Aug 18 05:47:24 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer > 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event > RecvKeepAlive new state Established

Aug. 20, 2018

Re: Routing of non-IX traffic

by Andrew Hoyos

Relavent: https://ripe63.ripe.net/presentations/130-Proxy_ARP_RIPE_Nov2011.pdf <https://ripe63.ripe.net/presentations/130-Proxy_ARP_RIPE_Nov2011.pdf> Seems like quite a few participants on MICE with proxy ARP still on. I know some IX’s toss you in a quarantine VLAN for initial turn-up - maybe this is something that needs to start, so this sort of thing can be checked? — Andrew Hoyos hoyosa(a)gmail.com > On Aug 16, 2018, at 9:52 PM, Frank Bulk <fbulk(a)mypremieronline.com> wrote: > > Thanks, Matthew, for explaining why ARP might be happening. > > Now that CNS has its proxy ARP turned off, it’s AS393639 that’s responding: > > SiouxCenter-Arista-North(s1)#traceroute ip www.yamaha-dealers.com <http://www.yamaha-dealers.com/> source et 3/24 > traceroute to www.yamaha-dealers.com <http://www.yamaha-dealers.com/> (45.60.73.16), 30 hops max, 60 byte packets > 1 AS393639.micemn.net <http://as393639.micemn.net/> (206.108.255.47) 13.936 ms 14.004 ms 13.998 ms > 2 v415.core1.msp1.he.net <http://v415.core1.msp1.he.net/> (184.105.25.93) 14.146 ms 14.205 ms 14.274 ms > 3 100ge13-1.core2.chi1.he.net <http://100ge13-1.core2.chi1.he.net/> (184.105.223.177) 22.533 ms 22.369 ms 22.538 ms > 4 * * * > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 *^CSiouxCenter-Arista-North(s1)# > > Can an ACL be created on the Arista that discards in/outbound ARP requests for the non-MICE address space? > > Frank > > From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of Steve Howard > Sent: Thursday, August 16, 2018 9:32 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> > Subject: Re: [MICE-DISCUSS] Routing of non-IX traffic > > I've disabled proxy arp on the CNS router... Has the behavior changed? > > On 08/16/2018 05:00 PM, Matthew Beckwell wrote: > I'm getting similar behavior as Frank. > > Like Doug, I only have 45.60.73.0/24 <http://45.60.73.0/24> from transit connections. > So a traceroute from my MICE interface should ARP and die (I would think).... > > When I traceroute to 45.60.73.16-- my router sends out an ARP request, as expected. > But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the order they came into my interface): > > > 00:23:33:c6:a0:c0 > 206.108.255.50 > Cooperative Network Services (CNS) > 32609 > e4:aa:5d:83:73:06 > 206.108.255.47 > IVDesk > 393639 > 88:43:e1:00:f2:10 > 206.108.255.18 > Consolidated Communications > 12042 > b0:aa:77:33:7b:03 > 206.108.255.79 > Gigamonster, LLC > 31939 > 3c:08:f6:81:6e:a5 > 206.108.255.46 > OneNetUSA > 46131 > 00:1d:e5:c0:78:c3 > 206.108.255.5 > Implex > 21709 > 54:75:d0:e6:08:30 > 206.108.255.106 > Nuvera Communications > 23465 > 00:11:5d:82:6c:00 > 206.108.255.80 > Future Technologies > 26451 > > > Proxy ARP (or something like it)? > CNS seems to be consistently coming in first place when I clear my ARP entry. > > ~Matthew > matthewb(a)aitech.net <mailto:matthewb@aitech.net> > AS13746 > > > > > On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com <mailto:fbulk@mypremieronline.com>> wrote: > When I force a traceroute to originate from our MICE-facing connection, the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? > > To making things more interesting, Incapsula-destined traffic goes via Paul Bunyan. Here's just one example: > > traceroute to www.yamaha-dealers.com <http://www.yamaha-dealers.com/> (45.60.73.16), 30 hops max, 60 byte packets > 1 AS32609.micemn.net <http://as32609.micemn.net/> (206.108.255.50) 14.059 ms 14.084 ms 14.076 ms > 2 cns70.cnsllc.net <http://cns70.cnsllc.net/> (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms > 3 fg30.ips.cnsllc.net <http://fg30.ips.cnsllc.net/> (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms > 4 crss2.PaulBunyan.net <http://crss2.paulbunyan.net/> (205.149.159.197) 20.527 ms 20.562 ms 20.619 ms > 5 cra.PaulBunyan.net <http://cra.paulbunyan.net/> (205.149.159.181) 23.398 ms fp233.ips.PaulBunyan.net <http://fp233.ips.paulbunyan.net/> (205.149.159.233) 22.669 ms cra.PaulBunyan.net <http://cra.paulbunyan.net/> (205.149.159.181) 23.393 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > SiouxCenter-Arista-North(s1) > > The reason I stumbled across this is because we've had more than a dozen customers over the last month complain about access to Incapsula-protected sites. Packet captures show TCP RSTs coming from the far side. > > Regards, > > Frank Bulk > AS53347 > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <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 <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 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>

Aug. 18, 2018

Re: Direct peering to Yahoo! unstable over the last few days

by Jeremy Lumby

I can confirm the same on my router. I also happen to know that Yahoo is connected via a longhaul circuit into MICE. I have a wavelength with the same provider that would logically take the same path based on the same endpoint locations, and they have been having intermittent DC power issues in one of their huts for over a week now. They currently have an electrician on site to try to determine the intermittent piece of equipment. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Saturday, August 18, 2018 11:12 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Direct peering to Yahoo! unstable over the last few days Anyone else seeing the same as us? Aug 17 17:55:10 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.58 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:10 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 17 17:55:14 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.59 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:14 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 17 17:55:17 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 2001:504:27::2846:0:2 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:17 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 17 18:02:13 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 18:02:19 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 18:02:48 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:30:59 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:31:03 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:31:06 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:38:05 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:38:12 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:38:20 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 00:54:55 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 00:54:57 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 00:54:59 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 01:02:41 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 01:02:49 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 01:02:53 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:01:30 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:01:32 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:01:35 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:15:55 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:16:00 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:16:00 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:36:50 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:36:53 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:36:56 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:47:17 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:47:21 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:47:24 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established

Aug. 18, 2018

Re: Subscription Mail: Re: [MICE-DISCUSS] Routing of non-IX traffic

by Mike Horwath

On Thu, Aug 16, 2018 at 10:25:13PM +0000, Ryan Goldberg wrote: > Proxy arp enabled by default is the silliest thing Cisco ever did. I'd say the constant 8:1 overcommit is the silliest thing ever, followed by proxy arp enablement by default. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Aug. 18, 2018

Direct peering to Yahoo! unstable over the last few days

by Frank Bulk

Anyone else seeing the same as us? Aug 17 17:55:10 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.58 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:10 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 17 17:55:14 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.59 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:14 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 17 17:55:17 207.32.15.28 Rib: %BGP-3-NOTIFICATION: sent to neighbor 2001:504:27::2846:0:2 (AS 10310) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Aug 17 17:55:17 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 17 18:02:13 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 18:02:19 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 18:02:48 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:30:59 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:31:03 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:31:06 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 17 21:38:05 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:38:12 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 17 21:38:20 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 00:54:55 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 00:54:57 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 00:54:59 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 01:02:41 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 01:02:49 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 01:02:53 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:01:30 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:01:32 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:01:35 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 02:15:55 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:16:00 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 02:16:00 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:36:50 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:36:53 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:36:56 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state Established event HoldTime new state Idle Aug 18 05:47:17 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.58 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:47:21 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.59 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established Aug 18 05:47:24 207.32.15.28 Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2846:0:2 (AS 10310) old state OpenConfirm event RecvKeepAlive new state Established

Aug. 18, 2018

Re: Routing of non-IX traffic

by Frank Bulk

Thanks, Matthew, for explaining why ARP might be happening. Now that CNS has its proxy ARP turned off, it’s AS393639 that’s responding: SiouxCenter-Arista-North(s1)#traceroute ip www.yamaha-dealers.com source et 3/24 traceroute to www.yamaha-dealers.com (45.60.73.16), 30 hops max, 60 byte packets 1 AS393639.micemn.net (206.108.255.47) 13.936 ms 14.004 ms 13.998 ms 2 v415.core1.msp1.he.net (184.105.25.93) 14.146 ms 14.205 ms 14.274 ms 3 100ge13-1.core2.chi1.he.net (184.105.223.177) 22.533 ms 22.369 ms 22.538 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 *^CSiouxCenter-Arista-North(s1)# Can an ACL be created on the Arista that discards in/outbound ARP requests for the non-MICE address space? Frank From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Steve Howard Sent: Thursday, August 16, 2018 9:32 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Routing of non-IX traffic I've disabled proxy arp on the CNS router... Has the behavior changed? On 08/16/2018 05:00 PM, Matthew Beckwell wrote: I'm getting similar behavior as Frank. Like Doug, I only have 45.60.73.0/24<http://45.60.73.0/24> from transit connections. So a traceroute from my MICE interface should ARP and die (I would think).... When I traceroute to 45.60.73.16-- my router sends out an ARP request, as expected. But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the order they came into my interface): 00:23:33:c6:a0:c0 206.108.255.50 Cooperative Network Services (CNS) 32609 e4:aa:5d:83:73:06 206.108.255.47 IVDesk 393639 88:43:e1:00:f2:10 206.108.255.18 Consolidated Communications 12042 b0:aa:77:33:7b:03 206.108.255.79 Gigamonster, LLC 31939 3c:08:f6:81:6e:a5 206.108.255.46 OneNetUSA 46131 00:1d:e5:c0:78:c3 206.108.255.5 Implex 21709 54:75:d0:e6:08:30 206.108.255.106 Nuvera Communications 23465 00:11:5d:82:6c:00 206.108.255.80 Future Technologies 26451 Proxy ARP (or something like it)? CNS seems to be consistently coming in first place when I clear my ARP entry. ~Matthew matthewb(a)aitech.net<mailto:matthewb@aitech.net> AS13746 On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: When I force a traceroute to originate from our MICE-facing connection, the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? To making things more interesting, Incapsula-destined traffic goes via Paul Bunyan. Here's just one example: traceroute to www.yamaha-dealers.com<http://www.yamaha-dealers.com> (45.60.73.16), 30 hops max, 60 byte packets 1 AS32609.micemn.net<http://AS32609.micemn.net> (206.108.255.50) 14.059 ms 14.084 ms 14.076 ms 2 cns70.cnsllc.net<http://cns70.cnsllc.net> (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms 3 fg30.ips.cnsllc.net<http://fg30.ips.cnsllc.net> (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms 4 crss2.PaulBunyan.net<http://crss2.PaulBunyan.net> (205.149.159.197) 20.527 ms 20.562 ms 20.619 ms 5 cra.PaulBunyan.net<http://cra.PaulBunyan.net> (205.149.159.181) 23.398 ms fp233.ips.PaulBunyan.net<http://fp233.ips.PaulBunyan.net> (205.149.159.233) 22.669 ms cra.PaulBunyan.net<http://cra.PaulBunyan.net> (205.149.159.181) 23.393 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * SiouxCenter-Arista-North(s1) The reason I stumbled across this is because we've had more than a dozen customers over the last month complain about access to Incapsula-protected sites. Packet captures show TCP RSTs coming from the far side. Regards, Frank Bulk AS53347 ________________________________ 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

Aug. 17, 2018

Re: Routing of non-IX traffic

by AnthonyAnderberg＠nuvera.net

Interesting - today I've learned that although IOS XR has Proxy ARP disabled by default, IOS XE has it enabled by default: nuveragw1#show ip int te0/3/0 | i ARP Proxy ARP is enabled RP/0/RSP0/CPU0:bbvgw1#show ip int te0/0/0/2 | i ARP Proxy ARP is disabled I’d agree that it’s not expected behavior in this context, so will disable it on Nuvera’s XE router. Thanks for making me smarter, anthony [Anthony_Anderberg]<https://www.nuvera.net/> From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Matthew Beckwell Sent: Thursday, August 16, 2018 5:01 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Routing of non-IX traffic I'm getting similar behavior as Frank. Like Doug, I only have 45.60.73.0/24<http://45.60.73.0/24> from transit connections. So a traceroute from my MICE interface should ARP and die (I would think).... When I traceroute to 45.60.73.16-- my router sends out an ARP request, as expected. But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the order they came into my interface): 00:23:33:c6:a0:c0 206.108.255.50 Cooperative Network Services (CNS) 32609 e4:aa:5d:83:73:06 206.108.255.47 IVDesk 393639 88:43:e1:00:f2:10 206.108.255.18 Consolidated Communications 12042 b0:aa:77:33:7b:03 206.108.255.79 Gigamonster, LLC 31939 3c:08:f6:81:6e:a5 206.108.255.46 OneNetUSA 46131 00:1d:e5:c0:78:c3 206.108.255.5 Implex 21709 54:75:d0:e6:08:30 206.108.255.106 Nuvera Communications 23465 00:11:5d:82:6c:00 206.108.255.80 Future Technologies 26451 Proxy ARP (or something like it)? CNS seems to be consistently coming in first place when I clear my ARP entry. ~Matthew matthewb(a)aitech.net<mailto:matthewb@aitech.net> AS13746 On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: When I force a traceroute to originate from our MICE-facing connection, the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? To making things more interesting, Incapsula-destined traffic goes via Paul Bunyan. Here's just one example: traceroute to www.yamaha-dealers.com<http://www.yamaha-dealers.com> (45.60.73.16), 30 hops max, 60 byte packets 1 AS32609.micemn.net<http://AS32609.micemn.net> (206.108.255.50) 14.059 ms 14.084 ms 14.076 ms 2 cns70.cnsllc.net<http://cns70.cnsllc.net> (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms 3 fg30.ips.cnsllc.net<http://fg30.ips.cnsllc.net> (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms 4 crss2.PaulBunyan.net<http://crss2.PaulBunyan.net> (205.149.159.197) 20.527 ms 20.562 ms 20.619 ms 5 cra.PaulBunyan.net<http://cra.PaulBunyan.net> (205.149.159.181) 23.398 ms fp233.ips.PaulBunyan.net<http://fp233.ips.PaulBunyan.net> (205.149.159.233) 22.669 ms cra.PaulBunyan.net<http://cra.PaulBunyan.net> (205.149.159.181) 23.393 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * SiouxCenter-Arista-North(s1) The reason I stumbled across this is because we've had more than a dozen customers over the last month complain about access to Incapsula-protected sites. Packet captures show TCP RSTs coming from the far side. Regards, Frank Bulk AS53347 ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 17, 2018

Re: Routing of non-IX traffic

by Steve Howard

Aug. 17, 2018

Re: Subscription Mail: Re: [MICE-DISCUSS] Routing of non-IX traffic

by David Farmer

At one level I agree with you, especially when you are talking about IXPs. However, facing userland, proxy arp plasters over a myriad of silly misconfigurations and typos. Which from a TAC and help desk point of view is a good thing, many tickets that are never opened, because it just works. On Thu, Aug 16, 2018 at 5:25 PM, Ryan Goldberg <RGoldberg(a)compudyne.com> wrote: > Proxy arp enabled by default is the silliest thing Cisco ever did. > > On Aug 16, 2018, at 5:14 PM, Andrew Hoyos <hoyosa(a)GMAIL.COM> wrote: > > Yeah, was just writing this. > Your router should see that it’s not a directly connected IP, and back up > to routing table/FIB. It may ARP for next hop depending on path. > > For those with this issue, what say your routing tables for this subnet? > And do *you* have proxy arp turned off? > > — > Andrew Hoyos > hoyosa(a)gmail.com > > > > On Aug 16, 2018, at 3:11 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM> wrote: > > Why would your router ARP for an address that is not on the same subnet as > any of your interfaces? > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET > <MICE-DISCUSS(a)LISTS.IPHOUSE.NET>] *On Behalf Of *Matthew Beckwell > *Sent:* Thursday, August 16, 2018 5:01 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Routing of non-IX traffic > > I'm getting similar behavior as Frank. > > Like Doug, I only have 45.60.73.0/24 from transit connections. > So a traceroute from my MICE interface should ARP and die (I would > think).... > > When I traceroute to 45.60.73.16-- my router sends out an ARP request, as > expected. > But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the > order they came into my interface): > > > 00:23:33:c6:a0:c0 > 206.108.255.50 > Cooperative Network Services (CNS) > 32609 > e4:aa:5d:83:73:06 > 206.108.255.47 > IVDesk > 393639 > 88:43:e1:00:f2:10 > 206.108.255.18 > Consolidated Communications > 12042 > b0:aa:77:33:7b:03 > 206.108.255.79 > Gigamonster, LLC > 31939 > 3c:08:f6:81:6e:a5 > 206.108.255.46 > OneNetUSA > 46131 > 00:1d:e5:c0:78:c3 > 206.108.255.5 > Implex > 21709 > 54:75:d0:e6:08:30 > 206.108.255.106 > Nuvera Communications > 23465 > 00:11:5d:82:6c:00 > 206.108.255.80 > Future Technologies > 26451 > > > Proxy ARP (or something like it)? > CNS seems to be consistently coming in first place when I clear my ARP > entry. > > ~Matthew > matthewb(a)aitech.net > AS13746 > > > > > On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com> > wrote: > When I force a traceroute to originate from our MICE-facing connection, > the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? > > To making things more interesting, Incapsula-destined traffic goes via > Paul Bunyan. Here's just one example: > > traceroute to www.yamaha-dealers.com (45.60.73.16), 30 hops max, 60 byte > packets > 1 AS32609.micemn.net <http://as32609.micemn.net/> (206.108.255.50) > 14.059 ms 14.084 ms 14.076 ms > 2 cns70.cnsllc.net (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms > 3 fg30.ips.cnsllc.net (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms > 4 crss2.PaulBunyan.net <http://crss2.paulbunyan.net/> (205.149.159.197) > 20.527 ms 20.562 ms 20.619 ms > 5 cra.PaulBunyan.net <http://cra.paulbunyan.net/> (205.149.159.181) > 23.398 ms fp233.ips.PaulBunyan.net <http://fp233.ips.paulbunyan.net/> (205.149.159.233) > 22.669 ms cra.PaulBunyan.net <http://cra.paulbunyan.net/> (205.149.159.181) > 23.393 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > SiouxCenter-Arista-North(s1) > > The reason I stumbled across this is because we've had more than a dozen > customers over the last month complain about access to Incapsula-protected > sites. Packet captures show TCP RSTs coming from the far side. > > Regards, > > Frank Bulk > AS53347 > > > ------------------------------ > > 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 > -- =============================================== 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 ===============================================

Aug. 16, 2018

Re: Routing of non-IX traffic

by Matthew Beckwell

On some gear, it will ARP for an address that is not directly connected when you force the interface being used. (Basically telling the router "Ignore the forwarding table...use this interface no matter what"). To which the router says "okay, but i'm gonna have to ARP for it, and anyone watching is going to think I don't know what i'm doing...." (And they'd be correct...) Under normal circumstances (not specifying the interface), my traceroutes happily go out the shortest transit path shown in the full BGP feed. No proxy arp here. :) ~Matthew On Thu, Aug 16, 2018 at 5:13 PM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: > Yeah, was just writing this. > Your router should see that it’s not a directly connected IP, and back up > to routing table/FIB. It may ARP for next hop depending on path. > > For those with this issue, what say your routing tables for this subnet? > And do *you* have proxy arp turned off? > > — > Andrew Hoyos > hoyosa(a)gmail.com > > > > On Aug 16, 2018, at 3:11 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM> wrote: > > Why would your router ARP for an address that is not on the same subnet as > any of your interfaces? > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET > <MICE-DISCUSS(a)LISTS.IPHOUSE.NET>] *On Behalf Of *Matthew Beckwell > *Sent:* Thursday, August 16, 2018 5:01 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Routing of non-IX traffic > > I'm getting similar behavior as Frank. > > Like Doug, I only have 45.60.73.0/24 from transit connections. > So a traceroute from my MICE interface should ARP and die (I would > think).... > > When I traceroute to 45.60.73.16-- my router sends out an ARP request, as > expected. > But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the > order they came into my interface): > > > 00:23:33:c6:a0:c0 > 206.108.255.50 > Cooperative Network Services (CNS) > 32609 > e4:aa:5d:83:73:06 > 206.108.255.47 > IVDesk > 393639 > 88:43:e1:00:f2:10 > 206.108.255.18 > Consolidated Communications > 12042 > b0:aa:77:33:7b:03 > 206.108.255.79 > Gigamonster, LLC > 31939 > 3c:08:f6:81:6e:a5 > 206.108.255.46 > OneNetUSA > 46131 > 00:1d:e5:c0:78:c3 > 206.108.255.5 > Implex > 21709 > 54:75:d0:e6:08:30 > 206.108.255.106 > Nuvera Communications > 23465 > 00:11:5d:82:6c:00 > 206.108.255.80 > Future Technologies > 26451 > > > Proxy ARP (or something like it)? > CNS seems to be consistently coming in first place when I clear my ARP > entry. > > ~Matthew > matthewb(a)aitech.net > AS13746 > > > > > On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com> > wrote: > When I force a traceroute to originate from our MICE-facing connection, > the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? > > To making things more interesting, Incapsula-destined traffic goes via > Paul Bunyan. Here's just one example: > > traceroute to www.yamaha-dealers.com (45.60.73.16), 30 hops max, 60 byte > packets > 1 AS32609.micemn.net <http://as32609.micemn.net/> (206.108.255.50) > 14.059 ms 14.084 ms 14.076 ms > 2 cns70.cnsllc.net (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms > 3 fg30.ips.cnsllc.net (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms > 4 crss2.PaulBunyan.net <http://crss2.paulbunyan.net/> (205.149.159.197) > 20.527 ms 20.562 ms 20.619 ms > 5 cra.PaulBunyan.net <http://cra.paulbunyan.net/> (205.149.159.181) > 23.398 ms fp233.ips.PaulBunyan.net <http://fp233.ips.paulbunyan.net/> (205.149.159.233) > 22.669 ms cra.PaulBunyan.net <http://cra.paulbunyan.net/> (205.149.159.181) > 23.393 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > SiouxCenter-Arista-North(s1) > > The reason I stumbled across this is because we've had more than a dozen > customers over the last month complain about access to Incapsula-protected > sites. Packet captures show TCP RSTs coming from the far side. > > Regards, > > Frank Bulk > AS53347 > > > ------------------------------ > > 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 >

Aug. 16, 2018

Re: Subscription Mail: Re: [MICE-DISCUSS] Routing of non-IX traffic

by Ryan Goldberg

Proxy arp enabled by default is the silliest thing Cisco ever did. On Aug 16, 2018, at 5:14 PM, Andrew Hoyos <hoyosa(a)GMAIL.COM<mailto:hoyosa@GMAIL.COM>> wrote: Yeah, was just writing this. Your router should see that it’s not a directly connected IP, and back up to routing table/FIB. It may ARP for next hop depending on path. For those with this issue, what say your routing tables for this subnet? And do *you* have proxy arp turned off? — Andrew Hoyos hoyosa(a)gmail.com<mailto:hoyosa@gmail.com> On Aug 16, 2018, at 3:11 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM<mailto:jlumby@MNVOIP.COM>> wrote: Why would your router ARP for an address that is not on the same subnet as any of your interfaces? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Matthew Beckwell Sent: Thursday, August 16, 2018 5:01 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Routing of non-IX traffic I'm getting similar behavior as Frank. Like Doug, I only have 45.60.73.0/24<http://45.60.73.0/24> from transit connections. So a traceroute from my MICE interface should ARP and die (I would think).... When I traceroute to 45.60.73.16-- my router sends out an ARP request, as expected. But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the order they came into my interface): 00:23:33:c6:a0:c0 206.108.255.50 Cooperative Network Services (CNS) 32609 e4:aa:5d:83:73:06 206.108.255.47 IVDesk 393639 88:43:e1:00:f2:10 206.108.255.18 Consolidated Communications 12042 b0:aa:77:33:7b:03 206.108.255.79 Gigamonster, LLC 31939 3c:08:f6:81:6e:a5 206.108.255.46 OneNetUSA 46131 00:1d:e5:c0:78:c3 206.108.255.5 Implex 21709 54:75:d0:e6:08:30 206.108.255.106 Nuvera Communications 23465 00:11:5d:82:6c:00 206.108.255.80 Future Technologies 26451 Proxy ARP (or something like it)? CNS seems to be consistently coming in first place when I clear my ARP entry. ~Matthew matthewb(a)aitech.net<mailto:matthewb@aitech.net> AS13746 On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: When I force a traceroute to originate from our MICE-facing connection, the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? To making things more interesting, Incapsula-destined traffic goes via Paul Bunyan. Here's just one example: traceroute to www.yamaha-dealers.com<http://www.yamaha-dealers.com/> (45.60.73.16), 30 hops max, 60 byte packets 1 AS32609.micemn.net<http://as32609.micemn.net/> (206.108.255.50) 14.059 ms 14.084 ms 14.076 ms 2 cns70.cnsllc.net<http://cns70.cnsllc.net/> (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms 3 fg30.ips.cnsllc.net<http://fg30.ips.cnsllc.net/> (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms 4 crss2.PaulBunyan.net<http://crss2.paulbunyan.net/> (205.149.159.197) 20.527 ms 20.562 ms 20.619 ms 5 cra.PaulBunyan.net<http://cra.paulbunyan.net/> (205.149.159.181) 23.398 ms fp233.ips.PaulBunyan.net<http://fp233.ips.paulbunyan.net/> (205.149.159.233) 22.669 ms cra.PaulBunyan.net<http://cra.paulbunyan.net/> (205.149.159.181) 23.393 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * SiouxCenter-Arista-North(s1) The reason I stumbled across this is because we've had more than a dozen customers over the last month complain about access to Incapsula-protected sites. Packet captures show TCP RSTs coming from the far side. Regards, Frank Bulk AS53347 ________________________________ 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

Aug. 16, 2018

Re: Routing of non-IX traffic

by Andrew Hoyos

Yeah, was just writing this. Your router should see that it’s not a directly connected IP, and back up to routing table/FIB. It may ARP for next hop depending on path. For those with this issue, what say your routing tables for this subnet? And do *you* have proxy arp turned off? — Andrew Hoyos hoyosa(a)gmail.com > On Aug 16, 2018, at 3:11 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM> wrote: > > Why would your router ARP for an address that is not on the same subnet as any of your interfaces? > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Matthew Beckwell > Sent: Thursday, August 16, 2018 5:01 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> > Subject: Re: [MICE-DISCUSS] Routing of non-IX traffic > > I'm getting similar behavior as Frank. > > Like Doug, I only have 45.60.73.0/24 <http://45.60.73.0/24> from transit connections. > So a traceroute from my MICE interface should ARP and die (I would think).... > > When I traceroute to 45.60.73.16-- my router sends out an ARP request, as expected. > But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the order they came into my interface): > > > 00:23:33:c6:a0:c0 > 206.108.255.50 > Cooperative Network Services (CNS) > 32609 > e4:aa:5d:83:73:06 > 206.108.255.47 > IVDesk > 393639 > 88:43:e1:00:f2:10 > 206.108.255.18 > Consolidated Communications > 12042 > b0:aa:77:33:7b:03 > 206.108.255.79 > Gigamonster, LLC > 31939 > 3c:08:f6:81:6e:a5 > 206.108.255.46 > OneNetUSA > 46131 > 00:1d:e5:c0:78:c3 > 206.108.255.5 > Implex > 21709 > 54:75:d0:e6:08:30 > 206.108.255.106 > Nuvera Communications > 23465 > 00:11:5d:82:6c:00 > 206.108.255.80 > Future Technologies > 26451 > > > Proxy ARP (or something like it)? > CNS seems to be consistently coming in first place when I clear my ARP entry. > > ~Matthew > matthewb(a)aitech.net <mailto:matthewb@aitech.net> > AS13746 > > > > > On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com <mailto:fbulk@mypremieronline.com>> wrote: > When I force a traceroute to originate from our MICE-facing connection, the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? > > To making things more interesting, Incapsula-destined traffic goes via Paul Bunyan. Here's just one example: > > traceroute to www.yamaha-dealers.com <http://www.yamaha-dealers.com/> (45.60.73.16), 30 hops max, 60 byte packets > 1 AS32609.micemn.net <http://as32609.micemn.net/> (206.108.255.50) 14.059 ms 14.084 ms 14.076 ms > 2 cns70.cnsllc.net <http://cns70.cnsllc.net/> (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms > 3 fg30.ips.cnsllc.net <http://fg30.ips.cnsllc.net/> (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms > 4 crss2.PaulBunyan.net <http://crss2.paulbunyan.net/> (205.149.159.197) 20.527 ms 20.562 ms 20.619 ms > 5 cra.PaulBunyan.net <http://cra.paulbunyan.net/> (205.149.159.181) 23.398 ms fp233.ips.PaulBunyan.net <http://fp233.ips.paulbunyan.net/> (205.149.159.233) 22.669 ms cra.PaulBunyan.net <http://cra.paulbunyan.net/> (205.149.159.181) 23.393 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > SiouxCenter-Arista-North(s1) > > The reason I stumbled across this is because we've had more than a dozen customers over the last month complain about access to Incapsula-protected sites. Packet captures show TCP RSTs coming from the far side. > > Regards, > > Frank Bulk > AS53347 > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <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 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>

Aug. 16, 2018

Re: Routing of non-IX traffic

by Jeremy Lumby

Why would your router ARP for an address that is not on the same subnet as any of your interfaces? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Matthew Beckwell Sent: Thursday, August 16, 2018 5:01 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Routing of non-IX traffic I'm getting similar behavior as Frank. Like Doug, I only have 45.60.73.0/24 from transit connections. So a traceroute from my MICE interface should ARP and die (I would think).... When I traceroute to 45.60.73.16-- my router sends out an ARP request, as expected. But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the order they came into my interface): 00:23:33:c6:a0:c0206.108.255.50Cooperative Network Services (CNS)32609 e4:aa:5d:83:73:06206.108.255.47IVDesk393639 88:43:e1:00:f2:10206.108.255.18Consolidated Communications12042 b0:aa:77:33:7b:03206.108.255.79Gigamonster, LLC31939 3c:08:f6:81:6e:a5206.108.255.46OneNetUSA46131 00:1d:e5:c0:78:c3206.108.255.5Implex21709 54:75:d0:e6:08:30206.108.255.106Nuvera Communications23465 00:11:5d:82:6c:00206.108.255.80Future Technologies26451 Proxy ARP (or something like it)? CNS seems to be consistently coming in first place when I clear my ARP entry. ~Matthew matthewb(a)aitech.net AS13746 On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com> wrote: When I force a traceroute to originate from our MICE-facing connection, the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? To making things more interesting, Incapsula-destined traffic goes via Paul Bunyan. Here's just one example: traceroute to www.yamaha-dealers.com (45.60.73.16), 30 hops max, 60 byte packets 1 AS32609.micemn.net (206.108.255.50) 14.059 ms 14.084 ms 14.076 ms 2 cns70.cnsllc.net (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms 3 fg30.ips.cnsllc.net (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms 4 crss2.PaulBunyan.net (205.149.159.197) 20.527 ms 20.562 ms 20.619 ms 5 cra.PaulBunyan.net (205.149.159.181) 23.398 ms fp233.ips.PaulBunyan.net (205.149.159.233) 22.669 ms cra.PaulBunyan.net (205.149.159.181) 23.393 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * SiouxCenter-Arista-North(s1) The reason I stumbled across this is because we've had more than a dozen customers over the last month complain about access to Incapsula-protected sites. Packet captures show TCP RSTs coming from the far side. Regards, Frank Bulk AS53347 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 16, 2018

Re: Routing of non-IX traffic

by Matthew Beckwell

I'm getting similar behavior as Frank. Like Doug, I only have 45.60.73.0/24 from transit connections. So a traceroute from my MICE interface should ARP and die (I would think).... When I traceroute to 45.60.73.16-- my router sends out an ARP request, as expected. But...I get ARP replies for 45.60.73.16 from these Cisco MACs (in the order they came into my interface): 00:23:33:c6:a0:c0 206.108.255.50 Cooperative Network Services (CNS) 32609 e4:aa:5d:83:73:06 206.108.255.47 IVDesk 393639 88:43:e1:00:f2:10 206.108.255.18 Consolidated Communications 12042 b0:aa:77:33:7b:03 206.108.255.79 Gigamonster, LLC 31939 3c:08:f6:81:6e:a5 206.108.255.46 OneNetUSA 46131 00:1d:e5:c0:78:c3 206.108.255.5 Implex 21709 54:75:d0:e6:08:30 206.108.255.106 Nuvera Communications 23465 00:11:5d:82:6c:00 206.108.255.80 Future Technologies 26451 Proxy ARP (or something like it)? CNS seems to be consistently coming in first place when I clear my ARP entry. ~Matthew matthewb(a)aitech.net AS13746 On Thu, Aug 16, 2018 at 3:25 PM, Frank Bulk <fbulk(a)mypremieronline.com> wrote: > When I force a traceroute to originate from our MICE-facing connection, > the first hop is 206.108.255.50 (AS32609 aka CNS). Any reason why? > > To making things more interesting, Incapsula-destined traffic goes via > Paul Bunyan. Here's just one example: > > traceroute to www.yamaha-dealers.com (45.60.73.16), 30 hops max, 60 byte > packets > 1 AS32609.micemn.net (206.108.255.50) 14.059 ms 14.084 ms 14.076 ms > 2 cns70.cnsllc.net (205.149.150.9) 18.484 ms 18.434 ms 18.507 ms > 3 fg30.ips.cnsllc.net (205.149.150.30) 20.254 ms 20.346 ms 20.267 ms > 4 crss2.PaulBunyan.net (205.149.159.197) 20.527 ms 20.562 ms 20.619 > ms > 5 cra.PaulBunyan.net (205.149.159.181) 23.398 ms > fp233.ips.PaulBunyan.net (205.149.159.233) 22.669 ms cra.PaulBunyan.net > (205.149.159.181) 23.393 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > SiouxCenter-Arista-North(s1) > > The reason I stumbled across this is because we've had more than a dozen > customers over the last month complain about access to Incapsula-protected > sites. Packet captures show TCP RSTs coming from the far side. > > Regards, > > Frank Bulk > AS53347 >

Aug. 16, 2018

Re: Routing of non-IX traffic

by Steve Howard

Aug. 16, 2018