From mehmet at akcin.net Fri Sep 1 00:50:28 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 01 Sep 2017 00:50:28 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: Hi Everyone! Thank you for 10s of great leads regarding PR and Internet EcoSystem. I am wondering if we were to have a Peering Forum in Puerto Rico, when would be the most preferred time? December, February are two options we have for now. Idea would be to create a day where people who are local and involved in network engineering/operations can meet with those in similar functions outside of the island. Thanks once again for amazing support and leads. We look forward to 2018 and the reLaunch. Mehmet On Sat, Aug 12, 2017 at 9:27 PM Mehmet Akcin wrote: > Hey there! > > ... ok this time I am not going to call it PRIX ;) well name doesn't > matter really. Nearly 13 years ago I have attempted to start Puerto rico > Internet exchange in San Juan. I have lived there over 5 years and i just > wanted to really watch videos faster. The project somewhat died when i > moved to LA but now there are few interested party to start an internet > exchange in Puerto rico. The jsland historically had one of the slowest > broadband/internet services which seemed to have improved in recent years > however as of 2017 there still is not an IX in Puerto rico. > > We , 3-4 internet engineers (on island and remote) , want to look into > relaunch of this IX and hopefully find a way to keep local traffic > exchanged at high speeds and low cost. We need expertise, and people who > want to help any way they can. > > We are trying to make this IX a not-for-profit one and we are looking at > opeeating models to adapt which has worked incredibly well like Seattle IX. > > We are hoping the relaunch to happen sometime in 2018. Thanks in advance > hope to share more info and traffic data sometime , soon. Watch this space! > > Mehmet > From nanog at ics-il.net Fri Sep 1 01:55:46 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 31 Aug 2017 20:55:46 -0500 (CDT) Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) In-Reply-To: <20170831200649.GP29058@Vurt.local> References: <20170831200649.GP29058@Vurt.local> Message-ID: <1344261662.6475.1504230946348.JavaMail.mhammett@ThunderFuck> I would like to use a BGP optimizer, but I'm too poor. :-\ That said, I'm also an eyeball network, so modifications of my own advertisements are what affects the desired traffic, not so much the outbound routes. I know the BGP optimization industry is weighted towards content networks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Job Snijders" To: nanog at nanog.org Sent: Thursday, August 31, 2017 3:06:49 PM Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) Dear all, disclaimer: [ The following is targetted at the context where a BGP optimizer generates BGP announcement that are ordinarily not seen in the Default-Free Zone. The OP indicated they announce a /23, and were unpleasantly surprised to see two unauthorized announcements for /24 more-specifics pop up in their alerting system. No permission was granted to create and announce these more-specifics. The AS_PATH for those /24 announcements was entirely fabricated. Original thread https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ] On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote: > Presuming it was a route optimizer and the issue was ongoing, what > would be the suggested course of action? I strongly recommend to turn off those BGP optimizers, glue the ports shut, burn the hardware, and salt the grounds on which the BGP optimizer sales people walked. It is extremely irresponsible behavior to use software that generates _fake_ BGP more-specifics for the purpose of traffic engineering. You simply cannot expect that those more-specifics will never escape into the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see software bugs related to NO_EXPORT, and community-squashing configuration mistakes happen all the time. Consider the following: if you leak your own internal more-specifics, at least you are the legitimate destination. (You may suffer from suboptimal routing, but it isn't guaranteed downtime.) However if you generate fake more-specifics for prefixes belonging to OTHER organisations, you essentially are complicit in BGP hijacking. If those fake more-specifics accidentally leak into the DFZ, you are bringing down the actual owner of such prefixes, and depriving people from access to the Internet. Example case: https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html > reach out to those 2 AS owners and see if they could stop it? Yes, absolutely! And if everyone of the affected parties of this localized hijack leak (or should we say 'victims') reaches out to the wrongdoers, they contribute peer pressure to rectify the situation. Just make sure you assign blame to the correct party. :) > Or is it something I just have to live with as a traffic engineering > solution they are using and mark the alerts as false positives? No, this is not something we should just accept. The Default-Free Zone is a shared resource. Anyone using "BGP optimizers" is not only risking their own online presence, but also everyone else's. Using a BGP optimizer is essentially trading a degree of risk to society for the purpose of saving a few bucks or milliseconds. It is basically saying: "The optimizer helps me, but may hurt others, and I am fine with that". An analogy: We don't want transporters of radioactive material to cut corners by using non-existant roads to bring the spent nuclear fuels from A to B faster, nor do we want them to rely on non-robust shielding that works "most of the time". We share the BGP DFZ environment, 'BGP optimizers' are downright pollution contributors. Kind regards, Job ps. If you want to do BGP optimization: don't have the BGP optimizer generate fake BGP announcements, but focus only on manipulating non-transitive attributes (like LOCAL_PREF) on real announcements you actually received from others. Or Perhaps BGP optimizers shouldn't even talk BGP but rather push freshly generated TE-optimized routing-policy to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate real announcements)... there are ways to do this, without risk to others! p.s. providing a publicly available BGP looking glasses will contribute to proving your innocence in cases like these. Since in many cases the AS_PATH is a complete fabrication, we need to manually check every AS in the AS_PATH to see whether the AS carries the fake more-specific. A public looking glass speeds up this fault-finding process. If you don't want to host a webinterface yourself, please consider sending a BGP feed to the Route Views Project or RIPE RIS, or for something queryable in a real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ From nanog at ics-il.net Fri Sep 1 02:02:07 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 31 Aug 2017 21:02:07 -0500 (CDT) Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) In-Reply-To: <1344261662.6475.1504230946348.JavaMail.mhammett@ThunderFuck> References: <20170831200649.GP29058@Vurt.local> <1344261662.6475.1504230946348.JavaMail.mhammett@ThunderFuck> Message-ID: <447723577.6501.1504231325656.JavaMail.mhammett@ThunderFuck> Actually, I do remember that one of them would optimize inbound routes, but only billed on outbound usage (as it was content-focused). My in is over 8x my out, so hrm... maybe I'm on to something. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, August 31, 2017 8:55:46 PM Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack) I would like to use a BGP optimizer, but I'm too poor. :-\ That said, I'm also an eyeball network, so modifications of my own advertisements are what affects the desired traffic, not so much the outbound routes. I know the BGP optimization industry is weighted towards content networks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Job Snijders" To: nanog at nanog.org Sent: Thursday, August 31, 2017 3:06:49 PM Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) Dear all, disclaimer: [ The following is targetted at the context where a BGP optimizer generates BGP announcement that are ordinarily not seen in the Default-Free Zone. The OP indicated they announce a /23, and were unpleasantly surprised to see two unauthorized announcements for /24 more-specifics pop up in their alerting system. No permission was granted to create and announce these more-specifics. The AS_PATH for those /24 announcements was entirely fabricated. Original thread https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ] On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote: > Presuming it was a route optimizer and the issue was ongoing, what > would be the suggested course of action? I strongly recommend to turn off those BGP optimizers, glue the ports shut, burn the hardware, and salt the grounds on which the BGP optimizer sales people walked. It is extremely irresponsible behavior to use software that generates _fake_ BGP more-specifics for the purpose of traffic engineering. You simply cannot expect that those more-specifics will never escape into the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see software bugs related to NO_EXPORT, and community-squashing configuration mistakes happen all the time. Consider the following: if you leak your own internal more-specifics, at least you are the legitimate destination. (You may suffer from suboptimal routing, but it isn't guaranteed downtime.) However if you generate fake more-specifics for prefixes belonging to OTHER organisations, you essentially are complicit in BGP hijacking. If those fake more-specifics accidentally leak into the DFZ, you are bringing down the actual owner of such prefixes, and depriving people from access to the Internet. Example case: https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html > reach out to those 2 AS owners and see if they could stop it? Yes, absolutely! And if everyone of the affected parties of this localized hijack leak (or should we say 'victims') reaches out to the wrongdoers, they contribute peer pressure to rectify the situation. Just make sure you assign blame to the correct party. :) > Or is it something I just have to live with as a traffic engineering > solution they are using and mark the alerts as false positives? No, this is not something we should just accept. The Default-Free Zone is a shared resource. Anyone using "BGP optimizers" is not only risking their own online presence, but also everyone else's. Using a BGP optimizer is essentially trading a degree of risk to society for the purpose of saving a few bucks or milliseconds. It is basically saying: "The optimizer helps me, but may hurt others, and I am fine with that". An analogy: We don't want transporters of radioactive material to cut corners by using non-existant roads to bring the spent nuclear fuels from A to B faster, nor do we want them to rely on non-robust shielding that works "most of the time". We share the BGP DFZ environment, 'BGP optimizers' are downright pollution contributors. Kind regards, Job ps. If you want to do BGP optimization: don't have the BGP optimizer generate fake BGP announcements, but focus only on manipulating non-transitive attributes (like LOCAL_PREF) on real announcements you actually received from others. Or Perhaps BGP optimizers shouldn't even talk BGP but rather push freshly generated TE-optimized routing-policy to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate real announcements)... there are ways to do this, without risk to others! p.s. providing a publicly available BGP looking glasses will contribute to proving your innocence in cases like these. Since in many cases the AS_PATH is a complete fabrication, we need to manually check every AS in the AS_PATH to see whether the AS carries the fake more-specific. A public looking glass speeds up this fault-finding process. If you don't want to host a webinterface yourself, please consider sending a BGP feed to the Route Views Project or RIPE RIS, or for something queryable in a real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ From nanog at ics-il.net Fri Sep 1 02:04:52 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 31 Aug 2017 21:04:52 -0500 (CDT) Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) In-Reply-To: <447723577.6501.1504231325656.JavaMail.mhammett@ThunderFuck> References: <20170831200649.GP29058@Vurt.local> <1344261662.6475.1504230946348.JavaMail.mhammett@ThunderFuck> <447723577.6501.1504231325656.JavaMail.mhammett@ThunderFuck> Message-ID: <1221110534.6509.1504231488623.JavaMail.mhammett@ThunderFuck> Sorry for now taking up 1/4 of this thread.... My words in the last message don't match what I was thinking, but I think you all get the point. I'm sick, maybe I should be in bed instead of on NANOG. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, August 31, 2017 9:02:07 PM Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack) Actually, I do remember that one of them would optimize inbound routes, but only billed on outbound usage (as it was content-focused). My in is over 8x my out, so hrm... maybe I'm on to something. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, August 31, 2017 8:55:46 PM Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack) I would like to use a BGP optimizer, but I'm too poor. :-\ That said, I'm also an eyeball network, so modifications of my own advertisements are what affects the desired traffic, not so much the outbound routes. I know the BGP optimization industry is weighted towards content networks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Job Snijders" To: nanog at nanog.org Sent: Thursday, August 31, 2017 3:06:49 PM Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) Dear all, disclaimer: [ The following is targetted at the context where a BGP optimizer generates BGP announcement that are ordinarily not seen in the Default-Free Zone. The OP indicated they announce a /23, and were unpleasantly surprised to see two unauthorized announcements for /24 more-specifics pop up in their alerting system. No permission was granted to create and announce these more-specifics. The AS_PATH for those /24 announcements was entirely fabricated. Original thread https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ] On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote: > Presuming it was a route optimizer and the issue was ongoing, what > would be the suggested course of action? I strongly recommend to turn off those BGP optimizers, glue the ports shut, burn the hardware, and salt the grounds on which the BGP optimizer sales people walked. It is extremely irresponsible behavior to use software that generates _fake_ BGP more-specifics for the purpose of traffic engineering. You simply cannot expect that those more-specifics will never escape into the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see software bugs related to NO_EXPORT, and community-squashing configuration mistakes happen all the time. Consider the following: if you leak your own internal more-specifics, at least you are the legitimate destination. (You may suffer from suboptimal routing, but it isn't guaranteed downtime.) However if you generate fake more-specifics for prefixes belonging to OTHER organisations, you essentially are complicit in BGP hijacking. If those fake more-specifics accidentally leak into the DFZ, you are bringing down the actual owner of such prefixes, and depriving people from access to the Internet. Example case: https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html > reach out to those 2 AS owners and see if they could stop it? Yes, absolutely! And if everyone of the affected parties of this localized hijack leak (or should we say 'victims') reaches out to the wrongdoers, they contribute peer pressure to rectify the situation. Just make sure you assign blame to the correct party. :) > Or is it something I just have to live with as a traffic engineering > solution they are using and mark the alerts as false positives? No, this is not something we should just accept. The Default-Free Zone is a shared resource. Anyone using "BGP optimizers" is not only risking their own online presence, but also everyone else's. Using a BGP optimizer is essentially trading a degree of risk to society for the purpose of saving a few bucks or milliseconds. It is basically saying: "The optimizer helps me, but may hurt others, and I am fine with that". An analogy: We don't want transporters of radioactive material to cut corners by using non-existant roads to bring the spent nuclear fuels from A to B faster, nor do we want them to rely on non-robust shielding that works "most of the time". We share the BGP DFZ environment, 'BGP optimizers' are downright pollution contributors. Kind regards, Job ps. If you want to do BGP optimization: don't have the BGP optimizer generate fake BGP announcements, but focus only on manipulating non-transitive attributes (like LOCAL_PREF) on real announcements you actually received from others. Or Perhaps BGP optimizers shouldn't even talk BGP but rather push freshly generated TE-optimized routing-policy to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate real announcements)... there are ways to do this, without risk to others! p.s. providing a publicly available BGP looking glasses will contribute to proving your innocence in cases like these. Since in many cases the AS_PATH is a complete fabrication, we need to manually check every AS in the AS_PATH to see whether the AS carries the fake more-specific. A public looking glass speeds up this fault-finding process. If you don't want to host a webinterface yourself, please consider sending a BGP feed to the Route Views Project or RIPE RIS, or for something queryable in a real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ From large.hadron.collider at gmx.com Fri Sep 1 05:51:05 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Thu, 31 Aug 2017 22:51:05 -0700 Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) In-Reply-To: <1221110534.6509.1504231488623.JavaMail.mhammett@ThunderFuck> References: <20170831200649.GP29058@Vurt.local> <1344261662.6475.1504230946348.JavaMail.mhammett@ThunderFuck> <447723577.6501.1504231325656.JavaMail.mhammett@ThunderFuck> <1221110534.6509.1504231488623.JavaMail.mhammett@ThunderFuck> Message-ID: <13c4ae36-7d05-ed66-14ac-7b8efe76456f@gmx.com> Nanog's quite a nice list to spend your sick day on. ;) On 31/08/2017 19:04, Mike Hammett wrote: > Sorry for now taking up 1/4 of this thread.... > > > My words in the last message don't match what I was thinking, but I think you all get the point. I'm sick, maybe I should be in bed instead of on NANOG. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Thursday, August 31, 2017 9:02:07 PM > Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack) > > Actually, I do remember that one of them would optimize inbound routes, but only billed on outbound usage (as it was content-focused). My in is over 8x my out, so hrm... maybe I'm on to something. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Thursday, August 31, 2017 8:55:46 PM > Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack) > > I would like to use a BGP optimizer, but I'm too poor. :-\ > > That said, I'm also an eyeball network, so modifications of my own advertisements are what affects the desired traffic, not so much the outbound routes. I know the BGP optimization industry is weighted towards content networks. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Job Snijders" > To: nanog at nanog.org > Sent: Thursday, August 31, 2017 3:06:49 PM > Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) > > Dear all, > > disclaimer: > > [ The following is targetted at the context where a BGP optimizer > generates BGP announcement that are ordinarily not seen in the > Default-Free Zone. The OP indicated they announce a /23, and were > unpleasantly surprised to see two unauthorized announcements for /24 > more-specifics pop up in their alerting system. No permission was > granted to create and announce these more-specifics. The AS_PATH > for those /24 announcements was entirely fabricated. Original thread > https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ] > > On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote: >> Presuming it was a route optimizer and the issue was ongoing, what >> would be the suggested course of action? > I strongly recommend to turn off those BGP optimizers, glue the ports > shut, burn the hardware, and salt the grounds on which the BGP optimizer > sales people walked. > > It is extremely irresponsible behavior to use software that generates > _fake_ BGP more-specifics for the purpose of traffic engineering. You > simply cannot expect that those more-specifics will never escape into > the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see > software bugs related to NO_EXPORT, and community-squashing > configuration mistakes happen all the time. > > Consider the following: if you leak your own internal more-specifics, at > least you are the legitimate destination. (You may suffer from > suboptimal routing, but it isn't guaranteed downtime.) However if you > generate fake more-specifics for prefixes belonging to OTHER > organisations, you essentially are complicit in BGP hijacking. If those > fake more-specifics accidentally leak into the DFZ, you are bringing > down the actual owner of such prefixes, and depriving people from access > to the Internet. Example case: > https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html > >> reach out to those 2 AS owners and see if they could stop it? > Yes, absolutely! And if everyone of the affected parties of this > localized hijack leak (or should we say 'victims') reaches out to the > wrongdoers, they contribute peer pressure to rectify the situation. Just > make sure you assign blame to the correct party. :) > >> Or is it something I just have to live with as a traffic engineering >> solution they are using and mark the alerts as false positives? > No, this is not something we should just accept. The Default-Free Zone > is a shared resource. Anyone using "BGP optimizers" is not only risking > their own online presence, but also everyone else's. Using a BGP > optimizer is essentially trading a degree of risk to society for the > purpose of saving a few bucks or milliseconds. It is basically saying: > "The optimizer helps me, but may hurt others, and I am fine with that". > > An analogy: We don't want transporters of radioactive material to cut > corners by using non-existant roads to bring the spent nuclear fuels > from A to B faster, nor do we want them to rely on non-robust shielding > that works "most of the time". > > We share the BGP DFZ environment, 'BGP optimizers' are downright > pollution contributors. > > Kind regards, > > Job > > ps. If you want to do BGP optimization: don't have the BGP optimizer > generate fake BGP announcements, but focus only on manipulating > non-transitive attributes (like LOCAL_PREF) on real announcements you > actually received from others. Or Perhaps BGP optimizers shouldn't even > talk BGP but rather push freshly generated TE-optimized routing-policy > to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come > to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate > real announcements)... there are ways to do this, without risk to others! > > p.s. providing a publicly available BGP looking glasses will contribute > to proving your innocence in cases like these. Since in many cases the > AS_PATH is a complete fabrication, we need to manually check every AS in > the AS_PATH to see whether the AS carries the fake more-specific. A > public looking glass speeds up this fault-finding process. If you don't > want to host a webinterface yourself, please consider sending a BGP feed > to the Route Views Project or RIPE RIS, or for something queryable in a > real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ > > > From amekkaoui at mektel.ca Fri Sep 1 06:56:00 2017 From: amekkaoui at mektel.ca (K MEKKAOUI) Date: Fri, 1 Sep 2017 02:56:00 -0400 Subject: Management softwares Message-ID: <008701d322ef$5fd83790$1f88a6b0$@ca> Hi We are a medium ISP. We are looking for Management software solutions. We are interested in finding a solution for billing, invoicing, scheduling, ticketing, provisioning and monitoring, Any suggestions or recommendations will be appreciated? We have been using multiple systems which do not communicate. Our objective is to use a single system or at least reduce the number of systems. Thank you KARIM M. From bjorn at mork.no Fri Sep 1 08:51:36 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 01 Sep 2017 10:51:36 +0200 Subject: BGP Optimizers In-Reply-To: <20170831200649.GP29058@Vurt.local> (Job Snijders's message of "Thu, 31 Aug 2017 22:06:49 +0200") References: <20170831200649.GP29058@Vurt.local> Message-ID: <87efrqyf6v.fsf@miraculix.mork.no> Job Snijders writes: > Using a BGP > optimizer is essentially trading a degree of risk to society for the > purpose of saving a few bucks or milliseconds. It is basically saying: > "The optimizer helps me, but may hurt others, and I am fine with that". People drive SUVs. Bjørn From randy at psg.com Fri Sep 1 09:26:13 2017 From: randy at psg.com (Randy Bush) Date: Fri, 01 Sep 2017 18:26:13 +0900 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> Message-ID: i have 142 largish bgp customers, a large enough number that the number of prefixes i receive from them varies annoyingly. how do i reasonably automate setting of my outbound prefix limit? randy From patrick at ianai.net Fri Sep 1 11:56:30 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 1 Sep 2017 07:56:30 -0400 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> Message-ID: <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> On Sep 1, 2017, at 5:26 AM, Randy Bush wrote: > > i have 142 largish bgp customers, a large enough number that the number > of prefixes i receive from them varies annoyingly. how do i reasonably > automate setting of my outbound prefix limit? First, it seems you know the inbound so automating the outbound is simple arithmetic. But even if that is unruly, setting the outbound to, say, 300K or so would keep you from spilling a full table. Not perfect, but better than nothing. Orrrrrr, perhaps this feature is not for you? -- TTFN, patrick From morrowc.lists at gmail.com Fri Sep 1 15:21:14 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 1 Sep 2017 11:21:14 -0400 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> Message-ID: On Fri, Sep 1, 2017 at 7:56 AM, Patrick W. Gilmore wrote: > On Sep 1, 2017, at 5:26 AM, Randy Bush wrote: > > > > i have 142 largish bgp customers, a large enough number that the number > > of prefixes i receive from them varies annoyingly. how do i reasonably > > automate setting of my outbound prefix limit? > > First, it seems you know the inbound so automating the outbound is simple > arithmetic. > > I would have said the same... i ought to know high-water marks for your inbound peer count(s), and can work out a +20% outbound... you also probably can survey your outbound peerings and +20% some high-water mark there, or make a 'meet in the middle' between the inbound-math and outbound-math. > But even if that is unruly, setting the outbound to, say, 300K or so would > keep you from spilling a full table. Not perfect, but better than nothing. > > Orrrrrr, perhaps this feature is not for you? > > -- > TTFN, > patrick > > From ml-nanog at techcompute.net Fri Sep 1 15:23:39 2017 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Fri, 1 Sep 2017 08:23:39 -0700 (PDT) Subject: NYC Metro Fiber Cut Message-ID: <893490560.1683407.1504279419398.JavaMail.zimbra@techcompute.net> Anyone hear about any fiber cuts in the NYC Metro that happened yesterday ? I had a service outage yesterday (that was area wide) with a carrier who I will not name that was blamed on a fiber cut. Any further information that could be offered would be appreciated. Regards, Mitchell T. Lewis MLewis at TechCompute.Net |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E Public PGP Key From lathama at gmail.com Fri Sep 1 15:34:40 2017 From: lathama at gmail.com (Andrew Latham) Date: Fri, 1 Sep 2017 10:34:40 -0500 Subject: Management softwares In-Reply-To: <008701d322ef$5fd83790$1f88a6b0$@ca> References: <008701d322ef$5fd83790$1f88a6b0$@ca> Message-ID: Long term developer on Odoo, could add some functionality via module for provisioning On Fri, Sep 1, 2017 at 1:56 AM, K MEKKAOUI wrote: > Hi > > > > We are a medium ISP. We are looking for Management software solutions. We > are interested in finding a solution for billing, invoicing, scheduling, > ticketing, provisioning and monitoring, Any suggestions or recommendations > will be appreciated? We have been using multiple systems which do not > communicate. Our objective is to use a single system or at least reduce the > number of systems. > > > > Thank you > > > > KARIM M. > > > > -- - Andrew "lathama" Latham lathama at gmail.com http://lathama.com - From cscora at apnic.net Fri Sep 1 18:02:44 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Sep 2017 04:02:44 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170901180244.6DDF4C44AD@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG MENOG, BJNOG, SDNOG, CMNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Sep, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 659343 Prefixes after maximum aggregation (per Origin AS): 257157 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 319791 Total ASes present in the Internet Routing Table: 58257 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 50359 Origin ASes announcing only one prefix: 22214 Transit ASes present in the Internet Routing Table: 7898 Transit-only ASes present in the Internet Routing Table: 227 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 56 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 60 Number of instances of unregistered ASNs: 63 Number of 32-bit ASNs allocated by the RIRs: 19864 Number of 32-bit ASNs visible in the Routing Table: 15650 Prefixes from 32-bit ASNs in the Routing Table: 63952 Number of bogon 32-bit ASNs visible in the Routing Table: 25 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 372 Number of addresses announced to Internet: 2853141856 Equivalent to 170 /8s, 15 /16s and 125 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219558 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179400 Total APNIC prefixes after maximum aggregation: 51947 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 178284 Unique aggregates announced from the APNIC address blocks: 74914 APNIC Region origin ASes present in the Internet Routing Table: 8310 APNIC Prefixes per ASN: 21.45 APNIC Region origin ASes announcing only one prefix: 2314 APNIC Region transit ASes present in the Internet Routing Table: 1181 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 56 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3170 Number of APNIC addresses announced to Internet: 764936416 Equivalent to 45 /8s, 152 /16s and 0 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 201333 Total ARIN prefixes after maximum aggregation: 95798 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 203102 Unique aggregates announced from the ARIN address blocks: 93704 ARIN Region origin ASes present in the Internet Routing Table: 17971 ARIN Prefixes per ASN: 11.30 ARIN Region origin ASes announcing only one prefix: 6641 ARIN Region transit ASes present in the Internet Routing Table: 1772 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2166 Number of ARIN addresses announced to Internet: 1110269216 Equivalent to 66 /8s, 45 /16s and 93 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 176865 Total RIPE prefixes after maximum aggregation: 86656 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 172744 Unique aggregates announced from the RIPE address blocks: 104339 RIPE Region origin ASes present in the Internet Routing Table: 24342 RIPE Prefixes per ASN: 7.10 RIPE Region origin ASes announcing only one prefix: 11172 RIPE Region transit ASes present in the Internet Routing Table: 3459 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6142 Number of RIPE addresses announced to Internet: 713157760 Equivalent to 42 /8s, 129 /16s and 236 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 84795 Total LACNIC prefixes after maximum aggregation: 18896 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 86057 Unique aggregates announced from the LACNIC address blocks: 39541 LACNIC Region origin ASes present in the Internet Routing Table: 6328 LACNIC Prefixes per ASN: 13.60 LACNIC Region origin ASes announcing only one prefix: 1755 LACNIC Region transit ASes present in the Internet Routing Table: 1176 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3839 Number of LACNIC addresses announced to Internet: 171204576 Equivalent to 10 /8s, 52 /16s and 95 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16888 Total AfriNIC prefixes after maximum aggregation: 3807 AfriNIC Deaggregation factor: 4.44 Prefixes being announced from the AfriNIC address blocks: 18784 Unique aggregates announced from the AfriNIC address blocks: 7013 AfriNIC Region origin ASes present in the Internet Routing Table: 1049 AfriNIC Prefixes per ASN: 17.91 AfriNIC Region origin ASes announcing only one prefix: 331 AfriNIC Region transit ASes present in the Internet Routing Table: 202 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 333 Number of AfriNIC addresses announced to Internet: 93091584 Equivalent to 5 /8s, 140 /16s and 119 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5408 4194 88 ERX-CERNET-BKB China Education and Rese 7545 3901 406 384 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2961 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2839 11126 752 KIXS-AS-KR Korea Telecom, KR 9829 2757 1499 541 BSNL-NIB National Internet Backbone, IN 9808 2351 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2101 423 221 TATACOMM-AS TATA Communications formerl 45899 2101 1468 116 VNPT-AS-VN VNPT Corp, VN 7552 1659 1105 70 VIETEL-AS-AP Viettel Corporation, VN 9498 1623 361 143 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3643 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3463 1341 87 SHAW - Shaw Communications Inc., CA 18566 2204 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2047 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2032 2237 434 CHARTER-NET-HKY-NC - Charter Communicat 209 1898 5066 641 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1826 329 285 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16509 1823 3960 527 AMAZON-02 - Amazon.com, Inc., US 6983 1695 854 229 ITCDELTA - Earthlink, Inc., US 701 1673 10557 629 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2977 958 2132 AKAMAI-ASN1, US 8551 2496 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2060 333 425 TELLCOM-AS, TR 9121 1801 1691 17 TTNET, TR 12389 1704 1614 669 ROSTELECOM-AS, RU 12479 1676 1052 60 UNI2-AS, ES 13188 1602 100 55 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1192 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3557 542 210 Telmex Colombia S.A., CO 8151 2980 3416 579 Uninet S.A. de C.V., MX 11830 2108 370 65 Instituto Costarricense de Electricidad 6503 1609 437 53 Axtel, S.A.B. de C.V., MX 7303 1564 1021 247 Telecom Argentina S.A., AR 6147 1252 377 27 Telefonica del Peru S.A.A., PE 3816 1025 504 94 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 960 2284 185 CLARO S.A., BR 11172 918 126 86 Alestra, S. de R.L. de C.V., MX 18881 898 1052 23 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1173 398 48 LINKdotNET-AS, EG 37611 755 91 8 Afrihost, ZA 36903 711 357 130 MT-MPLS, MA 36992 655 1383 29 ETISALAT-MISR, EG 24835 451 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 410 354 77 ORANGE-, TN 15399 361 35 7 WANANCHI-, KE 2018 300 327 74 TENET-1, ZA 23889 293 103 14 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5408 4194 88 ERX-CERNET-BKB China Education and Rese 7545 3901 406 384 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3643 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3557 542 210 Telmex Colombia S.A., CO 6327 3463 1341 87 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 8151 2980 3416 579 Uninet S.A. de C.V., MX 20940 2977 958 2132 AKAMAI-ASN1, US 17974 2961 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2839 11126 752 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3901 3517 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3643 3485 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 6327 3463 3376 SHAW - Shaw Communications Inc., CA 39891 3387 3364 ALJAWWALSTC-AS, SA 10620 3557 3347 Telmex Colombia S.A., CO 17974 2961 2888 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2496 2455 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 8151 2980 2401 Uninet S.A. de C.V., MX 9808 2351 2319 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2757 2216 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65346 PRIVATE 94.50.36.0/22 31094 TTKNET Tyumen, Russia, RU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.226.112.0/20 62788 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.79.12.0/22 37306 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:284 /13:552 /14:1046 /15:1862 /16:13418 /17:7658 /18:13439 /19:24735 /20:38788 /21:41733 /22:78989 /23:65026 /24:369192 /25:853 /26:632 /27:647 /28:39 /29:39 /30:214 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3260 3463 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2841 3643 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2088 2204 MEGAPATH5-US - MegaPath Corporation, US 8551 1961 2496 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1608 1826 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1501 3557 Telmex Colombia S.A., CO 11830 1498 2108 Instituto Costarricense de Electricidad y Telec 11492 1415 1593 CABLEONE - CABLE ONE, INC., US 6389 1358 2047 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1561 2:830 4:18 5:2466 6:31 7:1 8:1052 12:1851 13:144 14:1713 15:28 16:2 17:195 18:90 20:60 23:2444 24:1938 25:2 27:2361 29:1 31:1927 32:84 33:20 35:21 36:416 37:2351 38:1363 39:69 40:98 41:2869 42:462 43:1965 44:79 45:3006 46:2798 47:165 49:1253 50:994 51:19 52:817 54:365 55:4 56:4 57:43 58:1592 59:1007 60:311 61:1923 62:1698 63:1911 64:4681 65:2207 66:4575 67:2284 68:1227 69:3391 70:1169 71:604 72:2169 74:2715 75:398 76:427 77:1504 78:1464 79:1907 80:1401 81:1392 82:1004 83:730 84:966 85:1826 86:466 87:1194 88:762 89:2185 90:165 91:6212 92:1009 93:2400 94:2331 95:2673 96:641 97:355 98:1005 99:98 100:153 101:1446 102:1 103:15771 104:3033 105:185 106:552 107:1770 108:823 109:2908 110:1459 111:1745 112:1244 113:1272 114:1074 115:1587 116:1653 117:1761 118:2156 119:1654 120:736 121:1059 122:2347 123:1833 124:1484 125:1783 128:862 129:672 130:442 131:1472 132:578 133:194 134:686 135:225 136:452 137:489 138:1906 139:517 140:380 141:645 142:753 143:878 144:807 145:184 146:1090 147:698 148:1499 149:584 150:713 151:985 152:734 153:296 154:844 155:757 156:673 157:670 158:481 159:1558 160:748 161:746 162:2513 163:511 164:959 165:1425 166:383 167:1296 168:3008 169:841 170:3503 171:366 172:996 173:2000 174:782 175:759 176:1893 177:3944 178:2577 179:1115 180:2197 181:1987 182:2435 183:768 184:864 185:10659 186:3274 187:2192 188:2580 189:1809 190:8341 191:1318 192:9610 193:5805 194:4723 195:3917 196:2135 197:1306 198:5533 199:5894 200:7602 201:4365 202:10342 203:9941 204:4545 205:2853 206:3076 207:3159 208:4026 209:4006 210:3971 211:2059 212:2862 213:2527 214:847 215:66 216:5898 217:2116 218:903 219:601 220:1678 221:917 222:742 223:1206 End of report From jfmezei_nanog at vaxination.ca Fri Sep 1 18:32:44 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 1 Sep 2017 14:32:44 -0400 Subject: Moving fibre trunks: interruptions? Message-ID: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> A large highway interchange is being rebuilt in Montréal (Turcot) and this requires that the CN mainline tracks out of downtown be moved a few hundred metres to the north for a couple of kilometres until it rejoins the existing alignment. Part of the contract involves the cost of moving the fibre trunks along with the tracks. (old alignment will become commercial properties). So they have new cable that goes through the new alignment and joins the old one at both ends. So they'll have hundreds of strands to splice. When doing that type of work, how much downtime can be expected for each strand? Would they typically use patch panels in central offices to move a customer to a spare strand while they splice their assigned strand to use the new cable segment (and then move traffic back to that assigned strand?). Or would they switch customers around to new strands and update their documentation on which customer is on which strand? Or do they do nothing at patch panels in COs and just take whatever time it is needed to have crews at both ends of the work site splice each strand at same time (I assume about 5 minutes outage for each strand?) Would they normally involve the customer advising them of upcoming outage? Would the folks working trackside be limited to overnight hours to make outages less significant, or do they work around the clock ? From Daniel.Jameson at tdstelecom.com Fri Sep 1 18:42:11 2017 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Fri, 1 Sep 2017 18:42:11 +0000 Subject: Management softwares In-Reply-To: <008701d322ef$5fd83790$1f88a6b0$@ca> References: <008701d322ef$5fd83790$1f88a6b0$@ca> Message-ID: Give this a look; the webpage doesn't do it justice. It Doesn't do billing/invoicing, but does everything else on your list. http://www.crestpt.com/fme-platforms.html -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K MEKKAOUI Sent: Friday, September 01, 2017 12:56 AM To: nanog at nanog.org Subject: Management softwares Hi We are a medium ISP. We are looking for Management software solutions. We are interested in finding a solution for billing, invoicing, scheduling, ticketing, provisioning and monitoring, Any suggestions or recommendations will be appreciated? We have been using multiple systems which do not communicate. Our objective is to use a single system or at least reduce the number of systems. Thank you KARIM M. From jayhanke at gmail.com Fri Sep 1 18:44:23 2017 From: jayhanke at gmail.com (Jay Hanke) Date: Fri, 1 Sep 2017 13:44:23 -0500 Subject: Moving fibre trunks: interruptions? In-Reply-To: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: I'd expect at least a couple of hours of outage while the cable is reconnected. When doing the move on the live cable (assuming 1 cable). There will be a splicing crew at each end of the move. They will then break a tube or ribbon at a time and splice into the new cable. Splicing unused portions of the cable and then moving patches is also done. In my experience, it's much more common to resplice on the existing strands. A large cable will take quite a while to resplice, likely more than just overnight depending on the size of the cable. Jay On Fri, Sep 1, 2017 at 1:32 PM, Jean-Francois Mezei wrote: > > A large highway interchange is being rebuilt in Montréal (Turcot) and > this requires that the CN mainline tracks out of downtown be moved a few > hundred metres to the north for a couple of kilometres until it rejoins > the existing alignment. > > Part of the contract involves the cost of moving the fibre trunks along > with the tracks. (old alignment will become commercial properties). > > > So they have new cable that goes through the new alignment and joins the > old one at both ends. So they'll have hundreds of strands to splice. > > When doing that type of work, how much downtime can be expected for each > strand? > > Would they typically use patch panels in central offices to move a > customer to a spare strand while they splice their assigned strand to > use the new cable segment (and then move traffic back to that assigned > strand?). Or would they switch customers around to new strands and > update their documentation on which customer is on which strand? > > Or do they do nothing at patch panels in COs and just take whatever time > it is needed to have crews at both ends of the work site splice each > strand at same time (I assume about 5 minutes outage for each strand?) > > > Would they normally involve the customer advising them of upcoming > outage? Would the folks working trackside be limited to overnight hours > to make outages less significant, or do they work around the clock ? > From mloftis at wgops.com Fri Sep 1 19:32:44 2017 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 01 Sep 2017 19:32:44 +0000 Subject: Moving fibre trunks: interruptions? In-Reply-To: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: If it is in the railroad RoW they may be restricted to daylight working only. Check with your provider or OSP crew. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From edugas at unknowndevice.ca Fri Sep 1 19:34:39 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Fri, 01 Sep 2017 19:34:39 +0000 Subject: Moving fibre trunks: interruptions? In-Reply-To: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: From jared at puck.nether.net Fri Sep 1 19:37:01 2017 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 1 Sep 2017 15:37:01 -0400 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: > On Sep 1, 2017, at 3:32 PM, Michael Loftis wrote: > > If it is in the railroad RoW they may be restricted to daylight working > only. Check with your provider or OSP crew. > Yup. Railroad work is complex just because you have to coordinate with the railroad owner and they have to be onsite for all work. The cost of going underground vs aerial is also astronomical in many cases. - Jared From rod.beck at unitedcablecompany.com Fri Sep 1 19:52:40 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 1 Sep 2017 19:52:40 +0000 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> , Message-ID: I don't think there is virtually any aerial in Europe. So given the cost difference why is virtually all fiber buried on this side of the Atlantic? ________________________________ From: NANOG on behalf of Jared Mauch Sent: Friday, September 1, 2017 9:37 PM To: Michael Loftis Cc: Nanog at nanog.org Subject: Re: Moving fibre trunks: interruptions? > On Sep 1, 2017, at 3:32 PM, Michael Loftis wrote: > > If it is in the railroad RoW they may be restricted to daylight working > only. Check with your provider or OSP crew. > Yup. Railroad work is complex just because you have to coordinate with the railroad owner and they have to be onsite for all work. The cost of going underground vs aerial is also astronomical in many cases. - Jared From ahebert at pubnix.net Fri Sep 1 20:12:47 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 1 Sep 2017 16:12:47 -0400 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: <6c67adfc-41f8-5347-953a-a97ae9920031@pubnix.net> Yeah, Being somehow familiar with how things operate when it involve Quebec Govt and the Fed Govt... Expect hell. Pray for purgatory. Rejoice if it takes less than 3 months. PS: At least we have very good, and dedicated, cabling crews. =D. But yeah, there is work being done to reduce the downtime to a manageable timeframe. If not simply redundancy being added to allow for the time to splice that bad boy. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 09/01/17 14:44, Jay Hanke wrote: > I'd expect at least a couple of hours of outage while the cable is reconnected. > > When doing the move on the live cable (assuming 1 cable). There will > be a splicing crew at each end of the move. They will then break a > tube or ribbon at a time and splice into the new cable. > > Splicing unused portions of the cable and then moving patches is also > done. In my experience, it's much more common to resplice on the > existing strands. > > A large cable will take quite a while to resplice, likely more than > just overnight depending on the size of the cable. > > Jay > > On Fri, Sep 1, 2017 at 1:32 PM, Jean-Francois Mezei > wrote: >> A large highway interchange is being rebuilt in Montréal (Turcot) and >> this requires that the CN mainline tracks out of downtown be moved a few >> hundred metres to the north for a couple of kilometres until it rejoins >> the existing alignment. >> >> Part of the contract involves the cost of moving the fibre trunks along >> with the tracks. (old alignment will become commercial properties). >> >> >> So they have new cable that goes through the new alignment and joins the >> old one at both ends. So they'll have hundreds of strands to splice. >> >> When doing that type of work, how much downtime can be expected for each >> strand? >> >> Would they typically use patch panels in central offices to move a >> customer to a spare strand while they splice their assigned strand to >> use the new cable segment (and then move traffic back to that assigned >> strand?). Or would they switch customers around to new strands and >> update their documentation on which customer is on which strand? >> >> Or do they do nothing at patch panels in COs and just take whatever time >> it is needed to have crews at both ends of the work site splice each >> strand at same time (I assume about 5 minutes outage for each strand?) >> >> >> Would they normally involve the customer advising them of upcoming >> outage? Would the folks working trackside be limited to overnight hours >> to make outages less significant, or do they work around the clock ? >> From EPers at ansencorp.com Fri Sep 1 20:55:24 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Fri, 1 Sep 2017 20:55:24 +0000 Subject: Northeast TWC/Spectrum contact? Message-ID: Hi Can someone from TWC/Spectrum’s northeast division please contact me off list? AS11351 for what it’s worth About a week ago my modem dropped from 24 bonded channels at about -6dBmV to 19 channels ranging from -9.30 to -21.30dBmV, and I started seeing very high latency and packetloss. I’ve also been seeing a lot of Lost MDD’s and RCS Partial’s in my event log. Haven’t put a tdr down the customer side cabling yet but I doubt that’s the issue, it’s only a 25’ run and a visual inspection doesn’t show anything out of the ordinary. Sorry for spamming the list, but every time I’ve called TWC customer support lines in the past I’ve been transferred between 5-8 people who each told me to reboot my modem and check the cables. Thanks for your time, Ed Pers From jfmezei_nanog at vaxination.ca Fri Sep 1 22:02:34 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 1 Sep 2017 18:02:34 -0400 Subject: Moving fibre trunks: interruptions? In-Reply-To: <6c67adfc-41f8-5347-953a-a97ae9920031@pubnix.net> References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> <6c67adfc-41f8-5347-953a-a97ae9920031@pubnix.net> Message-ID: <172c7680-3af2-7d5b-e8fc-05e9af38c691@vaxination.ca> On 2017-09-01 16:12, Alain Hebert wrote: > Being somehow familiar with how things operate when it involve > Quebec Govt and the Fed Govt... Expect hell. Pray for purgatory. > Rejoice if it takes less than 3 months. In this particular case, the government is giving CN new land, and once construction crews for the highway/interchange have moved on, segments are opened for CN to bring its crews to install tracks, portals, signals, track service road etc. The main contract gives CN responsability to handle the telecom under its tracks, so I assume that once CN is given access to the full length of new right of way, it will coordinate with the various telecom companies that rent space under its tracks to do the move. The move is expected in summer 2018. (during next winter, the last remaining elevated structures that block the new CN right of way will be torn down, allowing CN to then finish the work starting in spring. (it does not lay tracks in winter). From jfbeam at gmail.com Fri Sep 1 22:38:23 2017 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 01 Sep 2017 18:38:23 -0400 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: On Fri, 01 Sep 2017 15:52:40 -0400, Rod Beck wrote: > I don't think there is virtually any aerial in Europe. So given the cost > difference why is virtually all fiber buried on this side of the > Atlantic? Aerial is simple and fast... pull the cable through a stringer, move to the next pole and repeat; when a section (about a mile) is done, it's hoisted into the air and tied to the pole. The stringers are then moved to the next mile of poles and the process repeats. Buried stuff requires a great deal of planning, permitting, and insurance. You have to know everything that's ever been stuffed in the ground within half a mile of where you're working to avoid the inevitable cutting of something important -- gas, water, sewer, power, other telcom, even vacuum tube lines and subways. And then you need trenching gear to get stuff in the ground, and crews to come along behind to remediate the "environmental damage". (Once the conduit is in the ground, it's a trivial matter to blow whatever you need through it.) From tom at cloudflare.com Fri Sep 1 23:56:24 2017 From: tom at cloudflare.com (Tom Paseka) Date: Sat, 2 Sep 2017 09:56:24 +1000 Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) In-Reply-To: <20170831200649.GP29058@Vurt.local> References: <20170831200649.GP29058@Vurt.local> Message-ID: We regularly see poorly configured "optimizers" or networks hijacking our prefixes (originating /25's, /24 of /23's etc). Thankfully, most of the time filters are in place to stop them leaking badly, but I agree, these are toxic. -Tom On Fri, Sep 1, 2017 at 6:06 AM, Job Snijders wrote: > Dear all, > > disclaimer: > > [ The following is targetted at the context where a BGP optimizer > generates BGP announcement that are ordinarily not seen in the > Default-Free Zone. The OP indicated they announce a /23, and were > unpleasantly surprised to see two unauthorized announcements for /24 > more-specifics pop up in their alerting system. No permission was > granted to create and announce these more-specifics. The AS_PATH > for those /24 announcements was entirely fabricated. Original thread > https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ] > > On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote: > > Presuming it was a route optimizer and the issue was ongoing, what > > would be the suggested course of action? > > I strongly recommend to turn off those BGP optimizers, glue the ports > shut, burn the hardware, and salt the grounds on which the BGP optimizer > sales people walked. > > It is extremely irresponsible behavior to use software that generates > _fake_ BGP more-specifics for the purpose of traffic engineering. You > simply cannot expect that those more-specifics will never escape into > the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see > software bugs related to NO_EXPORT, and community-squashing > configuration mistakes happen all the time. > > Consider the following: if you leak your own internal more-specifics, at > least you are the legitimate destination. (You may suffer from > suboptimal routing, but it isn't guaranteed downtime.) However if you > generate fake more-specifics for prefixes belonging to OTHER > organisations, you essentially are complicit in BGP hijacking. If those > fake more-specifics accidentally leak into the DFZ, you are bringing > down the actual owner of such prefixes, and depriving people from access > to the Internet. Example case: > https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html > > > reach out to those 2 AS owners and see if they could stop it? > > Yes, absolutely! And if everyone of the affected parties of this > localized hijack leak (or should we say 'victims') reaches out to the > wrongdoers, they contribute peer pressure to rectify the situation. Just > make sure you assign blame to the correct party. :) > > > Or is it something I just have to live with as a traffic engineering > > solution they are using and mark the alerts as false positives? > > No, this is not something we should just accept. The Default-Free Zone > is a shared resource. Anyone using "BGP optimizers" is not only risking > their own online presence, but also everyone else's. Using a BGP > optimizer is essentially trading a degree of risk to society for the > purpose of saving a few bucks or milliseconds. It is basically saying: > "The optimizer helps me, but may hurt others, and I am fine with that". > > An analogy: We don't want transporters of radioactive material to cut > corners by using non-existant roads to bring the spent nuclear fuels > from A to B faster, nor do we want them to rely on non-robust shielding > that works "most of the time". > > We share the BGP DFZ environment, 'BGP optimizers' are downright > pollution contributors. > > Kind regards, > > Job > > ps. If you want to do BGP optimization: don't have the BGP optimizer > generate fake BGP announcements, but focus only on manipulating > non-transitive attributes (like LOCAL_PREF) on real announcements you > actually received from others. Or Perhaps BGP optimizers shouldn't even > talk BGP but rather push freshly generated TE-optimized routing-policy > to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come > to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate > real announcements)... there are ways to do this, without risk to others! > > p.s. providing a publicly available BGP looking glasses will contribute > to proving your innocence in cases like these. Since in many cases the > AS_PATH is a complete fabrication, we need to manually check every AS in > the AS_PATH to see whether the AS carries the fake more-specific. A > public looking glass speeds up this fault-finding process. If you don't > want to host a webinterface yourself, please consider sending a BGP feed > to the Route Views Project or RIPE RIS, or for something queryable in a > real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ > From randy at psg.com Sat Sep 2 03:40:33 2017 From: randy at psg.com (Randy Bush) Date: Sat, 02 Sep 2017 12:40:33 +0900 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> Message-ID: >>> i have 142 largish bgp customers, a large enough number that the number >>> of prefixes i receive from them varies annoyingly. how do i reasonably >>> automate setting of my outbound prefix limit? >> >> First, it seems you know the inbound so automating the outbound is simple >> arithmetic. > > I would have said the same... i ought to know high-water marks for your > inbound peer count(s), and can work out a +20% outbound... you just assumed that the transitive closure of everybody's cones implement and propagate count. ain't gonna happen. From job at instituut.net Sat Sep 2 07:05:41 2017 From: job at instituut.net (Job Snijders) Date: Sat, 02 Sep 2017 07:05:41 +0000 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> Message-ID: On Sat, 2 Sep 2017 at 05:41, Randy Bush wrote: > >>> i have 142 largish bgp customers, a large enough number that the number > >>> of prefixes i receive from them varies annoyingly. how do i reasonably > >>> automate setting of my outbound prefix limit? > >> > >> First, it seems you know the inbound so automating the outbound is > simple > >> arithmetic. > > > > I would have said the same... i ought to know high-water marks for your > > inbound peer count(s), and can work out a +20% outbound... > > you just assumed that the transitive closure of everybody's cones > implement and propagate count. ain't gonna happen. I am not sure what the issue here is. If I can tell my peering partner a recommended maximum prefix value for them to set on their side, surely I can configure that same value on my side as the upper outbound limit. Kind regards, Job From randy at psg.com Sat Sep 2 07:27:03 2017 From: randy at psg.com (Randy Bush) Date: Sat, 02 Sep 2017 16:27:03 +0900 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> Message-ID: >>>>> i have 142 largish bgp customers, a large enough number that the >>>>> number of prefixes i receive from them varies annoyingly. how do >>>>> i reasonably automate setting of my outbound prefix limit? >>>> >>>> First, it seems you know the inbound so automating the outbound is >>>> simple arithmetic. >>> >>> I would have said the same... i ought to know high-water marks for >>> your inbound peer count(s), and can work out a +20% outbound... >> >> you just assumed that the transitive closure of everybody's cones >> implement and propagate count. ain't gonna happen. > > I am not sure what the issue here is. If I can tell my peering partner > a recommended maximum prefix value for them to set on their side, > surely I can configure that same value on my side as the upper > outbound limit. which is why i do not tell peers a max count. this stuff works for small isps, in the lab, ... but not at scale; especially when you have isps as customers. i wish it did. bgp at scale is rather dynamic. i suspect your $dayjob's irr filters being exact help a bit. randy From job at instituut.net Sat Sep 2 08:16:29 2017 From: job at instituut.net (Job Snijders) Date: Sat, 2 Sep 2017 10:16:29 +0200 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> Message-ID: <20170902081629.GS29058@Vurt.local> On Sat, Sep 02, 2017 at 04:27:03PM +0900, Randy Bush wrote: > > I am not sure what the issue here is. If I can tell my peering > > partner a recommended maximum prefix value for them to set on their > > side, surely I can configure that same value on my side as the upper > > outbound limit. > > which is why i do not tell peers a max count. I think you'll find that some of your peers will make an educated guess and set an inbound limit anyway. Actively requesting that no limit is applied may make one part of a fringe minority. Most networks publish a baseline number via a rendezvous point like PeeringDB, this makes it easy to signal to larger groups what the recommended values are. > this stuff works for small isps, in the lab, ... but not at scale; > especially when you have isps as customers. i wish it did. In this context "small ISPs" may account for the majority of the target audience. It appears there are about 50,000 "origin only" ASNs [1], for the majority of those it'll be straightforward to decide on a sensible max-out value. BGP speaking CDN caching nodes are also low hanging fruit. But even for a network like NTT I can see benefits of a max-out limit in a number of scenarios. > bgp at scale is rather dynamic. i suspect your $dayjob's irr filters > being exact help a bit. Yes, BGP is dynamic, but these days a lot of the topology at the wholesale level has been firmly pinned down through mechanisms like 'peerlock' [2]. Speaking as an ISP for ISPs: NTT/2914 applies an inbound maximum-prefix limit on each and every EBGP session. Kind regards, Job [1]: http://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2%2e0%2fbgp-as-term%2etxt&descr=Origin%20only%20ASes&ylabel=Origin%20only%20ASes&with=step [2]: http://instituut.net/~job/peerlock_manual.pdf From morrowc.lists at gmail.com Sat Sep 2 16:08:41 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 2 Sep 2017 12:08:41 -0400 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <20170902081629.GS29058@Vurt.local> References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> <20170902081629.GS29058@Vurt.local> Message-ID: (from earlier randy) > you just assumed that the transitive closure of everybody's cones > implement and propagate count. ain't gonna happen. well, I was thinking that you can survey your customers to know their approximate inbound number, you can implement a max-prefix in from them with that (ideally you're already doing that). You can figure out the output from you as well in a similar fashion. In either case you're not implementing a limit that's 1% larger than the actual number, you're hedging the number for at least operational overhead reasons to 20-40%. Even a large ISP is sending (today) less than 100k prefixes when the peer isn't asking for 'full routes'. So, I'd imagine you bucket your customers as: default only - limit 10 customer prefixes only - limit +30% of your customer routes set full transit - +20% of current full table (yes, you may have more buckets than me, meh) and those are good starting points, if you keep these bucketed you can just ratchet up the limits as time requires. The prefix-limits (in or out) isn't to stop jim-isp from sending 2 of jane-isp's routes, it's to keep jim-isp from making a bad situation very bad. You (ideally!) have prefix-lists to limit jim from sending jane's routes. On Sat, Sep 2, 2017 at 4:16 AM, Job Snijders wrote: > On Sat, Sep 02, 2017 at 04:27:03PM +0900, Randy Bush wrote: > > > I am not sure what the issue here is. If I can tell my peering > > > partner a recommended maximum prefix value for them to set on their > > > side, surely I can configure that same value on my side as the upper > > > outbound limit. > > > > which is why i do not tell peers a max count. > > I think you'll find that some of your peers will make an educated guess > and set an inbound limit anyway. Actively requesting that no limit is > applied may make one part of a fringe minority. > > This is a quick survey of your peers and setting the buckets from above at 'sane' limits, right? > Most networks publish a baseline number via a rendezvous point like > PeeringDB, this makes it easy to signal to larger groups what the > recommended values are. > > > this stuff works for small isps, in the lab, ... but not at scale; > > especially when you have isps as customers. i wish it did. > > In this context "small ISPs" may account for the majority of the target > audience. It appears there are about 50,000 "origin only" ASNs [1], for > the majority of those it'll be straightforward to decide on a sensible > max-out value. BGP speaking CDN caching nodes are also low hanging > fruit. But even for a network like NTT I can see benefits of a max-out > limit in a number of scenarios. > > > bgp at scale is rather dynamic. i suspect your $dayjob's irr filters > > being exact help a bit. > > Yes, BGP is dynamic, but these days a lot of the topology at the > wholesale level has been firmly pinned down through mechanisms like > 'peerlock' [2]. > > Speaking as an ISP for ISPs: NTT/2914 applies an inbound maximum-prefix > limit on each and every EBGP session. > > you can answer this if you want, or not.. but I'm curious, is this tuned-per-peer? or via some bucket form as I proposed above? I expect ntt COULD per-peer, since I think almost-all-config is auto-generated, but I'd be curious still if you decided at the bucket level instead because it's saner to think about it that way (for me anyway) or just went 'current +N%' for each peer? > Kind regards, > > Job > > [1]: http://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata% > 2fbgp%2fas2%2e0%2fbgp-as-term%2etxt&descr=Origin%20only% > 20ASes&ylabel=Origin%20only%20ASes&with=step > [2]: http://instituut.net/~job/peerlock_manual.pdf > From job at instituut.net Sat Sep 2 17:41:20 2017 From: job at instituut.net (Job Snijders) Date: Sat, 2 Sep 2017 19:41:20 +0200 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> <20170902081629.GS29058@Vurt.local> Message-ID: <20170902174120.GU29058@Vurt.local> On Sat, Sep 02, 2017 at 12:08:41PM -0400, Christopher Morrow wrote: > > I think you'll find that some of your peers will make an educated > > guess and set an inbound limit anyway. Actively requesting that no > > limit is applied may make one part of a fringe minority. > > This is a quick survey of your peers and setting the buckets from > above at 'sane' limits, right? yes > > Speaking as an ISP for ISPs: NTT/2914 applies an inbound > > maximum-prefix limit on each and every EBGP session. > > you can answer this if you want, or not.. but I'm curious, is this > tuned-per-peer? or via some bucket form as I proposed above? I expect > ntt COULD per-peer, since I think almost-all-config is auto-generated, > but I'd be curious still if you decided at the bucket level instead > because it's saner to think about it that way (for me anyway) or just > went 'current +N%' for each peer? I can contribute two examples: NTT (AS 2914): We use both approaches. For downstream customers a simple bucket system is used (currently with just one bucket: 31000 for IPv4, 2000 for IPv6). On the peering side of things the announcement count for each peer is polled at regular intervals and a +N% limit is set. In both approaches an override option is available in case someone emails the NOC "hey, we are about to turn up something big, can you ensure there is sufficient headroom". Coloclue (AS 8283): For every peering partner, data is fetched from the PeeringDB API and the fields visible here https://www.peeringdb.com/asn/2914 as 'IPv4 Prefixes' and 'IPv6 Prefixes' are used as input into the router configuration process. Coloclue's formula is simple, if the field's value is less than 100, set the limit to 100, if the value is over 100: add 10% to whatever value was published. This process is executed every 12 hours. In case no PDB record for the ASN exists: set 10,000 for IPv4 / 1,000 for IPv6. A manual override mechanism exists. If I compare the two: NTT's method emphasizes business continuity and has no external dependencies, Coloclue (being a network for experimentation) explores how to avoid explicit noc-to-noc coordination and relies on self-published data being kept up to date. Whatever your cooking method, maximum prefix limits should never get in the way of normal operations (e.g. organic growth), but exist only to try to nip obvious route leaks in the bud. This means one can be quite generous when picking values. Kind regards, Job From jfmezei_nanog at vaxination.ca Sat Sep 2 18:38:04 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 2 Sep 2017 14:38:04 -0400 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: <7a669ff6-34cb-4fb1-7daf-5f6437a78895@vaxination.ca> On 2017-09-01 18:38, Ricky Beam wrote: > Buried stuff requires a great deal of planning, permitting, and insurance. Are cables in railway right of way considered "burried stuff" from the point of view of all the regulatory approvals since it is on private land (railway's) ? I take it that it is the railway which burries a new cable in its ballast (since it knows where other cables are burried, has to handle cable crossing its bridges etc)? In the specific case of Turcot in Montréal, the government was in charge of cleaning the land, removing any obstructions (such as a major sewer collector which had to be moved) etc, and even drained and compressed the ground before handing it over to CN to build its tracks. So CN got a clean slate, ready to lay tarp, ballast and tracks (and later string fibre). (ironically, that land used to belong to CN and was the Turcot rail yards). From mh at xalto.net Sat Sep 2 18:59:37 2017 From: mh at xalto.net (Michael Hallgren) Date: Sat, 2 Sep 2017 20:59:37 +0200 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: Aerial's not that rare in Europe (rural areas, sometimes even close to metro). Cheers, mh Le 01/09/2017 à 21:52, Rod Beck a écrit : > I don't think there is virtually any aerial in Europe. So given the cost difference why is virtually all fiber buried on this side of the Atlantic? > > > ________________________________ > From: NANOG on behalf of Jared Mauch > Sent: Friday, September 1, 2017 9:37 PM > To: Michael Loftis > Cc: Nanog at nanog.org > Subject: Re: Moving fibre trunks: interruptions? > > > >> On Sep 1, 2017, at 3:32 PM, Michael Loftis wrote: >> >> If it is in the railroad RoW they may be restricted to daylight working >> only. Check with your provider or OSP crew. >> > > Yup. Railroad work is complex just because you have to coordinate with the railroad owner and they have to be onsite for all work. The cost of going underground vs aerial is also astronomical in many cases. > > - Jared From baldur.norddahl at gmail.com Sat Sep 2 19:25:33 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 2 Sep 2017 21:25:33 +0200 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: That depends on the country. Here in Denmark it is not possible to get rights to put up any aerial at all. The cost difference is irrelevant when you have no option but to put it in the ground. Not only is there no new aerial installations here but the old ones are taken down. Very little is left by now and in a few years it will all be gone. The municipalities want it pretty and wires in the air is ugly. One advantage however is that buried stuff usually survives storms better. Den 1. sep. 2017 21.53 skrev "Rod Beck" : I don't think there is virtually any aerial in Europe. So given the cost difference why is virtually all fiber buried on this side of the Atlantic? From mh at xalto.net Sat Sep 2 19:47:47 2017 From: mh at xalto.net (Michael Hallgren) Date: Sat, 2 Sep 2017 21:47:47 +0200 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: <7d5a95cb-8b19-2398-e5e8-e39aa9129822@xalto.net> Le 02/09/2017 à 21:25, Baldur Norddahl a écrit : > That depends on the country. Here in Denmark it is not possible to get > rights to put up any aerial at all. The cost difference is irrelevant when > you have no option but to put it in the ground. > > Not only is there no new aerial installations here but the old ones are > taken down. Very little is left by now and in a few years it will all be > gone. The municipalities want it pretty and wires in the air is ugly. > > One advantage however is that buried stuff usually survives storms better. Right. Here in France it (aerial running along with copper) happens even close to metropoles (like Paris). mh > > Den 1. sep. 2017 21.53 skrev "Rod Beck" : > > I don't think there is virtually any aerial in Europe. So given the cost > difference why is virtually all fiber buried on this side of the Atlantic? From theodore at ciscodude.net Sun Sep 3 00:05:26 2017 From: theodore at ciscodude.net (Theodore Baschak) Date: Sat, 2 Sep 2017 19:05:26 -0500 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <20170902174120.GU29058@Vurt.local> References: <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> <20170902081629.GS29058@Vurt.local> <20170902174120.GU29058@Vurt.local> Message-ID: > On Sep 2, 2017, at 12:41 PM, Job Snijders wrote: > > Coloclue (AS 8283): > > For every peering partner, data is fetched from the PeeringDB API > and the fields visible here https://www.peeringdb.com/asn/2914 as > 'IPv4 Prefixes' and 'IPv6 Prefixes' are used as input into the > router configuration process. Coloclue's formula is simple, if the > field's value is less than 100, set the limit to 100, if the value > is over 100: add 10% to whatever value was published. This process > is executed every 12 hours. In case no PDB record for the ASN > exists: set 10,000 for IPv4 / 1,000 for IPv6. A manual override > mechanism exists. > > If I compare the two: NTT's method emphasizes business continuity and > has no external dependencies, Coloclue (being a network for > experimentation) explores how to avoid explicit noc-to-noc coordination > and relies on self-published data being kept up to date. How has the Coloclue max-prefix method described worked out? This sounds pretty effective for this type of network. How often has manual intervention (beyond a pre-arranged manual override) been required? Theodore Baschak - AS395089 - Hextet Systems https://bgp.guru/ - https://hextet.net/ http://mbix.ca/ - http://mbnog.ca/ From randy at psg.com Sun Sep 3 03:00:46 2017 From: randy at psg.com (Randy Bush) Date: Sun, 03 Sep 2017 12:00:46 +0900 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> <73650B14-9A69-4023-880A-98391CE5418C@ianai.net> <20170902081629.GS29058@Vurt.local> Message-ID: > well, I was thinking that you can survey your customers to know their > approximate inbound number, you can implement a max-prefix in from them > with that (ideally you're already doing that). > > You can figure out the output from you as well in a similar fashion. > > In either case you're not implementing a limit that's 1% larger than the > actual number, you're hedging the number for at least operational overhead > reasons to 20-40%. Even a large ISP is sending (today) less than 100k > prefixes when the peer isn't asking for 'full routes'. > > So, I'd imagine you bucket your customers as: > default only - limit 10 > customer prefixes only - limit +30% of your customer routes set > full transit - +20% of current full table > (yes, you may have more buckets than me, meh) > > and those are good starting points, if you keep these bucketed you can just > ratchet up the limits as time requires. The prefix-limits (in or out) isn't > to stop jim-isp from sending 2 of jane-isp's routes, it's to keep jim-isp > from making a bad situation very bad. You (ideally!) have prefix-lists to > limit jim from sending jane's routes. first, i have no magic bullet. sure wish i did. and i do not mean ill using ntt as an example; after all, job assures us they are very very important and very smart :) even pulling from peering.db, which is about as well-maintained as the irr (a race to the bottom), as job suggests, this relies on manual maintenance. it assumes the same count at all peerings, etc. etc. and the registered counts are horrifyingly approximate; ntt could leak 10k prefixes and not hit the limit as published. that they are gross approximations shows that they are not at all rigorous, calculated, ... this is not to say that any reasonable prefix count would have allowed the full-table goog leak to vz. and vz could have used an as-path filter not allowing _goog_(lotso-tier-ones)_ (which ntt uses, for example). but without a rigorous source of ground truth, prefix count limits will be approximate upper bounds and hence allow large mis-announcements. it is one tool in a sadly sparse toolbox, and not a strong one. randy From jason at thebaughers.com Sun Sep 3 04:46:56 2017 From: jason at thebaughers.com (Jason Baugher) Date: Sat, 2 Sep 2017 23:46:56 -0500 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: The the USA, we have tornadoes, hurricanes, nasty wind and lightning, ice accumulation on lines, and idiot squirrels that like to eat fiber. Buried fiber over time will end up being cheaper than aerial once you factor in maintenance and repair. Add to that the additional cost of pole studies, replacement and attachments that the electric utility demands to be on their poles. When you're paying them for a pole study so that they can tell you that the pole isn't strong enough or tall enough to provide clearance, then paying them to replace the pole to make it sufficient, and then paying them monthly after that to be on the pole, just putting it in the ground starts making a lot of sense. We were affected by a fiber cut a while back caused by a truck that wiped out several electric poles. It was over 24 hours before the fiber company was even allowed access to the poles, because the electric utility wouldn't release them until they were finished. There's a lot to be said about controlling your own destiny by putting the fiber in the ground where you can work on it whenever you need to. You need insurance regardless of aerial or buried. 1/2 mile might be an exaggeration. Telcom doesn't do much trenching. Vibratory plow in open areas where there's nothing to contend with, but in urban, it's almost always directional boring. The only time we hit anything is when the other utilities fail to locate at all or fail to locate correctly. The easiest thing is to contract with a cable construction company that already has all the skills, insurance and equipment, and let them deal with it. On Fri, Sep 1, 2017 at 5:38 PM, Ricky Beam wrote: > On Fri, 01 Sep 2017 15:52:40 -0400, Rod Beck < > rod.beck at unitedcablecompany.com> wrote: > >> I don't think there is virtually any aerial in Europe. So given the cost >> difference why is virtually all fiber buried on this side of the Atlantic? >> > > Aerial is simple and fast... pull the cable through a stringer, move to > the next pole and repeat; when a section (about a mile) is done, it's > hoisted into the air and tied to the pole. The stringers are then moved to > the next mile of poles and the process repeats. > > Buried stuff requires a great deal of planning, permitting, and insurance. > You have to know everything that's ever been stuffed in the ground within > half a mile of where you're working to avoid the inevitable cutting of > something important -- gas, water, sewer, power, other telcom, even vacuum > tube lines and subways. And then you need trenching gear to get stuff in > the ground, and crews to come along behind to remediate the "environmental > damage". > > (Once the conduit is in the ground, it's a trivial matter to blow whatever > you need through it.) > From baldur.norddahl at gmail.com Sun Sep 3 17:22:39 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 3 Sep 2017 19:22:39 +0200 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> <7d5a95cb-8b19-2398-e5e8-e39aa9129822@xalto.net> Message-ID: Den 2. sep. 2017 21.49 skrev "Michael Hallgren" : Le 02/09/2017 à 21:25, Baldur Norddahl a écrit : > That depends on the country. Here in Denmark it is not possible to get > rights to put up any aerial at all. The cost difference is irrelevant when > you have no option but to put it in the ground. > > Not only is there no new aerial installations here but the old ones are > taken down. Very little is left by now and in a few years it will all be > gone. The municipalities want it pretty and wires in the air is ugly. > > One advantage however is that buried stuff usually survives storms better. Right. Here in France it (aerial running along with copper) happens even close to metropoles (like Paris). mh > I expect it is mostly northern Europe that is doing the no aerial thing. From mehmet at akcin.net Sun Sep 3 23:44:19 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 03 Sep 2017 23:44:19 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: Update : Event scheduled tentatively for February 5-7, 2017 in San Juan Puerto Rico! https://www.facebook.com/events/1968437066707713/?ti=icl Please confirm if you are able to attend, while we are working on details of agenda few highlights I want to share. High level datacenter intros within PR (15mins per provider, technical focus,-not sales-) Puerto Rico / San Juan network providers intros (cls to dc/dc to dc/dc to business) connectivity option providers ( technical not sales, dark fibre, waves, etc) Interneational / out of island capacity providers update. Peering round tables, local isps meeting with large content providers. And much more. If you are interested in contributing Puerto rico internet exchange initiative, please contact me directly or via fb. There is so much interest about this via linkedin/fb/ and nanog. Looking forward to support any level from basic accounting to technical ixp setup and other peering basics. Best regards and thank you everyone for supporting in advance Mehmet On Fri, Sep 1, 2017 at 10:50 AM Mehmet Akcin wrote: > Hi Everyone! > > Thank you for 10s of great leads regarding PR and Internet EcoSystem. I am > wondering if we were to have a Peering Forum in Puerto Rico, when would be > the most preferred time? December, February are two options we have for > now. > > Idea would be to create a day where people who are local and involved in > network engineering/operations can meet with those in similar functions > outside of the island. > > Thanks once again for amazing support and leads. We look forward to 2018 > and the reLaunch. > > Mehmet > > On Sat, Aug 12, 2017 at 9:27 PM Mehmet Akcin wrote: > >> Hey there! >> >> ... ok this time I am not going to call it PRIX ;) well name doesn't >> matter really. Nearly 13 years ago I have attempted to start Puerto rico >> Internet exchange in San Juan. I have lived there over 5 years and i just >> wanted to really watch videos faster. The project somewhat died when i >> moved to LA but now there are few interested party to start an internet >> exchange in Puerto rico. The jsland historically had one of the slowest >> broadband/internet services which seemed to have improved in recent years >> however as of 2017 there still is not an IX in Puerto rico. >> >> We , 3-4 internet engineers (on island and remote) , want to look into >> relaunch of this IX and hopefully find a way to keep local traffic >> exchanged at high speeds and low cost. We need expertise, and people who >> want to help any way they can. >> >> We are trying to make this IX a not-for-profit one and we are looking at >> opeeating models to adapt which has worked incredibly well like Seattle IX. >> >> We are hoping the relaunch to happen sometime in 2018. Thanks in advance >> hope to share more info and traffic data sometime , soon. Watch this space! >> >> Mehmet >> > From mehmet at akcin.net Mon Sep 4 03:39:16 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 3 Sep 2017 20:39:16 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: pardon , correct date is February 5-7, 2018 (apologies for sending twice ) On Sun, Sep 3, 2017 at 4:44 PM, Mehmet Akcin wrote: > Update : > > Event scheduled tentatively for February 5-7, 2017 in San Juan Puerto Rico! > > https://www.facebook.com/events/1968437066707713/?ti=icl > > Please confirm if you are able to attend, while we are working on details > of agenda few highlights I want to share. > > High level datacenter intros within PR (15mins per provider, technical > focus,-not sales-) > > Puerto Rico / San Juan network providers intros (cls to dc/dc to dc/dc to > business) connectivity option providers ( technical not sales, dark fibre, > waves, etc) > > Interneational / out of island capacity providers update. > > Peering round tables, local isps meeting with large content providers. > > And much more. > > If you are interested in contributing Puerto rico internet exchange > initiative, please contact me directly or via fb. > > There is so much interest about this via linkedin/fb/ and nanog. Looking > forward to support any level from basic accounting to technical ixp setup > and other peering basics. > > Best regards and thank you everyone for supporting in advance > > Mehmet > > On Fri, Sep 1, 2017 at 10:50 AM Mehmet Akcin wrote: > >> Hi Everyone! >> >> Thank you for 10s of great leads regarding PR and Internet EcoSystem. I >> am wondering if we were to have a Peering Forum in Puerto Rico, when would >> be the most preferred time? December, February are two options we have for >> now. >> >> Idea would be to create a day where people who are local and involved in >> network engineering/operations can meet with those in similar functions >> outside of the island. >> >> Thanks once again for amazing support and leads. We look forward to 2018 >> and the reLaunch. >> >> Mehmet >> >> On Sat, Aug 12, 2017 at 9:27 PM Mehmet Akcin wrote: >> >>> Hey there! >>> >>> ... ok this time I am not going to call it PRIX ;) well name doesn't >>> matter really. Nearly 13 years ago I have attempted to start Puerto rico >>> Internet exchange in San Juan. I have lived there over 5 years and i just >>> wanted to really watch videos faster. The project somewhat died when i >>> moved to LA but now there are few interested party to start an internet >>> exchange in Puerto rico. The jsland historically had one of the slowest >>> broadband/internet services which seemed to have improved in recent years >>> however as of 2017 there still is not an IX in Puerto rico. >>> >>> We , 3-4 internet engineers (on island and remote) , want to look into >>> relaunch of this IX and hopefully find a way to keep local traffic >>> exchanged at high speeds and low cost. We need expertise, and people who >>> want to help any way they can. >>> >>> We are trying to make this IX a not-for-profit one and we are looking at >>> opeeating models to adapt which has worked incredibly well like Seattle IX. >>> >>> We are hoping the relaunch to happen sometime in 2018. Thanks in advance >>> hope to share more info and traffic data sometime , soon. Watch this space! >>> >>> Mehmet >>> >> From joly at punkcast.com Mon Sep 4 04:28:50 2017 From: joly at punkcast.com (Joly MacFie) Date: Mon, 4 Sep 2017 00:28:50 -0400 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: Looking forward to updating https://en.wikipedia. org/wiki/Internet_Exchange_of_Puerto_Rico :) > >>> We are hoping the relaunch to happen sometime in 2018. Thanks in > advance > >>> hope to share more info and traffic data sometime , soon. Watch this > space! > >>> > >>> Mehmet > >>> > >> > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > -------------------------------------------------------------- > - > From rod.beck at unitedcablecompany.com Mon Sep 4 19:00:59 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Mon, 4 Sep 2017 19:00:59 +0000 Subject: Moving fibre trunks: interruptions? In-Reply-To: <7d5a95cb-8b19-2398-e5e8-e39aa9129822@xalto.net> References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> , <7d5a95cb-8b19-2398-e5e8-e39aa9129822@xalto.net> Message-ID: I agree as an European resident that is varies by country, but my impression is that it is a lot less. For example, fiber cuts on the European racetrack (London/Paris/Frankfurt/Amsterdam/London) seems to involve buried cable. It may just be a difference in regulatory regimes. - R. ________________________________ From: NANOG on behalf of Michael Hallgren Sent: Saturday, September 2, 2017 9:47 PM To: nanog at nanog.org Subject: Re: Moving fibre trunks: interruptions? Le 02/09/2017 à 21:25, Baldur Norddahl a écrit : > That depends on the country. Here in Denmark it is not possible to get > rights to put up any aerial at all. The cost difference is irrelevant when > you have no option but to put it in the ground. > > Not only is there no new aerial installations here but the old ones are > taken down. Very little is left by now and in a few years it will all be > gone. The municipalities want it pretty and wires in the air is ugly. > > One advantage however is that buried stuff usually survives storms better. Right. Here in France it (aerial running along with copper) happens even close to metropoles (like Paris). mh > > Den 1. sep. 2017 21.53 skrev "Rod Beck" : > > I don't think there is virtually any aerial in Europe. So given the cost > difference why is virtually all fiber buried on this side of the Atlantic? From mark.tinka at seacom.mu Tue Sep 5 06:58:41 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 5 Sep 2017 08:58:41 +0200 Subject: SAFNOG-3: Live Stream Happening Now... Message-ID: <85cc2628-72df-a936-10d2-ea39dd97c388@seacom.mu> Hello all. The SAFNOG-3 meeting is kicking off this morning, here in Durban, South Africa. If you would like to join remotely, please follow the URL below to live-stream the meeting: https://livestream.com/internetsociety/safnog3 SAFNOG would like to thank the Internet Society for their support in making this happen. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From dave at temk.in Tue Sep 5 17:59:32 2017 From: dave at temk.in (Dave Temkin) Date: Tue, 5 Sep 2017 10:59:32 -0700 Subject: 2017 NANOG Elections General Information In-Reply-To: References: Message-ID: Hi NANOG Community, Nominations are rapidly coming to a close - September 8th is the last day to submit nominees. Unfortunately, to follow up on my paragraph about diversity: So far, every single candidate that has completed the nomination process is a white male. Having sat in on sessions such as Women in Technology lunch, I know that this community is passionate about diversity. If you, or a friend, would like to discuss what it takes to be on the NANOG board, I or my colleagues would love to speak about it. If you're ready to enter the nomination process, you can see details below. Best Regards, -Dave Temkin, for the NANOG Board of Directors On Mon, Aug 7, 2017 at 2:54 PM, Dave Temkin wrote: > Hello NANOGers! > > We are once again approaching the annual NANOG election > and appointment time. Board > candidate nominations open August 7th and the complete Election timeline > can be found here . We encourage > those in the community who are not currently NANOG members to consider > becoming members of NANOG and to consider standing for a position in our > leadership. Through membership and voting, you will be an active > participant in directing all NANOG activities. > > Only NANOG members are eligible to nominate, be a candidate, vote, and > serve in the NANOG Board of Directors and Committees. Click here > to become a member today! **If you > are not a member and wish to vote in this election, your membership must > be received by 9:00 a.m. Pacific Time on Wednesday, October 4, 2017.** > > Why? > > NANOG is at its strongest and best when there is an engaged group of > members. If you care about NANOG and would like to take a turn at > volunteering your time, please consider becoming part of the team by taking > part in the nomination and election process. If you know someone else > that you believe would be interested in serving on the Board of Directors, > nominate them by completing the Online Process > beginning August 7, 2017. Any > questions should be submitted to elections at nanog.org. > > As I spoke about during my opening at NANOG 70, diversity is key to the > viability of the NANOG community. Personally, it concerns me that our only > non-white, non-male elected member of the Board is leaving the board this > year, having served the maximum allowable number of terms. While everyone > is welcome, it is important that we represent our community well at all > levels and so if you or someone you know could help improve that > representation, please consider the nomination process. > > As NANOG continues to evolve, our Board of Directors and Committees will > continue to play an increasingly important role in our success. By joining > now, you can be an integral part of the process. > > For more information about the role of a Board of Director or any > Committee Member, or to find out more about what's involved in serving, > please consult the current NANOG Bylaws > > or follow the links to the Board and Committee pages from the General > 2017 NANOG Elections Page . > > > Best regards, > > Dave Temkin > On behalf of the NANOG Board of Directors > From dwhite at olp.net Wed Sep 6 19:04:32 2017 From: dwhite at olp.net (Dan White) Date: Wed, 6 Sep 2017 14:04:32 -0500 Subject: Meraki Contact Message-ID: <20170906190432.sklk34vuxifurc7k@dan.olp.net> Please contact me off list regarding the Meraki dashboard. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at olp.net http://www.btcbroadband.com From courtneysmith at comcast.net Thu Sep 7 03:03:24 2017 From: courtneysmith at comcast.net (courtneysmith at comcast.net) Date: Thu, 7 Sep 2017 03:03:24 +0000 (UTC) Subject: 2017 NANOG Elections General Information In-Reply-To: References: Message-ID: <1293163688.1745005.1504753404515.JavaMail.zimbra@comcast.net> Have we considered "grooming" folks via the committees? Seems like a better place to allow folks to dip their toes in. But maybe I'm too timid. ------- Date: Tue, 5 Sep 2017 10:59:32 -0700 From: Dave Temkin To: members at nanog.org, "North American Network Operators' Group" Subject: Re: 2017 NANOG Elections General Information Message-ID: Content-Type: text/plain; charset="UTF-8" Hi NANOG Community, Nominations are rapidly coming to a close - September 8th is the last day to submit nominees. Unfortunately, to follow up on my paragraph about diversity: So far, every single candidate that has completed the nomination process is a white male. Having sat in on sessions such as Women in Technology lunch, I know that this community is passionate about diversity. If you, or a friend, would like to discuss what it takes to be on the NANOG board, I or my colleagues would love to speak about it. If you're ready to enter the nomination process, you can see details below. Best Regards, -Dave Temkin, for the NANOG Board of Directors From feldman at twincreeks.net Thu Sep 7 03:49:48 2017 From: feldman at twincreeks.net (Steve Feldman) Date: Wed, 6 Sep 2017 20:49:48 -0700 Subject: 2017 NANOG Elections General Information In-Reply-To: <1293163688.1745005.1504753404515.JavaMail.zimbra@comcast.net> References: <1293163688.1745005.1504753404515.JavaMail.zimbra@comcast.net> Message-ID: <38A0D771-1546-484E-B7C6-9CAA8D0893E9@twincreeks.net> > On Sep 6, 2017, at 8:03 PM, courtneysmith at comcast.net wrote: > > Have we considered "grooming" folks via the committees? Seems like a better place to allow folks to dip their toes in. Definitely! Most (maybe all?) of the current board members previously served on the Program Committee or one of the other committees before being elected to the board. Volunteering for a committee role is an excellent way to get started. The next round of PC nominations will start in early 2018. Steve From joly at punkcast.com Thu Sep 7 09:35:51 2017 From: joly at punkcast.com (Joly MacFie) Date: Thu, 7 Sep 2017 05:35:51 -0400 Subject: WEBCAST TODAY: ION Durban Message-ID: ​​ This is under way. Unlike many IONs, which are brief afternoon sessions, ION Durban is a full day of technical richness. A good quality webcast too, courtesy of ISOC ​'s​ Africa Regional Bureau.​ ISOC Africa also streamed the SAFNOG-3 Conference the last 2 days, which had many excellent presentations. See https://livestream.com/internetsociety/safnog3 ​​ ​ [image: Livestream] Today, *Thursday 7 September 2017* the *Internet Society Deploy 360 team * will present *ION Durban * alongside the South African *iWeek 2017 *. ION Conferences bring network engineers and leading industry experts together to discuss emerging technologies and hot technology topics. Early adopters provide valuable insight into their own deployment experiences and bring participants up to speed on new standards emerging from the IETF. There will be a full-day program covering topics including IPv6, DNSSEC, Securing BGP, and TLS for Applications. The event will be webcast live on the *Internet Society Livestream Channel *. Durban is 6 hours ahead of NYC (UTC+2). *What: ION Durban Where: Durban, Kwa-Zulu Natal, South AfricaWhen: Thursday 7 September 2017 09:00-16:45 SAST (UTC+2)Agenda: http://www.internetsociety.org/deploy360/ion/durban2017/agenda/ Webcast: https://livestream.com/internetsociety/iondurban Slides: http://www.internetsociety.org/deploy360/ion/durban2017/presentations/ Twitter: #ionconf https://bit.ly/ionconf * Comment See all comments *​Permalink* http://isoc-ny.org/p2/9380 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From dave at temk.in Thu Sep 7 15:22:29 2017 From: dave at temk.in (Dave Temkin) Date: Thu, 7 Sep 2017 08:22:29 -0700 Subject: 2017 NANOG Elections General Information In-Reply-To: References: Message-ID: While I respect your opinion, it's impossible to enumerate every single possible combination that would make a person diverse and keep this a reasonable length email. Diversity of race and gender (amongst other things) is a shortcut to saying diversity of background. What we have today are a bunch of North American males that came up in similar backgrounds. What I can say, and what does concern me, is that the current board shares a lot of very similar characteristics that are easy to group together due to our gender and ethnicity. This leads to groupthink and other less desirable behaviors by a team tasked with setting a strategic direction that benefits millions of very different people all over the internet. And with that, I will state that we have many qualified candidates on the slate, both who fit the current grouping and those who will bring some amount of diversity to the group. You are free to vote whomever you choose. Best Regards, -Dave On Wed, Sep 6, 2017 at 9:18 PM, Robert Brockway wrote: > On Tue, 5 Sep 2017, Dave Temkin wrote: > > Hi NANOG Community, >> >> Nominations are rapidly coming to a close - September 8th is the last day >> to submit nominees. >> >> Unfortunately, to follow up on my paragraph about diversity: So far, every >> single candidate that has completed the nomination process is a white >> male. >> > > What you're describing is a very coarse form of diversity based on > physical characteristics. A white man who has lived his entire life as a > peasant in Ukraine may well have a very different outlook and life > experience to a white man who grew up in Australia. These two white men > could bring quite diverse viewpoints to any situation even though they > share some superficial characteristics. > > I have always supported the most suitable candidates for any role, > irrespective of their physical characteristics. I will always continue to > do so. > > Rob > From jcurran at istaff.org Thu Sep 7 16:00:23 2017 From: jcurran at istaff.org (John Curran) Date: Thu, 7 Sep 2017 12:00:23 -0400 Subject: Cogent BCP-38 In-Reply-To: <6EAF4CD6-4B2B-4C66-A2A0-3450733F211A@steffann.nl> References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> <806F1F4A-5FB8-45E2-8AAE-D01CC8B33B54@inoc.net> <6EAF4CD6-4B2B-4C66-A2A0-3450733F211A@steffann.nl> Message-ID: <8AB49F35-473C-4EE1-BF7B-A1F1AC4DCF8A@istaff.org> On 30 Aug 2017, at 6:38 AM, Sander Steffann wrote: > > Hi, > >> Op 29 aug. 2017, om 15:29 heeft Rob Evans het volgende geschreven: >> >>> Well, if you are using public IP addresses for infra you are violating your RIR’s policy more than likely. >> >> [Citation needed.] :) > > I am pretty confident that I know those policies well enough to say that you won't find any ;) Indeed… your infrastructure, your choices (good or bad ;-) /John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 204 bytes Desc: Message signed with OpenPGP URL: From randy at psg.com Fri Sep 8 06:26:34 2017 From: randy at psg.com (Randy Bush) Date: Fri, 08 Sep 2017 15:26:34 +0900 Subject: 2017 NANOG Elections General Information In-Reply-To: References: Message-ID: my impression is that, in recent years, one has to be a white frat boy who is proud of being drunk. randy, who stopped attending From cscora at apnic.net Fri Sep 8 18:02:36 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Sep 2017 04:02:36 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170908180236.1CCD0C44AD@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG MENOG, BJNOG, SDNOG, CMNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Sep, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 662997 Prefixes after maximum aggregation (per Origin AS): 257792 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 320036 Total ASes present in the Internet Routing Table: 58342 Prefixes per ASN: 11.36 Origin-only ASes present in the Internet Routing Table: 50442 Origin ASes announcing only one prefix: 22239 Transit ASes present in the Internet Routing Table: 7900 Transit-only ASes present in the Internet Routing Table: 228 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 56 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 60 Number of instances of unregistered ASNs: 63 Number of 32-bit ASNs allocated by the RIRs: 19920 Number of 32-bit ASNs visible in the Routing Table: 15706 Prefixes from 32-bit ASNs in the Routing Table: 64185 Number of bogon 32-bit ASNs visible in the Routing Table: 25 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 354 Number of addresses announced to Internet: 2854371936 Equivalent to 170 /8s, 34 /16s and 66 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219492 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 182793 Total APNIC prefixes after maximum aggregation: 52381 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 181746 Unique aggregates announced from the APNIC address blocks: 75097 APNIC Region origin ASes present in the Internet Routing Table: 8337 APNIC Prefixes per ASN: 21.80 APNIC Region origin ASes announcing only one prefix: 2308 APNIC Region transit ASes present in the Internet Routing Table: 1190 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 56 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3175 Number of APNIC addresses announced to Internet: 765835488 Equivalent to 45 /8s, 165 /16s and 184 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 201058 Total ARIN prefixes after maximum aggregation: 95867 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 202840 Unique aggregates announced from the ARIN address blocks: 93729 ARIN Region origin ASes present in the Internet Routing Table: 17966 ARIN Prefixes per ASN: 11.29 ARIN Region origin ASes announcing only one prefix: 6634 ARIN Region transit ASes present in the Internet Routing Table: 1771 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2175 Number of ARIN addresses announced to Internet: 1110263072 Equivalent to 66 /8s, 45 /16s and 69 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 176808 Total RIPE prefixes after maximum aggregation: 86676 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 172692 Unique aggregates announced from the RIPE address blocks: 104276 RIPE Region origin ASes present in the Internet Routing Table: 24360 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 11189 RIPE Region transit ASes present in the Internet Routing Table: 3447 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6153 Number of RIPE addresses announced to Internet: 713023360 Equivalent to 42 /8s, 127 /16s and 223 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 84911 Total LACNIC prefixes after maximum aggregation: 18956 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 86164 Unique aggregates announced from the LACNIC address blocks: 39587 LACNIC Region origin ASes present in the Internet Routing Table: 6348 LACNIC Prefixes per ASN: 13.57 LACNIC Region origin ASes announcing only one prefix: 1762 LACNIC Region transit ASes present in the Internet Routing Table: 1173 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3860 Number of LACNIC addresses announced to Internet: 171057888 Equivalent to 10 /8s, 50 /16s and 34 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17365 Total AfriNIC prefixes after maximum aggregation: 3859 AfriNIC Deaggregation factor: 4.50 Prefixes being announced from the AfriNIC address blocks: 19201 Unique aggregates announced from the AfriNIC address blocks: 7060 AfriNIC Region origin ASes present in the Internet Routing Table: 1074 AfriNIC Prefixes per ASN: 17.88 AfriNIC Region origin ASes announcing only one prefix: 345 AfriNIC Region transit ASes present in the Internet Routing Table: 210 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 343 Number of AfriNIC addresses announced to Internet: 93713664 Equivalent to 5 /8s, 149 /16s and 245 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5417 4194 88 ERX-CERNET-BKB China Education and Rese 7545 3834 406 382 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2962 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2838 11126 751 KIXS-AS-KR Korea Telecom, KR 9829 2759 1499 541 BSNL-NIB National Internet Backbone, IN 9394 2418 5027 46 CTTNET China TieTong Telecommunications 9808 2363 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2163 1468 115 VNPT-AS-VN VNPT Corp, VN 4755 2102 422 221 TATACOMM-AS TATA Communications formerl 7552 1669 1105 69 VIETEL-AS-AP Viettel Corporation, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3644 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3444 1341 87 SHAW - Shaw Communications Inc., CA 18566 2204 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2045 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2032 2237 434 CHARTER-NET-HKY-NC - Charter Communicat 209 1892 5065 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1830 329 279 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16509 1829 3960 544 AMAZON-02 - Amazon.com, Inc., US 6983 1685 854 229 ITCDELTA - Earthlink, Inc., US 701 1673 10557 629 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2952 936 2115 AKAMAI-ASN1, US 8551 2478 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2059 333 425 TELLCOM-AS, TR 9121 1830 1691 17 TTNET, TR 12389 1706 1629 668 ROSTELECOM-AS, RU 12479 1682 1052 60 UNI2-AS, ES 13188 1603 100 52 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1195 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3568 543 209 Telmex Colombia S.A., CO 8151 2981 3418 578 Uninet S.A. de C.V., MX 11830 2097 370 65 Instituto Costarricense de Electricidad 6503 1583 437 53 Axtel, S.A.B. de C.V., MX 7303 1567 1024 248 Telecom Argentina S.A., AR 6147 1257 377 27 Telefonica del Peru S.A.A., PE 3816 1025 504 94 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 962 2284 185 CLARO S.A., BR 11172 917 126 85 Alestra, S. de R.L. de C.V., MX 18881 898 1052 23 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1194 398 48 LINKdotNET-AS, EG 37611 763 91 8 Afrihost, ZA 36903 710 357 131 MT-MPLS, MA 36992 655 1383 29 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 410 354 77 ORANGE-, TN 15399 357 35 7 WANANCHI-, KE 8452 310 1730 17 TE-AS TE-AS, EG 2018 299 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5417 4194 88 ERX-CERNET-BKB China Education and Rese 7545 3834 406 382 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3644 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3568 543 209 Telmex Colombia S.A., CO 6327 3444 1341 87 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 8151 2981 3418 578 Uninet S.A. de C.V., MX 17974 2962 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2952 936 2115 AKAMAI-ASN1, US 4766 2838 11126 751 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3644 3486 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3834 3452 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 10620 3568 3359 Telmex Colombia S.A., CO 6327 3444 3357 SHAW - Shaw Communications Inc., CA 17974 2962 2889 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2478 2437 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 8151 2981 2403 Uninet S.A. de C.V., MX 9394 2418 2372 CTTNET China TieTong Telecommunications Corpora 9808 2363 2331 CMNET-GD Guangdong Mobile Communication Co.Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65346 PRIVATE 94.50.36.0/22 31094 TTKNET Tyumen, Russia, RU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.226.112.0/20 62788 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:283 /13:550 /14:1046 /15:1872 /16:13443 /17:7744 /18:13757 /19:25219 /20:39220 /21:42490 /22:80052 /23:65206 /24:369524 /25:846 /26:625 /27:648 /28:37 /29:38 /30:200 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3241 3444 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2842 3644 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2088 2204 MEGAPATH5-US - MegaPath Corporation, US 8551 1943 2478 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1610 1830 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1516 3568 Telmex Colombia S.A., CO 11830 1487 2097 Instituto Costarricense de Electricidad y Telec 11492 1419 1597 CABLEONE - CABLE ONE, INC., US 6389 1356 2045 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1561 2:832 4:18 5:2447 6:31 7:1 8:1058 12:1854 13:150 14:1670 15:28 16:2 17:168 18:90 20:59 23:2455 24:1942 25:2 27:2365 29:1 31:1923 32:90 33:20 35:21 36:439 37:2354 38:1384 39:69 40:98 41:2978 42:462 43:1956 44:80 45:3037 46:2794 47:165 49:1240 50:1002 51:19 52:816 54:366 55:2 56:4 57:43 58:1573 59:997 60:312 61:2027 62:1711 63:1909 64:4687 65:2206 66:4553 67:2283 68:1227 69:3377 70:1170 71:603 72:2138 74:2712 75:400 76:423 77:1498 78:1481 79:1891 80:1397 81:1392 82:1009 83:726 84:964 85:1831 86:468 87:1194 88:780 89:2180 90:171 91:6199 92:1004 93:2389 94:2351 95:2674 96:644 97:351 98:997 99:98 100:153 101:1443 102:1 103:15737 104:3049 105:189 106:563 107:1756 108:825 109:2915 110:1471 111:1745 112:1250 113:1342 114:1069 115:1586 116:1645 117:1764 118:2160 119:1642 120:730 121:1060 122:2382 123:1858 124:1483 125:1786 128:876 129:673 130:432 131:1482 132:584 133:194 134:685 135:226 136:402 137:489 138:1943 139:514 140:380 141:644 142:734 143:891 144:795 145:183 146:1105 147:706 148:1501 149:585 150:710 151:983 152:735 153:296 154:881 155:755 156:675 157:689 158:481 159:1552 160:760 161:748 162:2508 163:509 164:964 165:1453 166:380 167:1284 168:3024 169:843 170:3538 171:367 172:1018 173:2007 174:782 175:768 176:1885 177:3924 178:2560 179:1112 180:2203 181:1999 182:2403 183:768 184:864 185:10659 186:3282 187:2143 188:2575 189:1843 190:8332 191:1351 192:9620 193:5802 194:4723 195:3934 196:2114 197:1329 198:5520 199:5879 200:7592 201:4364 202:10334 203:9936 204:4532 205:2845 206:3072 207:3162 208:3962 209:4028 210:3951 211:2137 212:2863 213:2533 214:835 215:66 216:5885 217:2118 218:911 219:600 220:1677 221:919 222:740 223:1207 End of report From dgolding at gmail.com Fri Sep 8 19:16:54 2017 From: dgolding at gmail.com (Daniel Golding) Date: Fri, 08 Sep 2017 19:16:54 +0000 Subject: 2017 NANOG Elections General Information In-Reply-To: References: Message-ID: I think you would have to work very hard to find a more sober group of individuals than the current and past members of the NANOG Board. I don't disagree with Randy that there is too much drinking and too much white frat boy nonsense in our industry. That being said, if you look at the past members of the NANOG board - folks like Sylvie, Dave, Ryan, Greg, Steve F, Mike Smith, Steve Gibbard, Duane, Jezzibell - you'll find people who *don't* buy into the party culture that sometimes surrounds NANOG. This leads to a good point, and I think the point Randy was trying to make - the Board elections should not be a popularity contest, either in terms of who people like or who the best engineers are. It should *not* be focused on who has the most fun at the socials or the room parties. Carefully look at the qualifications of who is running. Do they have prior experience on NANOG committees? Are they long time volunteers who understand the community and its mission? Are they diverse and help us look more like the network engineering community at large? There are a great mix of folks running. Some clearly do not meet these standards. Some do. Please be discerning in your vote. Dan On Fri, Sep 8, 2017 at 2:28 AM Randy Bush wrote: > my impression is that, in recent years, one has to be a white frat boy > who is proud of being drunk. > > randy, who stopped attending > From jason at unlimitednet.us Fri Sep 8 19:30:48 2017 From: jason at unlimitednet.us (Jason Canady) Date: Fri, 8 Sep 2017 15:30:48 -0400 Subject: Anyone here from Netflix? | VPN Detection Problem Message-ID: <32c189d8-70fe-f8d5-3c3a-7e6babd51b64@unlimitednet.us> Hello, We have IP addresses being blocked due to proxy servers that were once on the IP address space. They have now been reclaimed and will be used for ISP services to end-users. We need to ensure that customers can watch Netflix without any issues. Would someone please reach out to me to resolve this? Thank you! Best Regards, Jason Canady Unlimited Net, LLC From kvicknair at reservetele.com Fri Sep 8 22:06:11 2017 From: kvicknair at reservetele.com (Kody Vicknair) Date: Fri, 8 Sep 2017 22:06:11 +0000 Subject: Management softwares In-Reply-To: <008701d322ef$5fd83790$1f88a6b0$@ca> References: <008701d322ef$5fd83790$1f88a6b0$@ca> Message-ID: <3979AE529B56AB47942E2423B707F16E64C271BD@RTC-EXCH01.RESERVE.LDS> Nisc.coop If you can, request that it be hosted in-house as they tend to have an outage at least once a month. O.o Kody Vicknair Network Engineer Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K MEKKAOUI Sent: Friday, September 01, 2017 1:56 AM To: nanog at nanog.org Subject: Management softwares Hi We are a medium ISP. We are looking for Management software solutions. We are interested in finding a solution for billing, invoicing, scheduling, ticketing, provisioning and monitoring, Any suggestions or recommendations will be appreciated? We have been using multiple systems which do not communicate. Our objective is to use a single system or at least reduce the number of systems. Thank you KARIM M. From afmug at zirkel.us Fri Sep 8 22:59:22 2017 From: afmug at zirkel.us (Sean Heskett) Date: Fri, 08 Sep 2017 22:59:22 +0000 Subject: Management softwares In-Reply-To: <008701d322ef$5fd83790$1f88a6b0$@ca> References: <008701d322ef$5fd83790$1f88a6b0$@ca> Message-ID: Sonar will do everything you are looking for a more https://sonar.software/ -Sean On Fri, Sep 1, 2017 at 12:56 AM K MEKKAOUI wrote: > Hi > > > > We are a medium ISP. We are looking for Management software solutions. We > are interested in finding a solution for billing, invoicing, scheduling, > ticketing, provisioning and monitoring, Any suggestions or recommendations > will be appreciated? We have been using multiple systems which do not > communicate. Our objective is to use a single system or at least reduce the > number of systems. > > > > Thank you > > > > KARIM M. > > > > From kvicknair at reservetele.com Sat Sep 9 16:06:22 2017 From: kvicknair at reservetele.com (Kody Vicknair) Date: Sat, 9 Sep 2017 16:06:22 +0000 Subject: IPv6 Loopback/Point-to-Point address allocation Message-ID: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> All, I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it. I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554 It looks like the smallest subnet that should ever be assigned is a /64 on a particular link. Some questions that come to mind with IPv6: In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not? In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128? Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes. I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6. Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road? Kody Vicknair Network Engineer [cid:imagebf3343.JPG at c9d2fbd2.4db10e0d] Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From kvicknair at reservetele.com Sat Sep 9 16:53:11 2017 From: kvicknair at reservetele.com (Kody Vicknair) Date: Sat, 9 Sep 2017 16:53:11 +0000 Subject: IPv6 Loopback/Point-to-Point address allocation Message-ID: <3979AE529B56AB47942E2423B707F16E64C277ED@RTC-EXCH01.RESERVE.LDS> Apologies, Wrong link: https://www.sinog.si/docs/draft-IPv6pd-BCOP-v7.pdf Kody Vicknair Network Engineer [cid:image764c5e.JPG at bb882327.44b4b1d7] Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From: Kody Vicknair Sent: Saturday, September 09, 2017 11:06 AM To: nanog at nanog.org Subject: IPv6 Loopback/Point-to-Point address allocation All, I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it. I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554 It looks like the smallest subnet that should ever be assigned is a /64 on a particular link. Some questions that come to mind with IPv6: In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not? In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128? Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes. I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6. Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road? From baldur.norddahl at gmail.com Sat Sep 9 22:09:14 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 10 Sep 2017 00:09:14 +0200 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> Message-ID: You want to configure point to point interfaces as /127 or /126 even if you allocate a full /64 for the link. This prevents an NDP exhaustion attack with no downside. Loopback interfaces should be configured as /128. How you allocate these do not matter. Den 9. sep. 2017 18.08 skrev "Kody Vicknair" : > All, > > I’ve been doing some reading in preparation of IPv6 deployment and > figuring out how we will break up our /32. I think I’m on the right track > in thinking that each customer will be allocated a /48 to do whatever they > wish with it. > > I’ve read recent BCOP drafts that have been approved by the IETF: > https://www.ripe.net/publications/docs/ripe-554 > It looks like the smallest subnet that should ever be assigned is a /64 on > a particular link. > > > Some questions that come to mind with IPv6: > > In regards to Point to point links my thinking is this: > Assign a unique /64 to each point to point link with these addresses being > Globally routable. This seems to be what our IX providers do when assigning > us an IPv6 address. Am I correct in this train of thought? Why/Why not? > > In regards to core loopback addressing my initial thoughts are as follows: > Assign a single /64 encompassing all /128’s planned for loopback > addressing schemes. Should I be using Unique Local addressing for loopbacks > instead of going with a Globally routeable addressing scheme? Should each > interface IP configuration have a /64 or a /128? > > Also when talking about CPE mgmt addresses what do you think is a > practical way of going about assigning “Private” addressing schemes for cpe > management purposes. > > I’m sure some of these questions will be answered when I dive deeper into > how OSPFv6 works as well as BGP in regards to IPv6. > > Are any of you currently running IPv6 and wished you had done something > differently during the planning phase that may have prevented headaches > down the road? > > > > > Kody Vicknair > Network Engineer > > > [cid:imagebf3343.JPG at c9d2fbd2.4db10e0d] > > Tel: 985.536.1214 > Fax: 985.536.0300 > Email: kvicknair at reservetele.com > Web: www.rtconline.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > > > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Kody Vicknair immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Kody Vicknair therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. > > From sean at donelan.com Sun Sep 10 02:00:26 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 9 Sep 2017 22:00:26 -0400 (EDT) Subject: Hurricane Irma: U.S. Virgin Islands and Puerto Rico Message-ID: 5 fatalities in U.S. Virgin Islands and Puerto Rico FCC doesn't have reliable reporting on Wireline and Cable service providers in either USVI or Puerto Rico. The assumption is large numbers of customers are without cable or wireline service. 870,000 customers (55% of the island) without power in Puerto Rico 22,900 customers without power U.S. Vigin Islands 1 hospital closed, 25 hospitals on backup generators 29.3% of cell sites in Puerto Rico and 60.7% of cell sites in the U.S. Virgin Islands are out of service. 1 radio station and 2 TV stations in USVI are out of service 4 radio stations in Puerto Rico are out of service From masoodnt10 at gmail.com Sun Sep 10 04:32:16 2017 From: masoodnt10 at gmail.com (Masood Ahmad Shah) Date: Sat, 9 Sep 2017 21:32:16 -0700 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> Message-ID: I don't see any point of using larger Network space for point to point links or on loopback addresses. To me the best is that 127-Bit prefixes on IPv6 point-to-point links and /128 on Loopback serves the purpose, and offers us a lot of advantages such as it prevents us from neighbor discovery exhaustion attack (rfc6583) Draft is mainly referring to end user WAN links (i.e. xDSL, Cable, FTTN/H) and that's a different story where /64 /56 /48 are still open to dispute :P On Sat, Sep 9, 2017 at 9:06 AM, Kody Vicknair wrote: > All, > > I’ve been doing some reading in preparation of IPv6 deployment and > figuring out how we will break up our /32. I think I’m on the right track > in thinking that each customer will be allocated a /48 to do whatever they > wish with it. > > I’ve read recent BCOP drafts that have been approved by the IETF: > https://www.ripe.net/publications/docs/ripe-554 > It looks like the smallest subnet that should ever be assigned is a /64 on > a particular link. > > > Some questions that come to mind with IPv6: > > In regards to Point to point links my thinking is this: > Assign a unique /64 to each point to point link with these addresses being > Globally routable. This seems to be what our IX providers do when assigning > us an IPv6 address. Am I correct in this train of thought? Why/Why not? > > In regards to core loopback addressing my initial thoughts are as follows: > Assign a single /64 encompassing all /128’s planned for loopback > addressing schemes. Should I be using Unique Local addressing for loopbacks > instead of going with a Globally routeable addressing scheme? Should each > interface IP configuration have a /64 or a /128? > > Also when talking about CPE mgmt addresses what do you think is a > practical way of going about assigning “Private” addressing schemes for cpe > management purposes. > > I’m sure some of these questions will be answered when I dive deeper into > how OSPFv6 works as well as BGP in regards to IPv6. > > Are any of you currently running IPv6 and wished you had done something > differently during the planning phase that may have prevented headaches > down the road? > > > > > Kody Vicknair > Network Engineer > > > [cid:imagebf3343.JPG at c9d2fbd2.4db10e0d] > > Tel: 985.536.1214 > Fax: 985.536.0300 > Email: kvicknair at reservetele.com > Web: www.rtconline.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > > > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Kody Vicknair immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Kody Vicknair therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. > > From nick at foobar.org Sun Sep 10 09:47:05 2017 From: nick at foobar.org (Nick Hilliard) Date: Sun, 10 Sep 2017 10:47:05 +0100 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> Message-ID: <59B50A19.9050806@foobar.org> Baldur Norddahl wrote: > Loopback interfaces should be configured as /128. How you allocate these do > not matter. ..so long as there are interface ACLs on your network edge which block direct IP access to these IP addresses. Nick From erey at ernw.de Sun Sep 10 09:53:20 2017 From: erey at ernw.de (Enno Rey) Date: Sun, 10 Sep 2017 11:53:20 +0200 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <59B50A19.9050806@foobar.org> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B50A19.9050806@foobar.org> Message-ID: <20170910095320.GC88553@ernw.de> Hi, On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote: > Baldur Norddahl wrote: > > Loopback interfaces should be configured as /128. How you allocate these do > > not matter. > > ..so long as there are interface ACLs on your network edge which block > direct IP access to these IP addresses. or, maybe even more efficient, assign all loopbacks from a dedicated netblock which you null-route on the edge/your border devices. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From job at ntt.net Sun Sep 10 10:08:59 2017 From: job at ntt.net (Job Snijders) Date: Sun, 10 Sep 2017 12:08:59 +0200 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <20170910095320.GC88553@ernw.de> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B50A19.9050806@foobar.org> <20170910095320.GC88553@ernw.de> Message-ID: <20170910100859.GD1196@Vurt.local> Hi, On Sun, Sep 10, 2017 at 11:53:20AM +0200, Enno Rey wrote: > On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote: > > Baldur Norddahl wrote: > > > Loopback interfaces should be configured as /128. How you allocate these do > > > not matter. > > > > ..so long as there are interface ACLs on your network edge which block > > direct IP access to these IP addresses. > > or, maybe even more efficient, assign all loopbacks from a dedicated > netblock which you null-route on the edge/your border devices. Null-routing may not be sufficient, if the edge/border router has a route to that /128; the (forwardable) /128 entry will win from the blackholed /64 FIB entry since it is more-specific. Applying an ingress interface ACL to each and every external facing interface will probably work best in the most common deployment scenarios. For router-to-router linknets I recommend to configure a linknet that is as small as possible and is supported by all sides: /127, /126, /120, etc. Some vendors have put in effort to mitigate the problems related to Neighbor Discovery Protocol cache exhaustion attacks, but the fact of the matter is that on small subnets like a /127, /126 or /120 such attacks simply are non-existent. Kind regards, Job From bellman at nsc.liu.se Sun Sep 10 10:56:08 2017 From: bellman at nsc.liu.se (Thomas Bellman) Date: Sun, 10 Sep 2017 12:56:08 +0200 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> Message-ID: <59B51A48.6090305@nsc.liu.se> On 2017-09-10 00:09, Baldur Norddahl wrote: > You want to configure point to point interfaces as /127 or /126 even if you > allocate a full /64 for the link. This prevents an NDP exhaustion attack > with no downside. An alternative is to just have link-local addresses on your point-to- point links. At least on your internal links where you run your IGP. On external links, where you run eBGP or static routes, it's probably more trouble than it is worth, though, since link-local addresses can change if you replace the hardware, requiring a config change on the other end. (Also, I'm not sure all BGP implementations support using link-local addresses.) /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From saku at ytti.fi Sun Sep 10 11:25:04 2017 From: saku at ytti.fi (Saku Ytti) Date: Sun, 10 Sep 2017 14:25:04 +0300 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <59B51A48.6090305@nsc.liu.se> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B51A48.6090305@nsc.liu.se> Message-ID: On 10 September 2017 at 13:56, Thomas Bellman wrote: > An alternative is to just have link-local addresses on your point-to- > point links. At least on your internal links where you run your IGP. > On external links, where you run eBGP or static routes, it's probably > more trouble than it is worth, though, since link-local addresses can > change if you replace the hardware, requiring a config change on the > other end. (Also, I'm not sure all BGP implementations support using > link-local addresses.) This is solvable problem. Vendors support 'bgp listen' or 'bgp allow' to accept BGP session from specific CIDR range. Similarly you could allow IPv6 on interface, with SADDR anywhere in link-local. Your own end link-local stability you could guarantee by manually configuring MAC address, instead of using BIA. I.e. customers would experience stable DADDR, but we wouldn't care about customer's SADDR. However I don't think market would generally appreciate the implications linklocal brings to traceroute, where least bad option would be just to originate hop-limit exceeded from loop0, with no visibility on actual interface. -- ++ytti From erey at ernw.de Sun Sep 10 11:58:10 2017 From: erey at ernw.de (Enno Rey) Date: Sun, 10 Sep 2017 13:58:10 +0200 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B51A48.6090305@nsc.liu.se> Message-ID: <20170910115810.GD88553@ernw.de> Hi, On Sun, Sep 10, 2017 at 02:25:04PM +0300, Saku Ytti wrote: > On 10 September 2017 at 13:56, Thomas Bellman wrote: > > > An alternative is to just have link-local addresses on your point-to- > > point links. At least on your internal links where you run your IGP. > > On external links, where you run eBGP or static routes, it's probably > > more trouble than it is worth, though, since link-local addresses can > > change if you replace the hardware, requiring a config change on the > > other end. (Also, I'm not sure all BGP implementations support using > > link-local addresses.) all BGP implementations I'm aware of do that (support LLAs), BUT at least Cisco's doesn't support using the same LLAs in multiple BGP sessions (e.g. on PE-CE links) which in turn ruins the potential benefits in many environments, see https://ripe72.ripe.net/presentations/122-ERNW_RIPE72_IPv6wg_RFC7404.pdf https://blog.apnic.net/2016/05/31/beauty-ipv6-link-local-addressing-not/ > > This is solvable problem. Vendors support 'bgp listen' or 'bgp allow' > to accept BGP session from specific CIDR range. Similarly you could > allow IPv6 on interface, with SADDR anywhere in link-local. Your own > end link-local stability you could guarantee by manually configuring > MAC address, instead of using BIA. I.e. customers would experience > stable DADDR, but we wouldn't care about customer's SADDR. > > However I don't think market would generally appreciate the > implications linklocal brings to traceroute, where least bad option > would be just to originate hop-limit exceeded from loop0, with no > visibility on actual interface. some might be willing to accept that, as a trade-off for other benefits operations-wise. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From erey at ernw.de Sun Sep 10 12:07:36 2017 From: erey at ernw.de (Enno Rey) Date: Sun, 10 Sep 2017 14:07:36 +0200 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <20170910100859.GD1196@Vurt.local> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B50A19.9050806@foobar.org> <20170910095320.GC88553@ernw.de> <20170910100859.GD1196@Vurt.local> Message-ID: <20170910120736.GA90730@ernw.de> Hi, On Sun, Sep 10, 2017 at 12:08:59PM +0200, Job Snijders wrote: > Hi, > > On Sun, Sep 10, 2017 at 11:53:20AM +0200, Enno Rey wrote: > > On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote: > > > Baldur Norddahl wrote: > > > > Loopback interfaces should be configured as /128. How you allocate these do > > > > not matter. > > > > > > ..so long as there are interface ACLs on your network edge which block > > > direct IP access to these IP addresses. > > > > or, maybe even more efficient, assign all loopbacks from a dedicated > > netblock which you null-route on the edge/your border devices. > > Null-routing may not be sufficient, if the edge/border router has a > route to that /128 good point. I was coming from an Enterprise network perspective where - the border devices do not necessarily hold the/those 128(s) given there's a layer of stateful firewalls in between which creates an isolation boundary for routing protocols. - people do not necessarily fully trust the (outsourced) entities responsible for implementing the filters/ACLs. - this is hence a not-uncommon strategy to feel/be safer as for the (unwanted) global reachability of loopbacks, after the introduction of IPv6. best Enno ; the (forwardable) /128 entry will win from the > blackholed /64 FIB entry since it is more-specific. Applying an ingress > interface ACL to each and every external facing interface will probably > work best in the most common deployment scenarios. > > For router-to-router linknets I recommend to configure a linknet that is > as small as possible and is supported by all sides: /127, /126, /120, > etc. Some vendors have put in effort to mitigate the problems related to > Neighbor Discovery Protocol cache exhaustion attacks, but the fact of > the matter is that on small subnets like a /127, /126 or /120 such > attacks simply are non-existent. > > Kind regards, > > Job -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From erey at ernw.de Sun Sep 10 13:03:00 2017 From: erey at ernw.de (Enno Rey) Date: Sun, 10 Sep 2017 15:03:00 +0200 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <20170910100859.GD1196@Vurt.local> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B50A19.9050806@foobar.org> <20170910095320.GC88553@ernw.de> <20170910100859.GD1196@Vurt.local> Message-ID: <20170910130300.GC90730@ernw.de> Hi, On Sun, Sep 10, 2017 at 12:08:59PM +0200, Job Snijders wrote: > Hi, > > On Sun, Sep 10, 2017 at 11:53:20AM +0200, Enno Rey wrote: > > On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote: > > > Baldur Norddahl wrote: > > > > Loopback interfaces should be configured as /128. How you allocate these do > > > > not matter. > > > > > > ..so long as there are interface ACLs on your network edge which block > > > direct IP access to these IP addresses. > > > > or, maybe even more efficient, assign all loopbacks from a dedicated > > netblock which you null-route on the edge/your border devices. > > Null-routing may not be sufficient, if the edge/border router has a > route to that /128; the (forwardable) /128 entry will win from the > blackholed /64 FIB entry since it is more-specific. just thought about it a bit. As mentioned (in other post) I was thinking of a specific use case/setting, but wouldn't a static null-route (of a blackholed /64) win over a /128 learned from a RP anyway (given the better AD)? Am I missing sth here? thanks Enno Applying an ingress > interface ACL to each and every external facing interface will probably > work best in the most common deployment scenarios. > > For router-to-router linknets I recommend to configure a linknet that is > as small as possible and is supported by all sides: /127, /126, /120, > etc. Some vendors have put in effort to mitigate the problems related to > Neighbor Discovery Protocol cache exhaustion attacks, but the fact of > the matter is that on small subnets like a /127, /126 or /120 such > attacks simply are non-existent. > > Kind regards, > > Job -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From sthaug at nethelp.no Sun Sep 10 13:09:11 2017 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 10 Sep 2017 15:09:11 +0200 (CEST) Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <20170910130300.GC90730@ernw.de> References: <20170910095320.GC88553@ernw.de> <20170910100859.GD1196@Vurt.local> <20170910130300.GC90730@ernw.de> Message-ID: <20170910.150911.74688206.sthaug@nethelp.no> > > Null-routing may not be sufficient, if the edge/border router has a > > route to that /128; the (forwardable) /128 entry will win from the > > blackholed /64 FIB entry since it is more-specific. > > just thought about it a bit. > As mentioned (in other post) I was thinking of a specific use case/setting, but wouldn't a static null-route (of a blackholed /64) win over a /128 learned from a RP anyway (given the better AD)? > Am I missing sth here? Longest prefix match wins. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bryan at shout.net Sun Sep 10 20:59:19 2017 From: bryan at shout.net (Bryan Holloway) Date: Sun, 10 Sep 2017 15:59:19 -0500 Subject: 2017 NANOG Elections General Information In-Reply-To: References: Message-ID: <055ebefd-4648-a92e-8a1c-22829b76e074@shout.net> > This leads to a good point, and I think the point Randy was trying to make > - the Board elections should not be a popularity contest, either in terms > of who people like or who the best engineers are. It should *not* be > focused on who has the most fun at the socials or the room parties. +1 ... and .. ... if I may expand candidly on this, I'd like to see a little less of an -- to use the term loosely -- "Old Boys Network" mentality at meetings. I point specifically to the opening talk at Bellevue where there were wackily photoshop'd pictures of NANOG star heavy-hitters. I consider myself a relative newcomer to the community, and I find the meetings invaluable, but I've been to enough of them to know who the folks pictured were. Had I been a first-time attendee, I would've felt like a high-school freshman being told who all the "cool seniors" were. Frankly, it was awkward and off-putting. Just my $0.02 worth. > On Fri, Sep 8, 2017 at 2:28 AM Randy Bush wrote: > >> my impression is that, in recent years, one has to be a white frat boy >> who is proud of being drunk. >> >> randy, who stopped attending >> From surfer at mauigateway.com Mon Sep 11 00:00:59 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 10 Sep 2017 17:00:59 -0700 Subject: 2017 NANOG Elections General Information Message-ID: <20170910170059.3E05DB85@m0117459.ppops.net> --- bryan at shout.net wrote: From: Bryan Holloway Had I been a first-time attendee, I would've felt like a high-school freshman being told who all the "cool seniors" were. Frankly, it was awkward and off-putting. --------------------------------------------------- Not only first time attendees, but also long time list participants are made to feel that way; me included for making comments about vendor spam or top posting. I note that not only randy is doing what he says, but other old schoolers are now gone (such as vixie, li and others) who are folks that a person could learn a lot from. scott ps. I always shot peas at the "cool kids" table in the lunch room in high school. From time-to-time I want virtual peas to shoot now days... >;-) From matlockken at gmail.com Mon Sep 11 00:09:42 2017 From: matlockken at gmail.com (Ken Matlock) Date: Sun, 10 Sep 2017 18:09:42 -0600 Subject: 2017 NANOG Elections General Information In-Reply-To: <20170910170059.3E05DB85@m0117459.ppops.net> References: <20170910170059.3E05DB85@m0117459.ppops.net> Message-ID: Yep, I've been in this industry since.. '94 or so, and the absolute number one reason that I do not participate in NANOG is that even going back as far as I can remember it's been a good-old-boy's club. Yes, there are some very smart people that speak up, but I see time and time again the cliques and good-old-boys club mentality inherent in NANOG. And because of this, the thinking and mindset of NANOG in general will (in my opinion) never change. As you mention there is definitely a 'cool kids' or Ivory tower mentality. And I'm not sure that it really *can* be fixed and more welcoming of newer members without risking alienating the old guard. So for the most part I tease out the nuggets of wisdom I can, and ignore most of the mindless arguments that we have been over time and time again about. Ken On Sun, Sep 10, 2017 at 6:00 PM, Scott Weeks wrote: > > --- bryan at shout.net wrote: > From: Bryan Holloway > > Had I been a first-time attendee, I would've felt like a > high-school freshman being told who all the "cool seniors" > were. > > Frankly, it was awkward and off-putting. > --------------------------------------------------- > > Not only first time attendees, but also long time list > participants are made to feel that way; me included for > making comments about vendor spam or top posting. I note > that not only randy is doing what he says, but other old > schoolers are now gone (such as vixie, li and others) who > are folks that a person could learn a lot from. > > scott > > ps. I always shot peas at the "cool kids" table in the > lunch room in high school. From time-to-time I want > virtual peas to shoot now days... >;-) > From javier at advancedmachines.us Mon Sep 11 03:58:32 2017 From: javier at advancedmachines.us (Javier J) Date: Sun, 10 Sep 2017 23:58:32 -0400 Subject: Any validity to this claim? Fiber cable cut to St. John USVI. Message-ID: https://www.reddit.com/r/TropicalWeather/comments/6zcr3y/this_is_a_message_from_st_john_us_virgin_islands/?st=j7flzzyx&sh=28637fa3 From woody at pch.net Mon Sep 11 07:32:40 2017 From: woody at pch.net (Bill Woodcock) Date: Mon, 11 Sep 2017 00:32:40 -0700 Subject: 2017 NANOG Elections General Information In-Reply-To: References: Message-ID: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> > On Sep 7, 2017, at 11:26 PM, Randy Bush wrote: > my impression is that, in recent years, one has to be a white frat boy > who is proud of being drunk. One of those rare occasions when Randy and I are in complete agreement. > On Sep 10, 2017, at 1:59 PM, Bryan Holloway wrote: > I point specifically to the opening talk at Bellevue where there were wackily photoshop'd pictures of NANOG star heavy-hitters. > Had I been a first-time attendee, I would've felt like a high-school freshman being told who all the "cool seniors" were. > Frankly, it was awkward and off-putting. Probably a safe bet that it was mostly aspirant juniors. To my occasional observation, the cool seniors don't attend anymore. Unless Stephen Stuart or Sean Doran or John Hawkinson showed up. Which would surprise me very much. -Bill From shopik+lists at nvcube.net Mon Sep 11 07:35:15 2017 From: shopik+lists at nvcube.net (Nikolay Shopik) Date: Mon, 11 Sep 2017 10:35:15 +0300 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B51A48.6090305@nsc.liu.se> Message-ID: On 10/09/2017 14:25, Saku Ytti wrote: > However I don't think market would generally appreciate the > implications linklocal brings to traceroute, where least bad option > would be just to originate hop-limit exceeded from loop0, with no > visibility on actual interface. rfc5837 would help but it seems market universally ignore it for some reason unknown to me (lack of interest and IPv6 adoption?) We find LL is simpler, operation wise at some cases. From dave at temk.in Mon Sep 11 15:36:49 2017 From: dave at temk.in (Dave Temkin) Date: Mon, 11 Sep 2017 08:36:49 -0700 Subject: 2017 NANOG Elections General Information In-Reply-To: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> References: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> Message-ID: On Mon, Sep 11, 2017 at 12:32 AM, Bill Woodcock wrote: > > > On Sep 7, 2017, at 11:26 PM, Randy Bush wrote: > > my impression is that, in recent years, one has to be a white frat boy > > who is proud of being drunk. > > One of those rare occasions when Randy and I are in complete agreement. > So how do we fix it? As usual, that part is missed. Easier to snipe, not so easy to act. > > > On Sep 10, 2017, at 1:59 PM, Bryan Holloway wrote: > > I point specifically to the opening talk at Bellevue where there were > wackily photoshop'd pictures of NANOG star heavy-hitters. > > Had I been a first-time attendee, I would've felt like a high-school > freshman being told who all the "cool seniors" were. > > Frankly, it was awkward and off-putting. > > Probably a safe bet that it was mostly aspirant juniors. To my occasional > observation, the cool seniors don't attend anymore. Unless Stephen Stuart > or Sean Doran or John Hawkinson showed up. Which would surprise me very > much. > > I didn't like that opening, at all. I disliked it slightly less than when they had a video making fun of us. I personally and in my Board position thank NTT for sponsoring our events, and we give them, like all other hosts, a few minutes during the opening to do something that they think attendees will find educational and/or entertaining. I, like you, sincerely hate the inside jokes being tossed around from the stage and gave them my personal feedback as such. They are far from the only sponsor to have done so, and if you really feel that it's causing a hostile environment for newcomers, I suggest you speak up about it on the members list so that we can figure out the best way to fix it. With that said, newcomers may feel this moment of awkwardness during the opening, but we go above and beyond afterwards to make them feel welcome (newcomers lunch with a personal shepherd, etc.) that I hope at least has made up for some of it in the past. I won't sit around and mourn the greybeards that choose or don't choose to show up. We can't go chasing after people who have had vast changes in their career responsibilities and life circumstances and assume that we can always produce the conference that fits their aspirations. At some point we need to hand the torch over to the next guard, and that's the root of my diversity screed. If we try to be everything to everyone, we end up as nothing to no one (or worse, ITW). The board has been nothing but receptive towards ideas on how to make these meetings more valuable to long time and first time attendees alike. -Dave Temkin NANOG Board Chair From owen at delong.com Mon Sep 11 18:53:05 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Sep 2017 14:53:05 -0400 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> Message-ID: <70E6F446-8C8E-46D8-8ED5-89E6ACA2A772@delong.com> > On Sep 9, 2017, at 12:06 PM, Kody Vicknair wrote: > > All, > > I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it. Yes, please. If it turns out a /32 isn’t enough space to do this, then a /32 is too small for your network and you should trade it for a larger block. > I’ve read recent BCOP drafts that have been approved by the IETF: > https://www.ripe.net/publications/docs/ripe-554 > It looks like the smallest subnet that should ever be assigned is a /64 on a particular link. > > > Some questions that come to mind with IPv6: > > In regards to Point to point links my thinking is this: > Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not? Yes and no. An IX is usually _NOT_ a point to point, but a layer 2 fabric much like a LAN except that it connects a bunch of different ASNs. Still assigning a /64 to point to points makes a lot of sense, even if you use them as /127s on the link. > In regards to core loopback addressing my initial thoughts are as follows: > Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128? I prefer GUA. These might show up in traceroutes. Each LO interface should have a /128. There’s no point (in most situations) in giving anything more). > Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes. That’s way too open ended to provide useful advice. It really depends on your particular situation, topology, political limitations, and more. > I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6. 99.9% they work just like in IPv4. > Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road? Sounds like you’re generally on the right track. You may want to look in the archives for the NANOG on the Road in Las Vegas. I gave an Address Planning talk there and the slides should be online. If you’re anywhere near Cambridge, MA Thursday, I’ll be doing it again there. Owen > > > > > Kody Vicknair > Network Engineer > > > [cid:imagebf3343.JPG at c9d2fbd2.4db10e0d] > > Tel: 985.536.1214 > Fax: 985.536.0300 > Email: kvicknair at reservetele.com > Web: www.rtconline.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > > > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. > From owen at delong.com Mon Sep 11 18:55:46 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Sep 2017 14:55:46 -0400 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B51A48.6090305@nsc.liu.se> Message-ID: <2ACC7244-1A7B-4E3D-A931-B7347E593C3A@delong.com> > On Sep 11, 2017, at 3:35 AM, Nikolay Shopik wrote: > > On 10/09/2017 14:25, Saku Ytti wrote: >> However I don't think market would generally appreciate the >> implications linklocal brings to traceroute, where least bad option >> would be just to originate hop-limit exceeded from loop0, with no >> visibility on actual interface. > > rfc5837 would help but it seems market universally ignore it for some reason unknown to me (lack of interest and IPv6 adoption?) > > We find LL is simpler, operation wise at some cases. How’s that work out for you on routers with the same MAC address on multiple interfaces when you’re trying to troubleshoot ECMP trace routes? Owen From lee at asgard.org Mon Sep 11 22:08:51 2017 From: lee at asgard.org (Lee Howard) Date: Mon, 11 Sep 2017 18:08:51 -0400 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> Message-ID: On 9/9/17, 12:06 PM, "NANOG on behalf of Kody Vicknair" wrote: >All, > >I’ve been doing some reading in preparation of IPv6 deployment and >figuring out how we will break up our /32. I think I’m on the right track >in thinking that each customer will be allocated a /48 to do whatever >they wish with it. Yes. > >I’ve read recent BCOP drafts that have been approved by the IETF: >https://www.ripe.net/publications/docs/ripe-554 BCOP isn’t an IETF BCP. But that’s a really minor detail; BCOPs much better operator input than most IETF activities (IMHO, as an active IETF participant). >It looks like the smallest subnet that should ever be assigned is a /64 >on a particular link. > > >Some questions that come to mind with IPv6: > >In regards to Point to point links my thinking is this: >Assign a unique /64 to each point to point link with these addresses >being Globally routable. This seems to be what our IX providers do when >assigning us an IPv6 address. Am I correct in this train of thought? >Why/Why not? Yes, the general guidance is to reserve a /64 for the link and configure a very small subnet (like /127) on the interfaces, to avoid a ping-pong attack. > >In regards to core loopback addressing my initial thoughts are as follows: >Assign a single /64 encompassing all /128’s planned for loopback >addressing schemes. Should I be using Unique Local addressing for >loopbacks instead of going with a Globally routeable addressing scheme? >Should each interface IP configuration have a /64 or a /128? You can use ULAs for this; I know of a moderately sized network that does. I think most people still use GUA. You’re not wrong either way, though I know some people get emotional about ULA. > >Also when talking about CPE mgmt addresses what do you think is a >practical way of going about assigning “Private” addressing schemes for >cpe management purposes. Reserve another block from your /32 and route it separately. As somebody else said, if you find you’re running out of address space in IPv6, there’s no shame in requesting more than a /32. > >I’m sure some of these questions will be answered when I dive deeper into >how OSPFv6 works as well as BGP in regards to IPv6. Maybe, but don’t panic. It’s not significantly harder in IPv6 than in IPv4. > >Are any of you currently running IPv6 and wished you had done something >differently during the planning phase that may have prevented headaches >down the road? I always tell people: you’re going to rewrite your address plan three times. Do what you can with it, then start deploying through the network. You’ll see what changes you need to make once you know how your network is unique. I wish I’d pushed harder for /48s for customers from the beginning, even though we would’ve needed more address space. I wish I’d started sooner, but more than that I wish my vendors had started sooner, especially CPE vendors. I wish I had just replaced broken equipment rather than working around it. I wish I had had better monitoring of both IPv4 and IPv6 specific systems, so I could tell when one address family failed. I wish I had been able to plan my transition technology earlier, so I could move from dual-stack to IPv6. Lee > > > > >Kody Vicknair >Network Engineer > > > [cid:imagebf3343.JPG at c9d2fbd2.4db10e0d] > >Tel: 985.536.1214 >Fax: 985.536.0300 >Email: kvicknair at reservetele.com >Web: www.rtconline.com > > Reserve Telecommunications >100 RTC Dr >Reserve, LA 70084 > > > > > >Disclaimer: >The information transmitted, including attachments, is intended only for >the person(s) or entity to which it is addressed and may contain >confidential and/or privileged material which should not disseminate, >distribute or be copied. Please notify Kody Vicknair immediately by >e-mail if you have received this e-mail by mistake and delete this e-mail >from your system. E-mail transmission cannot be guaranteed to be secure >or error-free as information could be intercepted, corrupted, lost, >destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair >therefore does not accept liability for any errors or omissions in the >contents of this message, which arise as a result of e-mail transmission. > From spedersen.lists at gmail.com Mon Sep 11 22:40:34 2017 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Mon, 11 Sep 2017 15:40:34 -0700 Subject: Internet access for security consultants - pen tests, attack traffic, bulk e-mail, etc. Message-ID: <002c01d32b4e$fb9b9fc0$f2d2df40$@gmail.com> We were recently approached by a company that does security consulting. Some of the functions they perform include discovery scans, penetration testing, bulk e-mail generation (phishing, malware, etc.), hosting fake botnets - basically, they'd be generating a lot of bad network traffic. Targeted at specific clients/customers, but still bad. As an ISP, this is new territory for us and there are some concerns about potential impact, abuse reports, reputation, authorization to perform such tests, etc. Does anyone have experience in this area that would be willing to offer advice? From pozar at lns.com Mon Sep 11 22:58:10 2017 From: pozar at lns.com (Tim Pozar) Date: Mon, 11 Sep 2017 15:58:10 -0700 Subject: Internet access for security consultants - pen tests, attack traffic, bulk e-mail, etc. In-Reply-To: <002c01d32b4e$fb9b9fc0$f2d2df40$@gmail.com> References: <002c01d32b4e$fb9b9fc0$f2d2df40$@gmail.com> Message-ID: <55e67a0d-e0cf-749b-7d93-e2391e7a9be8@lns.com> Ping the DNC? :-) https://www.wired.com/story/the-dncs-technology-chief-is-phishing-his-staff-good/ Tim On 9/11/17 3:40 PM, Sean Pedersen wrote: > We were recently approached by a company that does security consulting. Some > of the functions they perform include discovery scans, penetration testing, > bulk e-mail generation (phishing, malware, etc.), hosting fake botnets - > basically, they'd be generating a lot of bad network traffic. Targeted at > specific clients/customers, but still bad. As an ISP, this is new territory > for us and there are some concerns about potential impact, abuse reports, > reputation, authorization to perform such tests, etc. > > > > Does anyone have experience in this area that would be willing to offer > advice? > > > > > From hvgeekwtrvl at gmail.com Mon Sep 11 23:00:10 2017 From: hvgeekwtrvl at gmail.com (james machado) Date: Mon, 11 Sep 2017 16:00:10 -0700 Subject: Internet access for security consultants - pen tests, attack traffic, bulk e-mail, etc. In-Reply-To: <002c01d32b4e$fb9b9fc0$f2d2df40$@gmail.com> References: <002c01d32b4e$fb9b9fc0$f2d2df40$@gmail.com> Message-ID: On Mon, Sep 11, 2017 at 3:40 PM, Sean Pedersen wrote: > We were recently approached by a company that does security consulting. > Some > of the functions they perform include discovery scans, penetration testing, > bulk e-mail generation (phishing, malware, etc.), hosting fake botnets - > basically, they'd be generating a lot of bad network traffic. Targeted at > specific clients/customers, but still bad. As an ISP, this is new territory > for us and there are some concerns about potential impact, abuse reports, > reputation, authorization to perform such tests, etc. > > > > Does anyone have experience in this area that would be willing to offer > advice? > > > From a customer point of view: We have written agreements with our vendors on who they can and can not send this traffic from, where exactly it is coming from and what type of traffic it will be. One reason our vendor does this is to not get on black hole/spam lists or to cause their ISP issues, as well as having proof that they are allowed to send specific traffic to specific addresses for a specific time period. The test managers then know what to expect and to head off abuse notifications after detection of the specific traffic. We, also, use this traffic to test other vendors we might have and only after detection we will have white lists or black lists put in place as warranted. I would expect the company in question to be able to provide documentation that could track any specific traffic back to an engagement that has the approval of their customer. If they have been around for a bit they should have a track record and may have current IP space that could be vetted to see what condition it is in. Are they leaving it or adding too it. If they are leaving their current space then find out why. James From sean at donelan.com Mon Sep 11 23:35:29 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 11 Sep 2017 19:35:29 -0400 (EDT) Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: Electric Power Florida: 6,117,0247 customer outages (59% of state) Puerto Rico: 368,682 customer outages (23.5% of territory) U.S. Virgin Islands: St. John: 100% customers without power St. Thomas: 99% customers without power (airport, hospital, and some areas on those substations re-energized) St. Croix: 31% customers without power Georgia: 866,682 customer outages (9% of state) South Carolina: 184,471 customer outages (7.2% of state Public Safety: 29 Public Safety Answering Points (9-1-1 centers) impacted Florida 14 PSAPs out-of-service, no re-route 11 PSAPs out-of-service, rerouted to other answering points 2 PSAPs with partial service, no automatic location U.S. Virgin Islands 2 PSAPs (out of 2) with partial service, no automatic location Wireless Services: Florida 27.4% cell sites out of service (6 counties with more than 50% out of service) Puerto Rico 19.4% cell sites out of service (8 areas with more than 50% out of service) U.S. Virgin Islands 55% cell sites out of service (90% out of service St. John, 72% out of service St. Thomas, 22.5% out of service St. Croix) Cable and Wireline Florida 7,597,945 customers out of service 390 switching centers (central offices) out of service Puerto Rico and U.S. Virgin Islands Reporting still spotty, assume customers out of service in areas without electric power. Some VSAT service restored on U.S. VI. Broadcast 8 TV stations out of service Florida: 2 stations Puerto Rico: 4 stations U.S. Vigin Islands: 2 stations 26 radio stations out of service Florida: 25 stations U.S. Virgin Islands: 1 station reporting (but other stations are likely out of service, but can't report) From sean at donelan.com Tue Sep 12 01:11:16 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 11 Sep 2017 21:11:16 -0400 (EDT) Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: A couple of additional items Telecommunications - Free WiFi hotspots (where power available) Comcast Xfinity WiFi Charter Spectrum WiFi I expect other commercial WiFi hotspot service providers in Florida have (or will) have free access in the disaster areas. AT&T and Verizon are bringing temporary Cells on Wheels trucks to the disaster areas. AT&T, Sprint and Verizon are providing extra mobile data or waiving usage surcharges in the disaster areas. Check the AT&T, Comcast, Charter, Sprint and Verizon corporate sites for details. T-Mobile is probably doing something too, but the T-mobile web-site makes it very difficult to find disaster information. From mattlists at rivervalleyinternet.net Tue Sep 12 01:42:30 2017 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Mon, 11 Sep 2017 21:42:30 -0400 Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: <6FD9427C-DAC9-49AD-A917-A5206FE3FE3F@rivervalleyinternet.net> T-Mobile is providing free calling text and data. > On Sep 11, 2017, at 21:11, Sean Donelan wrote: > > > A couple of additional items > > Telecommunications - Free WiFi hotspots (where power available) > > Comcast Xfinity WiFi > Charter Spectrum WiFi > > I expect other commercial WiFi hotspot service providers in Florida have (or will) have free access in the disaster areas. > > AT&T and Verizon are bringing temporary Cells on Wheels trucks to the disaster areas. AT&T, Sprint and Verizon are providing extra mobile data or waiving usage surcharges in the disaster areas. > > Check the AT&T, Comcast, Charter, Sprint and Verizon corporate sites for details. T-Mobile is probably doing something too, but the T-mobile web-site makes it very difficult to find disaster information. From saku at ytti.fi Tue Sep 12 07:52:58 2017 From: saku at ytti.fi (Saku Ytti) Date: Tue, 12 Sep 2017 10:52:58 +0300 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> Message-ID: On 12 September 2017 at 01:08, Lee Howard wrote: >>Are any of you currently running IPv6 and wished you had done something >>differently during the planning phase that may have prevented headaches >>down the road? > > I always tell people: you’re going to rewrite your address plan three > times. Do what you can with it, then start deploying through the network. > You’ll see what changes you need to make once you know how your network is > unique. Also write your iACL/edge-filter before you deploy your IPv6. If you can't write concise, almost static IPv6 iACL, your numbering plan requires work. -- ++ytti From spedersen.lists at gmail.com Tue Sep 12 15:02:18 2017 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Tue, 12 Sep 2017 08:02:18 -0700 Subject: Internet access for security consultants - pen tests, attack traffic, bulk e-mail, etc. In-Reply-To: References: <002c01d32b4e$fb9b9fc0$f2d2df40$@gmail.com> Message-ID: <001801d32bd8$218067f0$648137d0$@gmail.com> Quick note to thank everyone for their input. So far everything that has been suggested publicly and privately has been right in line with what were already putting on paper so this provided some great feedback and confirmation that we’re going in the right direction. From woody at pch.net Tue Sep 12 17:15:23 2017 From: woody at pch.net (Bill Woodcock) Date: Tue, 12 Sep 2017 10:15:23 -0700 Subject: 2017 NANOG Elections General Information In-Reply-To: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> References: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> Message-ID: >> On Sep 10, 2017, at 1:59 PM, Bryan Holloway wrote: >> I point specifically to the opening talk at Bellevue where there were wackily photoshop'd pictures of NANOG star heavy-hitters. >> Had I been a first-time attendee, I would've felt like a high-school freshman being told who all the "cool seniors" were. >> Frankly, it was awkward and off-putting. > > On Sep 11, 2017, at 12:32 AM, Bill Woodcock wrote: > Probably a safe bet that it was mostly aspirant juniors. Patrick has pointed out to me that my offhand dismissiveness painted with an overly broad brush and encompassed people whom I undoubtedly do not think so little of. So, my sincere apologies for my tone and speaking-out-of-turn about a slide deck that I hadn’t actually seen. I do very much miss the “cool seniors” who worked so hard to make this what it was, twenty-five and thirty years ago; I owe them a lot. I’m sure the people who are working hard to make the organization what it is today are serving a similar function for people who are entering the industry today. Nostalgia was causing me to conflate two things which are unrelated The frat-boy thing is a problem, not only in NANOG, but in ARIN and RIPE. I’d very much like to see it fixed, so that everyone can enjoy collegial support, rather than just a subset of participants. -Bill From admin at coldnorthadmin.com Tue Sep 12 21:29:50 2017 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Tue, 12 Sep 2017 17:29:50 -0400 Subject: Anyone here from Netflix? | VPN Detection Problem In-Reply-To: <32c189d8-70fe-f8d5-3c3a-7e6babd51b64@unlimitednet.us> References: <32c189d8-70fe-f8d5-3c3a-7e6babd51b64@unlimitednet.us> Message-ID: <4e252807-e009-7284-3ae1-908c60f83b74@coldnorthadmin.com> Hey Jason, We've had good luck contacting geosupport at netflix.com when we had issues with subnets being flagged as either VPS providers. They have been very responsive in the few indidents we had. On 9/8/2017 3:30 PM, Jason Canady wrote: > Hello, > > We have IP addresses being blocked due to proxy servers that were once > on the IP address space. They have now been reclaimed and will be used > for ISP services to end-users. We need to ensure that customers can > watch Netflix without any issues. > > Would someone please reach out to me to resolve this? > > Thank you! > > Best Regards, > > Jason Canady > Unlimited Net, LLC > > From sean at donelan.com Tue Sep 12 22:47:03 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Sep 2017 18:47:03 -0400 (EDT) Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: A couple of folks asked about commercial colocation and data centers... There are about 100 major colocation and datacenters in Florida and southern Georgia. I've check the usual suspects, and none have posted outages. Directv and Dishtv "local-in-local" TV stations appear to be uninterrupted, which indicates the major fiber hubs they use for TV signal aggregation are working in the local areas. I can't tell how many data centers are on backup generators. Today's update from various official sources (FEMA, Dept. of Energy, FCC, NOAA, etc). Electric Power (DOE) Florida: 4,788,277 customer outages (48% of total state customers) Georgia: 932,587 customer outages (22% of total state customers) South Carolina: 140,759 customer outages (6% of total state customers) North Carolina: 56,834 customer outages (1% of total state customers) Alabama: 20,050 customers outages (1% of total state customers) Puerto Rico: 303,998 customers (19% of total customers) U.S. Virgin Islands Water and Power Authority (WAPA) reported several feeders on St. Thomas are re-energized. There are currently two generators (#14 and #25) online with a maximum capacity of 39 MW. An 800 kW generator has arrived on St. Thomas September 12. Water (FEMA) U.S. Virgin Islands: 341,000 people without potable water Puerto Rico: 61,980 people without potable water Public Safety Hospitals (FEMA) Florida: 33 closed, 204 healthcare facilities evacuated Puerto Rico: 1 closed, 6 on generator power U.S. VI: 1 closed and evacuated NOAA Weather Radio (NOAA) Florida: 9 out of 32 stations (28%) out of service Georgia: 4 out of 29 stations (13%) out of service U.S. VI: 1 out of 1 station (100%) out of service Public Safety Answering Points (9-1-1 centers) (FCC) Florida: 27 impacted (3 out of service, 9 partial service, 9 re-routed with ALI, 8 re-routed without ALI) U.S. VI: 2 impacted, without ALI/ANI Cable and Wireline systems (FCC) 819 switching centers (cable headends and central offices) out of service. Unknown how many are isolated, damaged or just without power. 7,184,909 subscribers out of service in Alabama, Florida and Georgia; not including Puerto Rico and U.S. Virgin Islands. Because of the limited number of service providers, I think FCC is not releasing the information. >From other reporting, Puerto Rico has about 50% out of service and U.S. VI has about 33% out of service not including St. John and St. Thomas. Wireless Service (FCC) Alabama: less 1% cell sites out of service Florida: 24.6% cell sites out of service (5 counties over 50% OOS) Georgia: 10.5% cell sites out of service (1 county over 50% OOS) Puerto Rico: 14.5% cell sites out of service (3 counties over 50% OOS) U.S. VI: 53% cell sites out of service (St. John - 9 out of 10 OOS, St. Thomas 38 out of 57 OOS) Broadcast (FCC) Television: 9 stations out of service Radio: 51 stations out of service From dave at temk.in Tue Sep 12 22:53:28 2017 From: dave at temk.in (Dave Temkin) Date: Tue, 12 Sep 2017 15:53:28 -0700 Subject: 2017 NANOG Elections General Information In-Reply-To: References: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> Message-ID: On Tue, Sep 12, 2017 at 10:15 AM, Bill Woodcock wrote: > >> On Sep 10, 2017, at 1:59 PM, Bryan Holloway wrote: > >> I point specifically to the opening talk at Bellevue where there were > wackily photoshop'd pictures of NANOG star heavy-hitters. > >> Had I been a first-time attendee, I would've felt like a high-school > freshman being told who all the "cool seniors" were. > >> Frankly, it was awkward and off-putting. > > > > On Sep 11, 2017, at 12:32 AM, Bill Woodcock wrote: > > Probably a safe bet that it was mostly aspirant juniors. > > Patrick has pointed out to me that my offhand dismissiveness painted with > an overly broad brush and encompassed people whom I undoubtedly do not > think so little of. So, my sincere apologies for my tone and > speaking-out-of-turn about a slide deck that I hadn’t actually seen. I do > very much miss the “cool seniors” who worked so hard to make this what it > was, twenty-five and thirty years ago; I owe them a lot. I’m sure the > people who are working hard to make the organization what it is today are > serving a similar function for people who are entering the industry today. > Thanks Bill. That's definitely an accurate representation from my personal vantage point. Personally in my role within the organization I've stressed the importance of bringing the next Paul Vixie or Sean Doran into the industry and fostering their growth and influence. To me that's where NANOG can add the most value for the next 70 meetings. > > Nostalgia was causing me to conflate two things which are unrelated The > frat-boy thing is a problem, not only in NANOG, but in ARIN and RIPE. I’d > very much like to see it fixed, so that everyone can enjoy collegial > support, rather than just a subset of participants. > > Totally agree here. I'd love to come up with more ideas on how to fix this real issue; my personal diversity & inclusion bent is squarely aimed at that problem. -Dave From liam at fedney.org Tue Sep 12 23:07:22 2017 From: liam at fedney.org (L Sean Kennedy) Date: Tue, 12 Sep 2017 19:07:22 -0400 Subject: [NANOG-announce] NANOG 71 Agenda published Message-ID: NANOG Community, The NANOG 71 Agenda is published and available as an iCal Feed. The Program Committee has worked closely with our speakers to develop a first-rate program and we encourage all attendees to enjoy the whole conference ; as we review submitted content minor changes to the agenda are possible and will be updated in the online feed. Thank you to the many members of our community who submitted interesting content for NANOG 71! Over 800 attendees have registered and the NANOG family looks forward to welcoming all of you to San Jose. Useful Information - NANOG 71 General Information and Registration - Hotel Room Block (s) Information - There are a few remaining spots to register for the NANOG 71 Hackathon - We have a newly implemented attendee meeting scheduler for NANOG 71 - A welcome message that will be sent to registered NANOG 71 attendees shortly will provide more information on scheduled events and applications to help you to make the most of your time in San Jose - Register to attend NANOG On The Road Boston this Thursday and Fort Lauderdale in November Safe travels and see many of you in San Jose. Thanks, Sean L Sean Kennedy On behalf of the NANOG Program Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From large.hadron.collider at gmx.com Wed Sep 13 01:08:17 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Tue, 12 Sep 2017 18:08:17 -0700 Subject: Protocol 17 floods from Vietnam & Mexico? Message-ID: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> 18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx > umbrellix.net: ip-proto-17 18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx > umbrellix.net: ip-proto-17 18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, bad length 65500 > 1464 18:04:32.391145 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391152 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391158 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391164 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391170 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391176 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391182 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391188 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391194 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391199 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391205 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391211 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391217 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391223 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391229 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391234 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391248 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391255 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391261 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391266 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391272 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391278 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391284 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391289 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391295 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391313 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391319 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391325 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391331 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391336 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391342 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391348 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391354 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391367 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391374 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391379 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391385 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391391 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391396 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391402 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391408 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391414 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391420 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391426 IP 115.75.50.106 > umbrellix.net: ip-proto-17 Some stupidity has me wondering... protocol 17? Huh? Is this some attempt to exploit me while at the same time flooding me at over 800Mbit/s? Needless to say, I've shut my computer down to avoid going over my data allowance. From marka at isc.org Wed Sep 13 01:35:31 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 13 Sep 2017 11:35:31 +1000 Subject: Protocol 17 floods from Vietnam & Mexico? In-Reply-To: Your message of "Tue, 12 Sep 2017 18:08:17 -0700." <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> References: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> Message-ID: <20170913013531.8F0DE85448EA@rock.dv.isc.org> Protocol 17 == UDP. These are just very big (65500 byte) UDP packets which have been fragmented. Somebody need to teach that packet analyser that UDP packets can be this big over IPv4 and bigger still if you are using IPv6 jumbo packets. Mark In message <1bf07b56-f71c-1fec-bfd2-386a67c2b138 at gmx.com>, Large Hadron Collider writes: > 18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx > > umbrellix.net: ip-proto-17 > 18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx > > umbrellix.net: ip-proto-17 > 18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, bad > length 65500 > 1464 > 18:04:32.391145 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391152 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391158 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391164 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391170 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391176 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391182 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391188 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391194 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391199 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391205 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391211 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391217 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391223 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391229 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391234 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391248 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391255 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391261 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391266 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391272 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391278 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391284 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391289 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391295 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391313 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391319 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391325 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391331 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391336 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391342 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391348 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391354 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391367 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391374 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391379 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391385 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391391 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391396 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391402 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391408 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391414 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391420 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391426 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > > Some stupidity has me wondering... protocol 17? Huh? > > > Is this some attempt to exploit me while at the same time flooding me at > over 800Mbit/s? > > > Needless to say, I've shut my computer down to avoid going over my data > allowance. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From large.hadron.collider at gmx.com Wed Sep 13 02:20:13 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Tue, 12 Sep 2017 19:20:13 -0700 Subject: Protocol 17 floods from Vietnam & Mexico? In-Reply-To: References: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> Message-ID: <08ed2903-c81c-aa2e-cd04-4fa117840d14@gmx.com> Yes, I'm being UDP flooded. I worked that out by grepping /etc/protocols. On 12/09/2017 18:24, Matt Harris wrote: > Protocol 17 is UDP. UDP is pretty common on the internet. Not sure > why source and destination ports aren't being shown by your tool > there, might be malformed UDP packets designed to obscure themselves > from or otherwise evade some intrusion detection or firewall systems. > > > On Tue, Sep 12, 2017 at 8:08 PM, Large Hadron Collider > > > wrote: > > 18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx > > umbrellix.net > : ip-proto-17 > 18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx > > umbrellix.net > : ip-proto-17 > 18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, > bad length 65500 > 1464 > 18:04:32.391145 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391152 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391158 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391164 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391170 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391176 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391182 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391188 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391194 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391199 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391205 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391211 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391217 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391223 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391229 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391234 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391248 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391255 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391261 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391266 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391272 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391278 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391284 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391289 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391295 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391313 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391319 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391325 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391331 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391336 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391342 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391348 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391354 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391367 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391374 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391379 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391385 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391391 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391396 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391402 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391408 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391414 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391420 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > 18:04:32.391426 IP 115.75.50.106 > umbrellix.net > : ip-proto-17 > > Some stupidity has me wondering... protocol 17? Huh? > > > Is this some attempt to exploit me while at the same time flooding > me at over 800Mbit/s? > > > Needless to say, I've shut my computer down to avoid going over my > data allowance. > > > > > -- > Matt Harris - Chief Security Officer > Main: +1 855.696.3834 ext 103 > Mobile: +1 908.590.9472 > Email:matt at netfire.net From marka at isc.org Wed Sep 13 02:44:54 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 13 Sep 2017 12:44:54 +1000 Subject: Protocol 17 floods from Vietnam & Mexico? In-Reply-To: Your message of "Tue, 12 Sep 2017 19:20:13 -0700." <08ed2903-c81c-aa2e-cd04-4fa117840d14@gmx.com> References: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> <08ed2903-c81c-aa2e-cd04-4fa117840d14@gmx.com> Message-ID: <20170913024454.5B80B8550D8B@rock.dv.isc.org> In message <08ed2903-c81c-aa2e-cd04-4fa117840d14 at gmx.com>, Large Hadron Collider writes: > Yes, I'm being UDP flooded. I worked that out by grepping /etc/protocols. > > > On 12/09/2017 18:24, Matt Harris wrote: > > Protocol 17 is UDP. UDP is pretty common on the internet. Not sure > > why source and destination ports aren't being shown by your tool > > there, might be malformed UDP packets designed to obscure themselves > > from or otherwise evade some intrusion detection or firewall systems. No ports are listed because they are not the initial fragment of the UDP packet. Only the initial fragment that contains the UDP header has the ports reported. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sean at donelan.com Wed Sep 13 04:38:50 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 13 Sep 2017 00:38:50 -0400 (EDT) Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: On Tue, 12 Sep 2017, Sean Donelan wrote: > A couple of folks asked about commercial colocation and data centers... > > There are about 100 major colocation and datacenters in Florida and southern > Georgia. I've check the usual suspects, and none have posted outages. > Directv and Dishtv "local-in-local" TV stations appear to be uninterrupted, > which indicates the major fiber hubs they use for TV signal aggregation are > working in the local areas. > > I can't tell how many data centers are on backup generators. Just to clarify, since several people wanted corrections. There is substantial outside plant damage in Florida, and many local loop circuits are out of service. I was only referring to data services inside major colocation and data centers, not in offices and other locations. One person did report they had servers reboot in a Florida colocation facility during the hurricane, likely due to power distubances. The power came back quickly, I assume an issue switching to backup generators or a glitchy UPS. Another person reported they lost connectivity to their systems in a colocation facility for 24 hours. I'm still checking on that one. From randy at psg.com Wed Sep 13 05:03:31 2017 From: randy at psg.com (Randy Bush) Date: Wed, 13 Sep 2017 14:03:31 +0900 Subject: 2017 NANOG Elections General Information In-Reply-To: References: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> Message-ID: > So how do we fix it? since bussing is out, you're left with affirmative action :) ask the ripe women, a strong group, how they got women to be willing to server on the board ask the ietf women, a strong group, how they got women to be willing to server in the iesg apnic has a star woman on the execcom, ask her this is most strongly an american disease. nanog has encouraged and supported a frat boy ego parade and beauty contest. try the ietf nomcomm approach, but with zero white boys on the nomcomm. btw, one trick is getting more then one diverse player, so the one is not a martian and has peer support s/women/diversity/ q: how many psychiatrists does it take to change a light bulb a: one, but the light bulb has to want to change From mhuff at ox.com Wed Sep 13 09:30:28 2017 From: mhuff at ox.com (Matthew Huff) Date: Wed, 13 Sep 2017 09:30:28 +0000 Subject: Reliability of looking glass sites / rviews Message-ID: This weekend our uninterruptible power supply became interruptible and we lost all circuits. While I was doing initial debugging of the problem while I waited on site power verification, I noticed that there was still paths being shown in rviews for the circuit that were down. This was over an hour after we went hard down and it took hours before we were back up. I worked with our providers last night to verify there weren't any hanging static routes, etc... We shut the upstream circuit down and watched the convergence and saw that eventually all the paths disappeared. Given what we saw on Saturday, what would cause route-views to cache the paths that long? Some looking glass sites only show what they are peered with or at most what their peers are peered with, that's why I've always used route-views. What looking glass sites other than route-views would people recommend? From mhuff at ox.com Wed Sep 13 11:05:53 2017 From: mhuff at ox.com (Matthew Huff) Date: Wed, 13 Sep 2017 11:05:53 +0000 Subject: Getting an RADB entry removed that was added by a previous peer Message-ID: <17b2db517ab5409699ddb5b8cfed72a0@ox.com> It appears that Reliance Globalcom (AS6157) added an RADB entry for our prefix (129.77.0.0/16) when we were a peer of theirs years ago, and it was never removed when we ended the relationship. We are ASN 14607. I've reached out to their support, but does anyone have a suggestion on how I could get this cleaned up if they don't respond? From job at ntt.net Wed Sep 13 11:10:37 2017 From: job at ntt.net (Job Snijders) Date: Wed, 13 Sep 2017 11:10:37 +0000 Subject: Getting an RADB entry removed that was added by a previous peer In-Reply-To: <17b2db517ab5409699ddb5b8cfed72a0@ox.com> References: <17b2db517ab5409699ddb5b8cfed72a0@ox.com> Message-ID: On Wed, 13 Sep 2017 at 13:08, Matthew Huff wrote: > It appears that Reliance Globalcom (AS6157) added an RADB entry for our > prefix (129.77.0.0/16) when we were a peer of theirs years ago, and it > was never removed when we ended the relationship. We are ASN 14607. > > I've reached out to their support, but does anyone have a suggestion on > how I could get this cleaned up if they don't respond? > Easy! Email radb-support at merit.edu for assistance. Kind regards, Job From KShah at primustel.ca Wed Sep 13 13:59:04 2017 From: KShah at primustel.ca (Krunal Shah) Date: Wed, 13 Sep 2017 13:59:04 +0000 Subject: Protocol 17 floods from Vietnam & Mexico? In-Reply-To: <20170913024454.5B80B8550D8B@rock.dv.isc.org> References: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> <08ed2903-c81c-aa2e-cd04-4fa117840d14@gmx.com> <20170913024454.5B80B8550D8B@rock.dv.isc.org> Message-ID: It might be spoofed source IPs Krunal Shah -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews Sent: Tuesday, September 12, 2017 10:45 PM To: Large Hadron Collider Cc: nanog at nanog.org Subject: Re: Protocol 17 floods from Vietnam & Mexico? In message <08ed2903-c81c-aa2e-cd04-4fa117840d14 at gmx.com>, Large Hadron Collider writes: > Yes, I'm being UDP flooded. I worked that out by grepping /etc/protocols. > > > On 12/09/2017 18:24, Matt Harris wrote: > > Protocol 17 is UDP. UDP is pretty common on the internet. Not sure > > why source and destination ports aren't being shown by your tool > > there, might be malformed UDP packets designed to obscure themselves > > from or otherwise evade some intrusion detection or firewall systems. No ports are listed because they are not the initial fragment of the UDP packet. Only the initial fragment that contains the UDP header has the ports reported. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -------------------------------- This electronic message contains information from Primus Management ULC ("PRIMUS") , which may be legally privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or advice expressed in this electronic message are not necessarily the views, opinions or advice of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use thereof.The term "PRIMUS" includes its affiliates. -------------------------------- Pour la version en français de ce message, veuillez voir http://www.primustel.ca/fr/legal/cs.htm From morrowc.lists at gmail.com Wed Sep 13 14:57:25 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Sep 2017 10:57:25 -0400 Subject: Protocol 17 floods from Vietnam & Mexico? In-Reply-To: References: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> <08ed2903-c81c-aa2e-cd04-4fa117840d14@gmx.com> <20170913024454.5B80B8550D8B@rock.dv.isc.org> Message-ID: On Wed, Sep 13, 2017 at 9:59 AM, Krunal Shah wrote: > It might be spoofed source IPs > > if you are seeing large fragmented udp packets.. it's almost always not spoofed. or historically speaking anyway it's not been spoofed. There are cases with dns reflection that include spoofing, but by the time you see the large packet .. that's not spoofed it's coming from the dns server talking to you, why it's talking to you is due to spoofing, but that's outside (most times) your span of control. > > Krunal Shah > > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews > Sent: Tuesday, September 12, 2017 10:45 PM > To: Large Hadron Collider > Cc: nanog at nanog.org > Subject: Re: Protocol 17 floods from Vietnam & Mexico? > > > In message <08ed2903-c81c-aa2e-cd04-4fa117840d14 at gmx.com>, Large Hadron > Collider writes: > > Yes, I'm being UDP flooded. I worked that out by grepping /etc/protocols. > > > > > > On 12/09/2017 18:24, Matt Harris wrote: > > > Protocol 17 is UDP. UDP is pretty common on the internet. Not sure > > > why source and destination ports aren't being shown by your tool > > > there, might be malformed UDP packets designed to obscure themselves > > > from or otherwise evade some intrusion detection or firewall systems. > > No ports are listed because they are not the initial fragment of the UDP > packet. Only the initial fragment that contains the UDP header has the > ports reported. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > -------------------------------- > This electronic message contains information from Primus Management ULC > ("PRIMUS") , which may be legally privileged and confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient, be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message in > error, please notify us by telephone or e-mail (to the number or address > above) immediately. Any views, opinions or advice expressed in this > electronic message are not necessarily the views, opinions or advice of > PRIMUS. It is the responsibility of the recipient to ensure that any > attachments are virus free and PRIMUS bears no responsibility for any loss > or damage arising in any way from the use thereof.The term "PRIMUS" > includes its affiliates. > -------------------------------- > Pour la version en français de ce message, veuillez voir > http://www.primustel.ca/fr/legal/cs.htm > > From morrowc.lists at gmail.com Wed Sep 13 14:58:45 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Sep 2017 10:58:45 -0400 Subject: Reliability of looking glass sites / rviews In-Reply-To: References: Message-ID: On Wed, Sep 13, 2017 at 5:30 AM, Matthew Huff wrote: > This weekend our uninterruptible power supply became interruptible and we > lost all circuits. While I was doing initial debugging of the problem while > I waited on site power verification, I noticed that there was still paths > being shown in rviews for the circuit that were down. This was over an hour > after we went hard down and it took hours before we were back up. > > explicit vs implicit withdrawals causing different handling of the problem routes? > I worked with our providers last night to verify there weren't any hanging > static routes, etc... We shut the upstream circuit down and watched the > convergence and saw that eventually all the paths disappeared. Given what > we saw on Saturday, what would cause route-views to cache the paths that > long? Some looking glass sites only show what they are peered with or at > most what their peers are peered with, that's why I've always used > route-views. > > What looking glass sites other than route-views would people recommend? > ripe ris. From sandy at tislabs.com Wed Sep 13 15:21:47 2017 From: sandy at tislabs.com (Sandra Murphy) Date: Wed, 13 Sep 2017 11:21:47 -0400 Subject: Getting an RADB entry removed that was added by a previous peer In-Reply-To: References: <17b2db517ab5409699ddb5b8cfed72a0@ox.com> Message-ID: Job should also have pointed to http://irrexplorer.nlnog.net (notes "Created by Job Snijders"). It notes multiple route objects (e.g., http://irrexplorer.nlnog.net/search/129.77.0.0/16). IMHO, worth a look or two from time to time for one’s own resources. —Sandy > On Sep 13, 2017, at 7:10 AM, Job Snijders wrote: > > On Wed, 13 Sep 2017 at 13:08, Matthew Huff wrote: > >> It appears that Reliance Globalcom (AS6157) added an RADB entry for our >> prefix (129.77.0.0/16) when we were a peer of theirs years ago, and it >> was never removed when we ended the relationship. We are ASN 14607. >> >> I've reached out to their support, but does anyone have a suggestion on >> how I could get this cleaned up if they don't respond? >> > Easy! Email radb-support at merit.edu for assistance. > > Kind regards, > > Job From mhuff at ox.com Wed Sep 13 15:42:24 2017 From: mhuff at ox.com (Matthew Huff) Date: Wed, 13 Sep 2017 15:42:24 +0000 Subject: Reliability of looking glass sites / rviews In-Reply-To: References: Message-ID: Both should have been similar. In the first case we lost power to all of our BGP border routers that are peered with the upstream providers In the second case, I did an explicit “shut” on the interface connected to the upstream provider that appeared “stuck” after an hour after the outage. From: on behalf of Christopher Morrow Date: Wednesday, September 13, 2017 at 10:58 AM To: Matthew Huff Cc: nanog2 Subject: Re: Reliability of looking glass sites / rviews On Wed, Sep 13, 2017 at 5:30 AM, Matthew Huff > wrote: This weekend our uninterruptible power supply became interruptible and we lost all circuits. While I was doing initial debugging of the problem while I waited on site power verification, I noticed that there was still paths being shown in rviews for the circuit that were down. This was over an hour after we went hard down and it took hours before we were back up. explicit vs implicit withdrawals causing different handling of the problem routes? I worked with our providers last night to verify there weren't any hanging static routes, etc... We shut the upstream circuit down and watched the convergence and saw that eventually all the paths disappeared. Given what we saw on Saturday, what would cause route-views to cache the paths that long? Some looking glass sites only show what they are peered with or at most what their peers are peered with, that's why I've always used route-views. What looking glass sites other than route-views would people recommend? ripe ris. From morrowc.lists at gmail.com Wed Sep 13 15:52:22 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Sep 2017 11:52:22 -0400 Subject: Reliability of looking glass sites / rviews In-Reply-To: References: Message-ID: On Wed, Sep 13, 2017 at 11:42 AM, Matthew Huff wrote: > Both should have been similar. > > In the first case we lost power to all of our BGP border routers that are > peered with the upstream providers > In the second case, I did an explicit “shut” on the interface connected to > the upstream provider that appeared “stuck” after an hour after the outage. > oh, I had thought when you broke the second time intentionally you might have shut the bgp session (and then maybe the interface too) ... causing a different semantic for the withdrawals in the isp network. it's possible that if the load of updates was large enough for the ISP(s) in question that things simply took a long while to process. In a recent similar situation we'd observed updates/convergence taking upwards of 30 minutes to trickle through the global system :( > > From: on behalf of Christopher Morrow < > morrowc.lists at gmail.com> > Date: Wednesday, September 13, 2017 at 10:58 AM > To: Matthew Huff > Cc: nanog2 > Subject: Re: Reliability of looking glass sites / rviews > > > > On Wed, Sep 13, 2017 at 5:30 AM, Matthew Huff mhuff at ox.com>> wrote: > This weekend our uninterruptible power supply became interruptible and we > lost all circuits. While I was doing initial debugging of the problem while > I waited on site power verification, I noticed that there was still paths > being shown in rviews for the circuit that were down. This was over an hour > after we went hard down and it took hours before we were back up. > > explicit vs implicit withdrawals causing different handling of the problem > routes? > > I worked with our providers last night to verify there weren't any hanging > static routes, etc... We shut the upstream circuit down and watched the > convergence and saw that eventually all the paths disappeared. Given what > we saw on Saturday, what would cause route-views to cache the paths that > long? Some looking glass sites only show what they are peered with or at > most what their peers are peered with, that's why I've always used > route-views. > > What looking glass sites other than route-views would people recommend? > > ripe ris. > From imawsog at yahoo.com Wed Sep 13 15:59:20 2017 From: imawsog at yahoo.com (i mawsog) Date: Wed, 13 Sep 2017 15:59:20 +0000 (UTC) Subject: Protocol 17 floods from Vietnam & Mexico? In-Reply-To: References: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> <08ed2903-c81c-aa2e-cd04-4fa117840d14@gmx.com> <20170913024454.5B80B8550D8B@rock.dv.isc.org> Message-ID: <1337708133.1228299.1505318360549@mail.yahoo.com> The port info is in the first  fragmented packet as was mentioned elsewhere.  My guess is someone fragmenting large packets ( the mtu is set to  1464 or so). and  the host is receiving those fragment, but it not  reconstructing the packets.  If  it is possible to do a tcpdump/wireshark etc , then the content of the packets can be very easily observed .   18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx >  umbrellix.net: ip-proto-17 18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx >  umbrellix.net: ip-proto-17 18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, bad  length 65500 > 1464 18:04:32.391145 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391152 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391158 IP 115.75.50.106 > umbrellix.net: ip-proto-17 From: Christopher Morrow To: Krunal Shah Cc: "nanog at nanog.org" Sent: Wednesday, September 13, 2017 7:59 AM Subject: Re: Protocol 17 floods from Vietnam & Mexico? On Wed, Sep 13, 2017 at 9:59 AM, Krunal Shah wrote: > It might be spoofed source IPs > > if you are seeing large fragmented udp packets.. it's almost always not spoofed. or historically speaking anyway it's not been spoofed. There are cases with dns reflection that include spoofing, but by the time you see the large packet .. that's not spoofed it's coming from the dns server talking to you, why it's talking to you is due to spoofing, but that's outside (most times) your span of control. > > Krunal Shah > > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews > Sent: Tuesday, September 12, 2017 10:45 PM > To: Large Hadron Collider > Cc: nanog at nanog.org > Subject: Re: Protocol 17 floods from Vietnam & Mexico? > > > In message <08ed2903-c81c-aa2e-cd04-4fa117840d14 at gmx.com>, Large Hadron > Collider writes: > > Yes, I'm being UDP flooded. I worked that out by grepping /etc/protocols. > > > > > > On 12/09/2017 18:24, Matt Harris wrote: > > > Protocol 17 is UDP.  UDP is pretty common on the internet. Not sure > > > why source and destination ports aren't being shown by your tool > > > there, might be malformed UDP packets designed to obscure themselves > > > from or otherwise evade some intrusion detection or firewall systems. > > No ports are listed because they are not the initial fragment of the UDP > packet.  Only the initial fragment that contains the UDP header has the > ports reported. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742                INTERNET: marka at isc.org > > > > -------------------------------- > This electronic message contains information from Primus Management ULC > ("PRIMUS") , which may be legally privileged and confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient, be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message in > error, please notify us by telephone or e-mail (to the number or address > above) immediately. Any views, opinions or advice expressed in this > electronic message are not necessarily the views, opinions or advice of > PRIMUS. It is the responsibility of the recipient to ensure that any > attachments are virus free and PRIMUS bears no responsibility for any loss > or damage arising in any way from the use thereof.The term "PRIMUS" > includes its affiliates. > -------------------------------- > Pour la version en français de ce message, veuillez voir > http://www.primustel.ca/fr/legal/cs.htm > > From dave at temk.in Wed Sep 13 16:00:25 2017 From: dave at temk.in (Dave Temkin) Date: Wed, 13 Sep 2017 09:00:25 -0700 Subject: 2017 NANOG Elections General Information In-Reply-To: References: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> Message-ID: On Tue, Sep 12, 2017 at 10:03 PM, Randy Bush wrote: > > So how do we fix it? > > this is most strongly an american disease. nanog has encouraged and > supported a frat boy ego parade and beauty contest. try the ietf > nomcomm approach, but with zero white boys on the nomcomm. > > Love the idea, and I agree that the elections are a popularity contest in many cases and not a measure of who is most capable for the job. Luckily, we've generally ended up with people who are both - but that's not always best for the organization long term, and we generally end up with "more of the same". In my tenure in NANOG we've floated the idea of a nomcom a few times, but it's generally been summarily shot down. Are you suggesting that we try and float the idea again? I'm not 100% clear, but I believe it would require a bylaw change. > btw, one trick is getting more then one diverse player, so the one is > not a martian and has peer support > > s/women/diversity/ > > Completely agree; gender is only one of various keys that are important here. Race, age, national origin, orientation, etc. - all of these things matter in avoiding groupthink and helping to ensure that the board is representative of the membership that we wish to attract. > q: how many psychiatrists does it take to change a light bulb > a: one, but the light bulb has to want to change > > Alternate A: Depends, are we having the conference in a union hotel? From dvandyk at akamai.com Thu Sep 14 00:47:03 2017 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Thu, 14 Sep 2017 00:47:03 +0000 Subject: Verizon issues | Looking glass Message-ID: <22E40633-19B8-447D-AFDC-D017BCBE3742@akamai.com> Hello, Has anyone else been seeing issues today from routes being learnt through the Verizon network, AS 701? Does anyone know if they have a looking glass? I can’t find one. Thanks -- Donovan Van Dyk SOC Network Engineer Fort Lauderdale, FL USA [cid:image001.png at 01D32CD1.73DBD490] The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. From morrowc.lists at gmail.com Thu Sep 14 01:20:12 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Sep 2017 21:20:12 -0400 Subject: Verizon issues | Looking glass In-Reply-To: <22E40633-19B8-447D-AFDC-D017BCBE3742@akamai.com> References: <22E40633-19B8-447D-AFDC-D017BCBE3742@akamai.com> Message-ID: On Wed, Sep 13, 2017 at 8:47 PM, Van Dyk, Donovan via NANOG wrote: > Hello, > > Has anyone else been seeing issues today from routes being learnt through > the Verizon network, AS 701? > > Does anyone know if they have a looking glass? I can’t find one. > > they peer with routeviews... so you might check there. there used to be a web frontend off www21.verizon.com that enabled a lookup in (what I believe was offline copies) 701 bgp data... that i can't find any longer though :( > Thanks > > -- > Donovan Van Dyk > SOC Network Engineer > Fort Lauderdale, FL USA > > [cid:image001.png at 01D32CD1.73DBD490] > The information contained in this electronic mail transmission and its > attachments may be privileged and confidential and protected from > disclosure. If the reader of this message is not the intended recipient (or > an individual responsible for delivery of the message to such person), you > are strictly prohibited from copying, disseminating or distributing this > communication. If you have received this communication in error, please > notify the sender immediately and destroy all electronic, paper or other > versions. > > From sean at donelan.com Thu Sep 14 03:58:41 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 13 Sep 2017 23:58:41 -0400 (EDT) Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: Disclosure note: AT&T and Comcast public relations folks have been sending information about what they are doing for disaster recovery. I've included some of their information. >From various official sources (FEMA, Dept. of Energy, FCC, NOAA, etc). Fatalities (FEMA) Georgia: 2 Florida: 12 South Carolina: 2 Puerto Rico: 3 U.S. Virgin Islands: 4 Note: FEMA is slower than media reports about U.S. fatalities Non-US fatalities (AP/Reuters) Caribbean fatalities: Anguilla (4), Barbuda (1), British Virgin Islands (5), Cuba (10), French Territories (10), St. Maarten (4), Haiti (1) Electric Power (DOE) Florida: 3,568,499 customer outages (35% of total state customers) Georgia: 451,033 customer outages (11% of total state customers) South Carolina: 58,972 customer outages (2% of total state customers) North Carolina: 24,445 customer outages (<1% of total state customers) Puerto Rico: 117,244 customers (8% of total customers) U.S. Virgin Islands: The airport and hospital are still energized. Besides a few smaller areas, most customers on St. John and St. Thomas are without power. Restoration efforts will continue as USVI WAPA works to get critical facilities reenergized on the two islands. Water (FEMA) U.S. Virgin Islands: 341,000 people without potable water Puerto Rico: 61,980 people without potable water Public Safety Hospitals (FEMA) Florida: 11 closed, 204 healthcare facilities evacuated Puerto Rico: 1 closed, 6 on generator power U.S. VI: 1 closed and evacuated NOAA Weather Radio (NOAA) Florida: 6 out of 32 stations (18%) out of service Georgia: 7 out of 29 stations (24%) out of service U.S. VI: 1 out of 1 station (100%) out of service Public Safety Answering Points (9-1-1 centers) (FCC) Florida: 29 impacted (4 out of service, 9 partial service, 7 re-routed with ALI, 8 re-routed without ALI) Georgia: 5 impacted (1 re-routed with ALI, 3 re-routed without ALI) U.S. VI: 2 impacted, without ALI/ANI Cable and Wireline systems (FCC) 1,040 switching centers (cable headends and central offices) out of service. Unknown how many are isolated, damaged or just without power. 8,190,407 subscribers out of service in Alabama, Florida and Georgia; not including Puerto Rico and U.S. Virgin Islands. According to Comcast: All comcast's miami-dade and broward facilities are on generator power. Comcast is deploy portable generators in neighborhoods to re-charge outside plant. Comcast has no network access beyond Marthon in the Florida Keys, but has crews ready when the area is accessible. Wireless Service (FCC) Alabama: less 1% cell sites out of service Florida: 18.1% cell sites out of service (3 counties over 50% OOS) Georgia: 5.3% cell sites out of service Puerto Rico: 10.1% cell sites out of service U.S. VI: 55% cell sites out of service (St. John - 9 out of 10 OOS, St. Thomas 38 out of 57 OOS) According to AT&T: deployed 6 portable, satellite connected cell on trucks in the Florida Keys (Stock Island, Key West and Marathon and 2 satellite connected cell on trucks in Naples, Florida. The AT&T National Disaster Recovery Team has over 20 units deployed throughout Florida (don't know what that means, but sounded good). Broadcast (FCC) Television: 10 stations out of service Radio: 39 stations out of service From mark.tinka at seacom.mu Thu Sep 14 13:12:59 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 14 Sep 2017 15:12:59 +0200 Subject: SAFNOG-3: Conference Report Message-ID: Hello all. With the SAFNOG-3 event - recently held in Durban, South Africa - just concluded, the SAFNOG-3 MC (Management Committee) would like to extend its gratitude and appreciation to all the delegates, speakers, sponsors, partners and iWeek, for your support in producing yet another successful SAFNOG conference. SAFNOG-3 recorded 172 registered participants, with 160 shows in Durban. Furthermore, we attracted 1,009 unique views via the live stream throughout the 2-day conference. Each of the presentations that were given during the meeting are now available online to download at: http://www.safnog.org/#section-agenda Videos of each of the presentations are catalogued and available on the SAFNOG Youtube channel at: https://www.youtube.com/channel/UCLRItGb8Y2HXIu_EUdp3Sag/playlists High-resolution photographs of both conference days as well as the exhibition room, closing social dinner and whisky BoF are also all available at: http://www.safnog.org/ For those who attended the meeting (remotely or in-person), we welcome your feedback to help us understand what worked, what didn't, what you'd like to see for the next meeting(s), and how we can improve. Kindly spend some time completing the online survey for this at: https://www.surveymonkey.com/r/G2QGX5D SAFNOG now moves back into its normal schedule of April, with the upcoming SAFNOG-4 meeting. Details about this event will be shared on our mailing list and with the wider community in the coming weeks. We look forward to seeing you all (again) in April, 2018. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From colin at spakka.net Fri Sep 1 10:52:01 2017 From: colin at spakka.net (Colin Petrie) Date: Fri, 1 Sep 2017 12:52:01 +0200 Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) In-Reply-To: <20170831200649.GP29058@Vurt.local> References: <20170831200649.GP29058@Vurt.local> Message-ID: <3a048fd3-b4cf-e85f-c2ff-598a9d556545@spakka.net> On 31/08/17 22:06, Job Snijders wrote:> I strongly recommend to turn off those BGP optimizers, glue the ports > shut, burn the hardware, and salt the grounds on which the BGP optimizer > sales people walked. Yes. > p.s. providing a publicly available BGP looking glasses will contribute > to proving your innocence in cases like these. Since in many cases the > AS_PATH is a complete fabrication, we need to manually check every AS in > the AS_PATH to see whether the AS carries the fake more-specific. A > public looking glass speeds up this fault-finding process. If you don't > want to host a webinterface yourself, please consider sending a BGP feed > to the Route Views Project or RIPE RIS, or for something queryable in a > real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ As a RIPE RIS operator, we regularly get people complaining 'oh but we are not advertising that prefix, your system must be broken'. Usually it is one of these BGP-optimizer more-specifics leaking out. Cheers, Colin From mir at ripe.net Fri Sep 1 12:23:23 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 1 Sep 2017 14:23:23 +0200 Subject: Join RIPE NCC Hackathon Version 6, 4-5 November, Copenhagen, Denmark In-Reply-To: References: Message-ID: <0cccdcf5-3281-e161-3072-d6f4fcfb9989@ripe.net> Dear colleagues, The sixth RIPE NCC hackathon will take place on Saturday and Sunday, 4-5 November 2017 in Copenhagen, Denmark. The topic is: IPv6! We're looking for creative thinkers: front-end developers, UI designers, network operators, researchers, hackers and other enthusiastic coders, to help us develop new tools that would enable deployment of IPv6 and visualizations based on IPv6 measurements data. All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://atlas.ripe.net/hackathon/version6/#!application-form *The application deadline is 9 September.* We look forward to seeing you there! Find out more in this RIPE Labs article: https://labs.ripe.net/Members/becha/join-the-ripe-ncc-hackathon-version-6 Regards, Vesna Manojlovic & Mirjam Kuhne Community Building RIPE NCC From support at diua.org Fri Sep 1 20:43:56 2017 From: support at diua.org (Jacob Kukuk) Date: Fri, 1 Sep 2017 20:43:56 +0000 Subject: Management softwares Message-ID: Splynx is what weuse, it handles billing customer service, provisioning, ect. https://splynx.com On Sep 1, 2017 11:42 AM, "Jameson, Daniel" wrote: Give this a look; the webpage doesn't do it justice. It Doesn't do billing/invoicing, but does everything else on your list. http://www.crestpt.com/fme-platforms.html -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K MEKKAOUI Sent: Friday, September 01, 2017 12:56 AM To: nanog at nanog.org Subject: Management softwares Hi We are a medium ISP. We are looking for Management software solutions. We are interested in finding a solution for billing, invoicing, scheduling, ticketing, provisioning and monitoring, Any suggestions or recommendations will be appreciated? We have been using multiple systems which do not communicate. Our objective is to use a single system or at least reduce the number of systems. Thank you KARIM M. From jared at puck.nether.net Sat Sep 2 01:11:42 2017 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 1 Sep 2017 21:11:42 -0400 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: Pretty much. Here is an example of permitting requirements for underground. Underground costs 5-12/foot (or more in urban areas) whereas aerial can be as low as $2/foot. -------------- next part -------------- Jared Mauch > On Sep 1, 2017, at 6:38 PM, Ricky Beam wrote: > >> On Fri, 01 Sep 2017 15:52:40 -0400, Rod Beck wrote: >> I don't think there is virtually any aerial in Europe. So given the cost difference why is virtually all fiber buried on this side of the Atlantic? > > Aerial is simple and fast... pull the cable through a stringer, move to the next pole and repeat; when a section (about a mile) is done, it's hoisted into the air and tied to the pole. The stringers are then moved to the next mile of poles and the process repeats. > > Buried stuff requires a great deal of planning, permitting, and insurance. You have to know everything that's ever been stuffed in the ground within half a mile of where you're working to avoid the inevitable cutting of something important -- gas, water, sewer, power, other telcom, even vacuum tube lines and subways. And then you need trenching gear to get stuff in the ground, and crews to come along behind to remediate the "environmental damage". > > (Once the conduit is in the ground, it's a trivial matter to blow whatever you need through it.) From jerry at jtcloe.net Sat Sep 2 02:15:52 2017 From: jerry at jtcloe.net (=?utf-8?Q?Jerry_Cloe?=) Date: Fri, 1 Sep 2017 21:15:52 -0500 Subject: Northeast TWC/Spectrum contact? In-Reply-To: References: Message-ID: I doubt you're going to get a reply, but I will add this. Signal levels in that range are undoubtedly a local issue. Its either your drop, one of your splitters, or the tap on the pole. First thing I'd do is check with a neighbor thats on the same run and see what they say. That will pretty much confirm its something very local to you. Nex thing I'd do (if you're just refusing to call the cable company) is plug your modem straight into the ground block. That would eliminate your house wiring and your splitters.   If those signals were the same across the city, for all purposes, they are down. Almost everything is two-way, tv, phone, and of course 'net. There's no way they have a wide outage and don't know it. Customers may be soft on calling some issues, but that many, not a chance.   -----Original message----- From:Edwin Pers Sent:Fri 09-01-2017 03:55 pm Subject:Northeast TWC/Spectrum contact? To:nanog at nanog.org; Hi Can someone from TWC/Spectrum’s northeast division please contact me off list? AS11351 for what it’s worth About a week ago my modem dropped from 24 bonded channels at about -6dBmV to 19 channels ranging from -9.30 to -21.30dBmV, and I started seeing very high latency and packetloss. I’ve also been seeing a lot of Lost MDD’s and RCS Partial’s in my event log. Haven’t put a tdr down the customer side cabling yet but I doubt that’s the issue, it’s only a 25’ run and a visual inspection doesn’t show anything out of the ordinary. Sorry for spamming the list, but every time I’ve called TWC customer support lines in the past I’ve been transferred between 5-8 people who each told me to reboot my modem and check the cables. Thanks for your time, Ed Pers From alan.buxey at gmail.com Sat Sep 2 10:22:47 2017 From: alan.buxey at gmail.com (Alan Buxey) Date: Sat, 2 Sep 2017 11:22:47 +0100 Subject: Moving fibre trunks: interruptions? In-Reply-To: References: <4766ce45-da0f-63a8-9388-266fe2288975@vaxination.ca> Message-ID: i'm sure theres plenty of aerial in europe. usually carried on e.g. the top messenger cable on pylons - given i've attended talks about the issues of fixing such fibre after storms in Scotland.... :) On 1 September 2017 at 20:52, Rod Beck wrote: > I don't think there is virtually any aerial in Europe. So given the cost difference why is virtually all fiber buried on this side of the Atlantic? > > > ________________________________ > From: NANOG on behalf of Jared Mauch > Sent: Friday, September 1, 2017 9:37 PM > To: Michael Loftis > Cc: Nanog at nanog.org > Subject: Re: Moving fibre trunks: interruptions? > > > >> On Sep 1, 2017, at 3:32 PM, Michael Loftis wrote: >> >> If it is in the railroad RoW they may be restricted to daylight working >> only. Check with your provider or OSP crew. >> > > > Yup. Railroad work is complex just because you have to coordinate with the railroad owner and they have to be onsite for all work. The cost of going underground vs aerial is also astronomical in many cases. > > - Jared From jiri at cdn77.com Wed Sep 6 07:17:39 2017 From: jiri at cdn77.com (Jiri Prochazka) Date: Wed, 6 Sep 2017 09:17:39 +0200 Subject: 100G QSFP28 DAC cables - experience Message-ID: Hi folks, I'm wondering if anyone have (either positive or negative) experience with 100G QSFP28 DAC cables? Is there anyone who is using 100G DAC in large scale and would recommend it (which means there are no issues compared to SR4 links)? I'm thinking about cables with lenght up to 1m, not more. We have had quite bad experience with 10G DAC in the past - but I do not want to be slave of the past. Thank you for your thoughts! Jiri From robert at timetraveller.org Thu Sep 7 04:18:50 2017 From: robert at timetraveller.org (Robert Brockway) Date: Thu, 7 Sep 2017 14:18:50 +1000 (AEST) Subject: 2017 NANOG Elections General Information In-Reply-To: References: Message-ID: On Tue, 5 Sep 2017, Dave Temkin wrote: > Hi NANOG Community, > > Nominations are rapidly coming to a close - September 8th is the last day > to submit nominees. > > Unfortunately, to follow up on my paragraph about diversity: So far, every > single candidate that has completed the nomination process is a white male. What you're describing is a very coarse form of diversity based on physical characteristics. A white man who has lived his entire life as a peasant in Ukraine may well have a very different outlook and life experience to a white man who grew up in Australia. These two white men could bring quite diverse viewpoints to any situation even though they share some superficial characteristics. I have always supported the most suitable candidates for any role, irrespective of their physical characteristics. I will always continue to do so. Rob From mehmet at akcin.net Sun Sep 10 19:04:00 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 10 Sep 2017 19:04:00 +0000 Subject: Hurricane Irma: U.S. Virgin Islands and Puerto Rico In-Reply-To: References: Message-ID: I have talked(briefly sms/fb) to several friends of mine who operate critical datacenter infrastructure. What is not shot down mostlly on diesel generators but actual impact if power isnt restored in next 5-7 days is yet to come. USVI and Puerto Rico will get the restoration it needs in critical infrastrucure, no doubt I am more concerned about othet caribbean who were impacted. Having lived in Caribbean for years and been on many islands, i can only imagine recovery Of services on smaller islands taking long time. There is an effort by Martin hannigan announced on twitter and a coordination call. Martin is active member of NANOG, Martin how can we support/join this great initivative? On Sat, Sep 9, 2017 at 7:03 PM Sean Donelan wrote: > > 5 fatalities in U.S. Virgin Islands and Puerto Rico > > FCC doesn't have reliable reporting on Wireline and Cable service > providers in either USVI or Puerto Rico. The assumption is large numbers > of customers are without cable or wireline service. > > 870,000 customers (55% of the island) without power in Puerto Rico > > 22,900 customers without power U.S. Vigin Islands > > 1 hospital closed, 25 hospitals on backup generators > > 29.3% of cell sites in Puerto Rico and 60.7% of cell sites in the U.S. > Virgin Islands are out of service. > > 1 radio station and 2 TV stations in USVI are out of service > > 4 radio stations in Puerto Rico are out of service > From andrew at thekerrs.ca Tue Sep 12 00:11:38 2017 From: andrew at thekerrs.ca (Andrew Kerr) Date: Tue, 12 Sep 2017 00:11:38 +0000 Subject: Internet access for security consultants - pen tests, attack traffic, bulk e-mail, etc. In-Reply-To: References: <002c01d32b4e$fb9b9fc0$f2d2df40$@gmail.com> Message-ID: I work for a MSSP (Managed Security Services Provider) that provides some of these services including vulnerability scanning and such. If it's a legitimate provider doing work for customers, you should never get a complaint about their activities. Before we do any kind of scan, we have a contract in place with the customer and include the IP(s) we'll be scanning from and the range of IPs we'll be scanning (assuming this is an external scan). If they're not getting permission from customers first, they are almost certainly breaking laws by scanning systems they don't have permission to, and I wouldn't host them. Assuming you have a legal department, just make sure that you put something that says this type of activity will only be permitted when the target has agreed to the scan in advance. If you get some complaints, investigate, and if they're breaking the contract, turf them. On Mon, 11 Sep 2017 at 16:01 james machado wrote: > On Mon, Sep 11, 2017 at 3:40 PM, Sean Pedersen > wrote: > > > We were recently approached by a company that does security consulting. > > Some > > of the functions they perform include discovery scans, penetration > testing, > > bulk e-mail generation (phishing, malware, etc.), hosting fake botnets - > > basically, they'd be generating a lot of bad network traffic. Targeted at > > specific clients/customers, but still bad. As an ISP, this is new > territory > > for us and there are some concerns about potential impact, abuse reports, > > reputation, authorization to perform such tests, etc. > > > > > > > > Does anyone have experience in this area that would be willing to offer > > advice? > > > > > > From a customer point of view: > > We have written agreements with our vendors on who they can and can not > send this traffic from, where exactly it is coming from and what type of > traffic it will be. One reason our vendor does this is to not get on black > hole/spam lists or to cause their ISP issues, as well as having proof that > they are allowed to send specific traffic to specific addresses for a > specific time period. The test managers then know what to expect and to > head off abuse notifications after detection of the specific traffic. We, > also, use this traffic to test other vendors we might have and only after > detection we will have white lists or black lists put in place as > warranted. > > I would expect the company in question to be able to provide documentation > that could track any specific traffic back to an engagement that has the > approval of their customer. If they have been around for a bit they should > have a track record and may have current IP space that could be vetted to > see what condition it is in. Are they leaving it or adding too it. If > they are leaving their current space then find out why. > > James > From matthew.smee at sydney.edu.au Wed Sep 13 01:27:36 2017 From: matthew.smee at sydney.edu.au (Matthew Smee) Date: Wed, 13 Sep 2017 01:27:36 +0000 Subject: Protocol 17 floods from Vietnam & Mexico? In-Reply-To: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> References: <1bf07b56-f71c-1fec-bfd2-386a67c2b138@gmx.com> Message-ID: Protocol 17 likely refers to UDP. https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Large Hadron Collider Sent: Wednesday, 13 September 2017 11:08 AM To: nanog at nanog.org Subject: Protocol 17 floods from Vietnam & Mexico? 18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx > umbrellix.net: ip-proto-17 18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx > umbrellix.net: ip-proto-17 18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, bad length 65500 > 1464 18:04:32.391145 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391152 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391158 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391164 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391170 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391176 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391182 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391188 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391194 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391199 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391205 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391211 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391217 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391223 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391229 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391234 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391248 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391255 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391261 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391266 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391272 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391278 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391284 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391289 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391295 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391313 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391319 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391325 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391331 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391336 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391342 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391348 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391354 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391367 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391374 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391379 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391385 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391391 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391396 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391402 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391408 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391414 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391420 IP 115.75.50.106 > umbrellix.net: ip-proto-17 18:04:32.391426 IP 115.75.50.106 > umbrellix.net: ip-proto-17 Some stupidity has me wondering... protocol 17? Huh? Is this some attempt to exploit me while at the same time flooding me at over 800Mbit/s? Needless to say, I've shut my computer down to avoid going over my data allowance. From lista-gter at tbonet.net.br Wed Sep 13 11:25:13 2017 From: lista-gter at tbonet.net.br (=?UTF-8?Q?Jo=c3=a3o_Butzke?=) Date: Wed, 13 Sep 2017 08:25:13 -0300 Subject: Getting an RADB entry removed that was added by a previous peer In-Reply-To: <17b2db517ab5409699ddb5b8cfed72a0@ox.com> References: <17b2db517ab5409699ddb5b8cfed72a0@ox.com> Message-ID: <628aa7ee-aeca-5732-be01-07a97bcc1ce2@tbonet.net.br> You tried the contact on the whois database? route:      129.77.0.0/16 descr:      NYC-OTA LIMITED PARTNERSHIP-AS14607 (added by MAINT-AS6517) origin:     AS6517 remarks:    ------------------------------------------------- remarks:    - This route object was registered by           - remarks:    - Reliance Globalcom Services, Inc  MAINT-AS6517 - remarks:    - on behalf of their customer:                  - remarks:    - NYC-OTA LIMITED PARTNERSHIP-AS14607 NYC       - remarks:    ------------------------------------------------- notify: *noc at relianceglobalcom.com* mnt-by:     MAINT-AS6517 changed: *jkim at relianceglobalcom.com* 20091117 source:     RADB Best Regards, João Butzke. Em 13/09/2017 08:05, Matthew Huff escreveu: > It appears that Reliance Globalcom (AS6157) added an RADB entry for our prefix (129.77.0.0/16) when we were a peer of theirs years ago, and it was never removed when we ended the relationship. We are ASN 14607. > > I've reached out to their support, but does anyone have a suggestion on how I could get this cleaned up if they don't respond? From fredrik.sallinen at gmail.com Wed Sep 13 12:08:39 2017 From: fredrik.sallinen at gmail.com (Fredrik Sallinen) Date: Wed, 13 Sep 2017 16:38:39 +0430 Subject: IPv6 migration steps for mid-scale isp Message-ID: Hello, Recently we have decided to start IPv6 migration in our network. We have ~1K BNGs and connecting our customers to network using PPPoE. I'd be interested in hearing from the technical community about their experiences and recommendations on this process. I'm wondering: Shall I go for IPv6-only deployment or dual stack? Where to start with IPv6? (core, edge or ...) What are the best practices for ISPs? What are the costs and return on investment? How to identify address CPE and legacy application issues? Fredrik From tievens at cisco.com Thu Sep 14 03:17:14 2017 From: tievens at cisco.com (Tim Evens (tievens)) Date: Thu, 14 Sep 2017 03:17:14 +0000 Subject: Verizon issues | Looking glass In-Reply-To: <22E40633-19B8-447D-AFDC-D017BCBE3742@akamai.com> References: <22E40633-19B8-447D-AFDC-D017BCBE3742@akamai.com> Message-ID: <1B017CD2-A98A-4784-909F-2762C4760CBF@cisco.com> Attached shows the history for Verizon from all routeviews routers/collectors from 9/11 00:00:00 till 9/14 03:10 UTC. You can see this at: http://demo-rv.snas.io:3000/dashboard/db/top-asns?orgId=2&var-asn_num=701&from=1505174400000&to=1505358900971 Grafana is for stats/analysis of the data. You can use http://demo-rv.snas.io:8000/#/looking-glass to browse the current RIB as well as history of RIB's. The login is demo/snas. --Tim On 9/13/17, 5:48 PM, "NANOG on behalf of Van Dyk, Donovan via NANOG" wrote: Hello, Has anyone else been seeing issues today from routes being learnt through the Verizon network, AS 701? Does anyone know if they have a looking glass? I can’t find one. Thanks -- Donovan Van Dyk SOC Network Engineer Fort Lauderdale, FL USA [cid:image001.png at 01D32CD1.73DBD490] The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. From hugo at slabnet.com Thu Sep 14 16:54:31 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 14 Sep 2017 09:54:31 -0700 Subject: 100G QSFP28 DAC cables - experience In-Reply-To: References: Message-ID: <20170914165431.GA27042@bamboo.slabnet.com> On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka wrote: >Hi folks, > >I'm wondering if anyone have (either positive or negative) experience >with 100G QSFP28 DAC cables? > >Is there anyone who is using 100G DAC in large scale and would >recommend it (which means there are no issues compared to SR4 links)? > >I'm thinking about cables with lenght up to 1m, not more. > >We have had quite bad experience with 10G DAC in the past - but I do >not want to be slave of the past. > >Thank you for your thoughts! > >Jiri We're deploying a decent chunk of 100G QSFP28 at the moment, but it's a mix of: - a handful of 100G QSFP28 copper DACs for some switch peerlinks - a bit >100x 100G QSFP28 AOC for interswitch links - a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts We're only a few weeks in at this point, so mileage may vary in the long run etc. The copper peerlinks are mostly 1M with some 3M. We've had no issues with them so far. The AOC interswitch links vary more in length, but some of those are >10M (hence AOC rather than copper). We've faced no issues with those. Granted, there is BGP with BFD running across those, so those should help in terms of liveness checks and such. I mention that because where we _have_ had issues are on the 100G -> 4x25G copper breakouts. Those are for 25G edge connectivity. It's a decent sample size with a bit north of 600x 25G ports. The trouble we've had there have been with some links showing link up on the switch and server side but actually failing to pass any traffic, so we need to stuff some >L1 liveness checks on there to ensure those links are good while we sort out the root issue. It is not yet clear if this is a cable fault, driver issue, or something firmware-ish on the NICs. Also, fun fact: 25G only made its way into the 802.3ad bonding mode driver in the Linux kernel in March this year[1]. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19ddde1eeca1ee81f4add5e04da66055e09281ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From swmike at swm.pp.se Thu Sep 14 17:05:24 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 14 Sep 2017 19:05:24 +0200 (CEST) Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: On Wed, 13 Sep 2017, Fredrik Sallinen wrote: > Hello, > > Recently we have decided to start IPv6 migration in our network. We > have ~1K BNGs and connecting our customers to network using PPPoE. > I'd be interested in hearing from the technical community about their > experiences and recommendations on this process. I'm wondering: > > Shall I go for IPv6-only deployment or dual stack? For PPPoE with existing IPv4, go dual stack. > Where to start with IPv6? (core, edge or ...) Core, peering, work outwards towards end users. > What are the best practices for ISPs? > What are the costs and return on investment? > How to identify address CPE and legacy application issues? There is a lot written and presented about IPv6 deployment. People have been doing this in volume since around 2010, and if you search for IPv6 deployment experience you'll find lots of presentations. Some I found that seem relevant: https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson-pierantozzi-level3-ipv6.pdf https://www.ietf.org/proceedings/54/slides/plenary-15.pdf https://www.apnic.net/community/ipv6-program/ipv6-stories/ https://www.ipv6council.be/experiences-de-deploiements-ipv6/ If you prefer video form, there are lots of presentations from conferences, available on youtube as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From dave at temk.in Thu Sep 14 17:32:10 2017 From: dave at temk.in (Dave Temkin) Date: Thu, 14 Sep 2017 10:32:10 -0700 Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: Sean - I think I speak for all of us when I say thank you very much for these updates! The concise nature of them is super helpful. -Dave On Wed, Sep 13, 2017 at 8:58 PM, Sean Donelan wrote: > > Disclosure note: AT&T and Comcast public relations folks have been sending > information about what they are doing for disaster recovery. I've included > some of their information. > > > From various official sources (FEMA, Dept. of Energy, FCC, NOAA, etc). > > Fatalities (FEMA) > Georgia: 2 > Florida: 12 > South Carolina: 2 > Puerto Rico: 3 > U.S. Virgin Islands: 4 > Note: FEMA is slower than media reports about U.S. fatalities > > Non-US fatalities (AP/Reuters) > Caribbean fatalities: Anguilla (4), Barbuda (1), British Virgin > Islands (5), Cuba (10), French Territories (10), St. Maarten (4), > Haiti (1) > > Electric Power (DOE) > > Florida: 3,568,499 customer outages (35% of total state customers) > Georgia: 451,033 customer outages (11% of total state customers) > South Carolina: 58,972 customer outages (2% of total state customers) > North Carolina: 24,445 customer outages (<1% of total state customers) > Puerto Rico: 117,244 customers (8% of total customers) > U.S. Virgin Islands: > The airport and hospital are still energized. Besides a few smaller > areas, most customers on St. John and St. Thomas are without > power. Restoration efforts will continue as USVI WAPA works to get > critical facilities reenergized on the two islands. > > > Water (FEMA) > > U.S. Virgin Islands: 341,000 people without potable water > Puerto Rico: 61,980 people without potable water > > > Public Safety > Hospitals (FEMA) > Florida: 11 closed, 204 healthcare facilities evacuated > Puerto Rico: 1 closed, 6 on generator power > U.S. VI: 1 closed and evacuated > > NOAA Weather Radio (NOAA) > Florida: 6 out of 32 stations (18%) out of service > Georgia: 7 out of 29 stations (24%) out of service > U.S. VI: 1 out of 1 station (100%) out of service > > Public Safety Answering Points (9-1-1 centers) (FCC) > Florida: 29 impacted (4 out of service, 9 partial service, 7 > re-routed with ALI, 8 re-routed without ALI) > Georgia: 5 impacted (1 re-routed with ALI, 3 re-routed without ALI) > U.S. VI: 2 impacted, without ALI/ANI > > > Cable and Wireline systems (FCC) > > 1,040 switching centers (cable headends and central offices) out of > service. Unknown how many are isolated, damaged or just without power. > > 8,190,407 subscribers out of service in Alabama, Florida and Georgia; not > including Puerto Rico and U.S. Virgin Islands. > > According to Comcast: All comcast's miami-dade and broward facilities are > on generator power. Comcast is deploy portable generators in neighborhoods > to re-charge outside plant. Comcast has no network access beyond Marthon in > the Florida Keys, but has crews ready when the area is accessible. > > > > Wireless Service (FCC) > > Alabama: less 1% cell sites out of service > Florida: 18.1% cell sites out of service (3 counties over 50% OOS) > Georgia: 5.3% cell sites out of service > Puerto Rico: 10.1% cell sites out of service > U.S. VI: 55% cell sites out of service (St. John - 9 out of 10 OOS, > St. Thomas 38 out of 57 OOS) > > > According to AT&T: deployed 6 portable, satellite connected cell on trucks > in the Florida Keys (Stock Island, Key West and Marathon and 2 satellite > connected cell on trucks in Naples, Florida. The AT&T National Disaster > Recovery Team has over 20 units deployed throughout Florida (don't know > what that means, but sounded good). > > > > Broadcast (FCC) > > Television: 10 stations out of service > Radio: 39 stations out of service > > > > From tyler at tgconrad.com Thu Sep 14 18:12:29 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Thu, 14 Sep 2017 13:12:29 -0500 Subject: 100G QSFP28 DAC cables - experience In-Reply-To: <20170914165431.GA27042@bamboo.slabnet.com> References: <20170914165431.GA27042@bamboo.slabnet.com> Message-ID: We're using a mix as well, some QSFP28 AOC, others DAC. One thing that you need to keep in mind about the DACs is going to be the bend radius. These things are girthy af, so make sure to either overestimate your runs slightly, or buy one to test first. On Thu, Sep 14, 2017 at 11:54 AM, Hugo Slabbert wrote: > > On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka wrote: > > Hi folks, >> >> I'm wondering if anyone have (either positive or negative) experience >> with 100G QSFP28 DAC cables? >> >> Is there anyone who is using 100G DAC in large scale and would recommend >> it (which means there are no issues compared to SR4 links)? >> >> I'm thinking about cables with lenght up to 1m, not more. >> >> We have had quite bad experience with 10G DAC in the past - but I do not >> want to be slave of the past. >> >> Thank you for your thoughts! >> >> Jiri >> > > We're deploying a decent chunk of 100G QSFP28 at the moment, but it's a > mix of: > > - a handful of 100G QSFP28 copper DACs for some switch peerlinks > - a bit >100x 100G QSFP28 AOC for interswitch links > - a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts > > We're only a few weeks in at this point, so mileage may vary in the long > run etc. > > The copper peerlinks are mostly 1M with some 3M. We've had no issues with > them so far. > > The AOC interswitch links vary more in length, but some of those are >10M > (hence AOC rather than copper). We've faced no issues with those. > Granted, there is BGP with BFD running across those, so those should help > in terms of liveness checks and such. > > I mention that because where we _have_ had issues are on the 100G -> 4x25G > copper breakouts. Those are for 25G edge connectivity. It's a decent > sample size with a bit north of 600x 25G ports. The trouble we've had > there have been with some links showing link up on the switch and server > side but actually failing to pass any traffic, so we need to stuff some >L1 > liveness checks on there to ensure those links are good while we sort out > the root issue. It is not yet clear if this is a cable fault, driver > issue, or something firmware-ish on the NICs. > > Also, fun fact: 25G only made its way into the 802.3ad bonding mode driver > in the Linux kernel in March this year[1]. > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/ > linux.git/commit/?id=19ddde1eeca1ee81f4add5e04da66055e09281ac > From branto at argentiumsolutions.com Thu Sep 14 20:04:41 2017 From: branto at argentiumsolutions.com (Brant Ian Stevens) Date: Thu, 14 Sep 2017 16:04:41 -0400 Subject: 100G QSFP28 DAC cables - experience In-Reply-To: References: <20170914165431.GA27042@bamboo.slabnet.com> Message-ID: <59BAE0D9.6090201@argentiumsolutions.com> +1 on this... I'd go so far as to say skip the copper, and just go with active-optical for short-run interconnects. > Tyler Conrad > September 14, 2017 at 2:12 PM > We're using a mix as well, some QSFP28 AOC, others DAC. One thing that you > need to keep in mind about the DACs is going to be the bend radius. These > things are girthy af, so make sure to either overestimate your runs > slightly, or buy one to test first. > > Hugo Slabbert > September 14, 2017 at 12:54 PM > > On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka wrote: > > > We're deploying a decent chunk of 100G QSFP28 at the moment, but it's > a mix of: > > - a handful of 100G QSFP28 copper DACs for some switch peerlinks > - a bit >100x 100G QSFP28 AOC for interswitch links > - a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts > > We're only a few weeks in at this point, so mileage may vary in the > long run etc. > > The copper peerlinks are mostly 1M with some 3M. We've had no issues > with them so far. > > The AOC interswitch links vary more in length, but some of those are > >10M (hence AOC rather than copper). We've faced no issues with > those. Granted, there is BGP with BFD running across those, so those > should help in terms of liveness checks and such. > > I mention that because where we _have_ had issues are on the 100G -> > 4x25G copper breakouts. Those are for 25G edge connectivity. It's a > decent sample size with a bit north of 600x 25G ports. The trouble > we've had there have been with some links showing link up on the > switch and server side but actually failing to pass any traffic, so we > need to stuff some >L1 liveness checks on there to ensure those links > are good while we sort out the root issue. It is not yet clear if > this is a cable fault, driver issue, or something firmware-ish on the > NICs. > > Also, fun fact: 25G only made its way into the 802.3ad bonding mode > driver in the Linux kernel in March this year[1]. > > Jiri Prochazka > September 6, 2017 at 3:17 AM > Hi folks, > > I'm wondering if anyone have (either positive or negative) experience > with 100G QSFP28 DAC cables? > > Is there anyone who is using 100G DAC in large scale and would > recommend it (which means there are no issues compared to SR4 links)? > > I'm thinking about cables with lenght up to 1m, not more. > > We have had quite bad experience with 10G DAC in the past - but I do > not want to be slave of the past. > > > > > Thank you for your thoughts! > > > > Jiri > -- -- Regards, -- Brant I. Stevens, Principal & Consulting Architect branto at argentiumsolutions.com d:212.931.8566, x101. m:917.673.6536. f:917.525.4759. http://argentiumsolutions.com From Daniel.Jameson at tdstelecom.com Thu Sep 14 20:29:25 2017 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Thu, 14 Sep 2017 20:29:25 +0000 Subject: 100G QSFP28 DAC cables - experience In-Reply-To: <59BAE0D9.6090201@argentiumsolutions.com> References: <20170914165431.GA27042@bamboo.slabnet.com> <59BAE0D9.6090201@argentiumsolutions.com> Message-ID: They're pretty fragile assemblies too, I ruined about 30 of them lacing them in, they need fish-paper around each cable so you don't crush the conductors when lacing. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brant Ian Stevens Sent: Thursday, September 14, 2017 2:05 PM To: Tyler Conrad Cc: NANOG Subject: Re: 100G QSFP28 DAC cables - experience +1 on this... I'd go so far as to say skip the copper, and just go with active-optical for short-run interconnects. > Tyler Conrad > September 14, 2017 at 2:12 PM > We're using a mix as well, some QSFP28 AOC, others DAC. One thing that you > need to keep in mind about the DACs is going to be the bend radius. These > things are girthy af, so make sure to either overestimate your runs > slightly, or buy one to test first. > > Hugo Slabbert > September 14, 2017 at 12:54 PM > > On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka wrote: > > > We're deploying a decent chunk of 100G QSFP28 at the moment, but it's > a mix of: > > - a handful of 100G QSFP28 copper DACs for some switch peerlinks > - a bit >100x 100G QSFP28 AOC for interswitch links > - a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts > > We're only a few weeks in at this point, so mileage may vary in the > long run etc. > > The copper peerlinks are mostly 1M with some 3M. We've had no issues > with them so far. > > The AOC interswitch links vary more in length, but some of those are > >10M (hence AOC rather than copper). We've faced no issues with > those. Granted, there is BGP with BFD running across those, so those > should help in terms of liveness checks and such. > > I mention that because where we _have_ had issues are on the 100G -> > 4x25G copper breakouts. Those are for 25G edge connectivity. It's a > decent sample size with a bit north of 600x 25G ports. The trouble > we've had there have been with some links showing link up on the > switch and server side but actually failing to pass any traffic, so we > need to stuff some >L1 liveness checks on there to ensure those links > are good while we sort out the root issue. It is not yet clear if > this is a cable fault, driver issue, or something firmware-ish on the > NICs. > > Also, fun fact: 25G only made its way into the 802.3ad bonding mode > driver in the Linux kernel in March this year[1]. > > Jiri Prochazka > September 6, 2017 at 3:17 AM > Hi folks, > > I'm wondering if anyone have (either positive or negative) experience > with 100G QSFP28 DAC cables? > > Is there anyone who is using 100G DAC in large scale and would > recommend it (which means there are no issues compared to SR4 links)? > > I'm thinking about cables with lenght up to 1m, not more. > > We have had quite bad experience with 10G DAC in the past - but I do > not want to be slave of the past. > > > > > Thank you for your thoughts! > > > > Jiri > -- -- Regards, -- Brant I. Stevens, Principal & Consulting Architect branto at argentiumsolutions.com d:212.931.8566, x101. m:917.673.6536. f:917.525.4759. http://argentiumsolutions.com From SNaslund at medline.com Thu Sep 14 20:37:12 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 14 Sep 2017 20:37:12 +0000 Subject: 100G QSFP28 DAC cables - experience In-Reply-To: References: <20170914165431.GA27042@bamboo.slabnet.com> <59BAE0D9.6090201@argentiumsolutions.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402545D2275@MUNPRDMBXA1.medline.com> +1 on skipping the copper and going all optical. In my experience, the fiber is much less likely to have strange faults. We also experienced copper links that did not perform well but were showing up. It seems the optical modules are much more mature in terms of going offline properly if the signals are not within the parameters. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jameson, Daniel Sent: Thursday, September 14, 2017 3:29 PM To: Brant Ian Stevens; Tyler Conrad Cc: NANOG Subject: RE: 100G QSFP28 DAC cables - experience They're pretty fragile assemblies too, I ruined about 30 of them lacing them in, they need fish-paper around each cable so you don't crush the conductors when lacing. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brant Ian Stevens Sent: Thursday, September 14, 2017 2:05 PM To: Tyler Conrad Cc: NANOG Subject: Re: 100G QSFP28 DAC cables - experience +1 on this... I'd go so far as to say skip the copper, and just go with active-optical for short-run interconnects. > Tyler Conrad > September 14, 2017 at 2:12 PM > We're using a mix as well, some QSFP28 AOC, others DAC. One thing that you > need to keep in mind about the DACs is going to be the bend radius. These > things are girthy af, so make sure to either overestimate your runs > slightly, or buy one to test first. > > Hugo Slabbert > September 14, 2017 at 12:54 PM > > On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka wrote: > > > We're deploying a decent chunk of 100G QSFP28 at the moment, but it's > a mix of: > > - a handful of 100G QSFP28 copper DACs for some switch peerlinks > - a bit >100x 100G QSFP28 AOC for interswitch links > - a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts > > We're only a few weeks in at this point, so mileage may vary in the > long run etc. > > The copper peerlinks are mostly 1M with some 3M. We've had no issues > with them so far. > > The AOC interswitch links vary more in length, but some of those are > >10M (hence AOC rather than copper). We've faced no issues with > those. Granted, there is BGP with BFD running across those, so those > should help in terms of liveness checks and such. > > I mention that because where we _have_ had issues are on the 100G -> > 4x25G copper breakouts. Those are for 25G edge connectivity. It's a > decent sample size with a bit north of 600x 25G ports. The trouble > we've had there have been with some links showing link up on the > switch and server side but actually failing to pass any traffic, so we > need to stuff some >L1 liveness checks on there to ensure those links > are good while we sort out the root issue. It is not yet clear if > this is a cable fault, driver issue, or something firmware-ish on the > NICs. > > Also, fun fact: 25G only made its way into the 802.3ad bonding mode > driver in the Linux kernel in March this year[1]. > > Jiri Prochazka > September 6, 2017 at 3:17 AM > Hi folks, > > I'm wondering if anyone have (either positive or negative) experience > with 100G QSFP28 DAC cables? > > Is there anyone who is using 100G DAC in large scale and would > recommend it (which means there are no issues compared to SR4 links)? > > I'm thinking about cables with lenght up to 1m, not more. > > We have had quite bad experience with 10G DAC in the past - but I do > not want to be slave of the past. > > > > > Thank you for your thoughts! > > > > Jiri > -- -- Regards, -- Brant I. Stevens, Principal & Consulting Architect branto at argentiumsolutions.com d:212.931.8566, x101. m:917.673.6536. f:917.525.4759. http://argentiumsolutions.com From sean at donelan.com Fri Sep 15 04:57:20 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 15 Sep 2017 00:57:20 -0400 (EDT) Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: In my last summary, I made a comment I didn't know what the network disaster recovery team meant. AT&T recovery efforts 3000 recovery team members 14 Satellite Cell on Light Truck (SatCOLT) - 1 in Tallahassee, 2 in Naples, 4 in Florida Keys - 1 portable cell site St. Thomas, U.S. Virgin Islands 3 Emergency Communications Vehicles 50 Drones Command trailers, hazardous materials response equipment Verizon recovery efforts 2 Satellite Picocels on Trailers (SPOTs) in the Florida Keys Refueling and generators at cell towers througout Florida Hundreds of portable generators 2 Wireless Emergency Communication Centers in Naples (provide charging stations, phones and computers for the public to contact family and friends) Sprint recovery efforts Sprint reports over 75% of its network is repaired in the southeast and Puerto Rico. AT&T, Sprint, T-Mobile, Verizon continue to extend their wireless data, text and voice plans waiving overage charges in the disaster areas. Details are different for each carrier, so check their web sites or customer service. Federal Aviation Administration recovery efforts Deployed emergency mobile air traffic control tower to the international airport on St. Thomas, U.S. Virgin Islands Drone authorizations 138 commercial drone operator authorizations for Hurricane Harvey 80 commercial drone operator authorizations for Hurricane Irma Federal Communicatiosn Commission recovery efforts Reports at least 8,258,789 cable and wireline subscribers out of service in Alabama, Florida and Georgia. Strangely, the number of non-mobile switching centers increased from 1,040 (Sept 13) to 2,188 (Sept 14). I believe this exceeds the number of cable headends and central offices in Florida. So I don't know what this number represents or why it increased so much. The situation is still dire in some locations, but generally the disaster operations have moved to recovery and restoration. Unless something significant happens, this is the last summary report about Hurricane Irma from me. From randy at psg.com Fri Sep 15 10:25:41 2017 From: randy at psg.com (Randy Bush) Date: Fri, 15 Sep 2017 19:25:41 +0900 Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: any word on cuba? randy From rcarpen at network1.net Fri Sep 15 14:40:43 2017 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 15 Sep 2017 10:40:43 -0400 (EDT) Subject: Verizon Wireless IPv6 deployment contact? Message-ID: <390401197.773702.1505486443047.JavaMail.zimbra@network1.net> Is there anyone from Verizon Wireless that I can talk to regarding IPv6 deployment? I am getting nonsensical answers from my local contacts. Please contact me off-list. thanks, -Randy From owen at delong.com Fri Sep 15 14:54:39 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Sep 2017 10:54:39 -0400 Subject: IPv6 Loopback/Point-to-Point address allocation In-Reply-To: <87EE9BDE-D101-4E3B-A608-411315D467DE@nvcube.net> References: <3979AE529B56AB47942E2423B707F16E64C27570@RTC-EXCH01.RESERVE.LDS> <59B51A48.6090305@nsc.liu.se> <2ACC7244-1A7B-4E3D-A931-B7347E593C3A@delong.com> <87EE9BDE-D101-4E3B-A608-411315D467DE@nvcube.net> Message-ID: > On Sep 15, 2017, at 6:02 AM, Nikolay Shopik wrote: > > > >> On 11 Sep 2017, at 21:55, Owen DeLong wrote: >> >> >>> On Sep 11, 2017, at 3:35 AM, Nikolay Shopik wrote: >>> >>> On 10/09/2017 14:25, Saku Ytti wrote: >>>> However I don't think market would generally appreciate the >>>> implications linklocal brings to traceroute, where least bad option >>>> would be just to originate hop-limit exceeded from loop0, with no >>>> visibility on actual interface. >>> >>> rfc5837 would help but it seems market universally ignore it for some reason unknown to me (lack of interest and IPv6 adoption?) >>> >>> We find LL is simpler, operation wise at some cases. >> >> >> How’s that work out for you on routers with the same MAC address on multiple interfaces when you’re trying to troubleshoot ECMP trace routes? >> >> Owen >> > > We dont have such cases where LL used but i belive rfc i mention is exactly solve that problem It _MIGHT_ help in some circumstances if it were ubiquitously or universally implemented, however, as you yourself noted, it is not. You were offering advice to someone without investigating the characteristics of his network. That advice could well have negative tradeoffs which you neglected to mention. I felt a duty to point them out. Owen From dovid at telecurve.com Fri Sep 15 15:25:10 2017 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 15 Sep 2017 11:25:10 -0400 Subject: Find carriers that peer in two IX's Message-ID: Hi, Does anyone know of a tool like PeeringDB where I can select two exchanges say TELX 60 Hudson and then SIX (Seattle IX) and find all carriers that have a presence in both locations? TIA. Dovid From job at instituut.net Fri Sep 15 15:40:04 2017 From: job at instituut.net (Job Snijders) Date: Fri, 15 Sep 2017 17:40:04 +0200 Subject: Find carriers that peer in two IX's In-Reply-To: References: Message-ID: <20170915154004.GH1118@Vurt.local> On Fri, Sep 15, 2017 at 11:25:10AM -0400, Dovid Bender wrote: > Does anyone know of a tool like PeeringDB where I can select two exchanges > say TELX 60 Hudson and then SIX (Seattle IX) and find all carriers that > have a presence in both locations? a bit hacky ;-) Vurt:~ job$ comm -1 -2 <(curl -s https://peeringdb.com/api/ixlan/13 | jq ".data | .[] | .net_set | .[] | .name" | sort) <(curl -s https://peeringdb.com/api/ixlan/325 | jq ".data | .[] | .net_set | .[] | .name" | sort) "Amazon.com" "Cloudflare" "Default Route, LLC" "Digital Realty | Telx" "Facebook" "Facebook" "Faction Inc." "Google Inc." "Highwinds Network Group, Inc" "Hurricane Electric" "IPTP Networks" "ISPrime, LLC." "Internap" "Internet2 TransitRail" "Limelight Networks Global" "Microsoft" "NTT DATA Services - HCLS Cloud" "Netflix" "Nitel" "OpenDNS, Inc." "Packet Clearing House AS42" "Packet Clearing House" "Sipartech" "SoftLayer Technologies, Inc. (an IBM Company)" "Verizon Digital Media Services (EdgeCast Networks)" "Wolfe" "Yahoo!" Vurt:~ job$ From sean at donelan.com Fri Sep 15 15:43:17 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 15 Sep 2017 11:43:17 -0400 (EDT) Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: On Fri, 15 Sep 2017, Randy Bush wrote: > any word on cuba? Cuba status: (United Nations, Office of the Resident Coordinator) 10 fatalities. The country has recovered 70% of its power service. The seven provinces most affected are being assisted by other territories. It is expected that full services could take up to a month to be restored. 62% of the 320 Wi-Fi areas affected have been restored. Cellular coverage remains and 43% of the service was recovered, even though there were 176 transmitters affected. 50% of telephone services (fixed lines, collective phones, public pay phones and internet lines) have been restored, with 79,000 cases pending. https://reliefweb.int/report/cuba/response-hurricane-irma-cuba-situation-report-no-7-office-resident-coordinator-14092017 From mehmet at akcin.net Fri Sep 15 16:08:12 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 15 Sep 2017 09:08:12 -0700 Subject: Find carriers that peer in two IX's In-Reply-To: <20170915154004.GH1118@Vurt.local> References: <20170915154004.GH1118@Vurt.local> Message-ID: +carrier "Hurricane Electric" On Fri, Sep 15, 2017 at 8:40 AM, Job Snijders wrote: > On Fri, Sep 15, 2017 at 11:25:10AM -0400, Dovid Bender wrote: > > Does anyone know of a tool like PeeringDB where I can select two > exchanges > > say TELX 60 Hudson and then SIX (Seattle IX) and find all carriers that > > have a presence in both locations? > > a bit hacky ;-) > > Vurt:~ job$ comm -1 -2 <(curl -s https://peeringdb.com/api/ixlan/13 | jq > ".data | .[] | .net_set | .[] | .name" | sort) <(curl -s > https://peeringdb.com/api/ixlan/325 | jq ".data | .[] | .net_set | .[] | > .name" | sort) > "Amazon.com" > "Cloudflare" > "Default Route, LLC" > "Digital Realty | Telx" > "Facebook" > "Facebook" > "Faction Inc." > "Google Inc." > "Highwinds Network Group, Inc" > "Hurricane Electric" > "IPTP Networks" > "ISPrime, LLC." > "Internap" > "Internet2 TransitRail" > "Limelight Networks Global" > "Microsoft" > "NTT DATA Services - HCLS Cloud" > "Netflix" > "Nitel" > "OpenDNS, Inc." > "Packet Clearing House AS42" > "Packet Clearing House" > "Sipartech" > "SoftLayer Technologies, Inc. (an IBM Company)" > "Verizon Digital Media Services (EdgeCast Networks)" > "Wolfe" > "Yahoo!" > Vurt:~ job$ > From dovid at telecurve.com Fri Sep 15 16:26:52 2017 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 15 Sep 2017 12:26:52 -0400 Subject: Find carriers that peer in two IX's In-Reply-To: <20170915154004.GH1118@Vurt.local> References: <20170915154004.GH1118@Vurt.local> Message-ID: Thanks. On Fri, Sep 15, 2017 at 11:40 AM, Job Snijders wrote: > On Fri, Sep 15, 2017 at 11:25:10AM -0400, Dovid Bender wrote: > > Does anyone know of a tool like PeeringDB where I can select two > exchanges > > say TELX 60 Hudson and then SIX (Seattle IX) and find all carriers that > > have a presence in both locations? > > a bit hacky ;-) > > Vurt:~ job$ comm -1 -2 <(curl -s https://peeringdb.com/api/ixlan/13 | jq > ".data | .[] | .net_set | .[] | .name" | sort) <(curl -s > https://peeringdb.com/api/ixlan/325 | jq ".data | .[] | .net_set | .[] | > .name" | sort) > "Amazon.com" > "Cloudflare" > "Default Route, LLC" > "Digital Realty | Telx" > "Facebook" > "Facebook" > "Faction Inc." > "Google Inc." > "Highwinds Network Group, Inc" > "Hurricane Electric" > "IPTP Networks" > "ISPrime, LLC." > "Internap" > "Internet2 TransitRail" > "Limelight Networks Global" > "Microsoft" > "NTT DATA Services - HCLS Cloud" > "Netflix" > "Nitel" > "OpenDNS, Inc." > "Packet Clearing House AS42" > "Packet Clearing House" > "Sipartech" > "SoftLayer Technologies, Inc. (an IBM Company)" > "Verizon Digital Media Services (EdgeCast Networks)" > "Wolfe" > "Yahoo!" > Vurt:~ job$ > From marty at cloudflare.com Fri Sep 15 16:28:24 2017 From: marty at cloudflare.com (Marty Strong) Date: Fri, 15 Sep 2017 17:28:24 +0100 Subject: Find carriers that peer in two IX's In-Reply-To: References: <20170915154004.GH1118@Vurt.local> Message-ID: > TELX 60 Hudson and then SIX (Seattle IX) IX or building? Telx 60 Hudson is a building and SIX is an IX. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 15 Sep 2017, at 17:08, Mehmet Akcin wrote: > > +carrier > > "Hurricane Electric" > > On Fri, Sep 15, 2017 at 8:40 AM, Job Snijders wrote: > >> On Fri, Sep 15, 2017 at 11:25:10AM -0400, Dovid Bender wrote: >>> Does anyone know of a tool like PeeringDB where I can select two >> exchanges >>> say TELX 60 Hudson and then SIX (Seattle IX) and find all carriers that >>> have a presence in both locations? >> >> a bit hacky ;-) >> >> Vurt:~ job$ comm -1 -2 <(curl -s https://peeringdb.com/api/ixlan/13 | jq >> ".data | .[] | .net_set | .[] | .name" | sort) <(curl -s >> https://peeringdb.com/api/ixlan/325 | jq ".data | .[] | .net_set | .[] | >> .name" | sort) >> "Amazon.com" >> "Cloudflare" >> "Default Route, LLC" >> "Digital Realty | Telx" >> "Facebook" >> "Facebook" >> "Faction Inc." >> "Google Inc." >> "Highwinds Network Group, Inc" >> "Hurricane Electric" >> "IPTP Networks" >> "ISPrime, LLC." >> "Internap" >> "Internet2 TransitRail" >> "Limelight Networks Global" >> "Microsoft" >> "NTT DATA Services - HCLS Cloud" >> "Netflix" >> "Nitel" >> "OpenDNS, Inc." >> "Packet Clearing House AS42" >> "Packet Clearing House" >> "Sipartech" >> "SoftLayer Technologies, Inc. (an IBM Company)" >> "Verizon Digital Media Services (EdgeCast Networks)" >> "Wolfe" >> "Yahoo!" >> Vurt:~ job$ >> From hannigan at gmail.com Fri Sep 15 17:29:53 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 15 Sep 2017 17:29:53 +0000 Subject: Find carriers that peer in two IX's In-Reply-To: References: <20170915154004.GH1118@Vurt.local> Message-ID: Which will also have dramatically different results. An IX is not a good key for a carrier search. On Fri, Sep 15, 2017 at 12:32 Marty Strong via NANOG wrote: > > TELX 60 Hudson and then SIX (Seattle IX) > > IX or building? Telx 60 Hudson is a building and SIX is an IX. > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > > > On 15 Sep 2017, at 17:08, Mehmet Akcin wrote: > > > > +carrier > > > > "Hurricane Electric" > > > > On Fri, Sep 15, 2017 at 8:40 AM, Job Snijders wrote: > > > >> On Fri, Sep 15, 2017 at 11:25:10AM -0400, Dovid Bender wrote: > >>> Does anyone know of a tool like PeeringDB where I can select two > >> exchanges > >>> say TELX 60 Hudson and then SIX (Seattle IX) and find all carriers that > >>> have a presence in both locations? > >> > >> a bit hacky ;-) > >> > >> Vurt:~ job$ comm -1 -2 <(curl -s https://peeringdb.com/api/ixlan/13 | > jq > >> ".data | .[] | .net_set | .[] | .name" | sort) <(curl -s > >> https://peeringdb.com/api/ixlan/325 | jq ".data | .[] | .net_set | .[] > | > >> .name" | sort) > >> "Amazon.com" > >> "Cloudflare" > >> "Default Route, LLC" > >> "Digital Realty | Telx" > >> "Facebook" > >> "Facebook" > >> "Faction Inc." > >> "Google Inc." > >> "Highwinds Network Group, Inc" > >> "Hurricane Electric" > >> "IPTP Networks" > >> "ISPrime, LLC." > >> "Internap" > >> "Internet2 TransitRail" > >> "Limelight Networks Global" > >> "Microsoft" > >> "NTT DATA Services - HCLS Cloud" > >> "Netflix" > >> "Nitel" > >> "OpenDNS, Inc." > >> "Packet Clearing House AS42" > >> "Packet Clearing House" > >> "Sipartech" > >> "SoftLayer Technologies, Inc. (an IBM Company)" > >> "Verizon Digital Media Services (EdgeCast Networks)" > >> "Wolfe" > >> "Yahoo!" > >> Vurt:~ job$ > >> > > From cscora at apnic.net Fri Sep 15 18:02:46 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Sep 2017 04:02:46 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170915180246.94CECC44AD@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Sep, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 663581 Prefixes after maximum aggregation (per Origin AS): 258067 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 320181 Total ASes present in the Internet Routing Table: 58405 Prefixes per ASN: 11.36 Origin-only ASes present in the Internet Routing Table: 50494 Origin ASes announcing only one prefix: 22241 Transit ASes present in the Internet Routing Table: 7911 Transit-only ASes present in the Internet Routing Table: 231 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 34 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 89 Number of instances of unregistered ASNs: 90 Number of 32-bit ASNs allocated by the RIRs: 19985 Number of 32-bit ASNs visible in the Routing Table: 15788 Prefixes from 32-bit ASNs in the Routing Table: 64697 Number of bogon 32-bit ASNs visible in the Routing Table: 23 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 354 Number of addresses announced to Internet: 2854147424 Equivalent to 170 /8s, 30 /16s and 213 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 220221 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 182086 Total APNIC prefixes after maximum aggregation: 52304 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 181101 Unique aggregates announced from the APNIC address blocks: 74710 APNIC Region origin ASes present in the Internet Routing Table: 8326 APNIC Prefixes per ASN: 21.75 APNIC Region origin ASes announcing only one prefix: 2305 APNIC Region transit ASes present in the Internet Routing Table: 1192 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 34 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3184 Number of APNIC addresses announced to Internet: 765617376 Equivalent to 45 /8s, 162 /16s and 100 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 201350 Total ARIN prefixes after maximum aggregation: 96036 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 203033 Unique aggregates announced from the ARIN address blocks: 93861 ARIN Region origin ASes present in the Internet Routing Table: 17982 ARIN Prefixes per ASN: 11.29 ARIN Region origin ASes announcing only one prefix: 6632 ARIN Region transit ASes present in the Internet Routing Table: 1765 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2189 Number of ARIN addresses announced to Internet: 1110326048 Equivalent to 66 /8s, 46 /16s and 59 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 177405 Total RIPE prefixes after maximum aggregation: 86787 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 173276 Unique aggregates announced from the RIPE address blocks: 104518 RIPE Region origin ASes present in the Internet Routing Table: 24384 RIPE Prefixes per ASN: 7.11 RIPE Region origin ASes announcing only one prefix: 11191 RIPE Region transit ASes present in the Internet Routing Table: 3453 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6180 Number of RIPE addresses announced to Internet: 713021312 Equivalent to 42 /8s, 127 /16s and 215 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 85235 Total LACNIC prefixes after maximum aggregation: 19020 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 86510 Unique aggregates announced from the LACNIC address blocks: 39729 LACNIC Region origin ASes present in the Internet Routing Table: 6377 LACNIC Prefixes per ASN: 13.57 LACNIC Region origin ASes announcing only one prefix: 1767 LACNIC Region transit ASes present in the Internet Routing Table: 1178 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3891 Number of LACNIC addresses announced to Internet: 171192544 Equivalent to 10 /8s, 52 /16s and 48 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17414 Total AfriNIC prefixes after maximum aggregation: 3848 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 19307 Unique aggregates announced from the AfriNIC address blocks: 7067 AfriNIC Region origin ASes present in the Internet Routing Table: 1071 AfriNIC Prefixes per ASN: 18.03 AfriNIC Region origin ASes announcing only one prefix: 345 AfriNIC Region transit ASes present in the Internet Routing Table: 212 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 344 Number of AfriNIC addresses announced to Internet: 93524480 Equivalent to 5 /8s, 147 /16s and 18 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5404 4192 76 ERX-CERNET-BKB China Education and Rese 7545 3835 406 384 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2968 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2828 11126 752 KIXS-AS-KR Korea Telecom, KR 9829 2758 1499 541 BSNL-NIB National Internet Backbone, IN 9808 2359 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2193 1472 114 VNPT-AS-VN VNPT Corp, VN 9394 2174 4931 27 CTTNET China TieTong Telecommunications 4755 2102 422 221 TATACOMM-AS TATA Communications formerl 7552 1653 1105 70 VIETEL-AS-AP Viettel Corporation, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3644 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3430 1341 88 SHAW - Shaw Communications Inc., CA 18566 2204 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2044 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2036 2247 430 CHARTER-NET-HKY-NC - Charter Communicat 209 1908 5066 644 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1842 3963 545 AMAZON-02 - Amazon.com, Inc., US 30036 1835 330 274 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1686 854 229 ITCDELTA - Earthlink, Inc., US 701 1679 10589 626 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2964 939 2122 AKAMAI-ASN1, US 8551 2466 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2057 332 427 TELLCOM-AS, TR 9121 1882 1691 17 TTNET, TR 12389 1712 1631 664 ROSTELECOM-AS, RU 12479 1701 1051 64 UNI2-AS, ES 13188 1604 100 52 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1199 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3564 541 233 Telmex Colombia S.A., CO 8151 3144 3458 584 Uninet S.A. de C.V., MX 11830 2099 370 65 Instituto Costarricense de Electricidad 6503 1565 437 53 Axtel, S.A.B. de C.V., MX 7303 1558 1023 242 Telecom Argentina S.A., AR 6147 1281 377 27 Telefonica del Peru S.A.A., PE 3816 1027 506 95 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 963 2283 184 CLARO S.A., BR 11172 913 126 85 Alestra, S. de R.L. de C.V., MX 18881 898 1052 23 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1194 398 48 LINKdotNET-AS, EG 37611 766 91 8 Afrihost, ZA 36903 709 356 136 MT-MPLS, MA 36992 660 1383 31 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 410 354 77 ORANGE-, TN 15399 357 35 7 WANANCHI-, KE 8452 318 1730 17 TE-AS TE-AS, EG 23889 311 103 14 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5404 4192 76 ERX-CERNET-BKB China Education and Rese 7545 3835 406 384 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3644 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3564 541 233 Telmex Colombia S.A., CO 6327 3430 1341 88 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 8151 3144 3458 584 Uninet S.A. de C.V., MX 17974 2968 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2964 939 2122 AKAMAI-ASN1, US 4766 2828 11126 752 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3644 3486 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3835 3451 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3430 3342 SHAW - Shaw Communications Inc., CA 10620 3564 3331 Telmex Colombia S.A., CO 17974 2968 2895 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8151 3144 2560 Uninet S.A. de C.V., MX 8551 2466 2425 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2359 2327 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2758 2217 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65099 PRIVATE 95.173.150.0/24 43797 RSNET2-AS RSNET2, RU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.128.126.0/23 62878 XLITT - Xlitt, US 27.100.7.0/24 56096 UNKNOWN 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 62878 XLITT - Xlitt, US 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:106 /12:283 /13:551 /14:1048 /15:1871 /16:13440 /17:7746 /18:13662 /19:25198 /20:39200 /21:42516 /22:79908 /23:65175 /24:370247 /25:891 /26:662 /27:693 /28:37 /29:38 /30:216 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3226 3430 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2842 3644 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2088 2204 MEGAPATH5-US - MegaPath Corporation, US 8551 1931 2466 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1613 1835 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1518 3564 Telmex Colombia S.A., CO 11830 1489 2099 Instituto Costarricense de Electricidad y Telec 11492 1418 1596 CABLEONE - CABLE ONE, INC., US 6389 1355 2044 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1529 2:834 4:18 5:2457 6:31 7:1 8:1069 12:1860 13:154 14:1675 15:28 16:2 17:170 18:90 20:60 23:2438 24:1928 25:2 27:2367 29:1 31:1922 32:90 33:20 35:21 36:396 37:2355 38:1385 39:69 40:98 41:3047 42:404 43:1960 44:81 45:3081 46:2784 47:171 49:1244 50:1008 51:19 52:821 54:364 55:2 56:4 57:43 58:1556 59:982 60:323 61:2002 62:1710 63:1905 64:4686 65:2210 66:4549 67:2276 68:1225 69:3372 70:1167 71:603 72:2147 74:2707 75:400 76:422 77:1487 78:1532 79:1897 80:1399 81:1404 82:1015 83:723 84:965 85:1869 86:468 87:1197 88:794 89:2191 90:170 91:6240 92:1009 93:2386 94:2364 95:2689 96:640 97:350 98:994 99:98 100:153 101:1440 102:1 103:15840 104:3059 105:189 106:560 107:1753 108:826 109:2917 110:1473 111:1752 112:1254 113:1324 114:1072 115:1590 116:1646 117:1769 118:1982 119:1637 120:734 121:1071 122:2431 123:1871 124:1481 125:1799 128:909 129:673 130:434 131:1473 132:593 133:194 134:699 135:225 136:451 137:469 138:1954 139:515 140:380 141:653 142:745 143:910 144:791 145:184 146:1112 147:698 148:1492 149:586 150:700 151:990 152:736 153:300 154:890 155:758 156:679 157:684 158:484 159:1561 160:763 161:748 162:2515 163:507 164:975 165:1430 166:382 167:1296 168:3030 169:835 170:3549 171:368 172:1017 173:1997 174:784 175:778 176:1890 177:3946 178:2578 179:1149 180:2215 181:2046 182:2439 183:758 184:872 185:10751 186:3292 187:2146 188:2578 189:1832 190:8366 191:1361 192:9647 193:5806 194:4732 195:3933 196:2129 197:1321 198:5521 199:5889 200:7577 201:4381 202:10355 203:9920 204:4508 205:2836 206:3074 207:3169 208:3964 209:4027 210:3949 211:2138 212:2876 213:2557 214:845 215:66 216:5856 217:2129 218:915 219:605 220:1676 221:929 222:741 223:1211 End of report From brock at bmwl.co Thu Sep 14 22:58:35 2017 From: brock at bmwl.co (Brock Tice) Date: Thu, 14 Sep 2017 16:58:35 -0600 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: We are small but we are just about out of IPv4 and aren't going to get or buy any more. We have been testing for a while. > Shall I go for IPv6-only deployment or dual stack? You should plan for adding customers eventually that are IPv6-only, unless you have all the v4 you will ever need, and you will need to reserve IPv4 address blocks for translation. > How to identify address CPE and legacy application issues? Legacy application issues can be solved (for the most part) with 464XLAT, which also solves IP-literal-in-HTML problems. You need PLAT at the core and CLAT at the client. Unfortunately so far the only good way we've found to do CLAT is OpenWRT on the CPE or router. We are getting ready to bundle Linksys routers flashed with OpenWRT. For PLAT at the core we are running jool. It's actually quite simple to set up and we are currently using OSPF to do anycast, but we will probably be migrating to a single set of HA servers in the core. The good news is that even if it goes down, Netflix and Facebook will still work as they are fully functional on v6. We have tested this in my home and at my office with IPv6-only VLANs/wireless SSIDs, mostly without a hitch. If you run this setup without the CLAT on the client side you get NAT64 so it still will work for most things. I would be very, very happy if larger ISPs would put pressure on router manufacturers to support CLAT, we have no clout. I would also love to hear if any of this is stupid or if there's a better way. --Brock From mike at smashing.net Thu Sep 14 23:51:27 2017 From: mike at smashing.net (Mike Hughes) Date: Fri, 15 Sep 2017 00:51:27 +0100 Subject: 2017 NANOG Elections General Information In-Reply-To: References: <642FC266-1BEC-4FD7-BD38-A305F9A16B64@pch.net> Message-ID: I honestly wondered whether to wade in here, as I'm another person that seems to have drifted away from the NANOG community. But why have I drifted? Partly because I've only got so much T&E budget to go at, and sometimes I need to be somewhere else that isn't a NANOG meeting. NANOG has stopped being a "must attend" event for me, and become a "nice to do", probably once a year to catch up with some people, and only if I'm not too busy already. I've also not renewed my NANOG membership since it lapsed last year despite having previously been a member since NANOG memberships were first offered in 2011. One of the things that lost my continued membership was a recent election where a number of candidates ran as a slate. I felt it to be cringeworthy and unwarranted. When the opportunity to renew came, I chose not to give NANOG any more money because members of the incumbent Board had taken an action that had disappointed me. I strongly believe the NANOG community is best served by candidates elected based on their individual merit and their stated platform. Right now, the Board is all too easily perceived as an unassailable hegemony of powerful, successful individuals, who hold senior roles in their (successful) parent orgs, and that's regardless of the positive and community-spirited intentions they may have had when standing for election. It feels as though we need to wait for people to term-out and hope one of their powerful buddies isn't standing to continue the dynasty. Is that what the Board really wants? It seems not, but that's how it's ended up looking. There's also something of an "escalator" assumption about passage through committees and eventually becoming a Board member. While I don't doubt the experience of the other committees is useful, this "escalator" isn't necessarily a healthy path to Board membership. Back to the meetings themselves, I feel NANOG has become less of a welcoming meeting of technical peers and feels more like a trade fair, dominated by cliques, cabals, suites & private side rooms. The trade fair mentality likely attracted the undesirable trade fair antics that have been spoken of on this thread, perhaps unsurprisingly. Meanwhile, the governance seems to have become rather politicised and less representative of the community. That said, I'm pleased to see there's some recognition of the shortcomings and a desire to change the status quo. How that's done? Well that's a whole different question, but I think Dan made a few good points earlier in the thread. Maybe part of the solution is having some proportion of Board seats appointed by some sort of nominating process, while retaining the elections for others, to try and achieve a more balanced Board. Thanks, Mike From tim at snas.io Fri Sep 15 14:45:12 2017 From: tim at snas.io (Tim Evens) Date: Fri, 15 Sep 2017 07:45:12 -0700 Subject: FW: Reliability of looking glass sites / rviews In-Reply-To: References: Message-ID: You didn't mention details about which ASN or prefixes you were checking. Are you referring to ASN 14607 that only advertises two prefixes 129.77.0.0/16 and 2620:0:2810::/48? Based what we see over the weekend (using routeviews data), we see: Event Start Time: 2017-09-09 11:29:23 UTC (2017-09-09 07:29:23 EDT) Event End Time: 2017-09-09 13:31:30 UTC (2017-09-09 09:31:30 EDT) Are the above times correct? We see the routes withdraw and then come back. For example: http://demo-rv.snas.io:3000/dashboard/db/prefix-history?orgId=2&var-prefix=129.77.0.0&var-prefix_len=16&var-asn_num=All&var-router_name=All&var-peer_name=All&from=1504908000000&to=1505203200000 When you checked routeviews, which router and peer were you looking at? When you did a "show ip bgp ..." did you include the prefix length? If not, it would have then shown you 0/0 or 128/5, depending on which router you were on. --Tim On 9/13/17, 8:43 AM, "NANOG on behalf of Matthew Huff" wrote: Both should have been similar. In the first case we lost power to all of our BGP border routers that are peered with the upstream providers In the second case, I did an explicit "shut" on the interface connected to the upstream provider that appeared "stuck" after an hour after the outage. From: on behalf of Christopher Morrow Date: Wednesday, September 13, 2017 at 10:58 AM To: Matthew Huff Cc: nanog2 Subject: Re: Reliability of looking glass sites / rviews On Wed, Sep 13, 2017 at 5:30 AM, Matthew Huff > wrote: This weekend our uninterruptible power supply became interruptible and we lost all circuits. While I was doing initial debugging of the problem while I waited on site power verification, I noticed that there was still paths being shown in rviews for the circuit that were down. This was over an hour after we went hard down and it took hours before we were back up. explicit vs implicit withdrawals causing different handling of the problem routes? I worked with our providers last night to verify there weren't any hanging static routes, etc... We shut the upstream circuit down and watched the convergence and saw that eventually all the paths disappeared. Given what we saw on Saturday, what would cause route-views to cache the paths that long? Some looking glass sites only show what they are peered with or at most what their peers are peered with, that's why I've always used route-views. What looking glass sites other than route-views would people recommend? ripe ris. From adam.gregory at heidmar.com Fri Sep 15 15:40:25 2017 From: adam.gregory at heidmar.com (Adam Gregory) Date: Fri, 15 Sep 2017 15:40:25 +0000 Subject: Find carriers that peer in two IX's In-Reply-To: References: Message-ID: <93f32bc8bca441e9918f8c7d297ce2bd@USEXCH002.heidmar.com> Although this will not give you a side by side comparision I have been using the HE exchange report. Maybe that will help. https://bgp.he.net/report/exchanges Best Regards, ---------------------------------- adam gregory -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender Sent: Friday, September 15, 2017 11:25 AM To: NANOG Subject: Find carriers that peer in two IX's Hi, Does anyone know of a tool like PeeringDB where I can select two exchanges say TELX 60 Hudson and then SIX (Seattle IX) and find all carriers that have a presence in both locations? TIA. Dovid From matt.larson at icann.org Fri Sep 15 15:54:02 2017 From: matt.larson at icann.org (Matt Larson) Date: Fri, 15 Sep 2017 15:54:02 +0000 Subject: Operational message: DNS root zone KSK rollover to occur on October 11, 2017 at 1600 UTC Message-ID: <738164A2-B792-4B76-963F-F39EE704F5FB@icann.org> The root zone management partners, ICANN and Verisign, are working together to change the DNS root zone's key-signing key (KSK). This process is referred to as "rolling" the root zone KSK. The root zone's apex DNSKEY RRset has been signed with the same KSK, known as KSK-2010, since the root zone was first signed in July, 2010. On October 11, 2017, at approximately 1600 UTC, the root zone will be published with the apex DNSKEY RRset signed for the first time with a new KSK, known as KSK-2017. The root zone apex DNSKEY RRset will be signed with only KSK-2017 going forward. While the specific date of the KSK rollover, October 11, 2017, had been announced previously, the time of 1600 UTC on that day has not been announced until now, which is the primary purpose of this message. The public portion of the root zone KSK is configured as a trust anchor in software performing DNSSEC validation. The configuration of any software performing DNSSEC validation will need to be updated to reference KSK-2017 on or before October 11, 2017, or all DNS responses received by that software will fail DNSSEC validation, resulting ultimately in error messages to end users. In many cases, software performing DNSSEC validation supports "Automated Updates of DNS Security", the protocol defined in RFC 5011 that can automatically update a DNSSEC validator's trust anchor configuration. If the software does not support this protocol, or it is incorrectly implemented or not configured correctly, the trust anchor will need to be updated manually. Anyone operating software performing DNSSEC validation with the root zone KSK configured as a trust anchor must take action on or before October 11, 2017, to confirm that their software is configured with KSK-2017 as a trust anchor and, if not, take the necessary steps to update the configuration. Further information about the root KSK rollover, including information about how to check and update the trust anchor configuration of popular recursive resolver implementations that support DNSSEC validation, is available at https://icann.org/kskroll. For the root zone management partners, Matt Larson VP of Research, ICANN Duane Wessels Distinguished Engineer, Verisign -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From yifeiy2 at andrew.cmu.edu Fri Sep 15 17:06:24 2017 From: yifeiy2 at andrew.cmu.edu (Yifei Yuan) Date: Fri, 15 Sep 2017 17:06:24 +0000 Subject: Can you help on a survey on network testing? Message-ID: <1505495185006.34622@andrew.cmu.edu> Dear Folks, My name is Yifei Yuan, and I am a researcher at Carnegie Mellon University. I am working on a research project related to testing network configurations, where I want to survey the problems that are encountered when conducting testing on networks. I would very much appreciate it, if you could participate this survey, which can be found in the following link: http://cmu.ca1.qualtrics.com/jfe/form/SV_bvE1oBeO9NI5r5X The survey is anonymous, and it would take no more than 5 mins to finish up all questions. Your participation is voluntary with no compensation, and you must be at least 18 years of age to complete the survey. Thanks, Yifei Yuan Postdoctoral researcher ECE, CMU From randy at psg.com Fri Sep 15 20:40:39 2017 From: randy at psg.com (Randy Bush) Date: Sat, 16 Sep 2017 05:40:39 +0900 Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: >> any word on cuba? >... > https://reliefweb.int/report/cuba/response-hurricane-irma-cuba-situation-report-no-7-office-resident-coordinator-14092017 bad, but more like florida than their neighbors to the east, some of whom are almost standing on bedrock. thanks for the info. randy From sean at donelan.com Fri Sep 15 21:29:39 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 15 Sep 2017 17:29:39 -0400 (EDT) Subject: Hurricane Irma: Florida, Puerto Rico and U.S. VI In-Reply-To: References: Message-ID: On Fri, 15 Sep 2017, Sean Donelan wrote: > The situation is still dire in some locations, but generally the disaster > operations have moved to recovery and restoration. Unless something > significant happens, this is the last summary report about Hurricane Irma > from me. I said it would be the last summary report, but an important correction. FCC found a problem with the data statistics: [NOTE: The number of cable systems and wireline subscribers out of service is reduced significantly from yesterday because, in addition to removing from the total states/territories deactivated in DIRS, the FCC found that one or more providers had previously filed multiple entries, resulting in double/triple counting number of subscribers and inaccurate percentages per day. Those duplicative entries have now been removed.] There are at least 1,691,484 subscribers out of service in the affected areas in Florida, down from 8,258,789. From ryan.dirocco at totalserversolutions.com Sat Sep 16 01:50:42 2017 From: ryan.dirocco at totalserversolutions.com (Ryan DiRocco) Date: Sat, 16 Sep 2017 01:50:42 +0000 Subject: Contact for Frontiernet - AS5650 Message-ID: Can anyone put me in touch with a contact from Frontiernet regrading peering off-list? I've been contacting pering at frontiernet.net since 02/2017 without response and have sat on hold for the noc for 1+ hour multiple times without answer ;) Any help greatly appreciated! From nanog at ics-il.net Sat Sep 16 01:52:28 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 Sep 2017 20:52:28 -0500 (CDT) Subject: Contact for Frontiernet - AS5650 In-Reply-To: References: Message-ID: <39809875.2402.1505526745379.JavaMail.mhammett@ThunderFuck> Me too? :-p ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ryan DiRocco" To: nanog at nanog.org Sent: Friday, September 15, 2017 8:50:42 PM Subject: Contact for Frontiernet - AS5650 Can anyone put me in touch with a contact from Frontiernet regrading peering off-list? I've been contacting pering at frontiernet.net since 02/2017 without response and have sat on hold for the noc for 1+ hour multiple times without answer ;) Any help greatly appreciated! From marshall.eubanks at gmail.com Sat Sep 16 02:38:31 2017 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Fri, 15 Sep 2017 22:38:31 -0400 Subject: Contact for Frontiernet - AS5650 In-Reply-To: References: Message-ID: On Fri, Sep 15, 2017 at 9:50 PM, Ryan DiRocco < ryan.dirocco at totalserversolutions.com> wrote: > Can anyone put me in touch with a contact from Frontiernet regrading > peering off-list? > > I've been contacting pering at frontiernet.net > since 02/2017 without response and have sat on hold for the noc for 1+ hour > multiple times without answer ;) > > I suspect this is just an email typo, but it's listed with two "e"s. Contact Information - Maintenance: isisnoc at frontiernet.net - Peering: peering at frontiernet.net - Regards > Any help greatly appreciated! > > > From ryan.dirocco at totalserversolutions.com Sat Sep 16 02:40:15 2017 From: ryan.dirocco at totalserversolutions.com (Ryan DiRocco) Date: Sat, 16 Sep 2017 02:40:15 +0000 Subject: Contact for Frontiernet - AS5650 In-Reply-To: References: , Message-ID: Yes, just a typo on here, I have been sending to the right contact :) Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: Marshall Eubanks Date: 9/15/17 10:38 PM (GMT-05:00) To: Ryan DiRocco Cc: nanog at nanog.org Subject: Re: Contact for Frontiernet - AS5650 On Fri, Sep 15, 2017 at 9:50 PM, Ryan DiRocco > wrote: Can anyone put me in touch with a contact from Frontiernet regrading peering off-list? I've been contacting pering at frontiernet.net> since 02/2017 without response and have sat on hold for the noc for 1+ hour multiple times without answer ;) I suspect this is just an email typo, but it's listed with two "e"s. Contact Information * Maintenance: isisnoc at frontiernet.net * Peering: peering at frontiernet.net * Regards Any help greatly appreciated! From fredrik.sallinen at gmail.com Sat Sep 16 08:09:32 2017 From: fredrik.sallinen at gmail.com (Fredrik Sallinen) Date: Sat, 16 Sep 2017 12:39:32 +0430 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: Thank you all for your Ideas. AFAIK one of the main decisions for IPv6 transition and deployment is the choice of IPv6 IGP. I read somewhere that its a good practice to use different IGP protocol for IPv6 and IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6. any comments on this? Additionally I will appreciate it if you share your suggestions on products and their performance? For example If I go for NAT64+DNS64 to handle IPv4 traffic, What sort of carrier grade products are you recommending and can you share your experience on their performance/pitfalls? currently we have ~150Gbps of IPv4 traffic, so we need a solution to support such scale and future growth. Regards, On Thu, Sep 14, 2017 at 9:35 PM, Mikael Abrahamsson wrote: > On Wed, 13 Sep 2017, Fredrik Sallinen wrote: > >> Hello, >> >> Recently we have decided to start IPv6 migration in our network. We >> have ~1K BNGs and connecting our customers to network using PPPoE. >> I'd be interested in hearing from the technical community about their >> experiences and recommendations on this process. I'm wondering: >> >> Shall I go for IPv6-only deployment or dual stack? > > > For PPPoE with existing IPv4, go dual stack. > >> Where to start with IPv6? (core, edge or ...) > > > Core, peering, work outwards towards end users. > >> What are the best practices for ISPs? >> What are the costs and return on investment? >> How to identify address CPE and legacy application issues? > > > There is a lot written and presented about IPv6 deployment. People have been > doing this in volume since around 2010, and if you search for IPv6 > deployment experience you'll find lots of presentations. > > Some I found that seem relevant: > > https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson-pierantozzi-level3-ipv6.pdf > https://www.ietf.org/proceedings/54/slides/plenary-15.pdf > https://www.apnic.net/community/ipv6-program/ipv6-stories/ > https://www.ipv6council.be/experiences-de-deploiements-ipv6/ > > If you prefer video form, there are lots of presentations from conferences, > available on youtube as well. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From bengelly at gmail.com Sat Sep 16 08:39:42 2017 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Sat, 16 Sep 2017 10:39:42 +0200 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: Hi, My advice is not to mix IGPs. If you are already running ISIS, then go for multi-topology and dual-stack it. I've done that several times, running different backbones, works like a charm. Less overhead as you'd only be running one IGP. My 2 cents. > Le 16 sept. 2017 à 10:09, Fredrik Sallinen a écrit : > > Thank you all for your Ideas. AFAIK one of the main decisions for IPv6 > transition and deployment is the choice of IPv6 IGP. I read somewhere > that its a good practice to use different IGP protocol for IPv6 and > IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6. > any comments on this? > Additionally I will appreciate it if you share your suggestions on > products and their performance? For example If I go for NAT64+DNS64 to > handle IPv4 traffic, What sort of carrier grade products are you > recommending and can you share your experience on their > performance/pitfalls? currently we have ~150Gbps of IPv4 traffic, so > we need a solution to > support such scale and future growth. > > > Regards, > >> On Thu, Sep 14, 2017 at 9:35 PM, Mikael Abrahamsson wrote: >>> On Wed, 13 Sep 2017, Fredrik Sallinen wrote: >>> >>> Hello, >>> >>> Recently we have decided to start IPv6 migration in our network. We >>> have ~1K BNGs and connecting our customers to network using PPPoE. >>> I'd be interested in hearing from the technical community about their >>> experiences and recommendations on this process. I'm wondering: >>> >>> Shall I go for IPv6-only deployment or dual stack? >> >> >> For PPPoE with existing IPv4, go dual stack. >> >>> Where to start with IPv6? (core, edge or ...) >> >> >> Core, peering, work outwards towards end users. >> >>> What are the best practices for ISPs? >>> What are the costs and return on investment? >>> How to identify address CPE and legacy application issues? >> >> >> There is a lot written and presented about IPv6 deployment. People have been >> doing this in volume since around 2010, and if you search for IPv6 >> deployment experience you'll find lots of presentations. >> >> Some I found that seem relevant: >> >> https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson-pierantozzi-level3-ipv6.pdf >> https://www.ietf.org/proceedings/54/slides/plenary-15.pdf >> https://www.apnic.net/community/ipv6-program/ipv6-stories/ >> https://www.ipv6council.be/experiences-de-deploiements-ipv6/ >> >> If you prefer video form, there are lots of presentations from conferences, >> available on youtube as well. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se From sthaug at nethelp.no Sat Sep 16 08:56:28 2017 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 16 Sep 2017 10:56:28 +0200 (CEST) Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: <20170916.105628.74724293.sthaug@nethelp.no> > Thank you all for your Ideas. AFAIK one of the main decisions for IPv6 > transition and deployment is the choice of IPv6 IGP. I read somewhere > that its a good practice to use different IGP protocol for IPv6 and > IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6. > any comments on this? I've never heard this promoted as good practice - why on earth would you want to make life more difficult for yourself by running two IGPs if you can run one? Yes, if you use OSPF for IPv4 you *have* to use something else for IPv6. But if you already run IS-IS there is no reason to change, just remember to enable multi-topology. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mhuff at ox.com Sat Sep 16 09:48:32 2017 From: mhuff at ox.com (Matthew Huff) Date: Sat, 16 Sep 2017 09:48:32 +0000 Subject: FW: Reliability of looking glass sites / rviews In-Reply-To: References: Message-ID: <2d1a52612f7f4d32a6f6844091f8afb1@ox.com> ASN 14607, and 129.77.0.0/16 After slightly over an hour after our power event where 100% of our equipment was down, this is what I saw at routeviews BGP routing table entry for 129.77.0.0/16, version 24978989 Paths: (7 available, best #7, table default)   Not advertised to any peer   Refresh Epoch 1   134708 3491 6939 46887 14607     103.197.104.1 from 103.197.104.1 (123.108.254.70)       Origin IGP, localpref 100, valid, external       rx pathid: 0, tx pathid: 0   Refresh Epoch 1   3333 1273 6939 46887 14607     193.0.0.56 from 193.0.0.56 (193.0.0.56)       Origin IGP, localpref 100, valid, external       Community: 1273:23000       rx pathid: 0, tx pathid: 0   Refresh Epoch 1   8283 57866 6762 6939 46887 14607     94.142.247.3 from 94.142.247.3 (94.142.247.3)       Origin IGP, metric 0, localpref 100, valid, external       Community: 6762:33 6762:16500 8283:15 57866:105       unknown transitive attribute: flag 0xE0 type 0x20 length 0xC         value 0000 205B 0000 0006 0000 000F        rx pathid: 0, tx pathid: 0   Refresh Epoch 1   24441 3491 3491 6939 46887 14607     202.93.8.242 from 202.93.8.242 (202.93.8.242)       Origin IGP, localpref 100, valid, external       rx pathid: 0, tx pathid: 0   Refresh Epoch 1   20912 1267 1273 6939 46887 14607     212.66.96.126 from 212.66.96.126 (212.66.96.126)       Origin IGP, localpref 100, valid, external       Community: 1273:23000 9035:50 9035:100 20912:65001       rx pathid: 0, tx pathid: 0   Refresh Epoch 1   1221 4637 6939 46887 14607     203.62.252.83 from 203.62.252.83 (203.62.252.83)       Origin IGP, localpref 100, valid, external       rx pathid: 0, tx pathid: 0   Refresh Epoch 1   2497 6939 46887 14607     202.232.0.2 from 202.232.0.2 (202.232.0.2)       Origin IGP, localpref 100, valid, external, best       rx pathid: 0, tx pathid: 0x0 From: Tim Evens [mailto:tim at snas.io] Sent: Friday, September 15, 2017 10:45 AM To: Matthew Huff Cc: morrowc.lists at gmail.com; nanog at nanog.org Subject: Re: FW: Reliability of looking glass sites / rviews You didn't mention details about which ASN or prefixes you were checking. Are you referring to ASN 14607 that only advertises two prefixes 129.77.0.0/16 and 2620:0:2810::/48? Based what we see over the weekend (using routeviews data), we see: Event Start Time: 2017-09-09 11:29:23 UTC (2017-09-09 07:29:23 EDT) Event End Time: 2017-09-09 13:31:30 UTC (2017-09-09 09:31:30 EDT) Are the above times correct? We see the routes withdraw and then come back. For example: http://demo-rv.snas.io:3000/dashboard/db/prefix-history?orgId=2&var-prefix=129.77.0.0&var-prefix_len=16&var-asn_num=All&var-router_name=All&var-peer_name=All&from=1504908000000&to=1505203200000 When you checked routeviews, which router and peer were you looking at? When you did a "show ip bgp ..." did you include the prefix length? If not, it would have then shown you 0/0 or 128/5, depending on which router you were on. --Tim On 9/13/17, 8:43 AM, "NANOG on behalf of Matthew Huff" wrote: Both should have been similar. In the first case we lost power to all of our BGP border routers that are peered with the upstream providers In the second case, I did an explicit “shut” on the interface connected to the upstream provider that appeared “stuck” after an hour after the outage. From: on behalf of Christopher Morrow Date: Wednesday, September 13, 2017 at 10:58 AM To: Matthew Huff Cc: nanog2 Subject: Re: Reliability of looking glass sites / rviews On Wed, Sep 13, 2017 at 5:30 AM, Matthew Huff > wrote: This weekend our uninterruptible power supply became interruptible and we lost all circuits. While I was doing initial debugging of the problem while I waited on site power verification, I noticed that there was still paths being shown in rviews for the circuit that were down. This was over an hour after we went hard down and it took hours before we were back up. explicit vs implicit withdrawals causing different handling of the problem routes? I worked with our providers last night to verify there weren't any hanging static routes, etc... We shut the upstream circuit down and watched the convergence and saw that eventually all the paths disappeared. Given what we saw on Saturday, what would cause route-views to cache the paths that long? Some looking glass sites only show what they are peered with or at most what their peers are peered with, that's why I've always used route-views. What looking glass sites other than route-views would people recommend? ripe ris.     From randy at psg.com Sat Sep 16 11:57:25 2017 From: randy at psg.com (Randy Bush) Date: Sat, 16 Sep 2017 20:57:25 +0900 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: > if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6. this is nuts. one is-is instance carries both randy From mh at xalto.net Sat Sep 16 12:27:17 2017 From: mh at xalto.net (Michael Hallgren) Date: Sat, 16 Sep 2017 14:27:17 +0200 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: Le 16/09/2017 à 10:39, Youssef Bengelloun-Zahr a écrit : > Hi, > > My advice is not to mix IGPs. If you are already running ISIS, then go for multi-topology and dual-stack it. > > I've done that several times, running different backbones, works like a charm. Less overhead as you'd only be running one IGP. > > My 2 cents. Adding few cents of €. ;-) mh > > > >> Le 16 sept. 2017 à 10:09, Fredrik Sallinen a écrit : >> >> Thank you all for your Ideas. AFAIK one of the main decisions for IPv6 >> transition and deployment is the choice of IPv6 IGP. I read somewhere >> that its a good practice to use different IGP protocol for IPv6 and >> IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6. >> any comments on this? >> Additionally I will appreciate it if you share your suggestions on >> products and their performance? For example If I go for NAT64+DNS64 to >> handle IPv4 traffic, What sort of carrier grade products are you >> recommending and can you share your experience on their >> performance/pitfalls? currently we have ~150Gbps of IPv4 traffic, so >> we need a solution to >> support such scale and future growth. >> >> >> Regards, >> >>> On Thu, Sep 14, 2017 at 9:35 PM, Mikael Abrahamsson wrote: >>>> On Wed, 13 Sep 2017, Fredrik Sallinen wrote: >>>> >>>> Hello, >>>> >>>> Recently we have decided to start IPv6 migration in our network. We >>>> have ~1K BNGs and connecting our customers to network using PPPoE. >>>> I'd be interested in hearing from the technical community about their >>>> experiences and recommendations on this process. I'm wondering: >>>> >>>> Shall I go for IPv6-only deployment or dual stack? >>> >>> For PPPoE with existing IPv4, go dual stack. >>> >>>> Where to start with IPv6? (core, edge or ...) >>> >>> Core, peering, work outwards towards end users. >>> >>>> What are the best practices for ISPs? >>>> What are the costs and return on investment? >>>> How to identify address CPE and legacy application issues? >>> >>> There is a lot written and presented about IPv6 deployment. People have been >>> doing this in volume since around 2010, and if you search for IPv6 >>> deployment experience you'll find lots of presentations. >>> >>> Some I found that seem relevant: >>> >>> https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson-pierantozzi-level3-ipv6.pdf >>> https://www.ietf.org/proceedings/54/slides/plenary-15.pdf >>> https://www.apnic.net/community/ipv6-program/ipv6-stories/ >>> https://www.ipv6council.be/experiences-de-deploiements-ipv6/ >>> >>> If you prefer video form, there are lots of presentations from conferences, >>> available on youtube as well. >>> >>> -- >>> Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Sat Sep 16 16:09:47 2017 From: owen at delong.com (Owen DeLong) Date: Sat, 16 Sep 2017 09:09:47 -0700 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: <20170916.105628.74724293.sthaug@nethelp.no> References: <20170916.105628.74724293.sthaug@nethelp.no> Message-ID: > > > > Yes, if you use OSPF for IPv4 you *have* to use something else for > IPv6. But if you already run IS-IS there is no reason to change, just > remember to enable multi-topology. Well... sort of. The reality is that from a configuration and management perspective, there's very little difference between OSPFv2 for IPv4 and OSPFv3 for IPv6. I've run OSPF 2 and 3 on multiple networks and it's not difficult or problematic in any way. Owen > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no From baldur.norddahl at gmail.com Sat Sep 16 19:10:55 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 16 Sep 2017 21:10:55 +0200 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: <20170916.105628.74724293.sthaug@nethelp.no> References: <20170916.105628.74724293.sthaug@nethelp.no> Message-ID: <950220b1-8fcc-0f4b-bfc7-0e46a0848e98@gmail.com> 16/09/2017 kl. 10.56 sthaug at nethelp.no: > Yes, if you use OSPF for IPv4 you *have* to use something else for > IPv6. But if you already run IS-IS there is no reason to change, just > remember to enable multi-topology. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no We somehow manage to run just OSPFv2 and still deliver both IPv4 and IPv6... :-) The trick is MPLS with Internet in a VRF for both IPv4 and IPv6. Regards, Baldur From maxtul at netassist.ua Sun Sep 17 17:07:56 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 17 Sep 2017 20:07:56 +0300 Subject: USA local SIM card Message-ID: <59BEABEC.7020101@netassist.ua> Hi All, sorry for possible off-topic, I really did not know where to ask this. I'm going to visit USA for two weeks. I want to buy a local prepaid SIM card mostly for IP access. Is it possible in USA to buy a prepaid SIM as a visitor, without long term contract? I need a public (can be dynamic) IP address, NOT over NAT, and (or) IPv6, if possible. My phone is GSM UMTS 3G. Expected traffic volume is about 10G. Will use it in New York City and Orlando City, not in rural areas. Good data roaming tariff in Cannada will be a big advantage. What can you advice? Thank you! From maxtul at netassist.ua Sun Sep 17 17:13:10 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 17 Sep 2017 20:13:10 +0300 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: <59BEAD26.1090901@netassist.ua> Hello, for my point of view, the start question is do you control CPEs (can re-configure and re-flash it), or users buy and own CPEs themself? On 13.09.17 15:08, Fredrik Sallinen wrote: > Hello, > > Recently we have decided to start IPv6 migration in our network. We > have ~1K BNGs and connecting our customers to network using PPPoE. > I'd be interested in hearing from the technical community about their > experiences and recommendations on this process. I'm wondering: > > Shall I go for IPv6-only deployment or dual stack? > Where to start with IPv6? (core, edge or ...) > What are the best practices for ISPs? > What are the costs and return on investment? > How to identify address CPE and legacy application issues? > > Fredrik > From tyler at tgconrad.com Sun Sep 17 17:13:24 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Sun, 17 Sep 2017 12:13:24 -0500 Subject: USA local SIM card In-Reply-To: <59BEABEC.7020101@netassist.ua> References: <59BEABEC.7020101@netassist.ua> Message-ID: Look at TMobile, they provide IPv6 public addressing, and offer relatively cheap prepaid plans. On Sunday, September 17, 2017, Max Tulyev wrote: > Hi All, > > sorry for possible off-topic, I really did not know where to ask this. > > I'm going to visit USA for two weeks. I want to buy a local prepaid SIM > card mostly for IP access. > > Is it possible in USA to buy a prepaid SIM as a visitor, without long > term contract? > > I need a public (can be dynamic) IP address, NOT over NAT, and (or) > IPv6, if possible. > > My phone is GSM UMTS 3G. > > Expected traffic volume is about 10G. > > Will use it in New York City and Orlando City, not in rural areas. > > Good data roaming tariff in Cannada will be a big advantage. > > What can you advice? > > Thank you! > From bruns at 2mbit.com Sun Sep 17 17:15:32 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 17 Sep 2017 11:15:32 -0600 Subject: USA local SIM card In-Reply-To: <59BEABEC.7020101@netassist.ua> References: <59BEABEC.7020101@netassist.ua> Message-ID: <9ed27335-cf4f-4ace-88fa-e5316e4e8aa4@2mbit.com> On 9/17/2017 11:07 AM, Max Tulyev wrote: > Hi All, > > sorry for possible off-topic, I really did not know where to ask this. > > I'm going to visit USA for two weeks. I want to buy a local prepaid SIM > card mostly for IP access. > > Is it possible in USA to buy a prepaid SIM as a visitor, without long > term contract? > > I need a public (can be dynamic) IP address, NOT over NAT, and (or) > IPv6, if possible. > > My phone is GSM UMTS 3G. > > Expected traffic volume is about 10G. > > Will use it in New York City and Orlando City, not in rural areas. > > Good data roaming tariff in Cannada will be a big advantage. > > What can you advice? > > Thank you! > Walmart has the prepaid no contract Straight Talk plans that can be on VZW, T-Mobile, or AT&T. Grab a BYOD kit either from a Walmart store or order online. I keep a mobile hotspot deactivated and ready to add a service plan to for my customers if they have an outage. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jhellenthal at dataix.net Sun Sep 17 17:43:44 2017 From: jhellenthal at dataix.net (J. Hellenthal) Date: Sun, 17 Sep 2017 12:43:44 -0500 Subject: USA local SIM card In-Reply-To: <9ed27335-cf4f-4ace-88fa-e5316e4e8aa4@2mbit.com> References: <59BEABEC.7020101@netassist.ua> <9ed27335-cf4f-4ace-88fa-e5316e4e8aa4@2mbit.com> Message-ID: Ting isn’t too bad either for pricing but can’t speak to service quality but we have a few people that use them and haven’t heard much complaints. https://ting.com/?gclid=EAIaIQobChMInKW-mOKs1gIVglqGCh2CvQcDEAAYASAAEgLVSPD_BwE -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Sep 17, 2017, at 12:15, Brielle Bruns wrote: > On 9/17/2017 11:07 AM, Max Tulyev wrote: > Hi All, > sorry for possible off-topic, I really did not know where to ask this. > I'm going to visit USA for two weeks. I want to buy a local prepaid SIM > card mostly for IP access. > Is it possible in USA to buy a prepaid SIM as a visitor, without long > term contract? > I need a public (can be dynamic) IP address, NOT over NAT, and (or) > IPv6, if possible. > My phone is GSM UMTS 3G. > Expected traffic volume is about 10G. > Will use it in New York City and Orlando City, not in rural areas. > Good data roaming tariff in Cannada will be a big advantage. > What can you advice? > Thank you! Walmart has the prepaid no contract Straight Talk plans that can be on VZW, T-Mobile, or AT&T. Grab a BYOD kit either from a Walmart store or order online. I keep a mobile hotspot deactivated and ready to add a service plan to for my customers if they have an outage. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jared at puck.nether.net Sun Sep 17 17:47:56 2017 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 17 Sep 2017 13:47:56 -0400 Subject: USA local SIM card In-Reply-To: <9ed27335-cf4f-4ace-88fa-e5316e4e8aa4@2mbit.com> References: <59BEABEC.7020101@netassist.ua> <9ed27335-cf4f-4ace-88fa-e5316e4e8aa4@2mbit.com> Message-ID: <328140C5-59BE-41E8-B5ED-459CD7FCC53D@puck.nether.net> Many of the MVNOs don’t work well if you wander to the more remote parts of the US. I’ve used ultra.me before with good luck. Jared Mauch > On Sep 17, 2017, at 1:15 PM, Brielle Bruns wrote: > >> On 9/17/2017 11:07 AM, Max Tulyev wrote: >> Hi All, >> sorry for possible off-topic, I really did not know where to ask this. >> I'm going to visit USA for two weeks. I want to buy a local prepaid SIM >> card mostly for IP access. >> Is it possible in USA to buy a prepaid SIM as a visitor, without long >> term contract? >> I need a public (can be dynamic) IP address, NOT over NAT, and (or) >> IPv6, if possible. >> My phone is GSM UMTS 3G. >> Expected traffic volume is about 10G. >> Will use it in New York City and Orlando City, not in rural areas. >> Good data roaming tariff in Cannada will be a big advantage. >> What can you advice? >> Thank you! > > > Walmart has the prepaid no contract Straight Talk plans that can be on VZW, T-Mobile, or AT&T. Grab a BYOD kit either from a Walmart store or order online. > > I keep a mobile hotspot deactivated and ready to add a service plan to for my customers if they have an outage. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org From cb.list6 at gmail.com Sun Sep 17 17:51:07 2017 From: cb.list6 at gmail.com (Ca By) Date: Sun, 17 Sep 2017 17:51:07 +0000 Subject: USA local SIM card In-Reply-To: <59BEABEC.7020101@netassist.ua> References: <59BEABEC.7020101@netassist.ua> Message-ID: On Sun, Sep 17, 2017 at 10:09 AM Max Tulyev wrote: > Hi All, > > sorry for possible off-topic, I really did not know where to ask this. > > I'm going to visit USA for two weeks. I want to buy a local prepaid SIM > card mostly for IP access. > > Is it possible in USA to buy a prepaid SIM as a visitor, without long > term contract? > > I need a public (can be dynamic) IP address, NOT over NAT, and (or) > IPv6, if possible. > > My phone is GSM UMTS 3G. > > Expected traffic volume is about 10G. > > Will use it in New York City and Orlando City, not in rural areas. > > Good data roaming tariff in Cannada will be a big advantage. > > What can you advice? https://prepaid-phones.t-mobile.com/prepaid-international-tourist-plan Includes public ipv6 But here in the USA we UMTS is much poorer experience relative to LTE, you can get a decent LTE unlocked phone for around $100 https://www.bestbuy.com/site/motorola-moto-e4-4g-lte-with-16gb-memory-cell-phone-unlocked-licorice-black/5889300.p?skuId=5889300 Prepaid plans generally wont include roaming to canada > > Thank you! > From mike.lyon at gmail.com Sun Sep 17 18:03:07 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Sun, 17 Sep 2017 11:03:07 -0700 Subject: USA local SIM card In-Reply-To: References: <59BEABEC.7020101@netassist.ua> Message-ID: <03937EB9-FB99-462F-BE89-C121AF9114BD@gmail.com> GoogleFi https://fi.google.com/about/ > On Sep 17, 2017, at 10:51, Ca By wrote: > >> On Sun, Sep 17, 2017 at 10:09 AM Max Tulyev wrote: >> >> Hi All, >> >> sorry for possible off-topic, I really did not know where to ask this. >> >> I'm going to visit USA for two weeks. I want to buy a local prepaid SIM >> card mostly for IP access. >> >> Is it possible in USA to buy a prepaid SIM as a visitor, without long >> term contract? >> >> I need a public (can be dynamic) IP address, NOT over NAT, and (or) >> IPv6, if possible. >> >> My phone is GSM UMTS 3G. >> >> Expected traffic volume is about 10G. >> >> Will use it in New York City and Orlando City, not in rural areas. >> >> Good data roaming tariff in Cannada will be a big advantage. >> >> What can you advice? > > > https://prepaid-phones.t-mobile.com/prepaid-international-tourist-plan > > Includes public ipv6 > > But here in the USA we UMTS is much poorer experience relative to LTE, you > can get a decent LTE unlocked phone for around $100 > > https://www.bestbuy.com/site/motorola-moto-e4-4g-lte-with-16gb-memory-cell-phone-unlocked-licorice-black/5889300.p?skuId=5889300 > > Prepaid plans generally wont include roaming to canada > > > >> >> Thank you! >> From edugas at unknowndevice.ca Sun Sep 17 18:33:34 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Sun, 17 Sep 2017 14:33:34 -0400 Subject: USA local SIM card In-Reply-To: <59BEABEC.7020101@netassist.ua> References: <59BEABEC.7020101@netassist.ua> Message-ID: I'm using KnowRoaming in Europe. Didn't used it in the States yet but in Canada, I was on Bell LTE network. Pretty sure it's behind NAT though (it is on KPN in NL anyway). On Sep 17, 2017 19:08, "Max Tulyev" wrote: > Hi All, > > sorry for possible off-topic, I really did not know where to ask this. > > I'm going to visit USA for two weeks. I want to buy a local prepaid SIM > card mostly for IP access. > > Is it possible in USA to buy a prepaid SIM as a visitor, without long > term contract? > > I need a public (can be dynamic) IP address, NOT over NAT, and (or) > IPv6, if possible. > > My phone is GSM UMTS 3G. > > Expected traffic volume is about 10G. > > Will use it in New York City and Orlando City, not in rural areas. > > Good data roaming tariff in Cannada will be a big advantage. > > What can you advice? > > Thank you! > From mike.lyon at gmail.com Sun Sep 17 18:40:56 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Sun, 17 Sep 2017 11:40:56 -0700 Subject: USA local SIM card In-Reply-To: References: <59BEABEC.7020101@netassist.ua> <03937EB9-FB99-462F-BE89-C121AF9114BD@gmail.com> Message-ID: Eh, kinda, but not really.... https://ios.gadgethacks.com/how-to/set-up-googles-project-fi-your-iphone-0174991/ I used ProjectFi SIMs in my iphone and also in my Peplink LTE routers. Not as fast as VZW but they work. -Mike > On Sep 17, 2017, at 11:19, Caleb Smith wrote: > > Google Fi is great and all, however right now you're limited to only being able to use 3 models of phone on the network, wouldn't recommended that for an overseas traveler. > >> On Sun, Sep 17, 2017, 12:04 PM wrote: >> GoogleFi >> >> https://fi.google.com/about/ >> >> > On Sep 17, 2017, at 10:51, Ca By wrote: >> > >> >> On Sun, Sep 17, 2017 at 10:09 AM Max Tulyev wrote: >> >> >> >> Hi All, >> >> >> >> sorry for possible off-topic, I really did not know where to ask this. >> >> >> >> I'm going to visit USA for two weeks. I want to buy a local prepaid SIM >> >> card mostly for IP access. >> >> >> >> Is it possible in USA to buy a prepaid SIM as a visitor, without long >> >> term contract? >> >> >> >> I need a public (can be dynamic) IP address, NOT over NAT, and (or) >> >> IPv6, if possible. >> >> >> >> My phone is GSM UMTS 3G. >> >> >> >> Expected traffic volume is about 10G. >> >> >> >> Will use it in New York City and Orlando City, not in rural areas. >> >> >> >> Good data roaming tariff in Cannada will be a big advantage. >> >> >> >> What can you advice? >> > >> > >> > https://prepaid-phones.t-mobile.com/prepaid-international-tourist-plan >> > >> > Includes public ipv6 >> > >> > But here in the USA we UMTS is much poorer experience relative to LTE, you >> > can get a decent LTE unlocked phone for around $100 >> > >> > https://www.bestbuy.com/site/motorola-moto-e4-4g-lte-with-16gb-memory-cell-phone-unlocked-licorice-black/5889300.p?skuId=5889300 >> > >> > Prepaid plans generally wont include roaming to canada >> > >> > >> > >> >> >> >> Thank you! >> >> From jfmezei_nanog at vaxination.ca Sun Sep 17 19:52:07 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 17 Sep 2017 15:52:07 -0400 Subject: USA local SIM card In-Reply-To: <59BEABEC.7020101@netassist.ua> References: <59BEABEC.7020101@netassist.ua> Message-ID: <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> On 2017-09-17 13:07, Max Tulyev wrote: AT&T's $45 prepaid pans and its more expemsive sibbling (I think $65) allow over 6GB of data at LTE speeds, and the rest is unlimited but at 2G speeds (I think). The AT&T plans at the $45 and higher levels allows data and voice roaming into Canada, as long as your usage in Canada represents less than 50% of total use. The AT&T plan allows you to remove video throttling (the T-Mobile plan doesn't and has more severe net neutrality violations). If you obtain a SIM card from eBay, there is a hard to find web access to set it up (normal AT&T web site forces you to buy a SIM card which AT&T won't deliver outside of USA). https://www.att.com/prepaid/activations/#/activate.html In my case, I choose AT&T because I tested T-Mobile a few years ago along the route taken and found too many areas without service, interestingly, one area where in 1998-1999, I had service with Omnipoint on a 1900 only phone (Fort Edward NY). Note on T-Mobile: its coverage map expects you to be on postpaid plans which includes areas where you're allowed to roam on AT&T, but not necessarily if on prepaid, so hard to tell if you will really get service based on its maps. Also note: AT&T on an iPhone gets to disable the "manual" seach for available carriers, so you can't test in a town if T-Mobile would also be available. You can insert you own SIM card just to scan for networks and with roaming disbaled, you won't encurr any charges by home carrier. From jfmezei_nanog at vaxination.ca Sun Sep 17 19:55:12 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 17 Sep 2017 15:55:12 -0400 Subject: USA local SIM card In-Reply-To: <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> References: <59BEABEC.7020101@netassist.ua> <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> Message-ID: BTW, AT&T's prefered roaming partner in Canada is Rogers. In other words, if you have an AT&T SIM card, it will try to log in first via Rogers. I assume it also roams with Bell/Telus as second choices but have not been able to test it. From jfmezei_nanog at vaxination.ca Sun Sep 17 20:35:47 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 17 Sep 2017 16:35:47 -0400 Subject: USA local SIM card In-Reply-To: References: <59BEABEC.7020101@netassist.ua> <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> Message-ID: Addituinal notes: When setting up AT&T prepaid, at one point you need to insert the SIM into your handset in order to receive a confirmation code (your login password). I know this process works while the handset is in Canada. Even though service is not yet activated on this SIM, the SIM can still receive SMS from AT&T via the Rogers network. I *assume* this would work from other countries as well but can't garantee. Rogers and AT&T tend to have fairly compatible and very "connected" systems for roaming as AT&T Wireless(original company) used to own a big chunk of Rogers Wireless. (this step is required for you to login to your new account, deposit funds via credit card and choose your package). From maxtul at netassist.ua Sun Sep 17 20:40:29 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 17 Sep 2017 23:40:29 +0300 Subject: USA local SIM card In-Reply-To: <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> References: <59BEABEC.7020101@netassist.ua> <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> Message-ID: <59BEDDBD.9040507@netassist.ua> Nice advertising, thank you! =) But still have open some questions I asked before: 1. My phone is not LTE but 3G GSM/UMTS capable (all bands, 850/900/1700/1900/2100). Will it work? Is 3G coverage good enough in New York and Orlando for VoIP calls (SIP, Viber, Skype)? 2. Is there public or private IP address? IPv6? On 17.09.17 22:52, Jean-Francois Mezei wrote: > On 2017-09-17 13:07, Max Tulyev wrote: > > > AT&T's $45 prepaid pans and its more expemsive sibbling (I think $65) > allow over 6GB of data at LTE speeds, and the rest is unlimited but at > 2G speeds (I think). > > > The AT&T plans at the $45 and higher levels allows data and voice > roaming into Canada, as long as your usage in Canada represents less > than 50% of total use. > > The AT&T plan allows you to remove video throttling (the T-Mobile plan > doesn't and has more severe net neutrality violations). > > If you obtain a SIM card from eBay, there is a hard to find web access > to set it up (normal AT&T web site forces you to buy a SIM card which > AT&T won't deliver outside of USA). > > https://www.att.com/prepaid/activations/#/activate.html > > In my case, I choose AT&T because I tested T-Mobile a few years ago > along the route taken and found too many areas without service, > interestingly, one area where in 1998-1999, I had service with Omnipoint > on a 1900 only phone (Fort Edward NY). > > Note on T-Mobile: its coverage map expects you to be on postpaid plans > which includes areas where you're allowed to roam on AT&T, but not > necessarily if on prepaid, so hard to tell if you will really get > service based on its maps. > > Also note: AT&T on an iPhone gets to disable the "manual" seach for > available carriers, so you can't test in a town if T-Mobile would also > be available. You can insert you own SIM card just to scan for networks > and with roaming disbaled, you won't encurr any charges by home carrier. > From jfmezei_nanog at vaxination.ca Sun Sep 17 20:56:01 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 17 Sep 2017 16:56:01 -0400 Subject: IOS new versions and network load Message-ID: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> A couple years ago, Apple unleashed an IOS update which made the news because network operators reported serious congestion on their networks as everyone and their uncle tried to download the gig+ package at 11:00 PDT. Was the problem solved simply by Apple staggering the announcement of downloads? or were there distribution network changes also made to reduce the load? In Canada, during net neutralirty hearings, it was revealed that cellular carriers zero rated over the air updates. I know my iPhone gets updates without me asking for them, only getting a "update ready to install" while on a long cycling ride (aka: must have used cellular data). Does anyone know whether this is pushed by Apple who has gotten the OK form individual carriers, or is it pushed by carriers (with Apple's OK) in a low priorioty stream that doesn't cause congestion on cellular network? (carriers delivering content in "push mode" would change their role). From tshaw at oitc.com Sun Sep 17 21:29:33 2017 From: tshaw at oitc.com (TR Shaw) Date: Sun, 17 Sep 2017 17:29:33 -0400 Subject: USA local SIM card In-Reply-To: <59BEDDBD.9040507@netassist.ua> References: <59BEABEC.7020101@netassist.ua> <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> <59BEDDBD.9040507@netassist.ua> Message-ID: <0D892FAC-1CA7-4903-A881-B08E6AEC018A@oitc.com> If you are talking about Orlando/Central Florida (or anywhere in FL) now or in next couple of weeks be advised that coverage is still spotty for both voice and data due to the hurricane. > On Sep 17, 2017, at 4:40 PM, Max Tulyev wrote: > > Nice advertising, thank you! =) > > But still have open some questions I asked before: > > 1. My phone is not LTE but 3G GSM/UMTS capable (all bands, > 850/900/1700/1900/2100). Will it work? Is 3G coverage good enough in New > York and Orlando for VoIP calls (SIP, Viber, Skype)? > > 2. Is there public or private IP address? IPv6? > > On 17.09.17 22:52, Jean-Francois Mezei wrote: >> On 2017-09-17 13:07, Max Tulyev wrote: >> >> >> AT&T's $45 prepaid pans and its more expemsive sibbling (I think $65) >> allow over 6GB of data at LTE speeds, and the rest is unlimited but at >> 2G speeds (I think). >> >> >> The AT&T plans at the $45 and higher levels allows data and voice >> roaming into Canada, as long as your usage in Canada represents less >> than 50% of total use. >> >> The AT&T plan allows you to remove video throttling (the T-Mobile plan >> doesn't and has more severe net neutrality violations). >> >> If you obtain a SIM card from eBay, there is a hard to find web access >> to set it up (normal AT&T web site forces you to buy a SIM card which >> AT&T won't deliver outside of USA). >> >> https://www.att.com/prepaid/activations/#/activate.html >> >> In my case, I choose AT&T because I tested T-Mobile a few years ago >> along the route taken and found too many areas without service, >> interestingly, one area where in 1998-1999, I had service with Omnipoint >> on a 1900 only phone (Fort Edward NY). >> >> Note on T-Mobile: its coverage map expects you to be on postpaid plans >> which includes areas where you're allowed to roam on AT&T, but not >> necessarily if on prepaid, so hard to tell if you will really get >> service based on its maps. >> >> Also note: AT&T on an iPhone gets to disable the "manual" seach for >> available carriers, so you can't test in a town if T-Mobile would also >> be available. You can insert you own SIM card just to scan for networks >> and with roaming disbaled, you won't encurr any charges by home carrier. >> > From jfmezei_nanog at vaxination.ca Sun Sep 17 21:33:36 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 17 Sep 2017 17:33:36 -0400 Subject: USA local SIM card In-Reply-To: <59BEDDBD.9040507@netassist.ua> References: <59BEABEC.7020101@netassist.ua> <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> <59BEDDBD.9040507@netassist.ua> Message-ID: <0f12ea44-99d1-99fb-8bb0-47a28bf2ea57@vaxination.ca> On 2017-09-17 16:40, Max Tulyev wrote: > 1. My phone is not LTE but 3G GSM/UMTS capable (all bands, > 850/900/1700/1900/2100). Will it work? Is 3G coverage good enough in New > York and Orlando for VoIP calls (SIP, Viber, Skype)? 3G coverage is a superset of LTE coverage. (aka: carriers still have some areas that have 3G but not LTE). AT&T has 850 and 1900 in 3G. the AWS (1700/2100) is for LTE only. AT&T has shutdown 2G, but T-Mobile still has it. In Canada, Rogers still has 2G, but Bell/Telus never had 2G. (they went from CDMA to 3G circa 2010). T-Mobile does not have 850. It has AWS (1700/2100) and 1900 in the above list. Originally, it had 1900 only (2G). When it acquired 1700, it deployed 3G on it. But because the big US carriers deemed 1700 to be for LTE once it arrived, very few handset manufacturers provided support for 3G on 1700, especially during the days when handsets coudl only support 3 or 4 frequencies. Many of the hansets custom ordered by T-Mobile and the 3 small new Canadian carriers replaced 1900 support in 3G with 1700 support. (so when Rogers got the Mobilicity customers, many of them had handsets that could not support 3G services in 1900 so Rogers had to get a package to upgrade those customers). T-Mobile has subsequently refarmed 1700 to support LTE, and split its 1900 to support 2G and 3G. It has since acquired some 700 for LTE service, but this is no help to you. However, as a 3G-only user on t-mobile, you are limited to 1900 which has shorter propagation from antennas. So consider that the T-Mobile coverage maps may be built with 700mhz propagation in mind, so you would not get as much coverage on a 1900 only sertvice. There may still be areas where 3G is on 1700, but propagation is similar to 1900. (assuming your handset can support 3G on AWS (1700/2100). Note that AWS (1700/2100) is not used outside North America, even if frequemncies such as 2100 are. Carefully check your handset's specs. > 2. Is there public or private IP address? IPv6? I can't answer this. During my bike trip, I choose AT&T because it is the service which cuases me the least amount of waiting to post a tweet or check emails. Getting the IP address on an iPhone isn't easy so I didn't waste any time doing this. From mel at beckman.org Sun Sep 17 22:17:45 2017 From: mel at beckman.org (Mel Beckman) Date: Sun, 17 Sep 2017 22:17:45 +0000 Subject: IOS new versions and network load In-Reply-To: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> Message-ID: <141D136F-F53B-4B27-AAE5-98130BF3AAAB@beckman.org> My understanding is that these updates can only be downloaded when you're in a Wi-Fi network. -mel via cell > On Sep 17, 2017, at 1:56 PM, Jean-Francois Mezei wrote: > > A couple years ago, Apple unleashed an IOS update which made the news > because network operators reported serious congestion on their networks > as everyone and their uncle tried to download the gig+ package at 11:00 PDT. > > Was the problem solved simply by Apple staggering the announcement of > downloads? or were there distribution network changes also made to > reduce the load? > > > In Canada, during net neutralirty hearings, it was revealed that > cellular carriers zero rated over the air updates. I know my iPhone > gets updates without me asking for them, only getting a "update ready to > install" while on a long cycling ride (aka: must have used cellular data). > > Does anyone know whether this is pushed by Apple who has gotten the OK > form individual carriers, or is it pushed by carriers (with Apple's OK) > in a low priorioty stream that doesn't cause congestion on cellular > network? (carriers delivering content in "push mode" would change their > role). > From jfmezei_nanog at vaxination.ca Sun Sep 17 23:34:29 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 17 Sep 2017 19:34:29 -0400 Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> Message-ID: <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> On 2017-09-17 18:41, Eduardo Schoedler wrote: > https://www.peeringdb.com/net/3554 Peering would reduce an ISP's reliance on transit provider (and thus load on transit providers) hut still present same problem on the ISP's internal network. Also, doesn't Apple use a CDN such as Akamai or L3 to deliver content like that? > "We do have another option to consider - > http://www.apple.com/osx/server/features/#caching-server" Considering Apple has been out of the server business since 2010, Would ISPs really bother installing/configuring (and finding a spot on a rack shelf ) for a Mac Mini only to reduce load once a year ? From jfmezei_nanog at vaxination.ca Sun Sep 17 23:43:50 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 17 Sep 2017 19:43:50 -0400 Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> Message-ID: <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> On 2017-09-17 19:37, Eduardo Schoedler wrote: > Server is an app now, any MacOS can have it running. But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini or iMac at a carrier hotel? If the Server App could run on Linux, or if OS-X could boot on standard servers, perhaps, it it seems to be a very bad fit in carrier/enterprise environments. > Implementation will be a little tricky, because you need your > customers to look a record in your domain. I've tried reading some about it. The cache server app registers with Apple its existence and the IP address ranges it serves When a client wants to download new IOS version, Apple checked and finds that the client's IP is served by the caching server whose "local" IP is a.b.c.d (akaL the inside NAT IP address). Tells client to get version of software from that IP address. The DNS TXT records are used by the Caching Server to get the list of IP blocks it can serve. (not needed in the target small office environments where everyone is on same subnet and the caching server can tell the apple serves the one subnet it seves). From paul at paulstewart.org Sun Sep 17 23:47:10 2017 From: paul at paulstewart.org (Paul Stewart) Date: Sun, 17 Sep 2017 19:47:10 -0400 Subject: IOS new versions and network load In-Reply-To: <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> Message-ID: <94A1A325-73C6-4C50-ABAC-742ED3F96459@paulstewart.org> Apple does use CDN’s and does peer quite a bit as well.. What I have seen is our peering with Apple goes to a certain level of bandwidth and then spills over to CDN’s that we are either peered with or have on-net caches. From our network perspective it’s simply a matter of ensuring there is enough capacit on the peering links and/or cache capacity. If both of those options are exceeded then upstream transit starts to fill in the gap (only seen that happen once). Paul > On Sep 17, 2017, at 7:34 PM, Jean-Francois Mezei wrote: > > On 2017-09-17 18:41, Eduardo Schoedler wrote: >> https://www.peeringdb.com/net/3554 > > Peering would reduce an ISP's reliance on transit provider (and thus > load on transit providers) hut still present same problem on the ISP's > internal network. > > Also, doesn't Apple use a CDN such as Akamai or L3 to deliver content > like that? > >> "We do have another option to consider - >> http://www.apple.com/osx/server/features/#caching-server" > > Considering Apple has been out of the server business since 2010, Would > ISPs really bother installing/configuring (and finding a spot on a rack > shelf ) for a Mac Mini only to reduce load once a year ? > From mel at beckman.org Mon Sep 18 02:47:46 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 18 Sep 2017 02:47:46 +0000 Subject: IOS new versions and network load In-Reply-To: <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> , <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> Message-ID: <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> There used to be a Mac mini "hotel" at Switch networks in Vegas. I think it's still there. -mel > On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei wrote: > >> On 2017-09-17 19:37, Eduardo Schoedler wrote: >> >> Server is an app now, any MacOS can have it running. > > But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini > or iMac at a carrier hotel? If the Server App could run on Linux, or if > OS-X could boot on standard servers, perhaps, it it seems to be a very > bad fit in carrier/enterprise environments. > >> Implementation will be a little tricky, because you need your >> customers to look a record in your domain. > > > I've tried reading some about it. > The cache server app registers with Apple its existence and the IP > address ranges it serves > > When a client wants to download new IOS version, Apple checked and finds > that the client's IP is served by the caching server whose "local" IP is > a.b.c.d (akaL the inside NAT IP address). Tells client to get version of > software from that IP address. > > The DNS TXT records are used by the Caching Server to get the list of IP > blocks it can serve. (not needed in the target small office > environments where everyone is on same subnet and the caching server can > tell the apple serves the one subnet it seves). > From mel at beckman.org Mon Sep 18 02:50:37 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 18 Sep 2017 02:50:37 +0000 Subject: IOS new versions and network load In-Reply-To: <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> , <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca>, <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> Message-ID: <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> It is still there. MacMiniColo. -mel beckman > On Sep 17, 2017, at 7:48 PM, Mel Beckman wrote: > > There used to be a Mac mini "hotel" at Switch networks in Vegas. I think it's still there. > > -mel > >>> On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei wrote: >>> >>> On 2017-09-17 19:37, Eduardo Schoedler wrote: >>> >>> Server is an app now, any MacOS can have it running. >> >> But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini >> or iMac at a carrier hotel? If the Server App could run on Linux, or if >> OS-X could boot on standard servers, perhaps, it it seems to be a very >> bad fit in carrier/enterprise environments. >> >>> Implementation will be a little tricky, because you need your >>> customers to look a record in your domain. >> >> >> I've tried reading some about it. >> The cache server app registers with Apple its existence and the IP >> address ranges it serves >> >> When a client wants to download new IOS version, Apple checked and finds >> that the client's IP is served by the caching server whose "local" IP is >> a.b.c.d (akaL the inside NAT IP address). Tells client to get version of >> software from that IP address. >> >> The DNS TXT records are used by the Caching Server to get the list of IP >> blocks it can serve. (not needed in the target small office >> environments where everyone is on same subnet and the caching server can >> tell the apple serves the one subnet it seves). >> From jbothe at me.com Mon Sep 18 03:05:05 2017 From: jbothe at me.com (JASON BOTHE) Date: Sun, 17 Sep 2017 22:05:05 -0500 Subject: IOS new versions and network load In-Reply-To: <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> Message-ID: My best experience with Apple has been directly peering with them. Definitely handles the update issue without putting strain on transit links. Apple is very well connected. https://www.peeringdb.com/net/3554 Sent from my iPhone > On Sep 17, 2017, at 21:50, Mel Beckman wrote: > > It is still there. MacMiniColo. > > -mel beckman > >> On Sep 17, 2017, at 7:48 PM, Mel Beckman wrote: >> >> There used to be a Mac mini "hotel" at Switch networks in Vegas. I think it's still there. >> >> -mel >> >>>> On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei wrote: >>>> >>>> On 2017-09-17 19:37, Eduardo Schoedler wrote: >>>> >>>> Server is an app now, any MacOS can have it running. >>> >>> But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini >>> or iMac at a carrier hotel? If the Server App could run on Linux, or if >>> OS-X could boot on standard servers, perhaps, it it seems to be a very >>> bad fit in carrier/enterprise environments. >>> >>>> Implementation will be a little tricky, because you need your >>>> customers to look a record in your domain. >>> >>> >>> I've tried reading some about it. >>> The cache server app registers with Apple its existence and the IP >>> address ranges it serves >>> >>> When a client wants to download new IOS version, Apple checked and finds >>> that the client's IP is served by the caching server whose "local" IP is >>> a.b.c.d (akaL the inside NAT IP address). Tells client to get version of >>> software from that IP address. >>> >>> The DNS TXT records are used by the Caching Server to get the list of IP >>> blocks it can serve. (not needed in the target small office >>> environments where everyone is on same subnet and the caching server can >>> tell the apple serves the one subnet it seves). >>> From morrowc.lists at gmail.com Mon Sep 18 04:48:45 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 18 Sep 2017 00:48:45 -0400 Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> Message-ID: On Sun, Sep 17, 2017 at 11:05 PM, JASON BOTHE wrote: > My best experience with Apple has been directly peering with them. > Definitely handles the update issue without putting strain on transit > links. Apple is very well connected. > > https://www.peeringdb.com/net/3554 > > apple is AS714 though, right? or are they having the trucking company do their delivery of bits? > > > > > Sent from my iPhone > > On Sep 17, 2017, at 21:50, Mel Beckman wrote: > > > > It is still there. MacMiniColo. > > > > -mel beckman > > > >> On Sep 17, 2017, at 7:48 PM, Mel Beckman wrote: > >> > >> There used to be a Mac mini "hotel" at Switch networks in Vegas. I > think it's still there. > >> > >> -mel > >> > >>>> On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei < > jfmezei_nanog at vaxination.ca> wrote: > >>>> > >>>> On 2017-09-17 19:37, Eduardo Schoedler wrote: > >>>> > >>>> Server is an app now, any MacOS can have it running. > >>> > >>> But do carriers/ISPs really want to deal with a rack unfriendly Mac > Mini > >>> or iMac at a carrier hotel? If the Server App could run on Linux, or > if > >>> OS-X could boot on standard servers, perhaps, it it seems to be a very > >>> bad fit in carrier/enterprise environments. > >>> > >>>> Implementation will be a little tricky, because you need your > >>>> customers to look a record in your domain. > >>> > >>> > >>> I've tried reading some about it. > >>> The cache server app registers with Apple its existence and the IP > >>> address ranges it serves > >>> > >>> When a client wants to download new IOS version, Apple checked and > finds > >>> that the client's IP is served by the caching server whose "local" IP > is > >>> a.b.c.d (akaL the inside NAT IP address). Tells client to get version > of > >>> software from that IP address. > >>> > >>> The DNS TXT records are used by the Caching Server to get the list of > IP > >>> blocks it can serve. (not needed in the target small office > >>> environments where everyone is on same subnet and the caching server > can > >>> tell the apple serves the one subnet it seves). > >>> > From sean at donelan.com Mon Sep 18 07:54:56 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 18 Sep 2017 03:54:56 -0400 (EDT) Subject: Hurricane Maria: U.S. Virgin Islands suspends recovery efforts Message-ID: U.S. Virigin Islands suspended hurricane recovery efforts on the islands in order to prepare for potential landfall by Hurricane Maria on Tuesday night/Wednesday morning. Hurricane Maria is expected to strengthen to a major hurricane by Monday evening. Storm preparation efforts on the U.S. VI are being shifted to readying shelters and distributing as much food and water to people in advance of the storm. The U.S. VI Governor is warning people most of the temporary repairs from the last hurricane will be knocked out again when Hurricane Maria strikes the islands. Hurricane Maria will also impact other leeward islands beginning Monday, including Guadeloupe, Dominica, St. Kitts, Nevis, and Montserrat, and Martinique. From ren.provo at gmail.com Mon Sep 18 08:27:20 2017 From: ren.provo at gmail.com (Ren Provo) Date: Mon, 18 Sep 2017 09:27:20 +0100 Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> Message-ID: Thank you Jason! Big week ahead for http://as714.peeringdb.com Cheers! -ren.provo at gmail.com > On Sep 18, 2017, at 5:48 AM, Christopher Morrow wrote: > >> On Sun, Sep 17, 2017 at 11:05 PM, JASON BOTHE wrote: >> >> My best experience with Apple has been directly peering with them. >> Definitely handles the update issue without putting strain on transit >> links. Apple is very well connected. >> >> https://www.peeringdb.com/net/3554 >> >> > apple is AS714 though, right? or are they having the trucking company do > their delivery of bits? > > >> >> >> >> >> Sent from my iPhone >>> On Sep 17, 2017, at 21:50, Mel Beckman wrote: >>> >>> It is still there. MacMiniColo. >>> >>> -mel beckman >>> >>>> On Sep 17, 2017, at 7:48 PM, Mel Beckman wrote: >>>> >>>> There used to be a Mac mini "hotel" at Switch networks in Vegas. I >> think it's still there. >>>> >>>> -mel >>>> >>>>>> On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei < >> jfmezei_nanog at vaxination.ca> wrote: >>>>>> >>>>>> On 2017-09-17 19:37, Eduardo Schoedler wrote: >>>>>> >>>>>> Server is an app now, any MacOS can have it running. >>>>> >>>>> But do carriers/ISPs really want to deal with a rack unfriendly Mac >> Mini >>>>> or iMac at a carrier hotel? If the Server App could run on Linux, or >> if >>>>> OS-X could boot on standard servers, perhaps, it it seems to be a very >>>>> bad fit in carrier/enterprise environments. >>>>> >>>>>> Implementation will be a little tricky, because you need your >>>>>> customers to look a record in your domain. >>>>> >>>>> >>>>> I've tried reading some about it. >>>>> The cache server app registers with Apple its existence and the IP >>>>> address ranges it serves >>>>> >>>>> When a client wants to download new IOS version, Apple checked and >> finds >>>>> that the client's IP is served by the caching server whose "local" IP >> is >>>>> a.b.c.d (akaL the inside NAT IP address). Tells client to get version >> of >>>>> software from that IP address. >>>>> >>>>> The DNS TXT records are used by the Caching Server to get the list of >> IP >>>>> blocks it can serve. (not needed in the target small office >>>>> environments where everyone is on same subnet and the caching server >> can >>>>> tell the apple serves the one subnet it seves). >>>>> >> From job at ntt.net Mon Sep 18 08:37:17 2017 From: job at ntt.net (Job Snijders) Date: Mon, 18 Sep 2017 09:37:17 +0100 Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> Message-ID: <20170918083717.GP1118@Vurt.local> On Mon, Sep 18, 2017 at 12:48:45AM -0400, Christopher Morrow wrote: > On Sun, Sep 17, 2017 at 11:05 PM, JASON BOTHE wrote: > > My best experience with Apple has been directly peering with them. > > Definitely handles the update issue without putting strain on transit > > links. Apple is very well connected. > > > > https://www.peeringdb.com/net/3554 > > apple is AS714 though, right? or are they having the trucking company > do their delivery of bits? You may be shuffling the opaque peeringdb 'net_id' that is assigned to each network with the ASN of such a network. These entry points lead to the same information: https://www.peeringdb.com/asn/714 https://as714.peeringdb.com/ https://www.peeringdb.com/net/3554 Kind regards, Job From nanog at ics-il.net Mon Sep 18 12:48:10 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Sep 2017 07:48:10 -0500 (CDT) Subject: IOS new versions and network load In-Reply-To: <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> Message-ID: <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> We've been looking into the caching server bit lately given that we're not due to get an official Apple node for at least another year yet. It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement. The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675 ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" To: "Eduardo Schoedler" Cc: Nanog at nanog.org Sent: Sunday, September 17, 2017 6:43:50 PM Subject: Re: IOS new versions and network load On 2017-09-17 19:37, Eduardo Schoedler wrote: > Server is an app now, any MacOS can have it running. But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini or iMac at a carrier hotel? If the Server App could run on Linux, or if OS-X could boot on standard servers, perhaps, it it seems to be a very bad fit in carrier/enterprise environments. > Implementation will be a little tricky, because you need your > customers to look a record in your domain. I've tried reading some about it. The cache server app registers with Apple its existence and the IP address ranges it serves When a client wants to download new IOS version, Apple checked and finds that the client's IP is served by the caching server whose "local" IP is a.b.c.d (akaL the inside NAT IP address). Tells client to get version of software from that IP address. The DNS TXT records are used by the Caching Server to get the list of IP blocks it can serve. (not needed in the target small office environments where everyone is on same subnet and the caching server can tell the apple serves the one subnet it seves). From paul at paulstewart.org Mon Sep 18 12:53:00 2017 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 18 Sep 2017 08:53:00 -0400 Subject: IOS new versions and network load In-Reply-To: <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> Message-ID: <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> Curious as mentioned if anyone doing this on scale? I kind of doubt it but love to hear otherwise. My assumption is this is more Enterprise focused than ISP Paul Sent from my iPhone > On Sep 18, 2017, at 8:48 AM, Mike Hammett wrote: > > We've been looking into the caching server bit lately given that we're not due to get an official Apple node for at least another year yet. > > It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement. > > The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675 > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Jean-Francois Mezei" > To: "Eduardo Schoedler" > Cc: Nanog at nanog.org > Sent: Sunday, September 17, 2017 6:43:50 PM > Subject: Re: IOS new versions and network load > >> On 2017-09-17 19:37, Eduardo Schoedler wrote: >> >> Server is an app now, any MacOS can have it running. > > But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini > or iMac at a carrier hotel? If the Server App could run on Linux, or if > OS-X could boot on standard servers, perhaps, it it seems to be a very > bad fit in carrier/enterprise environments. > >> Implementation will be a little tricky, because you need your >> customers to look a record in your domain. > > > I've tried reading some about it. > The cache server app registers with Apple its existence and the IP > address ranges it serves > > When a client wants to download new IOS version, Apple checked and finds > that the client's IP is served by the caching server whose "local" IP is > a.b.c.d (akaL the inside NAT IP address). Tells client to get version of > software from that IP address. > > The DNS TXT records are used by the Caching Server to get the list of IP > blocks it can serve. (not needed in the target small office > environments where everyone is on same subnet and the caching server can > tell the apple serves the one subnet it seves). > > From nanog at ics-il.net Mon Sep 18 12:58:16 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Sep 2017 07:58:16 -0500 (CDT) Subject: IOS new versions and network load In-Reply-To: <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> Message-ID: <664856873.66819.1505739492896.JavaMail.mhammett@ThunderFuck> *nods* It appears to be very enterprise focused, but then it's mentioned on their PeeringDB page, so that makes one wonder. It doesn't seem like it would be easy for an ISP to manage given that they can't set the required domain search field via static or PPPoE. That would leave DHCP as the only way to assign that field and then that's assuming that whatever router is at the customer location passes that field through to the end user devices. It seems like it would be a lot more effective to ditch the requirement for the domain search field and just let the caching server tell Apple what prefixes it supports and there be an automated verification system using RIR records that the request is legitimate. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Paul Stewart" To: "Mike Hammett" Cc: Nanog at nanog.org Sent: Monday, September 18, 2017 7:53:00 AM Subject: Re: IOS new versions and network load Curious as mentioned if anyone doing this on scale? I kind of doubt it but love to hear otherwise. My assumption is this is more Enterprise focused than ISP Paul Sent from my iPhone > On Sep 18, 2017, at 8:48 AM, Mike Hammett wrote: > > We've been looking into the caching server bit lately given that we're not due to get an official Apple node for at least another year yet. > > It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement. > > The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675 > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Jean-Francois Mezei" > To: "Eduardo Schoedler" > Cc: Nanog at nanog.org > Sent: Sunday, September 17, 2017 6:43:50 PM > Subject: Re: IOS new versions and network load > >> On 2017-09-17 19:37, Eduardo Schoedler wrote: >> >> Server is an app now, any MacOS can have it running. > > But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini > or iMac at a carrier hotel? If the Server App could run on Linux, or if > OS-X could boot on standard servers, perhaps, it it seems to be a very > bad fit in carrier/enterprise environments. > >> Implementation will be a little tricky, because you need your >> customers to look a record in your domain. > > > I've tried reading some about it. > The cache server app registers with Apple its existence and the IP > address ranges it serves > > When a client wants to download new IOS version, Apple checked and finds > that the client's IP is served by the caching server whose "local" IP is > a.b.c.d (akaL the inside NAT IP address). Tells client to get version of > software from that IP address. > > The DNS TXT records are used by the Caching Server to get the list of IP > blocks it can serve. (not needed in the target small office > environments where everyone is on same subnet and the caching server can > tell the apple serves the one subnet it seves). > > From lguillory at reservetele.com Mon Sep 18 13:52:40 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 18 Sep 2017 13:52:40 +0000 Subject: IOS new versions and network load In-Reply-To: <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart Sent: Monday, September 18, 2017 7:53 AM To: Mike Hammett Cc: Nanog at nanog.org Subject: Re: IOS new versions and network load Curious as mentioned if anyone doing this on scale? I kind of doubt it but love to hear otherwise. My assumption is this is more Enterprise focused than ISP Paul Sent from my iPhone > On Sep 18, 2017, at 8:48 AM, Mike Hammett wrote: > > We've been looking into the caching server bit lately given that we're not due to get an official Apple node for at least another year yet. > > It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement. > > The caching service does support a lot more than content than "once a > year" https://support.apple.com/en-us/HT204675 > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Jean-Francois Mezei" > To: "Eduardo Schoedler" > Cc: Nanog at nanog.org > Sent: Sunday, September 17, 2017 6:43:50 PM > Subject: Re: IOS new versions and network load > >> On 2017-09-17 19:37, Eduardo Schoedler wrote: >> >> Server is an app now, any MacOS can have it running. > > But do carriers/ISPs really want to deal with a rack unfriendly Mac > Mini or iMac at a carrier hotel? If the Server App could run on Linux, > or if OS-X could boot on standard servers, perhaps, it it seems to be > a very bad fit in carrier/enterprise environments. > >> Implementation will be a little tricky, because you need your >> customers to look a record in your domain. > > > I've tried reading some about it. > The cache server app registers with Apple its existence and the IP > address ranges it serves > > When a client wants to download new IOS version, Apple checked and > finds that the client's IP is served by the caching server whose > "local" IP is a.b.c.d (akaL the inside NAT IP address). Tells client > to get version of software from that IP address. > > The DNS TXT records are used by the Caching Server to get the list of > IP blocks it can serve. (not needed in the target small office > environments where everyone is on same subnet and the caching server > can tell the apple serves the one subnet it seves). > > From sethm at rollernet.us Mon Sep 18 15:41:38 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 18 Sep 2017 08:41:38 -0700 Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> Message-ID: On 9/17/17 20:05, JASON BOTHE wrote: > My best experience with Apple has been directly peering with them. Definitely handles the update issue without putting strain on transit links. Apple is very well connected. The cache thing mentioned in their peeringdb entry appears useless outside of an enterprise environment where a DNS search domain can be forced. Ideally the cache should be able to speak BGP and learn prefixes that way, especially if Apple can't or won't peer in a region. ~Seth From marco at marcoslater.com Mon Sep 18 15:57:55 2017 From: marco at marcoslater.com (Marco Slater) Date: Mon, 18 Sep 2017 16:57:55 +0100 Subject: IOS new versions and network load In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> Message-ID: <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> > While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title. Would you be open to elaborating a bit on how that’s set up on your network? :) Regards, Marco Slater On 18 Sep 2017, 14:55 +0100, Luke Guillory , wrote: > While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title. > > > > > > > > Luke Guillory > Vice President – Technology and Innovation > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > _________________________________________________________________________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart > Sent: Monday, September 18, 2017 7:53 AM > To: Mike Hammett > Cc: Nanog at nanog.org > Subject: Re: IOS new versions and network load > > Curious as mentioned if anyone doing this on scale? I kind of doubt it but love to hear otherwise. My assumption is this is more Enterprise focused than ISP > > Paul > > Sent from my iPhone > > > On Sep 18, 2017, at 8:48 AM, Mike Hammett wrote: > > > > We've been looking into the caching server bit lately given that we're not due to get an official Apple node for at least another year yet. > > > > It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement. > > > > The caching service does support a lot more than content than "once a > > year" https://support.apple.com/en-us/HT204675 > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Jean-Francois Mezei" > To: "Eduardo Schoedler" > Cc: Nanog at nanog.org > > Sent: Sunday, September 17, 2017 6:43:50 PM > > Subject: Re: IOS new versions and network load > > > > > On 2017-09-17 19:37, Eduardo Schoedler wrote: > > > > > > Server is an app now, any MacOS can have it running. > > > > But do carriers/ISPs really want to deal with a rack unfriendly Mac > > Mini or iMac at a carrier hotel? If the Server App could run on Linux, > > or if OS-X could boot on standard servers, perhaps, it it seems to be > > a very bad fit in carrier/enterprise environments. > > > > > Implementation will be a little tricky, because you need your > > > customers to look a record in your domain. > > > > > > I've tried reading some about it. > > The cache server app registers with Apple its existence and the IP > > address ranges it serves > > > > When a client wants to download new IOS version, Apple checked and > > finds that the client's IP is served by the caching server whose > > "local" IP is a.b.c.d (akaL the inside NAT IP address). Tells client > > to get version of software from that IP address. > > > > The DNS TXT records are used by the Caching Server to get the list of > > IP blocks it can serve. (not needed in the target small office > > environments where everyone is on same subnet and the caching server > > can tell the apple serves the one subnet it seves). > > > > > From valdis.kletnieks at vt.edu Mon Sep 18 16:14:11 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 18 Sep 2017 12:14:11 -0400 Subject: IOS new versions and network load In-Reply-To: <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> Message-ID: <82994.1505751251@turing-police.cc.vt.edu> On Mon, 18 Sep 2017 16:57:55 +0100, Marco Slater said: > > While we don���t use Apple's caching servers we do have transparent caching > > in place which nets us about 82% of their content being serverd locally. On a > > big IOS update it will probably be close to 99% for that one title. > Would you be open to elaborating a bit on how that���s set up on your network? :) I'm particularly interested in how they introspect https:// targets. Apple *IS* using https:// (or other TLS-secured connections), right? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From jared at puck.nether.net Mon Sep 18 16:19:14 2017 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Sep 2017 12:19:14 -0400 Subject: IOS new versions and network load In-Reply-To: <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> Message-ID: <6C748BF2-627A-4ED0-AFF5-908E818ECD4F@puck.nether.net> > On Sep 18, 2017, at 11:57 AM, Marco Slater wrote: > >> While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title. > > Would you be open to elaborating a bit on how that’s set up on your network? :) I used to run a transparent cache that redirected tcp/80 traffic to a squid instance that was configured to hold the objects for an extended period of time and ignore the do-not-cache type options sent from the CDNs. A quick search in your favorite AltaVista location returns URLs like this: https://lkrms.org/caching-ios-updates-on-a-squid-proxy-server/ - Jared From jared at puck.nether.net Mon Sep 18 16:30:24 2017 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Sep 2017 12:30:24 -0400 Subject: IOS new versions and network load In-Reply-To: <82994.1505751251@turing-police.cc.vt.edu> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <82994.1505751251@turing-police.cc.vt.edu> Message-ID: <05597439-59A8-4313-BC6F-E725E371B491@puck.nether.net> > On Sep 18, 2017, at 12:14 PM, valdis.kletnieks at vt.edu wrote: > > On Mon, 18 Sep 2017 16:57:55 +0100, Marco Slater said: >>> While we don’t use Apple's caching servers we do have transparent caching >>> in place which nets us about 82% of their content being serverd locally. On a >>> big IOS update it will probably be close to 99% for that one title. > >> Would you be open to elaborating a bit on how that’s set up on your network? :) > > I'm particularly interested in how they introspect https:// targets. Apple *IS* using > https:// (or other TLS-secured connections), right? I see no https in the XML right now. Only these hostnames are referenced: appldnld.apple.com appldnld.apple.com.edgesuite.net apsu.apple.com - Jared From jfmezei_nanog at vaxination.ca Mon Sep 18 17:11:22 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 18 Sep 2017 13:11:22 -0400 Subject: IOS new versions and network load In-Reply-To: <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> Message-ID: On 2017-09-18 08:48, Mike Hammett wrote: > It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement. I would have to read the stuff again, but my understanding is: caching server starts. caching server registers with Apple, gives it its local IP, as well as the IP ranges that it manages. When a client wants something, it first reaches out to an Apple server. That server decides which content server is nearest to the client, and if there is a caching server in the same network, will give the client the IP address to access that local caching server. (and this is where there is NAT friendliness , as other have pointed out, designed mostlty for enterprise). The business about TXT records is to allow real IPs with multiple ranges to be used. I *assume* that it is the caching server which reads those records upon startup and then transmits it to Apple when it "logs in" as a caching server. You can have up to 24 chained TXT records to list all the IP blocks you can service. From nanog at ics-il.net Mon Sep 18 17:14:15 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Sep 2017 12:14:15 -0500 (CDT) Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> Message-ID: <788388926.67393.1505754853540.JavaMail.mhammett@ThunderFuck> They also say the domain needs to be in your domain search field on your end user device, meaning I think the enduser device looks up whatever default hostname, appending whatever domain name is in your client. Your authoritative DNS then returns the IP of your Apple cache. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" To: nanog at nanog.org Sent: Monday, September 18, 2017 12:11:22 PM Subject: Re: IOS new versions and network load On 2017-09-18 08:48, Mike Hammett wrote: > It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement. I would have to read the stuff again, but my understanding is: caching server starts. caching server registers with Apple, gives it its local IP, as well as the IP ranges that it manages. When a client wants something, it first reaches out to an Apple server. That server decides which content server is nearest to the client, and if there is a caching server in the same network, will give the client the IP address to access that local caching server. (and this is where there is NAT friendliness , as other have pointed out, designed mostlty for enterprise). The business about TXT records is to allow real IPs with multiple ranges to be used. I *assume* that it is the caching server which reads those records upon startup and then transmits it to Apple when it "logs in" as a caching server. You can have up to 24 chained TXT records to list all the IP blocks you can service. From jordi.palet at consulintel.es Mon Sep 18 17:58:38 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 18 Sep 2017 14:58:38 -0300 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: <19206460-B77B-4E74-BBDD-084D438228C5@consulintel.es> Fully agree, 464XLAT is the way to go. We have tested this in many IPv6-only access deployments, non-cellular networks (cellular is well tested by T-Mobile and others, that have got it in production for years). We always have the issue of the CPEs support, but this is the same problem if you want to go to lw4o6, MAP, etc. In general, newer transition mechanisms, aren’t well supported. So, you either use OpenWRT if you can re-flash the CPEs, or you push your vendors to make sure they provide a firmware upgrade. This is the reason I started to work on an update of the RFC7084 (https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ and https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis-transition/) and see also the related discussion in v6ops. Also, I run a panel with CPE vendors in the last week APNIC meeting, and the interesting thing is that they confirmed there is no any technical issue to support those (hardware is ok), and they have already developed it, just waiting for customers to ask for it. https://conference.apnic.net/44/program/schedule/#/day/6/bof-discussion-with-ipv6-ce-vendors I will compile a report out of this panel ASAP. So please, keep pushing your vendors for it! Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Brock Tice Responder a: Fecha: viernes, 15 de septiembre de 2017, 17:14 Para: Fredrik Sallinen CC: Asunto: Re: IPv6 migration steps for mid-scale isp We are small but we are just about out of IPv4 and aren't going to get or buy any more. We have been testing for a while. > Shall I go for IPv6-only deployment or dual stack? You should plan for adding customers eventually that are IPv6-only, unless you have all the v4 you will ever need, and you will need to reserve IPv4 address blocks for translation. > How to identify address CPE and legacy application issues? Legacy application issues can be solved (for the most part) with 464XLAT, which also solves IP-literal-in-HTML problems. You need PLAT at the core and CLAT at the client. Unfortunately so far the only good way we've found to do CLAT is OpenWRT on the CPE or router. We are getting ready to bundle Linksys routers flashed with OpenWRT. For PLAT at the core we are running jool. It's actually quite simple to set up and we are currently using OSPF to do anycast, but we will probably be migrating to a single set of HA servers in the core. The good news is that even if it goes down, Netflix and Facebook will still work as they are fully functional on v6. We have tested this in my home and at my office with IPv6-only VLANs/wireless SSIDs, mostly without a hitch. If you run this setup without the CLAT on the client side you get NAT64 so it still will work for most things. I would be very, very happy if larger ISPs would put pressure on router manufacturers to support CLAT, we have no clout. I would also love to hear if any of this is stupid or if there's a better way. --Brock ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From joelja at bogus.com Mon Sep 18 21:03:43 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 18 Sep 2017 14:03:43 -0700 Subject: 100G QSFP28 DAC cables - experience In-Reply-To: References: Message-ID: On 9/6/17 00:17, Jiri Prochazka wrote: > Hi folks, > > I'm wondering if anyone have (either positive or negative) experience > with 100G QSFP28 DAC cables? I found the ones we tested to be substantially more finicky particularly at 5 meter then 10gig dacs, adding 4 x 25 sfp28 breakout on the other end probably isn't a help. We went with AOCs for the equivalent (3, 5 meter) lengths. > Is there anyone who is using 100G DAC in large scale and would > recommend it (which means there are no issues compared to SR4 links)? > > I'm thinking about cables with lenght up to 1m, not more. > > We have had quite bad experience with 10G DAC in the past - but I do > not want to be slave of the past. > > 10g dacs were less reliable then I would have preferred for  3 5 7 meter distances but they were tolerable especially if you leave the bundles alone, 25g was sufficiently less so at least in testing that we didn't try it in the field, being at the limits at 5m was a sufficient problemthat it ruled out some adjacent rack arrangements. so we're all optical for 25/100 > > Thank you for your thoughts! > > > > Jiri >      > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From nathana at fsr.com Mon Sep 18 23:01:43 2017 From: nathana at fsr.com (Nathan Anderson) Date: Mon, 18 Sep 2017 23:01:43 +0000 Subject: USA local SIM card In-Reply-To: <59BEABEC.7020101@netassist.ua> References: <59BEABEC.7020101@netassist.ua> Message-ID: <83d86f1bc10d4896b23d17e4ae9a28df@STONEFISH.FSI.local> I cannot think of any prepaid plans in the U.S. that meet all of your requirements, though I am far from being familiar with all of them. Here is what I (think I) "know", though I would love to be set straight on anything I got wrong or missed: Generally 3G is available wherever LTE is. Between the national GSM/UMTS carriers, AT&T generally has better coverage than T-Mobile does outside of metropolitan areas, so if you are traveling a lot between metros in something other than an aircraft then this is something to consider (though it doesn't sound like this would likely be an issue for you). In some areas, AT&T and T-Mobile might allow you to roam between their networks, but I believe this is pretty rare (esp. on prepaid), so you should plan on being forced to make a decision to be on one network or the other, and just be satisfied with the native coverage of whatever network you pick. The larger issue for you with T-Mobile might be their previous (and ongoing?) use of AWS bands (split 1700MHz uplink/2100 downlink) for 3G service, which very few phones sold outside of the U.S. support. They have been working nationwide to reallocate their AWS licenses to LTE, turn off 2G service on PCS (1900MHz) bands, and move the 3G service to PCS, but my understanding is that it has been taking them a while to complete this migration and I do not know the status of it in any given market. If you are planning to bring your own phone, then don't bother with Verizon or Sprint...not only are they generally hostile to "bring your own phone", but their 3G coverage consists of SIMless EVDO with a fallback to CDMA/1xRTT for voice, NOT GSM/UMTS. Your phone most certainly will not support this. Very very few (if any) prepaid plans, either from the carriers themselves or MVNOs, have roaming in Canada (data or otherwise) built-in to the "plan". You will likely have to buy a separate SIM+plan while you are up there. I have zero knowledge about what the Canadian wireless market looks like so cannot help you there unfortunately. I can also think of exactly zero prepaid offering by either AT&T or T-Mobile that give you non-NAT IPv4 access. As others have said, T-Mobile does offer native v6 (dual-stacked with NATted v4), which of course would not be NAT. If you need publicly-reachable IPv4 you might consider VPNing to an access concentrator that will hand you such an IP when you need it...I happen to know that L2TP+IPsec w/ NAT Traversal happens to work over v4 on most AT&T prepaid plans and the plans of their MVNOs. One popular MVNO here is Straight Talk, a sub-brand of America Movil. They will only sell in blocks of 30 days minimum, but you can get 8GB over 30 days for USD $45 or 12GB for $55. If you exhaust your data allocation then it doesn't cut you off, just throttles you down massively. But if you do exhaust and want full-speed back, you can choose to waive whatever remaining days you have left of the 30 you initially bought and immediately refill your SIM with another 8 or 12GB purchase, which starts the 30 day clock over. The only way to get a SIM in person instead of by mail-order is to buy one of their activation kits at retail from a Wal-Mart store...I believe they are USD $60 and it includes SIMs both for the AT&T and T-Mobile networks (you must choose only one at time of activation) plus a $45 8GB service card (so the SIMs themselves really only cost $15). Unfortunately, if you want the 12GB service plan, other than ordering just a SIM from straighttalk.com and having it shipped to a friend in the States ahead of your travels, I don't know of any way to accomplish that while also being able to avoid paying for the 8GB service card that is included with the retail kit. If you shop for other MVNOs, be very careful to get clarification on what carrier's network they use before you fork over any cash. Many of them only offer access to one carrier, and if that carrier happens to be Sprint or Verizon then no way will it work for you (and there are an awful lot of Sprint-only MVNOs in particular). Just because a certain vendor offers a SIM card doesn't mean it is for a compatible network...Sprint and Verizon use SIM cards for access to their LTE networks. One (admittedly more fiddly) option you may want to consider, which would allow you to use whatever carrier you wanted without needing to be concerned about the underlying network technology or support for particular bands, would be to look into either purchasing a cheap "MiFi"-like device, or see if one of the providers will rent one to you for the duration of your visit. Then you could jump on, say, Verizon's LTE network with the MiFi and have your phone talk to the MiFi with WiFi. You said you were likely to use VoIP for voice communication anyway so not having a SIM in your phone doesn't sound like it would be a problem. (This may not solve your Canada problem, though...you'd still likely have to work out a separate solution for any time spent up there.) Hope this helps, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev Sent: Sunday, September 17, 2017 10:08 AM To: nanog at nanog.org Subject: USA local SIM card Hi All, sorry for possible off-topic, I really did not know where to ask this. I'm going to visit USA for two weeks. I want to buy a local prepaid SIM card mostly for IP access. Is it possible in USA to buy a prepaid SIM as a visitor, without long term contract? I need a public (can be dynamic) IP address, NOT over NAT, and (or) IPv6, if possible. My phone is GSM UMTS 3G. Expected traffic volume is about 10G. Will use it in New York City and Orlando City, not in rural areas. Good data roaming tariff in Cannada will be a big advantage. What can you advice? Thank you! From ray at oneunified.net Mon Sep 18 23:38:43 2017 From: ray at oneunified.net (Raymond Burkholder) Date: Mon, 18 Sep 2017 20:38:43 -0300 Subject: USA local SIM card In-Reply-To: <59BEABEC.7020101@netassist.ua> References: <59BEABEC.7020101@netassist.ua> Message-ID: <8e604751-a9b2-9d2f-175b-21320d49a5bc@oneunified.net> On 09/17/17 14:07, Max Tulyev wrote: > I'm going to visit USA for two weeks. I want to buy a local prepaid SIM > card mostly for IP access. I use these guys when I fly through the US. Can't say who the carrier(s) they might use. Can't say if there was a non-natted address. But I think IPv6 was supplied. https://roammobility.com/ You can mail order the SIM and top it up on demand. > > Is it possible in USA to buy a prepaid SIM as a visitor, without long > term contract? Can activate from a day to a month. > > I need a public (can be dynamic) IP address, NOT over NAT, and (or) > IPv6, if possible. > > My phone is GSM UMTS 3G. > > Expected traffic volume is about 10G. the 1 month plan about covers that. > > Will use it in New York City and Orlando City, not in rural areas. I had no problems at the Newark airport as I passed through. > > Good data roaming tariff in Cannada will be a big advantage. The same guys do something in Canada. I used them for 14 days earlier this year and roamed from the prairies of Alberta through into the Rockies without nary a hiccup. Whether there be a static ip address assigned... don't know. Can't recall if they used Bell or Telus or Rogers. https://roammobility.ca/ This one is different, this is a one-time use SIM. > > What can you advice? > > Thank you! > -- Raymond Burkholder https://blog.raymond.burkholder.net/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jfmezei_nanog at vaxination.ca Tue Sep 19 00:53:55 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 18 Sep 2017 20:53:55 -0400 Subject: USA local SIM card In-Reply-To: <83d86f1bc10d4896b23d17e4ae9a28df@STONEFISH.FSI.local> References: <59BEABEC.7020101@netassist.ua> <83d86f1bc10d4896b23d17e4ae9a28df@STONEFISH.FSI.local> Message-ID: On 2017-09-18 19:01, Nathan Anderson wrote: > The larger issue for you with T-Mobile might be their previous (and ongoing?) use of AWS bands (split 1700MHz uplink/2100 downlink) for 3G service, which very few phones sold outside of the U.S. support. They have been working nationwide to reallocate their AWS licenses to LTE, turn off 2G service on PCS (1900MHz) bands, T-Mobile isn't shutting down its 2G for now. AT&T did and T-Mobile hoped to get IoT business for people whose devices are stuck on 2G. (Think parking meters etc). However, T-Mobile carved a big chunk of its 1900s to support 3G (UMTS/HSPA+) leaving little for 2G. > Very very few (if any) prepaid plans, either from the carriers themselves or MVNOs, have roaming in Canada AT&T's prepaid plans at $45 and $65 provide full roaming into Canada for voice and Data, using your US "bucket". The one at $30 and the daily "pay as you go" don't. T-Mobile prepaid has roaming in Canada for its $75 plan, as well as it $45/$55 plans with a $5 surcharge. because AT&T and T-Mo have reciprocal roaming with the Canadian carriers, they can afford to offer roaming because it costs them next to nothing. MVNOs would have to pay higher roaming fees so less likely to include roaming in Canada. > If you shop for other MVNOs, be very careful to get clarification on what carrier's network they use before you>fork over any cash. Sprit is very common for MVNOs which means you can't use it with a standard handset. From job at ntt.net Tue Sep 19 22:14:05 2017 From: job at ntt.net (Job Snijders) Date: Tue, 19 Sep 2017 22:14:05 +0000 Subject: Sideloading RFC 8212 on Junos Message-ID: Dear all, Adam Chappell created an interesting shim to improve the default behaviour related to EBGP Internet routing on Juniper Junos. https://twitter.com/packetsource/status/910219911150080007 SLAX script here: https://github.com/packetsource/rfc8212-junos Props to both Adam for creating the script and to Juniper for allowing such permissionless patching! This is cool. Kind regards, Job From aaron1 at gvtc.com Wed Sep 20 02:58:02 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 19 Sep 2017 21:58:02 -0500 Subject: IOS new versions and network load In-Reply-To: <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> Message-ID: <002301d331bc$468c9f70$d3a5de50$@gvtc.com> I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights. But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc? -Aaron From sean at donelan.com Wed Sep 20 04:50:15 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 20 Sep 2017 00:50:15 -0400 (EDT) Subject: Hurricane Maria: Dominica complete communication outage 12 hours Message-ID: Its very unusual to loose all communications with a country for almost 12 hours in 2017. During Hurricane Maria, essentially all communications were cut with the Commonwealth of Dominica at about September 19, 2017 at 4:00am local time. It took nearly 12 hours to re-establish any communications with officials on the island via radio. There has been some unofficial communications with ham radio operators, assumed to be on the island. All power, wireline, internet and cell service appears to still be out. Its unclear how much is due to general damage which will take a while to repair or specific points which could be repaired quickly. There are some VSAT links in Dominica, but I didn't get responses from the ones I tried. Initial aerial fly-overs by CDEMA/RSS, a joint disaster agency by 6 participating countries in the Eastern Caribbean, saw 70%-80% damage to buildings, the hospital and other infrastructure. The Barbados Coast Guard is sailing tonight towards Dominica trying to re-establish better communications for relief efforts. Additional relief personnel are due to be sent in the morning, during daylight hours. From jared at puck.nether.net Wed Sep 20 10:41:24 2017 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 20 Sep 2017 06:41:24 -0400 Subject: IOS new versions and network load In-Reply-To: <002301d331bc$468c9f70$d3a5de50$@gvtc.com> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> Message-ID: <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> > On Sep 19, 2017, at 10:58 PM, Aaron Gould wrote: > > I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights. I remember seeing this years ago. What I saw yesterday from my own home was IPv6 traffic to the Apple CDN nodes in Chicago. > But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc? If you are at an IX or have traffic volumes, I would check this: https://www.peeringdb.com/asn/714 - Jared From javier at advancedmachines.us Wed Sep 20 11:31:38 2017 From: javier at advancedmachines.us (Javier J) Date: Wed, 20 Sep 2017 07:31:38 -0400 Subject: Puerto Rico just lost internet? Message-ID: Any info would help. From dbrisson at uvm.edu Wed Sep 20 11:33:56 2017 From: dbrisson at uvm.edu (Daniel Brisson) Date: Wed, 20 Sep 2017 11:33:56 +0000 Subject: Puerto Rico just lost internet? In-Reply-To: References: Message-ID: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> “Strongest storm of the century” just hit San Juan. -dan — Dan Brisson Network Engineer University of Vermont On 9/20/17, 7:31 AM, "NANOG on behalf of Javier J" wrote: Any info would help. From toddunder at gmail.com Wed Sep 20 11:45:58 2017 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 20 Sep 2017 07:45:58 -0400 Subject: Puerto Rico just lost internet? In-Reply-To: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: http://www.nhc.noaa.gov/graphics_at5.shtml?cone#contents it's still south of san juan but maría will move across the island all day today. t On Wed, Sep 20, 2017 at 7:33 AM, Daniel Brisson wrote: > “Strongest storm of the century” just hit San Juan. > > -dan > > > > — > > Dan Brisson > Network Engineer > University of Vermont > > On 9/20/17, 7:31 AM, "NANOG on behalf of Javier J" < > nanog-bounces at nanog.org on behalf of javier at advancedmachines.us> wrote: > > Any info would help. > > > From nanog at ics-il.net Wed Sep 20 12:33:24 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 Sep 2017 07:33:24 -0500 (CDT) Subject: IOS new versions and network load In-Reply-To: <002301d331bc$468c9f70$d3a5de50$@gvtc.com> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> Message-ID: <144493657.69406.1505910801478.JavaMail.mhammett@ThunderFuck> https://help.apple.com/serverapp/mac/5.3/#/apd74DDE89F-08D2-4E0A-A5CD-155E345EFB83 https://support.apple.com/en-us/HT204675 They appear to be very enterprise focused. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Aaron Gould" To: "Marco Slater" , "Paul Stewart" , "Mike Hammett" , "Luke Guillory" Cc: Nanog at nanog.org Sent: Tuesday, September 19, 2017 9:58:02 PM Subject: RE: IOS new versions and network load I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights. But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc? -Aaron From nanog at ics-il.net Wed Sep 20 12:36:19 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 Sep 2017 07:36:19 -0500 (CDT) Subject: IOS new versions and network load In-Reply-To: <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> Message-ID: <835000059.69409.1505910978843.JavaMail.mhammett@ThunderFuck> Apple seems to be quite behind on their node roll out. They were talking about our Indianapolis IX getting one this year, but now we're at least another year away from one. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Aaron Gould" Cc: "Marco Slater" , "Paul Stewart" , "Mike Hammett" , "Luke Guillory" , Nanog at nanog.org Sent: Wednesday, September 20, 2017 5:41:24 AM Subject: Re: IOS new versions and network load > On Sep 19, 2017, at 10:58 PM, Aaron Gould wrote: > > I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights. I remember seeing this years ago. What I saw yesterday from my own home was IPv6 traffic to the Apple CDN nodes in Chicago. > But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc? If you are at an IX or have traffic volumes, I would check this: https://www.peeringdb.com/asn/714 - Jared From nanog at ics-il.net Wed Sep 20 12:38:20 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 Sep 2017 07:38:20 -0500 (CDT) Subject: IOS new versions and network load In-Reply-To: <835000059.69409.1505910978843.JavaMail.mhammett@ThunderFuck> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> <835000059.69409.1505910978843.JavaMail.mhammett@ThunderFuck> Message-ID: <864932765.69420.1505911098124.JavaMail.mhammett@ThunderFuck> I've never quite understood CDNs and why more of them aren't more nimble. For most of them when we talk to them they're talking a full rack or more of deployment. Why haven't they all figured out how to do a single box or even a handful of boxes? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" Cc: Nanog at nanog.org Sent: Wednesday, September 20, 2017 7:36:19 AM Subject: Re: IOS new versions and network load Apple seems to be quite behind on their node roll out. They were talking about our Indianapolis IX getting one this year, but now we're at least another year away from one. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Aaron Gould" Cc: "Marco Slater" , "Paul Stewart" , "Mike Hammett" , "Luke Guillory" , Nanog at nanog.org Sent: Wednesday, September 20, 2017 5:41:24 AM Subject: Re: IOS new versions and network load > On Sep 19, 2017, at 10:58 PM, Aaron Gould wrote: > > I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights. I remember seeing this years ago. What I saw yesterday from my own home was IPv6 traffic to the Apple CDN nodes in Chicago. > But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc? If you are at an IX or have traffic volumes, I would check this: https://www.peeringdb.com/asn/714 - Jared From sean at donelan.com Wed Sep 20 12:45:56 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 20 Sep 2017 08:45:56 -0400 (EDT) Subject: Puerto Rico just lost internet? In-Reply-To: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: On Wed, 20 Sep 2017, Daniel Brisson wrote: > “Strongest storm of the century” just hit San Juan. The number of reachable networks in Puerto Rico is down by 50%. Puerto Rico still has connectivity to the island, but outside facilities and electrical grid is being damaged by Hurricane Maria (Cat 4). From ahad at swiftelnetworks.com Sun Sep 17 08:14:10 2017 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Sun, 17 Sep 2017 18:14:10 +1000 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: Hi Fredrik, Running two different IGPs for IPv4 and IPv6 is a recipe for disaster even if it’s a short-term goal. Here are a few things to consider; OSPF is good for small ISPs with small routing tables (10 to 15K routes). It will support more routes but configuration of your network becomes more complex hence an increase in human error (network engineers) EIGRP is more suitable for mid-size say 50K subscriber base but you are really stretching your luck if you go beyond the 50K subscriber base. EIGRP is more susceptible to flap when adding a new device with an MTU mis-match etc. You can google up some stories about EIGRP flap issues…. My recommendation is to use iBGP for both IPv4/IPv6, you can use OSPF or EIGRP for link layer connectivity and iBGP to carry the traffic. I prefer OSPF over EIGRP because of its equal cost load balancing if you have multiple interfaces from PE devices to your core. iBGP is scalable, you can introduce router reflectors to avoid full mesh peering between PE routers – and the sky if your limit! Hope this helps Thanks Ahad On Sat, Sep 16, 2017 at 6:09 PM, Fredrik Sallinen < fredrik.sallinen at gmail.com> wrote: > Thank you all for your Ideas. AFAIK one of the main decisions for IPv6 > transition and deployment is the choice of IPv6 IGP. I read somewhere > that its a good practice to use different IGP protocol for IPv6 and > IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6. > any comments on this? > Additionally I will appreciate it if you share your suggestions on > products and their performance? For example If I go for NAT64+DNS64 to > handle IPv4 traffic, What sort of carrier grade products are you > recommending and can you share your experience on their > performance/pitfalls? currently we have ~150Gbps of IPv4 traffic, so > we need a solution to > support such scale and future growth. > > > Regards, > > On Thu, Sep 14, 2017 at 9:35 PM, Mikael Abrahamsson > wrote: > > On Wed, 13 Sep 2017, Fredrik Sallinen wrote: > > > >> Hello, > >> > >> Recently we have decided to start IPv6 migration in our network. We > >> have ~1K BNGs and connecting our customers to network using PPPoE. > >> I'd be interested in hearing from the technical community about their > >> experiences and recommendations on this process. I'm wondering: > >> > >> Shall I go for IPv6-only deployment or dual stack? > > > > > > For PPPoE with existing IPv4, go dual stack. > > > >> Where to start with IPv6? (core, edge or ...) > > > > > > Core, peering, work outwards towards end users. > > > >> What are the best practices for ISPs? > >> What are the costs and return on investment? > >> How to identify address CPE and legacy application issues? > > > > > > There is a lot written and presented about IPv6 deployment. People have > been > > doing this in volume since around 2010, and if you search for IPv6 > > deployment experience you'll find lots of presentations. > > > > Some I found that seem relevant: > > > > https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson- > pierantozzi-level3-ipv6.pdf > > https://www.ietf.org/proceedings/54/slides/plenary-15.pdf > > https://www.apnic.net/community/ipv6-program/ipv6-stories/ > > https://www.ipv6council.be/experiences-de-deploiements-ipv6/ > > > > If you prefer video form, there are lots of presentations from > conferences, > > available on youtube as well. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > From caleb at calebsmith.net Sun Sep 17 18:19:53 2017 From: caleb at calebsmith.net (Caleb Smith) Date: Sun, 17 Sep 2017 18:19:53 +0000 Subject: USA local SIM card In-Reply-To: <03937EB9-FB99-462F-BE89-C121AF9114BD@gmail.com> References: <59BEABEC.7020101@netassist.ua> <03937EB9-FB99-462F-BE89-C121AF9114BD@gmail.com> Message-ID: Google Fi is great and all, however right now you're limited to only being able to use 3 models of phone on the network, wouldn't recommended that for an overseas traveler. On Sun, Sep 17, 2017, 12:04 PM wrote: > GoogleFi > > https://fi.google.com/about/ > > > On Sep 17, 2017, at 10:51, Ca By wrote: > > > >> On Sun, Sep 17, 2017 at 10:09 AM Max Tulyev > wrote: > >> > >> Hi All, > >> > >> sorry for possible off-topic, I really did not know where to ask this. > >> > >> I'm going to visit USA for two weeks. I want to buy a local prepaid SIM > >> card mostly for IP access. > >> > >> Is it possible in USA to buy a prepaid SIM as a visitor, without long > >> term contract? > >> > >> I need a public (can be dynamic) IP address, NOT over NAT, and (or) > >> IPv6, if possible. > >> > >> My phone is GSM UMTS 3G. > >> > >> Expected traffic volume is about 10G. > >> > >> Will use it in New York City and Orlando City, not in rural areas. > >> > >> Good data roaming tariff in Cannada will be a big advantage. > >> > >> What can you advice? > > > > > > https://prepaid-phones.t-mobile.com/prepaid-international-tourist-plan > > > > Includes public ipv6 > > > > But here in the USA we UMTS is much poorer experience relative to LTE, > you > > can get a decent LTE unlocked phone for around $100 > > > > > https://www.bestbuy.com/site/motorola-moto-e4-4g-lte-with-16gb-memory-cell-phone-unlocked-licorice-black/5889300.p?skuId=5889300 > > > > Prepaid plans generally wont include roaming to canada > > > > > > > >> > >> Thank you! > >> > From alessandro.improta at iit.cnr.it Sun Sep 17 21:43:36 2017 From: alessandro.improta at iit.cnr.it (alessandro.improta at iit.cnr.it) Date: Sun, 17 Sep 2017 23:43:36 +0200 Subject: Reliability of looking glass sites / rviews In-Reply-To: References: Message-ID: <930c62a00ab698fc761d4de9fbc99cf0@iit.cnr.it> Hello Matthew, I think you may be interested in Isolario (www.isolario.it). It's a route collector which offer real-time analyses in change of full routing tables. Let me know if you want more details about that! Best regards, Alessandro Il 2017-09-13 11:30 Matthew Huff ha scritto: > This weekend our uninterruptible power supply became interruptible and > we lost all circuits. While I was doing initial debugging of the > problem while I waited on site power verification, I noticed that > there was still paths being shown in rviews for the circuit that were > down. This was over an hour after we went hard down and it took hours > before we were back up. > > I worked with our providers last night to verify there weren't any > hanging static routes, etc... We shut the upstream circuit down and > watched the convergence and saw that eventually all the paths > disappeared. Given what we saw on Saturday, what would cause > route-views to cache the paths that long? Some looking glass sites > only show what they are peered with or at most what their peers are > peered with, that's why I've always used route-views. > > What looking glass sites other than route-views would people recommend? From ryan at deadfrog.net Sun Sep 17 21:48:38 2017 From: ryan at deadfrog.net (Ryan Wilkins) Date: Sun, 17 Sep 2017 17:48:38 -0400 Subject: USA local SIM card In-Reply-To: <59BEDDBD.9040507@netassist.ua> References: <59BEABEC.7020101@netassist.ua> <9720d448-661d-0a28-38da-afcdc2aed41e@vaxination.ca> <59BEDDBD.9040507@netassist.ua> Message-ID: <8C9D0CAA-E42E-4E8D-AEEA-F316B6F15163@deadfrog.net> > On Sep 17, 2017, at 4:40 PM, Max Tulyev wrote: > > Nice advertising, thank you! =) > > But still have open some questions I asked before: > > 1. My phone is not LTE but 3G GSM/UMTS capable (all bands, > 850/900/1700/1900/2100). Will it work? Is 3G coverage good enough in New > York and Orlando for VoIP calls (SIP, Viber, Skype)? This limits you to using either T-Mobile or AT&T since they're the only nationwide carriers using GSM/UMTS. T-Mobile's network on GSM for data is garbage, but they've got UMTS deployed in many areas, however, there are areas which only have GSM and LTE service. Those are more likely to be areas where they never added UMTS but did add LTE when they started on their LTE deployment 3 or so years ago. I haven't kept up with where UMTS is deployed these days on T-Mobile but it's either AWS-band (1700/2100 MHz) or PCS-band (1900 MHz). Their coverage has gotten a lot better, but that's primarily in LTE deployed areas. I don't think they're doing much to expand their UMTS footprint. AT&T is going to be similar but I'm less familiar with their network and can't speak on it as much. Latency will be higher on UMTS but you can still use VoIP services, but perhaps with some additional audio dropouts. Your mileage may vary. > > 2. Is there public or private IP address? IPv6? With standard service, I'm not sure if they support inbound connections to the phones or not. I've never tried. I suppose that could be worked around with a VPN. I believe that IPv4 is run through NAT but IPv6 might be a public IP. Again, I haven't tried to access a network this way over cellular. Best, Ryan Wilkins From eron at mawcom.com Mon Sep 18 00:31:51 2017 From: eron at mawcom.com (Eron Lloyd) Date: Sun, 17 Sep 2017 20:31:51 -0400 (EDT) Subject: Management softwares In-Reply-To: <008701d322ef$5fd83790$1f88a6b0$@ca> References: <008701d322ef$5fd83790$1f88a6b0$@ca> Message-ID: <1014810294.220515.1505694711376.JavaMail.zimbra@mawcom.com> I'd recommend Sonar (www.sonar.software) as well. The API is the best I've seen, and can be used to integrate your OSS into just about anything else. Eron ----- Original Message ----- From: "K MEKKAOUI" To: nanog at nanog.org Sent: Friday, September 1, 2017 2:56:00 AM Subject: Management softwares Hi We are a medium ISP. We are looking for Management software solutions. We are interested in finding a solution for billing, invoicing, scheduling, ticketing, provisioning and monitoring, Any suggestions or recommendations will be appreciated? We have been using multiple systems which do not communicate. Our objective is to use a single system or at least reduce the number of systems. Thank you KARIM M. -- Eron Lloyd Information Technology Director 717-344-5958 eron at mawcom.com MAW Communications, Inc. From support at diua.org Mon Sep 18 01:29:35 2017 From: support at diua.org (DIUA Support) Date: Mon, 18 Sep 2017 01:29:35 +0000 Subject: USA local SIM card Message-ID: <73343094-9b7c-4b9f-af23-7535c29cd32a@email.android.com> Sounds like you should go the mvno or twilio route. Twilio is beta testing cloud based since assignments that tie into their data and SIP services. If you go the direct carrier route try mvno. On Sep 17, 2017 2:34 PM, Jean-Francois Mezei wrote: On 2017-09-17 16:40, Max Tulyev wrote: > 1. My phone is not LTE but 3G GSM/UMTS capable (all bands, > 850/900/1700/1900/2100). Will it work? Is 3G coverage good enough in New > York and Orlando for VoIP calls (SIP, Viber, Skype)? 3G coverage is a superset of LTE coverage. (aka: carriers still have some areas that have 3G but not LTE). AT&T has 850 and 1900 in 3G. the AWS (1700/2100) is for LTE only. AT&T has shutdown 2G, but T-Mobile still has it. In Canada, Rogers still has 2G, but Bell/Telus never had 2G. (they went from CDMA to 3G circa 2010). T-Mobile does not have 850. It has AWS (1700/2100) and 1900 in the above list. Originally, it had 1900 only (2G). When it acquired 1700, it deployed 3G on it. But because the big US carriers deemed 1700 to be for LTE once it arrived, very few handset manufacturers provided support for 3G on 1700, especially during the days when handsets coudl only support 3 or 4 frequencies. Many of the hansets custom ordered by T-Mobile and the 3 small new Canadian carriers replaced 1900 support in 3G with 1700 support. (so when Rogers got the Mobilicity customers, many of them had handsets that could not support 3G services in 1900 so Rogers had to get a package to upgrade those customers). T-Mobile has subsequently refarmed 1700 to support LTE, and split its 1900 to support 2G and 3G. It has since acquired some 700 for LTE service, but this is no help to you. However, as a 3G-only user on t-mobile, you are limited to 1900 which has shorter propagation from antennas. So consider that the T-Mobile coverage maps may be built with 700mhz propagation in mind, so you would not get as much coverage on a 1900 only sertvice. There may still be areas where 3G is on 1700, but propagation is similar to 1900. (assuming your handset can support 3G on AWS (1700/2100). Note that AWS (1700/2100) is not used outside North America, even if frequemncies such as 2100 are. Carefully check your handset's specs. > 2. Is there public or private IP address? IPv6? I can't answer this. During my bike trip, I choose AT&T because it is the service which cuases me the least amount of waiting to post a tweet or check emails. Getting the IP address on an iPhone isn't easy so I didn't waste any time doing this. From rperkins at macstadium.com Mon Sep 18 03:02:12 2017 From: rperkins at macstadium.com (Robert Perkins) Date: Mon, 18 Sep 2017 03:02:12 +0000 Subject: IOS new versions and network load In-Reply-To: <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> , <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca>, <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org>, <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> Message-ID: MacMiniColo is now part of MacStadium, we have tons of Mac Minis and Mac Pros in Las Vegas NV, Atlanta GA and Dublin Ireland. We are currently moving out of SWITCH's NAP2 and into zColo Las Vegas. Our speciality it private clouds on the Mac platform for CI/CD environments. 360 degrees views cole aisle: https://kuula.co/post/7lkFV mini racks: https://kuula.co/post/7lkXV On Sep 17, 2017, at 7:53 PM, Mel Beckman > wrote: It is still there. MacMiniColo. -mel beckman On Sep 17, 2017, at 7:48 PM, Mel Beckman > wrote: There used to be a Mac mini "hotel" at Switch networks in Vegas. I think it's still there. -mel On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei > wrote: On 2017-09-17 19:37, Eduardo Schoedler wrote: Server is an app now, any MacOS can have it running. But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini or iMac at a carrier hotel? If the Server App could run on Linux, or if OS-X could boot on standard servers, perhaps, it it seems to be a very bad fit in carrier/enterprise environments. Implementation will be a little tricky, because you need your customers to look a record in your domain. I've tried reading some about it. The cache server app registers with Apple its existence and the IP address ranges it serves When a client wants to download new IOS version, Apple checked and finds that the client's IP is served by the caching server whose "local" IP is a.b.c.d (akaL the inside NAT IP address). Tells client to get version of software from that IP address. The DNS TXT records are used by the Caching Server to get the list of IP blocks it can serve. (not needed in the target small office environments where everyone is on same subnet and the caching server can tell the apple serves the one subnet it seves). From hintsss at gmail.com Mon Sep 18 04:09:32 2017 From: hintsss at gmail.com (Fake Name (hintss)) Date: Sun, 17 Sep 2017 21:09:32 -0700 Subject: IOS new versions and network load In-Reply-To: <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> Message-ID: <5F5415A3-C49B-4C8F-B308-AE9E69CECC49@gmail.com> My understanding was that macminicolo stopped accepting new customers in Switch after they got bought out? > On Sep 17, 2017, at 19:50, Mel Beckman wrote: > > It is still there. MacMiniColo. > > -mel beckman > >> On Sep 17, 2017, at 7:48 PM, Mel Beckman wrote: >> >> There used to be a Mac mini "hotel" at Switch networks in Vegas. I think it's still there. >> >> -mel >> >>>> On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei wrote: >>>> >>>> On 2017-09-17 19:37, Eduardo Schoedler wrote: >>>> >>>> Server is an app now, any MacOS can have it running. >>> >>> But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini >>> or iMac at a carrier hotel? If the Server App could run on Linux, or if >>> OS-X could boot on standard servers, perhaps, it it seems to be a very >>> bad fit in carrier/enterprise environments. >>> >>>> Implementation will be a little tricky, because you need your >>>> customers to look a record in your domain. >>> >>> >>> I've tried reading some about it. >>> The cache server app registers with Apple its existence and the IP >>> address ranges it serves >>> >>> When a client wants to download new IOS version, Apple checked and finds >>> that the client's IP is served by the caching server whose "local" IP is >>> a.b.c.d (akaL the inside NAT IP address). Tells client to get version of >>> software from that IP address. >>> >>> The DNS TXT records are used by the Caching Server to get the list of IP >>> blocks it can serve. (not needed in the target small office >>> environments where everyone is on same subnet and the caching server can >>> tell the apple serves the one subnet it seves). >>> From lguillory at reservetele.com Mon Sep 18 16:16:03 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 18 Sep 2017 16:16:03 +0000 Subject: IOS new versions and network load In-Reply-To: <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D21A4@RTC-EXCH01.RESERVE.LDS> We use a commercial product from https://qwilt.com/. Here is some info for the month of August, while it does reduce transit the customers are also getting better speeds when it comes from us. We span links from our core to the server in order to get visibility into the server, this does cause some issues since we’ve expanded our core outside of one location. [cid:image003.jpg at 01D3306F.82F47BC0] [cid:image004.png at 01D3306F.82F47BC0] Luke Guillory Vice President – Technology and Innovation [cid:image48b438.JPG at a3e7a3b5.4ea77b73] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From: Marco Slater [mailto:marco at marcoslater.com] Sent: Monday, September 18, 2017 10:58 AM To: Paul Stewart; Mike Hammett; Luke Guillory Cc: Nanog at nanog.org Subject: RE: IOS new versions and network load While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title. Would you be open to elaborating a bit on how that’s set up on your network? :) Regards, Marco Slater On 18 Sep 2017, 14:55 +0100, Luke Guillory >, wrote: While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart Sent: Monday, September 18, 2017 7:53 AM To: Mike Hammett Cc: Nanog at nanog.org Subject: Re: IOS new versions and network load Curious as mentioned if anyone doing this on scale? I kind of doubt it but love to hear otherwise. My assumption is this is more Enterprise focused than ISP Paul Sent from my iPhone On Sep 18, 2017, at 8:48 AM, Mike Hammett > wrote: We've been looking into the caching server bit lately given that we're not due to get an official Apple node for at least another year yet. It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement. The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675 ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" Hello world. I was wondering and forgive me if this discussions has already taken place. How many AS PATHS are too many? Meaning how do we determine how many to filter on transit links or public peering links? Thanks in advance From owen at delong.com Wed Sep 20 15:04:45 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Sep 2017 12:04:45 -0300 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: <8290D082-E5B7-478F-8026-29342E3E6E7A@delong.com> > On Sep 17, 2017, at 5:14 AM, Ahad Aboss wrote: > > Hi Fredrik, > > Running two different IGPs for IPv4 and IPv6 is a recipe for disaster even > if it’s a short-term goal. > > Here are a few things to consider; > > OSPF is good for small ISPs with small routing tables (10 to 15K routes). > It will support more routes but configuration of your network becomes more > complex hence an increase in human error (network engineers) Another perfectly workable alternative is to divide your network up into OSPF instances which each have an internal ASN and linking them together with BGP. > EIGRP is more suitable for mid-size say 50K subscriber base but you are > really stretching your luck if you go beyond the 50K subscriber base. You also have the problem that EIGRP locks you into an all-Cisco network. > EIGRP is more susceptible to flap when adding a new device with an MTU > mis-match etc. You can google up some stories about EIGRP flap issues…. > > My recommendation is to use iBGP for both IPv4/IPv6, you can use OSPF or > EIGRP for link layer connectivity and iBGP to carry the traffic. > > I prefer OSPF over EIGRP because of its equal cost load balancing if you > have multiple interfaces from PE devices to your core. > > iBGP is scalable, you can introduce router reflectors to avoid full mesh > peering between PE routers – and the sky if your limit! I think in general most serious networks consider this a question of OSPF vs. ISIS for IGP and BGP is the only choice for EGP. I find it interesting that you don’t even mention ISIS in your discussion. I don’t know of any substantial networks running EIGRP these days. I’m not saying they don’t exist, but they are certainly rare exceptions. Owen > > > > Hope this helps > > > > Thanks > > Ahad > > > > > > On Sat, Sep 16, 2017 at 6:09 PM, Fredrik Sallinen < > fredrik.sallinen at gmail.com> wrote: > >> Thank you all for your Ideas. AFAIK one of the main decisions for IPv6 >> transition and deployment is the choice of IPv6 IGP. I read somewhere >> that its a good practice to use different IGP protocol for IPv6 and >> IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6. >> any comments on this? >> Additionally I will appreciate it if you share your suggestions on >> products and their performance? For example If I go for NAT64+DNS64 to >> handle IPv4 traffic, What sort of carrier grade products are you >> recommending and can you share your experience on their >> performance/pitfalls? currently we have ~150Gbps of IPv4 traffic, so >> we need a solution to >> support such scale and future growth. >> >> >> Regards, >> >> On Thu, Sep 14, 2017 at 9:35 PM, Mikael Abrahamsson >> wrote: >>> On Wed, 13 Sep 2017, Fredrik Sallinen wrote: >>> >>>> Hello, >>>> >>>> Recently we have decided to start IPv6 migration in our network. We >>>> have ~1K BNGs and connecting our customers to network using PPPoE. >>>> I'd be interested in hearing from the technical community about their >>>> experiences and recommendations on this process. I'm wondering: >>>> >>>> Shall I go for IPv6-only deployment or dual stack? >>> >>> >>> For PPPoE with existing IPv4, go dual stack. >>> >>>> Where to start with IPv6? (core, edge or ...) >>> >>> >>> Core, peering, work outwards towards end users. >>> >>>> What are the best practices for ISPs? >>>> What are the costs and return on investment? >>>> How to identify address CPE and legacy application issues? >>> >>> >>> There is a lot written and presented about IPv6 deployment. People have >> been >>> doing this in volume since around 2010, and if you search for IPv6 >>> deployment experience you'll find lots of presentations. >>> >>> Some I found that seem relevant: >>> >>> https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson- >> pierantozzi-level3-ipv6.pdf >>> https://www.ietf.org/proceedings/54/slides/plenary-15.pdf >>> https://www.apnic.net/community/ipv6-program/ipv6-stories/ >>> https://www.ipv6council.be/experiences-de-deploiements-ipv6/ >>> >>> If you prefer video form, there are lots of presentations from >> conferences, >>> available on youtube as well. >>> >>> -- >>> Mikael Abrahamsson email: swmike at swm.pp.se >> From nickdwhite at gmail.com Wed Sep 20 15:28:06 2017 From: nickdwhite at gmail.com (Nick W) Date: Wed, 20 Sep 2017 11:28:06 -0400 Subject: Contact for Frontiernet - AS5650 In-Reply-To: References: Message-ID: Did you ever get a response from someone at Frontier? I sent a peering request yesterday and got a response today. On Fri, Sep 15, 2017 at 10:40 PM, Ryan DiRocco < ryan.dirocco at totalserversolutions.com> wrote: > Yes, just a typo on here, I have been sending to the right contact :) > > > > Sent from my Verizon, Samsung Galaxy smartphone > > > -------- Original message -------- > From: Marshall Eubanks > Date: 9/15/17 10:38 PM (GMT-05:00) > To: Ryan DiRocco > Cc: nanog at nanog.org > Subject: Re: Contact for Frontiernet - AS5650 > > > > On Fri, Sep 15, 2017 at 9:50 PM, Ryan DiRocco totalserversolutions.com> > wrote: > Can anyone put me in touch with a contact from Frontiernet regrading > peering off-list? > > I've been contacting pering at frontiernet.net >> since > 02/2017 without response and have sat on hold for the noc for 1+ hour > multiple times without answer ;) > > > I suspect this is just an email typo, but it's listed with two "e"s. > > Contact Information > > * Maintenance: isisnoc at frontiernet.net > > > * Peering: peering at frontiernet.net > * > > Regards > > > Any help greatly appreciated! > > > > From valdis.kletnieks at vt.edu Wed Sep 20 15:45:51 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 20 Sep 2017 11:45:51 -0400 Subject: AS PATH limits In-Reply-To: References: Message-ID: <9547.1505922351@turing-police.cc.vt.edu> On Tue, 19 Sep 2017 13:33:03 -0000, craig washington said: > How many AS PATHS are too many? Well - how many do you see when things are operating nominally? How many do you regard as "the other end is obviously too crazy to listen to"? Add them up and divide by two. Of course, the hard part is quantifying those two values - the network engineers for the AS I work for probably have a different tolerance level for such shenanigans than the guys running a Tier 1/1.5/more-than-2 network (and *those* guys almost certainly have different tolerances based on which of their peers and transits they're talking to).... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mansaxel at besserwisser.org Wed Sep 20 16:14:25 2017 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 20 Sep 2017 18:14:25 +0200 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: <8290D082-E5B7-478F-8026-29342E3E6E7A@delong.com> References: <8290D082-E5B7-478F-8026-29342E3E6E7A@delong.com> Message-ID: <20170920161425.GJ18073@besserwisser.org> Subject: Re: IPv6 migration steps for mid-scale isp Date: Wed, Sep 20, 2017 at 12:04:45PM -0300 Quoting Owen DeLong (owen at delong.com): > > iBGP is scalable, you can introduce router reflectors to avoid full mesh > > peering between PE routers – and the sky if your limit! > > I think in general most serious networks consider this a question of OSPF > vs. ISIS for IGP and BGP is the only choice for EGP. > > I find it interesting that you don’t even mention ISIS in your discussion. > > I don’t know of any substantial networks running EIGRP these days. I’m not > saying they don’t exist, but they are certainly rare exceptions. The fact that we'll be running dual-stack for perhaps another decade and that there are no 36-hour days available makes the choice very simple; IS-IS is my preferred choice. One routing instance less. But, I'd rather limit the IS-IS scope to "links and loopbacks" -- there is no need to have link-state flooding for a customer network that will always be originated from one specific access router. iBGP is much more appropriate for that. As long as I'll have one working path up to that router I can rely on BGP to tell me where the network is. The key is the time domain. If the topology is likely to be changing slowly (customer moves premises or commissions new connection), use BGP to signal it. If the topology is potentially unstable, i.e. subject to backhoes and similar, use IS-IS. Oh, by the way; I concur with Owen: EIGRP is not done. I've stumbled on it once the last decade, and it was a PABX network engineer who insisted. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Am I in GRADUATE SCHOOL yet? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nanog at ics-il.net Wed Sep 20 16:48:22 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 Sep 2017 11:48:22 -0500 (CDT) Subject: Contact for Frontiernet - AS5650 In-Reply-To: References: Message-ID: <2034449892.69667.1505926101449.JavaMail.mhammett@ThunderFuck> Got a phone call set for tomorrow. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick W" To: "Ryan DiRocco" , nanog at nanog.org Sent: Wednesday, September 20, 2017 10:28:06 AM Subject: Re: Contact for Frontiernet - AS5650 Did you ever get a response from someone at Frontier? I sent a peering request yesterday and got a response today. On Fri, Sep 15, 2017 at 10:40 PM, Ryan DiRocco < ryan.dirocco at totalserversolutions.com> wrote: > Yes, just a typo on here, I have been sending to the right contact :) > > > > Sent from my Verizon, Samsung Galaxy smartphone > > > -------- Original message -------- > From: Marshall Eubanks > Date: 9/15/17 10:38 PM (GMT-05:00) > To: Ryan DiRocco > Cc: nanog at nanog.org > Subject: Re: Contact for Frontiernet - AS5650 > > > > On Fri, Sep 15, 2017 at 9:50 PM, Ryan DiRocco totalserversolutions.com> > wrote: > Can anyone put me in touch with a contact from Frontiernet regrading > peering off-list? > > I've been contacting pering at frontiernet.net >> since > 02/2017 without response and have sat on hold for the noc for 1+ hour > multiple times without answer ;) > > > I suspect this is just an email typo, but it's listed with two "e"s. > > Contact Information > > * Maintenance: isisnoc at frontiernet.net > > > * Peering: peering at frontiernet.net > * > > Regards > > > Any help greatly appreciated! > > > > From sethm at rollernet.us Wed Sep 20 17:34:48 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 20 Sep 2017 10:34:48 -0700 Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <2d0b28e8-0324-ac42-c82c-0fd721b38374@vaxination.ca> <7d0e821f-5778-6fbc-d39f-f5f772a6e6f1@vaxination.ca> <30148F54-0975-4168-AC3A-2F7B518B4493@beckman.org> <46236E79-198B-4497-A4F7-09CEC3343CA7@beckman.org> Message-ID: On 9/17/17 20:02, Robert Perkins wrote: > mini racks:https://kuula.co/post/7lkXV Even if you're not doing Minis at that scale they easily fit into a 1U space. Someone said minis aren't rack friendly and no, they aren't rackmount standalone, but just add a 1U shelf. ~Seth From tim at snas.io Wed Sep 20 17:34:39 2017 From: tim at snas.io (Tim Evens) Date: Wed, 20 Sep 2017 10:34:39 -0700 Subject: AS PATH limits In-Reply-To: References: Message-ID: <6d1293f0b5453646d34ba5de9127e188@evensweb.com> An AS_PATH is encoded with one or more segments. Each segment has a maximum size of 255 entries (8 bit segment length). The absolute limit will depend on the complete BGP message size, which is limited to 4096 and extended via draft-ietf-idr-bgp-extended-messages. The longest as_path at this time (changes frequently though) is 51 entries, but in the past we have seen as many as 501. Below is an example showing an excessive amount of prepending for prefix 185.135.134.0/23 at 2017-09-18 20:20:05 UTC. as_path_count: 501 as_path: 38726 9957 17604 7922 6830 197451 197451 197451 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 207239 201228 --Tim On 19.09.2017 06:33, craig washington wrote: > Hello world. > > I was wondering and forgive me if this discussions has already taken place. > > How many AS PATHS are too many? > > Meaning how do we determine how many to filter on transit links or public peering links? > > Thanks in advance From mehmet at akcin.net Wed Sep 20 17:36:36 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 20 Sep 2017 10:36:36 -0700 Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: There is a major outage going on in Puerto Rico and you can see it here - https://stat.ripe.net/PR#tabId=routing I am putting together some analysis as time passes - i will publish them in a blog and share. On Wed, Sep 20, 2017 at 5:45 AM, Sean Donelan wrote: > On Wed, 20 Sep 2017, Daniel Brisson wrote: > >> “Strongest storm of the century” just hit San Juan. >> > > The number of reachable networks in Puerto Rico is down by 50%. > > Puerto Rico still has connectivity to the island, but outside facilities > and electrical grid is being damaged by Hurricane Maria (Cat 4). > From toddunder at gmail.com Wed Sep 20 18:09:57 2017 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 20 Sep 2017 14:09:57 -0400 Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: the entire island is now without power: http://www.bbc.co.uk/news/world-latin-america-41340392 no bueno. t On Wed, Sep 20, 2017 at 1:36 PM, Mehmet Akcin wrote: > There is a major outage going on in Puerto Rico and you can see it here - > > https://stat.ripe.net/PR#tabId=routing > > I am putting together some analysis as time passes - i will publish them in > a blog and share. > > On Wed, Sep 20, 2017 at 5:45 AM, Sean Donelan wrote: > > > On Wed, 20 Sep 2017, Daniel Brisson wrote: > > > >> “Strongest storm of the century” just hit San Juan. > >> > > > > The number of reachable networks in Puerto Rico is down by 50%. > > > > Puerto Rico still has connectivity to the island, but outside facilities > > and electrical grid is being damaged by Hurricane Maria (Cat 4). > > > From cjwolff at nola.gov Wed Sep 20 18:54:26 2017 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Wed, 20 Sep 2017 18:54:26 +0000 Subject: Level 3 SIP trunking and E911 Message-ID: <47F264CE123954429FC99B9E768819F22597A6AD@CNO-XCH02.cityofno.com> I've been informed by my Level 3 sales rep that the only way to make moves/adds/changes for Level 3 E911 is through the portal. This seems awkward since I have Emergency Responder which can link into products like Intrado. Are there any SIP/E911 folks from Level 3 that can clarify what my options are? It would be appreciated. Thanks in advance, CJ From beecher at beecher.cc Wed Sep 20 19:22:27 2017 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 20 Sep 2017 15:22:27 -0400 Subject: IOS new versions and network load In-Reply-To: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> Message-ID: Apple's peering/CDN strategy has completely changed in the last few years. (Hi to my friends on the list here!) They do a much better job getting bits delivered for this stuff now. Some of the IOS coding is still occasionally not the most well thought out when it comes to data retrieval, but it's gotten better. :) On Sun, Sep 17, 2017 at 4:56 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > A couple years ago, Apple unleashed an IOS update which made the news > because network operators reported serious congestion on their networks > as everyone and their uncle tried to download the gig+ package at 11:00 > PDT. > > Was the problem solved simply by Apple staggering the announcement of > downloads? or were there distribution network changes also made to > reduce the load? > > > In Canada, during net neutralirty hearings, it was revealed that > cellular carriers zero rated over the air updates. I know my iPhone > gets updates without me asking for them, only getting a "update ready to > install" while on a long cycling ride (aka: must have used cellular data). > > Does anyone know whether this is pushed by Apple who has gotten the OK > form individual carriers, or is it pushed by carriers (with Apple's OK) > in a low priorioty stream that doesn't cause congestion on cellular > network? (carriers delivering content in "push mode" would change their > role). > > From randy at psg.com Wed Sep 20 19:36:54 2017 From: randy at psg.com (Randy Bush) Date: Thu, 21 Sep 2017 04:36:54 +0900 Subject: AS PATH limits In-Reply-To: <6d1293f0b5453646d34ba5de9127e188@evensweb.com> References: <6d1293f0b5453646d34ba5de9127e188@evensweb.com> Message-ID: > Below is an example showing an excessive amount of prepending for prefix > 185.135.134.0/23 at 2017-09-18 20:20:05 UTC. and they are probably still wondering why it does not achieve what they want. randy From lee at asgard.org Wed Sep 20 19:47:41 2017 From: lee at asgard.org (Lee Howard) Date: Wed, 20 Sep 2017 15:47:41 -0400 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: Message-ID: On 9/13/17, 8:08 AM, "NANOG on behalf of Fredrik Sallinen" wrote: >Hello, > >Recently we have decided to start IPv6 migration in our network. We >have ~1K BNGs and connecting our customers to network using PPPoE. >I'd be interested in hearing from the technical community about their >experiences and recommendations on this process. I'm wondering: > >Shall I go for IPv6-only deployment or dual stack? Dual-stack is the best way to get to IPv6-only. You’ll need IPv6-only in order to solve the IPv4 runout problem, though “only” is likely to include translation. >Where to start with IPv6? (core, edge or ...) Web site. Then core and peering. Then push toward regional networks. You’ll need IPv6 into at least the part of your data center does provisioning and monitoring. Then start pushing to customers. >What are the best practices for ISPs? Lots of documents exist. Here’s one: https://tools.ietf.org/html/rfc6782 >What are the costs and return on investment? Oh, I have so much to say on this topic. Search for “TCO of CGN” and “TCO of IPv6” to find it. You should have very little incremental capital cost; that is, you shouldn’t have to buy new hardware, because practically anything less than ten years old can support IPv6. Whether it *does* is a question. You’ll have some opex network engineering costs in testing and deployment, which might be high(ish) if you have a lot of different equipment in your network. Your biggest cost is likely to be the development labor to update your IPAM, provisioning systems, management, logging, and tech support tools to be able to store and use the new address format. Development is likely to be what takes longest, so that’s really the place to start. The return on investment is that you don’t have to spend $15 to buy an IPv4 address for every new user you have to sign up. Or $25 per address in 2019, if trends continue. [1] Depending on how happy you are with your transition mechanism (NAT64, 464xlat, MAP, etc.) you could, instead, sell off those IPv4 addresses. “Hey, boss, we’ll turn up 10,000 new customers in 2019, right? We can either spend $250,000 to buy addresses, or we can put 10% of our customers behind NAT64 (or whatever) and sell their IPv4 addresses for $25 each.” (Dozens of NANOGers laugh, a few cock their heads and think “maybe…”). >How to identify address CPE and legacy application issues? How do you do it now? I’m guessing you test CPE that you provide, at least for basic functionality. Some bugs still get past you. A few customers call, you notice a trend among customers with X CPE that they have a problem in the area where you just rolled out IPv6. You roll back IPv6 in that area or (hopefully) just from those devices, and put that CPE in the lab and test the heck out of it. For legacy applications, it depends on the application. If you can update it, that’s the best answer. Or you can put a NAT64 box in front of it (on a VM, router, firewall, or load balancer—you don’t necessarily need new hardware). But there’s also the entire rest of the old Internet: you will probably want to have some kind of transition mechanism in place. I know folks who specialize in transition mechanisms; I’ll follow up privately so this doesn’t look like a sales pitch on the list. > >Fredrik > Lee [1] Charts, using IPv4auctions.com (Hilco Streambank) data: http://www.wleecoyote.com/blog/2017prices.htm From deleskie at gmail.com Wed Sep 20 19:55:20 2017 From: deleskie at gmail.com (jim deleskie) Date: Wed, 20 Sep 2017 16:55:20 -0300 Subject: AS PATH limits In-Reply-To: References: <6d1293f0b5453646d34ba5de9127e188@evensweb.com> Message-ID: In my MUCH younger days, I may have helped abuse the global table via prepends, but never to that level :) On Wed, Sep 20, 2017 at 4:36 PM, Randy Bush wrote: > > Below is an example showing an excessive amount of prepending for prefix > > 185.135.134.0/23 at 2017-09-18 20:20:05 UTC. > > and they are probably still wondering why it does not achieve what they > want. > > randy > From beecher at beecher.cc Wed Sep 20 20:01:12 2017 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 20 Sep 2017 16:01:12 -0400 Subject: AS PATH limits In-Reply-To: References: Message-ID: Too many prepends = any more than you really need for what you're trying to accomplish. :) I've cutoff paths as short as 4 to as long as 8 before in different jobs for different reasons. On Tue, Sep 19, 2017 at 9:33 AM, craig washington < craigwashington01 at hotmail.com> wrote: > Hello world. > > I was wondering and forgive me if this discussions has already taken place. > > How many AS PATHS are too many? > > Meaning how do we determine how many to filter on transit links or public > peering links? > > > Thanks in advance > > > From javier at advancedmachines.us Wed Sep 20 20:04:20 2017 From: javier at advancedmachines.us (Javier J) Date: Wed, 20 Sep 2017 16:04:20 -0400 Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: Thank you for the updates. How long usually till generators at cell sites run out of juice? On Wed, Sep 20, 2017 at 2:09 PM, Todd Underwood wrote: > the entire island is now without power: > > http://www.bbc.co.uk/news/world-latin-america-41340392 > 2Fnews%2Fworld-latin-america-41340392&sa=D&sntz=1&usg= > AFQjCNEYKsHT4Y3MS40bMMoPBLC0X9-DMg> > > > no bueno. > > t > > On Wed, Sep 20, 2017 at 1:36 PM, Mehmet Akcin wrote: > > > There is a major outage going on in Puerto Rico and you can see it here - > > > > https://stat.ripe.net/PR#tabId=routing > > > > I am putting together some analysis as time passes - i will publish them > in > > a blog and share. > > > > On Wed, Sep 20, 2017 at 5:45 AM, Sean Donelan wrote: > > > > > On Wed, 20 Sep 2017, Daniel Brisson wrote: > > > > > >> “Strongest storm of the century” just hit San Juan. > > >> > > > > > > The number of reachable networks in Puerto Rico is down by 50%. > > > > > > Puerto Rico still has connectivity to the island, but outside > facilities > > > and electrical grid is being damaged by Hurricane Maria (Cat 4). > > > > > > From sean at donelan.com Wed Sep 20 20:36:53 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 20 Sep 2017 16:36:53 -0400 (EDT) Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: On Wed, 20 Sep 2017, Javier J wrote: > How long usually till generators at cell sites run out of juice? Rough, every provider is different, backup power hierarchy: Neighborhood pole boxes: 1-4 hours, batteries only. May be re-charged with portable generators when safe to access area. There is likely severe physical damage to neighborhood lines. Cell towers: 8-12 hours battery. Some, not all, towers have a natural gas generator or 24 hours diesel generator Central offices and cable headends: 8-12 hours battery, 1-3 days diesel generators. Core, tandem, and hub sites usually have more backup. Major colocation data centers: <1 hour battery, 3-14 days diesel generators Submarine cable landing points and satellite control stations: 24 hours battery, 30 days diesel generators From aaron1 at gvtc.com Wed Sep 20 22:34:41 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 20 Sep 2017 17:34:41 -0500 Subject: IOS new versions and network load In-Reply-To: <864932765.69420.1505911098124.JavaMail.mhammett@ThunderFuck> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> <835000059.69409.1505910978843.JavaMail.mhammett@ThunderFuck> <864932765.69420.1505911098124.JavaMail.mhammett@ThunderFuck> Message-ID: <001d01d33260$a6d6caa0$f4845fe0$@gvtc.com> My Netflix servers are half a petabyte of cached movies and they are about 18 inches tall .... not sure what you mean. -Aaron Gould From aaron1 at gvtc.com Wed Sep 20 22:42:51 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 20 Sep 2017 17:42:51 -0500 Subject: IOS new versions and network load In-Reply-To: References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> Message-ID: <002101d33261$caead340$60c079c0$@gvtc.com> Is there anyone from Apple that can contact me about the caching servers that I could possibly put into my local ISP network ? -Aaron From ryan.dirocco at totalserversolutions.com Wed Sep 20 22:59:35 2017 From: ryan.dirocco at totalserversolutions.com (Ryan DiRocco) Date: Wed, 20 Sep 2017 22:59:35 +0000 Subject: Contact for Frontiernet - AS5650 In-Reply-To: References: , Message-ID: We sure did Nick. Thanks for the contacts everyone, we're now happily peering with AS5650 on 4 exchanges ;) ________________________________________ From: Nick W [nickdwhite at gmail.com] Sent: Wednesday, September 20, 2017 11:28 AM To: Ryan DiRocco; nanog at nanog.org Subject: Re: Contact for Frontiernet - AS5650 Did you ever get a response from someone at Frontier? I sent a peering request yesterday and got a response today. From nanog at ics-il.net Wed Sep 20 23:02:49 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 Sep 2017 18:02:49 -0500 (CDT) Subject: IOS new versions and network load In-Reply-To: <001d01d33260$a6d6caa0$f4845fe0$@gvtc.com> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> <835000059.69409.1505910978843.JavaMail.mhammett@ThunderFuck> <864932765.69420.1505911098124.JavaMail.mhammett@ThunderFuck> <001d01d33260$a6d6caa0$f4845fe0$@gvtc.com> Message-ID: <703455265.70294.1505948566488.JavaMail.mhammett@ThunderFuck> A couple of the CDNs have one or multiple rack minimum deployments. You can get a Netflix box in 4U that does many TB of storage, BGP, etc. CDN in a box. A lot of them were just built with big scale in mind, based on the fact that the US has 10 or so major sites and the scale needed to serve that much of the US. Now it's all about getting to the edge, but they haven't made their deployment smaller to accommodate. Some parts of their businesses evolve very rapidly, while other parts of the same business plod along ridiculously slow. Not meaning to pick on Apple (or Microsoft who's in the same boat), but they're the original reason for this thread. Most of Apple or Microsoft's peak usage (major OS updates) could fit in a 10 year old desktop's RAM drive, provided the rest of the system could keep up with the throughput needs. I'm surprised more companies haven't more quickly adopted something the configuration of the Netflix box. It doesn't have to do everything, just do the high demand stuff well. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Aaron Gould" To: "Mike Hammett" Cc: Nanog at nanog.org Sent: Wednesday, September 20, 2017 5:34:41 PM Subject: RE: IOS new versions and network load My Netflix servers are half a petabyte of cached movies and they are about 18 inches tall .... not sure what you mean. -Aaron Gould From sean at donelan.com Thu Sep 21 01:40:09 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 20 Sep 2017 21:40:09 -0400 (EDT) Subject: Hurricane Maria: Dominica partial communications restored In-Reply-To: References: Message-ID: At Sept. 21, 2017 01:00 UTC, partial telecommunications service was restored to Dominica. However, essentially 100% of the island does not have electric service, cell service is still out, and most people do not have service. CDEMA/RSS has delivered 5 satellite telephones to the Dominica government and island emergency services. About 50 relief workers arrived from Barbados and now working to re-open the port and airport for further relief supplies and personnel. Some people asked about satellite phones on Dominica earlier. Satellite phones are very useful after a disaster, but have some limitations during a catagory 5 hurricane. Satellite phones only work outside, not where you want to be during a hurricane. Satellite signals also experience rain fade in heavy storms, so you need to wait until the hurricane clears from the area. Satellite phones also need batteries or power, which tend to fail just when you need them. I don't know the exact details yet about what happened to the telecommunications on Dominica. Some ham radio operators have been verified as operating from Dominica. Its an unfortunate, but necessary thing that needs to be verified during disaster communications. From lyndon at orthanc.ca Thu Sep 21 01:45:53 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 20 Sep 2017 18:45:53 -0700 Subject: Hurricane Maria: Dominica partial communications restored In-Reply-To: References: Message-ID: > On Sep 20, 2017, at 6:40 PM, Sean Donelan wrote: > > Some ham radio operators have been verified as operating from Dominica. Its an unfortunate, but necessary thing that needs to be verified during disaster communications. I'm not clear what you're getting at here. Are you saying people are faking operating from the islands? That seems unlikely. Basic RDF is going to tell you in short order where they are transmitting from. And for the smaller islands, the local operators are well known in the region, so it seems unlikely someone would be able to set up shop in, say, Tennessee and claim to be a new ham who just moved to Anguilla last week. --lyndon From javier at advancedmachines.us Thu Sep 21 03:29:06 2017 From: javier at advancedmachines.us (Javier J) Date: Wed, 20 Sep 2017 23:29:06 -0400 Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: Thank you for this info! I think most of us kind of know there are backup power strategies in place but this is very detailed and appreciated. The little communication I have had with family on the island they tell me no internet, no cable tv, etc so this timing is good to know for when the few cell towers that survived start to go dark. - J On Wed, Sep 20, 2017 at 4:36 PM, Sean Donelan wrote: > On Wed, 20 Sep 2017, Javier J wrote: > >> How long usually till generators at cell sites run out of juice? >> > > Rough, every provider is different, backup power hierarchy: > > Neighborhood pole boxes: 1-4 hours, batteries only. May be re-charged with > portable generators when safe to access area. There is likely severe > physical damage to neighborhood lines. > > Cell towers: 8-12 hours battery. Some, not all, towers have a natural gas > generator or 24 hours diesel generator > > Central offices and cable headends: 8-12 hours battery, 1-3 days diesel > generators. Core, tandem, and hub sites usually have more backup. > > Major colocation data centers: <1 hour battery, 3-14 days diesel generators > > Submarine cable landing points and satellite control stations: 24 hours > battery, 30 days diesel generators > > From ahmed.dalaali at hrins.net Thu Sep 21 08:08:43 2017 From: ahmed.dalaali at hrins.net (ahmed.dalaali at hrins.net) Date: Thu, 21 Sep 2017 11:08:43 +0300 Subject: Drop cable Message-ID: Hello, I would like to buy drop cable 6 core, I am already buying from China, but the quality sometimes is bad so anyone who deals with good companies there can share their contact with me? Regards, From ahmed.dalaali at hrins.net Thu Sep 21 08:27:30 2017 From: ahmed.dalaali at hrins.net (Ahmed Munaf) Date: Thu, 21 Sep 2017 11:27:30 +0300 Subject: Drop cable In-Reply-To: References: Message-ID: <0199401F-FFDB-4CF6-B603-7A16F782C76E@hrins.net> sorry I forgot to mention the model: drop cable 6 core fiber optic GYXTW 1Km/ drum in I am using this model too: drop fiber cable 2 core G657A2 fiber & 1.2mm self-supporting steel & LSZH Regards, > On Sep 21, 2017, at 11:08 AM, ahmed.dalaali at hrins.net wrote: > > Hello, > > I would like to buy drop cable 6 core, I am already buying from China, but the quality sometimes is bad so anyone who deals with good companies there can share their contact with me? > > Regards, From jared at puck.Nether.net Thu Sep 21 11:12:14 2017 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 21 Sep 2017 07:12:14 -0400 Subject: IOS new versions and network load In-Reply-To: <001d01d33260$a6d6caa0$f4845fe0$@gvtc.com> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> <835000059.69409.1505910978843.JavaMail.mhammett@ThunderFuck> <864932765.69420.1505911098124.JavaMail.mhammett@ThunderFuck> <001d01d33260$a6d6caa0$f4845fe0$@gvtc.com> Message-ID: <20170921111214.GA15171@puck.nether.net> On Wed, Sep 20, 2017 at 05:34:41PM -0500, Aaron Gould wrote: > My Netflix servers are half a petabyte of cached movies and they are about 18 inches tall .... not sure what you mean. Serving different file types requires different things. If you are serving the same episodes from storage it's much different than live content, or serving dynamic updates based on entitlement levels, etc. Not all CDNs are like Netflix, for better or worse. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From beecher at beecher.cc Thu Sep 21 13:09:19 2017 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 21 Sep 2017 09:09:19 -0400 Subject: IOS new versions and network load In-Reply-To: <20170921111214.GA15171@puck.nether.net> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> <835000059.69409.1505910978843.JavaMail.mhammett@ThunderFuck> <864932765.69420.1505911098124.JavaMail.mhammett@ThunderFuck> <001d01d33260$a6d6caa0$f4845fe0$@gvtc.com> <20170921111214.GA15171@puck.nether.net> Message-ID: There are also considerations with the throughput capability of the hardware too. 500T in a couple RU is nice and all, but if the box can only push ~15Gbps because of bottlenecks in hardware, or the kernel isn't tuned, it's might be a lot less useful depending on the content, as Jared points out. On Thu, Sep 21, 2017 at 7:12 AM, Jared Mauch wrote: > On Wed, Sep 20, 2017 at 05:34:41PM -0500, Aaron Gould wrote: > > My Netflix servers are half a petabyte of cached movies and they are > about 18 inches tall .... not sure what you mean. > > Serving different file types requires different things. If you > are serving the same episodes from storage it's much different than > live content, or serving dynamic updates based on entitlement > levels, etc. > > Not all CDNs are like Netflix, for better or worse. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > From fhr at fhrnet.eu Thu Sep 21 13:09:21 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 21 Sep 2017 15:09:21 +0200 Subject: Drop cable In-Reply-To: <0199401F-FFDB-4CF6-B603-7A16F782C76E@hrins.net> References: <0199401F-FFDB-4CF6-B603-7A16F782C76E@hrins.net> Message-ID: Hi, Try FiberStore - fs.com Dne 9/21/17 v 10:27 Ahmed Munaf napsal(a): > sorry I forgot to mention the model: > > drop cable 6 core fiber optic GYXTW 1Km/ drum > > in I am using this model too: > > drop fiber cable 2 core G657A2 fiber & 1.2mm self-supporting steel & LSZH > > Regards, > > > >> On Sep 21, 2017, at 11:08 AM, ahmed.dalaali at hrins.net wrote: >> >> Hello, >> >> I would like to buy drop cable 6 core, I am already buying from China, but the quality sometimes is bad so anyone who deals with good companies there can share their contact with me? >> >> Regards, -- Best Regards, Filip Hruska Linux System Administrator From aaron1 at gvtc.com Thu Sep 21 14:03:09 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 21 Sep 2017 09:03:09 -0500 Subject: IOS new versions and network load In-Reply-To: <20170921111214.GA15171@puck.nether.net> References: <59269c23-4ae7-c3de-a322-76a857dcd5a1@vaxination.ca> <1912716896.66776.1505738890500.JavaMail.mhammett@ThunderFuck> <0B75F87F-A3A0-4FC5-9E44-423C79EF7CA9@paulstewart.org> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB2D1B5F@RTC-EXCH01.RESERVE.LDS> <154b1c7f-3479-4fce-a201-97c9afeab918@Spark> <002301d331bc$468c9f70$d3a5de50$@gvtc.com> <31C75AA7-A313-4375-B876-DFF067031FFB@puck.nether.net> <835000059.69409.1505910978843.JavaMail.mhammett@ThunderFuck> <864932765.69420.1505911098124.JavaMail.mhammett@ThunderFuck> <001d01d33260$a6d6caa0$f4845fe0$@gvtc.com> <20170921111214.GA15171@puck.nether.net> Message-ID: <001701d332e2$5b5e9800$121bc800$@gvtc.com> Oh, thanks Jared, I don't know what Netflix puts in my caches that they have locally here on -site... can I know ? Will the OCA portal show my what types of things are in there ? -Aaron From mehmet at akcin.net Thu Sep 21 04:26:55 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 20 Sep 2017 21:26:55 -0700 Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: Things are getting only worst so far - most of the island is offline - see the screenshot or the link here live https://stat.ripe.net/PR#tabId=routing On Wed, Sep 20, 2017 at 8:29 PM, Javier J wrote: > Thank you for this info! > > > I think most of us kind of know there are backup power strategies in place > but this is very detailed and appreciated. The little communication I have > had with family on the island they tell me no internet, no cable tv, etc so > this timing is good to know for when the few cell towers that survived > start to go dark. > > - J > > > > On Wed, Sep 20, 2017 at 4:36 PM, Sean Donelan wrote: > > > On Wed, 20 Sep 2017, Javier J wrote: > > > >> How long usually till generators at cell sites run out of juice? > >> > > > > Rough, every provider is different, backup power hierarchy: > > > > Neighborhood pole boxes: 1-4 hours, batteries only. May be re-charged > with > > portable generators when safe to access area. There is likely severe > > physical damage to neighborhood lines. > > > > Cell towers: 8-12 hours battery. Some, not all, towers have a natural gas > > generator or 24 hours diesel generator > > > > Central offices and cable headends: 8-12 hours battery, 1-3 days diesel > > generators. Core, tandem, and hub sites usually have more backup. > > > > Major colocation data centers: <1 hour battery, 3-14 days diesel > generators > > > > Submarine cable landing points and satellite control stations: 24 hours > > battery, 30 days diesel generators > > > > > From colinj at gt86car.org.uk Thu Sep 21 15:27:05 2017 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 21 Sep 2017 16:27:05 +0100 Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: one ripe atlas probe is still green though Probe ID20057IPv4 ASNAS5786 IPv4 Prefix136.145.0.0/16 IPv6 ASNAS65003 IPv6 Prefix2607:2000:100:116::/64 CountryPRConnected since: 2017-09-12 16:17:06 UTC > On 21 Sep 2017, at 05:26, Mehmet Akcin wrote: > > Things are getting only worst so far - most of the island is offline - see > the screenshot or the link here live https://stat.ripe.net/PR#tabId=routing > > On Wed, Sep 20, 2017 at 8:29 PM, Javier J > wrote: > >> Thank you for this info! >> >> >> I think most of us kind of know there are backup power strategies in place >> but this is very detailed and appreciated. The little communication I have >> had with family on the island they tell me no internet, no cable tv, etc so >> this timing is good to know for when the few cell towers that survived >> start to go dark. >> >> - J >> >> >> >> On Wed, Sep 20, 2017 at 4:36 PM, Sean Donelan wrote: >> >>> On Wed, 20 Sep 2017, Javier J wrote: >>> >>>> How long usually till generators at cell sites run out of juice? >>>> >>> >>> Rough, every provider is different, backup power hierarchy: >>> >>> Neighborhood pole boxes: 1-4 hours, batteries only. May be re-charged >> with >>> portable generators when safe to access area. There is likely severe >>> physical damage to neighborhood lines. >>> >>> Cell towers: 8-12 hours battery. Some, not all, towers have a natural gas >>> generator or 24 hours diesel generator >>> >>> Central offices and cable headends: 8-12 hours battery, 1-3 days diesel >>> generators. Core, tandem, and hub sites usually have more backup. >>> >>> Major colocation data centers: <1 hour battery, 3-14 days diesel >> generators >>> >>> Submarine cable landing points and satellite control stations: 24 hours >>> battery, 30 days diesel generators >>> >>> >> From sean at donelan.com Thu Sep 21 16:47:16 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 21 Sep 2017 12:47:16 -0400 (EDT) Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: On Thu, 21 Sep 2017, Colin Johnston wrote: > one ripe atlas probe is still green though It looks like the last Internet service provider to Puerto Rico just went down. Zero routes. Hopefully its just power, and they will be able to re-fuel and be back on line quickly. From sean at donelan.com Thu Sep 21 17:08:18 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 21 Sep 2017 13:08:18 -0400 (EDT) Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: On Thu, 21 Sep 2017, Sean Donelan wrote: > On Thu, 21 Sep 2017, Colin Johnston wrote: >> one ripe atlas probe is still green though > > It looks like the last Internet service provider to Puerto Rico just went > down. Zero routes. > > Hopefully its just power, and they will be able to re-fuel and be back on > line quickly. May have just been a BGP bounce. The routes about back, around 300 networks. From dvandyk at akamai.com Thu Sep 21 17:10:13 2017 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Thu, 21 Sep 2017 17:10:13 +0000 Subject: Has Level3 done away with traceroute?? Message-ID: <06B9FC37-423D-439C-BC6A-3826FB62243C@akamai.com> Hello All, Recently I was troubleshooting a network event for a client of our who resides on the Level3 network. While trying to verify the path, I noticed I am no longer able to traceroute through the Level3 network. The funny thing is this is not just isolated to the /32. It appears to be that the entire 4.0.0.0/9 network is no longer able to traceroute through. Everything dies on their edge network. This appears to be isolated to traceroute. I have check this in NA and EU. My carrier contacted Level3 who pretty much stated that they can’t provide anything. I have checked multiple looking glasses and other online tools and none of them make it. Even Level3 looking glass drops the packets. Does anyone know anything about this? I’m pretty sure this is the first time we are seeing this. Random 4.0.0.0/9 address. NTT looking glass Tracing the route to 4.35.230.7 1 * ae-2.a00.snjsca04.us.bb.gin.ntt.net (129.250.3.58) 3 msec 1 msec 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * TATA looking glass traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets 1 if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173) 1.253 ms 1.177 ms MPLS Label=616998 CoS=0 TTL=1 S=1 2 195.219.50.50 (195.219.50.50) 1.214 ms 1.247 ms 1.535 ms 3 195.219.50.50 (195.219.50.50) 1.144 ms * 2.246 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * Telia looking glass traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets 1 if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173) 1.253 ms 1.177 ms MPLS Label=616998 CoS=0 TTL=1 S=1 2 195.219.50.50 (195.219.50.50) 1.214 ms 1.247 ms 1.535 ms 3 195.219.50.50 (195.219.50.50) 1.144 ms * 2.246 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * Level3 looking glass Traceroute results from Atlanta, GA to 4.200.65.42(dialup-4.200.65.42.Dial1.LosAngeles1) 1 0.0.0.0 * * * 2 0.0.0.0 * * * 3 0.0.0.0 * * * 4 0.0.0.0 * * * 5 0.0.0.0 * * * 6 0.0.0.0 * * * 7 0.0.0.0 * * * 8 0.0.0.0 * * * 9 0.0.0.0 * * * 10 0.0.0.0 * * * 11 0.0.0.0 * * * -- Donovan Van Dyk SOC Network Engineer Fort Lauderdale, FL USA [cid:image001.png at 01D332DA.F4DD00A0] The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. From dhubbard at dino.hostasaurus.com Thu Sep 21 17:26:19 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 21 Sep 2017 17:26:19 +0000 Subject: Has Level3 done away with traceroute?? In-Reply-To: <06B9FC37-423D-439C-BC6A-3826FB62243C@akamai.com> References: <06B9FC37-423D-439C-BC6A-3826FB62243C@akamai.com> Message-ID: <9AB47C11-A2EA-4C23-8ECF-2C3E6393AC6F@dino.hostasaurus.com> I’m seeing the same thing across our Level 3 circuits, even if the traffic never leaves their network. This was not the case as recently as two days ago when I had a reachability ticket open with them. My SE says they’re having an internal issue that’s being worked on; didn’t provide detail. On 9/21/17, 1:13 PM, "NANOG on behalf of Van Dyk, Donovan via NANOG" wrote: Hello All, Recently I was troubleshooting a network event for a client of our who resides on the Level3 network. While trying to verify the path, I noticed I am no longer able to traceroute through the Level3 network. The funny thing is this is not just isolated to the /32. It appears to be that the entire 4.0.0.0/9 network is no longer able to traceroute through. Everything dies on their edge network. This appears to be isolated to traceroute. I have check this in NA and EU. My carrier contacted Level3 who pretty much stated that they can’t provide anything. I have checked multiple looking glasses and other online tools and none of them make it. Even Level3 looking glass drops the packets. Does anyone know anything about this? I’m pretty sure this is the first time we are seeing this. Random 4.0.0.0/9 address. NTT looking glass Tracing the route to 4.35.230.7 1 * ae-2.a00.snjsca04.us.bb.gin.ntt.net (129.250.3.58) 3 msec 1 msec 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * TATA looking glass traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets 1 if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173) 1.253 ms 1.177 ms MPLS Label=616998 CoS=0 TTL=1 S=1 2 195.219.50.50 (195.219.50.50) 1.214 ms 1.247 ms 1.535 ms 3 195.219.50.50 (195.219.50.50) 1.144 ms * 2.246 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * Telia looking glass traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets 1 if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173) 1.253 ms 1.177 ms MPLS Label=616998 CoS=0 TTL=1 S=1 2 195.219.50.50 (195.219.50.50) 1.214 ms 1.247 ms 1.535 ms 3 195.219.50.50 (195.219.50.50) 1.144 ms * 2.246 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * Level3 looking glass Traceroute results from Atlanta, GA to 4.200.65.42(dialup-4.200.65.42.Dial1.LosAngeles1) 1 0.0.0.0 * * * 2 0.0.0.0 * * * 3 0.0.0.0 * * * 4 0.0.0.0 * * * 5 0.0.0.0 * * * 6 0.0.0.0 * * * 7 0.0.0.0 * * * 8 0.0.0.0 * * * 9 0.0.0.0 * * * 10 0.0.0.0 * * * 11 0.0.0.0 * * * -- Donovan Van Dyk SOC Network Engineer Fort Lauderdale, FL USA [cid:image001.png at 01D332DA.F4DD00A0] The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. From fhr at fhrnet.eu Thu Sep 21 17:45:04 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 21 Sep 2017 19:45:04 +0200 Subject: Has Level3 done away with traceroute?? In-Reply-To: <06B9FC37-423D-439C-BC6A-3826FB62243C@akamai.com> References: <06B9FC37-423D-439C-BC6A-3826FB62243C@akamai.com> Message-ID: Hi, Did a measurement with RIPE Atlas and it seems like a worldwide problem, based on data from 100 probes. https://atlas.ripe.net/measurements/9324230/#!tracemon Dne 9/21/17 v 19:10 Van Dyk, Donovan via NANOG napsal(a): > Hello All, > > Recently I was troubleshooting a network event for a client of our who resides on the Level3 network. While trying to verify the path, I noticed I am no longer able to traceroute through the Level3 network. > The funny thing is this is not just isolated to the /32. It appears to be that the entire 4.0.0.0/9 network is no longer able to traceroute through. Everything dies on their edge network. > > This appears to be isolated to traceroute. I have check this in NA and EU. > > My carrier contacted Level3 who pretty much stated that they can’t provide anything. > > I have checked multiple looking glasses and other online tools and none of them make it. Even Level3 looking glass drops the packets. > > Does anyone know anything about this? I’m pretty sure this is the first time we are seeing this. > > > Random 4.0.0.0/9 address. > > NTT looking glass > Tracing the route to 4.35.230.7 > > 1 * > ae-2.a00.snjsca04.us.bb.gin.ntt.net (129.250.3.58) 3 msec 1 msec > 2 * * * > 3 * * * > 4 * * * > 5 * * * > 6 * * * > > > TATA looking glass > traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets > 1 if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173) 1.253 ms 1.177 ms > MPLS Label=616998 CoS=0 TTL=1 S=1 > 2 195.219.50.50 (195.219.50.50) 1.214 ms 1.247 ms 1.535 ms > 3 195.219.50.50 (195.219.50.50) 1.144 ms * 2.246 ms > 4 * * * > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > > > Telia looking glass > traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets > 1 if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173) 1.253 ms 1.177 ms > MPLS Label=616998 CoS=0 TTL=1 S=1 > 2 195.219.50.50 (195.219.50.50) 1.214 ms 1.247 ms 1.535 ms > 3 195.219.50.50 (195.219.50.50) 1.144 ms * 2.246 ms > 4 * * * > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > > > Level3 looking glass > Traceroute results from Atlanta, GA to 4.200.65.42(dialup-4.200.65.42.Dial1.LosAngeles1) > > 1 0.0.0.0 * * * > 2 0.0.0.0 * * * > 3 0.0.0.0 * * * > 4 0.0.0.0 * * * > 5 0.0.0.0 * * * > 6 0.0.0.0 * * * > 7 0.0.0.0 * * * > 8 0.0.0.0 * * * > 9 0.0.0.0 * * * > 10 0.0.0.0 * * * > 11 0.0.0.0 * * * > > -- > Donovan Van Dyk > SOC Network Engineer > Fort Lauderdale, FL USA > > [cid:image001.png at 01D332DA.F4DD00A0] > The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. > -- Best Regards, Filip Hruska Linux System Administrator From ml at kenweb.org Thu Sep 21 17:56:31 2017 From: ml at kenweb.org (ML) Date: Thu, 21 Sep 2017 13:56:31 -0400 Subject: Has Level3 done away with traceroute?? In-Reply-To: References: <06B9FC37-423D-439C-BC6A-3826FB62243C@akamai.com> Message-ID: <8663d45e-0fb7-0ca8-7cfc-7f3d9fdfc915@kenweb.org> I just performed a few traceroutes. Comcast to 4.2.2.2 5. hu-0-11-0-0-ar03.ivyland.pa.panjde.comcast.net  6. xe-4-0-0.edge1.Toronto.Level3.net  7. ???  8. b.resolvers.Level3.net Comcast to Level3 customer  5. hu-0-11-0-0-ar03.ivyland.pa.panjde.comcast.net  6. xe-4-0-0.edge1.Toronto.Level3.net  7. ae-11-11.bar1.Philadelphia1.Level3.net  8. XXXXXXXX.bar1.Philadelphia1.Level3.net I see the problem for sure FROM a Level3 Philadelphia customer to other destinations though. On 9/21/2017 1:45 PM, Filip Hruska wrote: > Hi, > > Did a measurement with RIPE Atlas and it seems like a worldwide > problem, based on data from 100 probes. > > https://atlas.ripe.net/measurements/9324230/#!tracemon > > > Dne 9/21/17 v 19:10 Van Dyk, Donovan via NANOG napsal(a): >> Hello All, >> >> Recently I was troubleshooting a network event for a client of our >> who resides on the Level3 network. While trying to verify the path, I >> noticed I am no longer able to traceroute through the Level3 network. >> The funny thing is this is not just isolated to the /32. It appears >> to be that the entire 4.0.0.0/9 network is no longer able to >> traceroute through. Everything dies on their edge network. >> >> This appears to be isolated to traceroute. I have check this in NA >> and EU. >> >> My carrier contacted Level3 who pretty much stated that they can’t >> provide anything. >> >> I have checked multiple looking glasses and other online tools and >> none of them make it. Even Level3 looking glass drops the packets. >> >> Does anyone know anything about this? I’m pretty sure this is the >> first time we are seeing this. >> >> >> Random 4.0.0.0/9 address. >> >> NTT looking glass >> Tracing the route to 4.35.230.7 >> >> 1   * >>      ae-2.a00.snjsca04.us.bb.gin.ntt.net (129.250.3.58) 3 msec 1 msec >>   2   *  *  * >>   3   *  *  * >>   4   *  *  * >>   5   *  *  * >>   6   *  *  * >> >> >> TATA looking glass >> traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets >> 1  if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 >> ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173)  1.253 >> ms  1.177 ms >>       MPLS Label=616998 CoS=0 TTL=1 S=1 >> 2  195.219.50.50 (195.219.50.50)  1.214 ms  1.247 ms  1.535 ms >> 3  195.219.50.50 (195.219.50.50)  1.144 ms *  2.246 ms >> 4  * * * >> 5  * * * >> 6  * * * >> 7  * * * >> 8  * * * >> 9  * * * >> 10  * * * >> >> >> Telia looking glass >> traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets >> 1  if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 >> ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173)  1.253 >> ms  1.177 ms >>       MPLS Label=616998 CoS=0 TTL=1 S=1 >> 2  195.219.50.50 (195.219.50.50)  1.214 ms  1.247 ms  1.535 ms >> 3  195.219.50.50 (195.219.50.50)  1.144 ms *  2.246 ms >> 4  * * * >> 5  * * * >> 6  * * * >> 7  * * * >> 8  * * * >> 9  * * * >> 10  * * * >> >> >> Level3 looking glass >> Traceroute results from Atlanta, GA to >> 4.200.65.42(dialup-4.200.65.42.Dial1.LosAngeles1) >> >>    1  0.0.0.0  * * * >>    2  0.0.0.0  * * * >>    3  0.0.0.0  * * * >>    4  0.0.0.0  * * * >>    5  0.0.0.0  * * * >>    6  0.0.0.0  * * * >>    7  0.0.0.0  * * * >>    8  0.0.0.0  * * * >>    9  0.0.0.0  * * * >>   10  0.0.0.0  * * * >>   11  0.0.0.0  * * * >> >> -- >> Donovan Van Dyk >> SOC Network Engineer >> Fort Lauderdale, FL USA >> >> [cid:image001.png at 01D332DA.F4DD00A0] >> The information contained in this electronic mail transmission and >> its attachments may be privileged and confidential and protected from >> disclosure. If the reader of this message is not the intended >> recipient (or an individual responsible for delivery of the message >> to such person), you are strictly prohibited from copying, >> disseminating or distributing this communication. If you have >> received this communication in error, please notify the sender >> immediately and destroy all electronic, paper or other versions. >> > From mel at beckman.org Thu Sep 21 17:57:51 2017 From: mel at beckman.org (Mel Beckman) Date: Thu, 21 Sep 2017 17:57:51 +0000 Subject: Has Level3 done away with traceroute?? In-Reply-To: References: <06B9FC37-423D-439C-BC6A-3826FB62243C@akamai.com>, Message-ID: I am able to traceroute in and out of Level3, but it seems like some L3 internal hops are missing, as I appear to go straight from the L3 edge router to my L3 customer agg router: traceroute to 206.83.0.42 (206.83.0.42), 64 hops max, 52 byte packets 1 47.155.227.1 (47.155.227.1) 4.318 ms 4.661 ms 4.715 ms 2 172.102.107.166 (172.102.107.166) 10.202 ms 7.521 ms 172.102.102.240 (172.102.102.240) 7.240 ms 3 ae8---0.scr02.lsan.ca.frontiernet.net (74.40.3.49) 9.609 ms 7.501 ms ae8---0.scr01.lsan.ca.frontiernet.net (74.40.3.37) 5.298 ms 4 ae0---0.cbr01.lsan.ca.frontiernet.net (74.40.3.198) 7.169 ms 7.015 ms 7.277 ms 5 * * * 6 ae-4-90.edge1.losangeles9.level3.net (4.69.144.202) 8.384 ms 7.012 ms ae-2-70.edge1.losangeles9.level3.net (4.69.144.74) 9.865 ms 7 ae-2-70.edge1.losangeles9.level3.net (4.69.144.74) 7.471 ms ae-3-80.edge1.losangeles9.level3.net (4.69.144.138) 6.551 ms ae-2-70.edge1.losangeles9.level3.net (4.69.144.74) 10.520 ms 8 4.68.111.22 (4.68.111.22) 9.010 ms 7.445 ms 7.314 ms 9 sba1-ar1-xe-11-0-0-0.us.twtelecom.net (35.248.2.6) 9.788 ms 9.536 ms 10.266 ms 10 206-190-77-10.static.twtelecom.net (206.190.77.10) 14.739 ms 12.525 ms 9.979 ms 11 iris1.jet.net (206.83.0.42) 10.285 ms 9.880 ms 10.063 ms traceroute to 47.155.227.1 (47.155.227.1), 64 hops max, 40 byte packets 1 router1.sb.becknet.com (206.83.0.1) 1.270 ms 1.023 ms 0.352 ms 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.799 ms 0.741 ms 0.785 ms 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 3.052 ms 3.126 ms 2.957 ms 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 3.456 ms 3.043 ms 2.981 ms 5 * * * 6 4.16.30.130 (4.16.30.130) 27.564 ms 3.574 ms 3.445 ms 7 ae1---0.scr02.lsan.ca.frontiernet.net (74.40.3.213) 3.489 ms ae1---0.scr01.lsan.ca.frontiernet.net (74.40.3 .197) 3.396 ms ae1---0.scr02.lsan.ca.frontiernet.net (74.40.3.213) 3.428 ms 8 be10---0.lcr21.lsan.ca.frontiernet.net (74.40.3.38) 11.736 ms 5.026 ms be10---0.lcr22.lsan.ca.frontiernet. net (74.40.3.50) 9.858 ms 9 47.155.227.1 (47.155.227.1) 6.545 ms 5.398 ms 6.499 ms -mel beckman > On Sep 21, 2017, at 10:45 AM, Filip Hruska wrote: > > Hi, > > Did a measurement with RIPE Atlas and it seems like a worldwide problem, based on data from 100 probes. > > https://atlas.ripe.net/measurements/9324230/#!tracemon > > > Dne 9/21/17 v 19:10 Van Dyk, Donovan via NANOG napsal(a): >> Hello All, >> >> Recently I was troubleshooting a network event for a client of our who resides on the Level3 network. While trying to verify the path, I noticed I am no longer able to traceroute through the Level3 network. >> The funny thing is this is not just isolated to the /32. It appears to be that the entire 4.0.0.0/9 network is no longer able to traceroute through. Everything dies on their edge network. >> >> This appears to be isolated to traceroute. I have check this in NA and EU. >> >> My carrier contacted Level3 who pretty much stated that they can’t provide anything. >> >> I have checked multiple looking glasses and other online tools and none of them make it. Even Level3 looking glass drops the packets. >> >> Does anyone know anything about this? I’m pretty sure this is the first time we are seeing this. >> >> >> Random 4.0.0.0/9 address. >> >> NTT looking glass >> Tracing the route to 4.35.230.7 >> >> 1 * >> ae-2.a00.snjsca04.us.bb.gin.ntt.net (129.250.3.58) 3 msec 1 msec >> 2 * * * >> 3 * * * >> 4 * * * >> 5 * * * >> 6 * * * >> >> >> TATA looking glass >> traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets >> 1 if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173) 1.253 ms 1.177 ms >> MPLS Label=616998 CoS=0 TTL=1 S=1 >> 2 195.219.50.50 (195.219.50.50) 1.214 ms 1.247 ms 1.535 ms >> 3 195.219.50.50 (195.219.50.50) 1.144 ms * 2.246 ms >> 4 * * * >> 5 * * * >> 6 * * * >> 7 * * * >> 8 * * * >> 9 * * * >> 10 * * * >> >> >> Telia looking glass >> traceroute to 4.7.6.4 (4.7.6.4), 30 hops max, 52 byte packets >> 1 if-ae-14-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.89) 2.056 ms if-ae-6-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.173) 1.253 ms 1.177 ms >> MPLS Label=616998 CoS=0 TTL=1 S=1 >> 2 195.219.50.50 (195.219.50.50) 1.214 ms 1.247 ms 1.535 ms >> 3 195.219.50.50 (195.219.50.50) 1.144 ms * 2.246 ms >> 4 * * * >> 5 * * * >> 6 * * * >> 7 * * * >> 8 * * * >> 9 * * * >> 10 * * * >> >> >> Level3 looking glass >> Traceroute results from Atlanta, GA to 4.200.65.42(dialup-4.200.65.42.Dial1.LosAngeles1) >> >> 1 0.0.0.0 * * * >> 2 0.0.0.0 * * * >> 3 0.0.0.0 * * * >> 4 0.0.0.0 * * * >> 5 0.0.0.0 * * * >> 6 0.0.0.0 * * * >> 7 0.0.0.0 * * * >> 8 0.0.0.0 * * * >> 9 0.0.0.0 * * * >> 10 0.0.0.0 * * * >> 11 0.0.0.0 * * * >> >> -- >> Donovan Van Dyk >> SOC Network Engineer >> Fort Lauderdale, FL USA >> >> [cid:image001.png at 01D332DA.F4DD00A0] >> The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. > > -- > Best Regards, > Filip Hruska > Linux System Administrator > From jheitz at cisco.com Thu Sep 21 18:51:04 2017 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Thu, 21 Sep 2017 18:51:04 +0000 Subject: AS PATH limits Message-ID: The consequence of keeping a route with a long AS_PATH is that it uses a little more memory. Also, if you send it on, you will add one ASN and may exceed the maximum BGP message size and not be able to send it. Even that is no reason to drop the incoming route. The consequence of dropping the route is that someone loses connectivity because you dropped it. The need for limiting AS_PATH length stemmed from this incident: https://dyn.com/blog/the-flap-heard-around-the-world/ This bug has long been fixed, so it should not happen again. However, if you want to be extra cautious, because unpatched routers may still be out there, then 200 should not drop any normal route. Just keep an eye on what you are dropping Thanks, Jakob Date: Tue, 19 Sep 2017 13:33:03 +0000 From: craig washington To: "nanog at nanog.org" Subject: AS PATH limits Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hello world. I was wondering and forgive me if this discussions has already taken place. How many AS PATHS are too many? Meaning how do we determine how many to filter on transit links or public peering links? Thanks in advance From stl at wiredrive.com Thu Sep 21 18:53:33 2017 From: stl at wiredrive.com (Scott Larson) Date: Thu, 21 Sep 2017 11:53:33 -0700 Subject: Bell Canada (AS 577) and NTT (AS 2914) routing Message-ID: I'm looking for a contact at Bell to look at a routing/traffic issue we've been seeing since at least 5pm PDT yesterday. One of our uplinks is via NTT and after correlating with their NOC, it appears traffic passing through that link ends up dying inside the Bell network. -- *[image: userimage]Scott Larson[image: los angeles] Lead Systems Administrator[image: wdlogo] [image: linkedin] [image: facebook] [image: twitter] [image: instagram] T 310 823 8238 <310%20823%208238%20x1106> | M 310 904 8818 <310%20904%208818>* From jared at puck.nether.net Thu Sep 21 19:53:58 2017 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 21 Sep 2017 15:53:58 -0400 Subject: Bell Canada (AS 577) and NTT (AS 2914) routing In-Reply-To: References: Message-ID: > On Sep 21, 2017, at 2:53 PM, Scott Larson wrote: > > I'm looking for a contact at Bell to look at a routing/traffic issue > we've been seeing since at least 5pm PDT yesterday. One of our uplinks is > via NTT and after correlating with their NOC, it appears traffic passing > through that link ends up dying inside the Bell network. > % traceroute www.bell.ca traceroute to www.bell.ca (184.150.211.7), 30 hops max, 60 byte packets 1 Internal (x.x.x.x) 0.400 ms 0.436 ms 0.431 ms 2 ae-1.a01.chcgil09.us.bb.gin.ntt.net (129.250.5.94) 0.378 ms 0.412 ms 0.409 ms 3 ae-0.bell-canada.chcgil09.us.bb.gin.ntt.net (128.241.3.10) 0.765 ms bx4-chicagodt_pos0-1-0-1_core.net.bell.ca (64.230.186.217) 0.885 ms 0.979 ms 4 tcore3-chicagocp_0-10-0-0.net.bell.ca (64.230.79.84) 26.458 ms 26.501 ms tcore4-chicagocp_0-10-0-0.net.bell.ca (64.230.79.86) 23.043 ms 5 tcore4-toronto12_hundredgige1-2-0-0.net.bell.ca (64.230.79.156) 26.938 ms 26.939 ms 26.978 ms 6 tcore4-montreal01_hundredgige0-9-0-0.net.bell.ca (64.230.79.195) 26.487 ms tcore3-montreal02_1-7-0-0.net.bell.ca (64.230.79.31) 24.361 ms tcore4-montreal01_hundredgige0-9-0-0.net.bell.ca (64.230.79.195) 25.795 ms 7 tcore4-montreal02_pos0-7-0-0_core.net.bell.ca (64.230.168.98) 24.879 ms 24.859 ms tcore3-montrealak_pos0-13-0-0.net.bell.ca (64.230.32.117) 24.168 ms 8 agg2-montrealak_xe5-0-0.net.bell.ca (64.230.173.46) 25.591 ms 25.534 ms agg2-montrealak_xe7-0-0.net.bell.ca (64.230.173.38) 23.145 ms 9 dis1-montreal43_7-0-0.net.bell.ca (64.230.128.70) 23.254 ms 21.132 ms 33.596 ms 10 * * * 11 216.208.226.199 (216.208.226.199) 25.462 ms 25.444 ms 23.482 ms From randy at psg.com Fri Sep 22 01:59:01 2017 From: randy at psg.com (Randy Bush) Date: Fri, 22 Sep 2017 10:59:01 +0900 Subject: pd table vs 6296 Message-ID: say i want to use pd to a fairly large aggregation. the router has to hold the pd table. it sees some routers have limited table size, e.g. 1k. so what's a poor boy to do? the classic ipv4 solution would be 6296 . are folk doing pd scaling? how? randy From colton.conor at gmail.com Fri Sep 22 03:10:48 2017 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 21 Sep 2017 22:10:48 -0500 Subject: Application Layer Gateways Message-ID: Working with an ISP, we recently deployed Comtrend VDSL routers, and Alcatel-Lucent GPON ONTs. Both of these devices uses chipsets made by Broadcom, and as such probably use the same underlying Broadcom operating system if I had to guess. They are different chipsets though as one is from VDSL2, and the other for GPON By default, the Comtrend had the following Firewall -- ALG/Pass-Throughs enabled: FTP H323 IPSec IRC PPTP RTSP SIP TFTP On the Acatel-Lucent (Nokia) ONT, the following came enabled by default from the factory: FTP H323 IPSEC L2TP PPTP RTSP SIP TFTP The only difference between these two is the Comtrend has an IRC as a ALG, and Acatel has L2TP as a protocol type. The other seven ALG protocols as the same. My question is in general, is it a good idea to disable all Application Layer Gateways? The only ALG I have had experience with was a SIP ALG. Almost all SIP providers strongly recommend you disable SIP ALGs as it does more harm and breaks more things than it does good, so we always disable SIP ALG. But what about the other protocols on these two? Do you think they should be enabled or disabled by default? I am leaning towards disabling them all for our standard config. From sean at donelan.com Fri Sep 22 03:53:21 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 21 Sep 2017 23:53:21 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of Message-ID: This summary status is a bit different. Instead it is a report about what we don't know, and estimate how much we don't know based on official reporting. The FCC DIRS report is based on outages reported by service providers. Almost no local providers have been able to file either a positive or negative report on the DIRS website. So the data is very incomplete. Electric Services Puerto Rico: 1,569,796 customers out of service (100%) U.S. Virgin Islands: 90% of grid on St. Thomas and St. John destroyed by Hurricane Irma, a few critical facilities re-energized. 25,000 customers on St. Croix out of service after Hurricane Maria, but may be able to re-energize most of the St. Croix grid on Friday. Internet Services All submarine cables and landing stations appear operational. 2 colocation data centers on Puerto Rico appear to be operational. I couldn't tell if there any of the old Internet Exchange Points were still operating, or had ceased before the hurricanes. Puerto Rico: Approximately 880 networks out of 1200 not reachable (24 out 48 ASN). U.S. Virgin Islands: Approximately 13 networks out of 70 not reachable (2 out of 6 ASN) Public Safety Services Public Safety Answering Points (9-1-1 centers) Puerto Rico: 2 out of 2 PSAPs reporting. 2 operating normally. US Virgin Islands: 2 out of 2 PSAPs reporting. 2 operating without automatic location identifier NOAA Weather Forecast Office Puerto Rico: Office on backup generation, weather RADAR offline, 1 of 2 Weather Radio transmitters offline US Virgin Islands: Served by San Juan, PR WFO, 1 of 1 Weather Radio transmitter offline Wireless Services Puerto Rico: (1703 cell sites out of 1789) 95% of cell sites out of service. 48 out of 78 counties with 100% of cell sites out of service. U.S. Virgin Islands: (82 cell sites out of 107) 77% of cell sites out of service. Cable and Wireline Systems Puerto Rico (est. 11 companies-ILEC, CLECs and Cable in LATA) FCC summary implies no companies have reported yet. Large percentages of consumers without cable or wireline service U.S. Virgin Islands (est. 3 companies-ILEC, CLECs and Cable in LATA) FCC summary implies no companies have reported yet. Large percentage of consumers without cable or wireline service Broadcast facilities Puerto Rico 34 TV stations-not including repeaters, translators, boosters 1 TV station reporting - 1 station out of service 33 TV stations not reporting (public reports no TV stations operating on air) 141 radio stations-not including repeaters, translators 141 radio stations not reporting (public reports estimate a dozen radio stations operating on air) U.S. Virgin Islands 5 TV stations- not including repeaters, translaters, boosters 5 TV stations not reporting 26 radio stations-not including repeaters, translators 26 radio stations not reporting From shoemakerp at vectordatasystems.com Thu Sep 21 22:50:54 2017 From: shoemakerp at vectordatasystems.com (Patrick Shoemaker) Date: Thu, 21 Sep 2017 22:50:54 +0000 Subject: Hughesnet IPv6 Message-ID: <046C142F-EE88-4990-834C-EF2B4C2EB948@vectordatasystems.com> Are there any HughesNet network engineers on here who could either contact me off list to answer some questions about the IPv6 implementation on the Gen5 platform? Standard support mechanisms are not very useful here. Thanks, Patrick Shoemaker From cb.list6 at gmail.com Fri Sep 22 04:02:01 2017 From: cb.list6 at gmail.com (Ca By) Date: Fri, 22 Sep 2017 04:02:01 +0000 Subject: Application Layer Gateways In-Reply-To: References: Message-ID: On Thu, Sep 21, 2017 at 8:12 PM Colton Conor wrote: > Working with an ISP, we recently deployed Comtrend VDSL routers, and > Alcatel-Lucent GPON ONTs. Both of these devices uses chipsets made by > Broadcom, and as such probably use the same underlying Broadcom operating > system if I had to guess. They are different chipsets though as one is from > VDSL2, and the other for GPON > > By default, the Comtrend had the following Firewall -- ALG/Pass-Throughs > enabled: > > FTP > H323 > IPSec > IRC > PPTP > RTSP > SIP > TFTP > > On the Acatel-Lucent (Nokia) ONT, the following came enabled by default > from the factory: > > FTP > H323 > IPSEC > L2TP > PPTP > RTSP > SIP > TFTP > > > The only difference between these two is the Comtrend has an IRC as a ALG, > and Acatel has L2TP as a protocol type. The other seven ALG protocols as > the same. > > My question is in general, is it a good idea to disable all Application > Layer Gateways? > Yes. ALG are frequently too smart for their own good. > The only ALG I have had experience with was a SIP ALG. Almost all SIP > providers strongly recommend you disable SIP ALGs as it does more harm and > breaks more things than it does good, so we always disable SIP ALG. But > what about the other protocols on these two? Do you think they should be > enabled or disabled by default? > > I am leaning towards disabling them all for our standard config. > From jfmezei_nanog at vaxination.ca Fri Sep 22 05:25:49 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 22 Sep 2017 01:25:49 -0400 Subject: Puerto Rico just lost internet? In-Reply-To: References: <26802501-9682-4A51-9317-22F948878DE0@uvm.edu> Message-ID: <7ef13594-bfdc-8723-3bef-54640062a197@vaxination.ca> During the 1998 ice storm, Hydro Québec stated its infrastructure had not been built to widthstand this once in 100 year event. Reporters did some research and the next day asked him if there was a trend in increased freezing rain events. "I'll have to look into it". The next day, the HQ CEO came back at the daily press conference to confirm a gradual increase in last 20 years in freezing rain events, and after looking at situation, HQ would change standards for its infrastructure to widstand more frequent freezing rain events. In Ontario, the govt passed new stronger standards for utility poles which while granfathering existing ones, required the new standards apply before you can add one more wire to a pole. This seemed innocusous until telcos (Bell and smaller ones) started to want to add fibre to poles, where, in many cases, poles had to be replaced at $30k a shot, and original owner retained onwership of new pole paid by the telco. During the same event, Bell Canada, whose disaster plans were overwhelmed by the extent of power outages didn't have enough mobile generators to keep every outdoor plant's batteries charged all the time. As a result many areas suffered rolling POTS and cellular blackouts until a truck could there there with a generator. Because of the extent of the event, Bell couldn't bring spare generators from the next town over because that town was also in short supply of generators. When the nature of disruptive weather events changes (or become more frequent), utilities needs to adapt by adding more resiliency to physical infrastructure and being prepared with more spare hardware to cope with the aftermath. Hurricanes have the advantage of giving a few days warning and predictions are becoming more accurate. In the case of Irma, utilises have the time to pre-position trucks/equipment so they can kick in as soon as winds/flooding go down. In the case of Hydro Québec, their own statistics showed significant long term increase in freezing rain events, so easy to justify spending money to upgrade infrastrtucture. In the case of recent hurricanes, it is still debatable whether those were unusual events (since many towns had not experienced such striong weather for over 50 years) or whetgher frequencty of such events was going to increase. This would affect how telcos plan how resilient their infrastructure needs to be. From benoit.panizzon at imp.ch Fri Sep 22 11:46:40 2017 From: benoit.panizzon at imp.ch (Benoit Panizzon) Date: Fri, 22 Sep 2017 13:46:40 +0200 Subject: Vodafone Global Carrier Services: Contact to Abuse/Fraud Department? Message-ID: <20170922134640.257b2f47@go.imp.ch> Hello I'm trying to reach somebody from Vodafone Global Carrier Services, regarding abusive calls originating from their network (probably transit from some other TSP). Their IC team do not consider them self in charge of abuse cases. The Vodafone UK fraud teams declares itself only responsible if I am a Vodafone end customer. If somebody has a contact or works @ Vodafone Global Carrier Services, could you please contact me off list? Kind regards -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ From steve.teusch at rtr.guru Fri Sep 22 07:12:12 2017 From: steve.teusch at rtr.guru (Steve Teusch) Date: Fri, 22 Sep 2017 07:12:12 +0000 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: I am running into venders that do not support injection of a delegated route when operating as a DHCPv6 relay (or server for that matter). Brocade supports this, but I am not finding this as part of any of the RFC's. This is to deliver home ISP service, so it is very important or return packets won't go to the client unless the route is manually added as a routing protocol is not an option. There should be a MUST activity for this somewhere. Anyone know what gives? From sean at donelan.com Fri Sep 22 14:43:24 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 22 Sep 2017 10:43:24 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: Following up - there are three cable landing stations and 9 submarine cable systems connecting Puerto Rico. One of the cable landing stations experienced flooding, and shutdown its power system affecting some circuits. I haven't been able to determine how many submarine cable systems are affected, since they share cable landing stations. From rubensk at gmail.com Fri Sep 22 15:11:34 2017 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 22 Sep 2017 12:11:34 -0300 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: On Fri, Sep 22, 2017 at 11:43 AM, Sean Donelan wrote: > > Following up - there are three cable landing stations and 9 submarine > cable systems connecting Puerto Rico. > > One of the cable landing stations experienced flooding, and shutdown its > power system affecting some circuits. I haven't been able to determine how > many submarine cable systems are affected, since they share cable landing > stations. > > And that shutdown affected Internet capacity throughout South America. Rubens From nick at foobar.org Fri Sep 22 15:37:13 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Sep 2017 16:37:13 +0100 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: <59C52E29.2000504@foobar.org> Steve Teusch wrote: > I am running into venders that do not support injection of a > delegated route when operating as a DHCPv6 relay (or server for that > matter). Brocade supports this, but I am not finding this as part of > any of the RFC's. This is to deliver home ISP service, so it is very > important or return packets won't go to the client unless the route > is manually added as a routing protocol is not an option. There > should be a MUST activity for this somewhere. > > Anyone know what gives? This is being blocked by a number of parties at the IETF because of religious systemic antipathy towards DHCPv6. Nick From lee at asgard.org Fri Sep 22 16:37:14 2017 From: lee at asgard.org (Lee Howard) Date: Fri, 22 Sep 2017 12:37:14 -0400 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: On 9/22/17, 3:12 AM, "NANOG on behalf of Steve Teusch" wrote: >I am running into venders that do not support injection of a delegated >route when operating as a DHCPv6 relay (or server for that matter). >Brocade supports this, but I am not finding this as part of any of the >RFC's. This is to deliver home ISP service, so it is very important or >return packets won't go to the client unless the route is manually added >as a routing protocol is not an option. There should be a MUST activity >for this somewhere. > >Anyone know what gives? Well, it’s weird for a DHCPv6 relay process to inspect relayed Reply messages and use them to update the routing table. Weird, but I’ve done it. What origin type do you use for that route? Static, really? This behavior was requested by operators who needed it; I don’t remember whether we even went to the IETF with it. I think descriptions exist in CableLabs IPv6 docs; maybe in BBF docs, too. Any vendor who doesn’t do it is in the process of shutting down their ISP access router business. Lee From joelja at bogus.com Fri Sep 22 16:41:10 2017 From: joelja at bogus.com (joel jaeggli) Date: Fri, 22 Sep 2017 09:41:10 -0700 Subject: pd table vs 6296 In-Reply-To: References: Message-ID: <3a6e45b2-3d87-218a-c7ff-7b582d965ff8@bogus.com> On 9/21/17 18:59, Randy Bush wrote: > say i want to use pd to a fairly large aggregation. the router has to > hold the pd table. it sees some routers have limited table size, e.g. > 1k. so what's a poor boy to do? the classic ipv4 solution would be > 6296 . are folk doing pd scaling? how? > > randy > This is kind of in the neighborhood of stupid pet tricks, but I've done it to substantially increase the table size in a non-pd scenario, so there is that. In an accommodating switch, program a particular prefix length (say 56 or 48 ending on a byte offset) to be installed and matched in the exact match table. Voila your PD routes are now host routes, and the table for VLSM routes is free for other purposes. 1. Isn't this robbing peter to pay paul? - yes 2. Is this some kind of strange classful addressing hetrodoxy? - not really, masks just happen to be expensive. 3. How does this work with variable length prefix delegation? - all PD prefixes are the same (maximum) size and you install them in the routing table accordingly> what the end system asks for and what they do with it when you route it to them are both their business. A decent (not necessarily high end) L3 switch will let you partition the CAM  in several variations that are more or less appropriate for this application. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From baldur.norddahl at gmail.com Fri Sep 22 16:51:38 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 22 Sep 2017 18:51:38 +0200 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: This method is lacking because you might have several routers eg. using VRRP and the backup router will not learn anything from a relay on the primary. Den 22. sep. 2017 14.02 skrev "Steve Teusch" : I am running into venders that do not support injection of a delegated route when operating as a DHCPv6 relay (or server for that matter). Brocade supports this, but I am not finding this as part of any of the RFC's. This is to deliver home ISP service, so it is very important or return packets won't go to the client unless the route is manually added as a routing protocol is not an option. There should be a MUST activity for this somewhere. Anyone know what gives? From nwarren at barryelectric.com Fri Sep 22 17:08:02 2017 From: nwarren at barryelectric.com (Nicholas Warren) Date: Fri, 22 Sep 2017 17:08:02 +0000 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: Which method would you recommend as an alternative? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl Sent: Friday, September 22, 2017 11:52 AM This method is lacking because you might have several routers eg. using VRRP and the backup router will not learn anything from a relay on the primary. Den 22. sep. 2017 14.02 skrev "Steve Teusch" : I am running into venders that do not support injection of a delegated route when operating as a DHCPv6 relay (or server for that matter). Brocade supports this, but I am not finding this as part of any of the RFC's. This is to deliver home ISP service, so it is very important or return packets won't go to the client unless the route is manually added as a routing protocol is not an option. There should be a MUST activity for this somewhere. Anyone know what gives? From cscora at apnic.net Fri Sep 22 18:02:33 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Sep 2017 04:02:33 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170922180233.B444EC44AD@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Sep, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 665219 Prefixes after maximum aggregation (per Origin AS): 258596 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 320766 Total ASes present in the Internet Routing Table: 58466 Prefixes per ASN: 11.38 Origin-only ASes present in the Internet Routing Table: 50520 Origin ASes announcing only one prefix: 22262 Transit ASes present in the Internet Routing Table: 7946 Transit-only ASes present in the Internet Routing Table: 230 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN ( 8591) 26 Prefixes from unregistered ASNs in the Routing Table: 94 Number of instances of unregistered ASNs: 95 Number of 32-bit ASNs allocated by the RIRs: 20036 Number of 32-bit ASNs visible in the Routing Table: 15872 Prefixes from 32-bit ASNs in the Routing Table: 64954 Number of bogon 32-bit ASNs visible in the Routing Table: 23 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 368 Number of addresses announced to Internet: 2853913952 Equivalent to 170 /8s, 27 /16s and 69 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 220782 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 183318 Total APNIC prefixes after maximum aggregation: 52306 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 182289 Unique aggregates announced from the APNIC address blocks: 75028 APNIC Region origin ASes present in the Internet Routing Table: 8345 APNIC Prefixes per ASN: 21.84 APNIC Region origin ASes announcing only one prefix: 2312 APNIC Region transit ASes present in the Internet Routing Table: 1199 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 32 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3202 Number of APNIC addresses announced to Internet: 765521632 Equivalent to 45 /8s, 160 /16s and 238 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 200202 Total ARIN prefixes after maximum aggregation: 96002 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 201865 Unique aggregates announced from the ARIN address blocks: 93864 ARIN Region origin ASes present in the Internet Routing Table: 17957 ARIN Prefixes per ASN: 11.24 ARIN Region origin ASes announcing only one prefix: 6624 ARIN Region transit ASes present in the Internet Routing Table: 1765 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2197 Number of ARIN addresses announced to Internet: 1109873952 Equivalent to 66 /8s, 39 /16s and 85 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 177675 Total RIPE prefixes after maximum aggregation: 86849 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 173627 Unique aggregates announced from the RIPE address blocks: 104715 RIPE Region origin ASes present in the Internet Routing Table: 24420 RIPE Prefixes per ASN: 7.11 RIPE Region origin ASes announcing only one prefix: 11206 RIPE Region transit ASes present in the Internet Routing Table: 3475 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6202 Number of RIPE addresses announced to Internet: 713228160 Equivalent to 42 /8s, 130 /16s and 255 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 86491 Total LACNIC prefixes after maximum aggregation: 19501 LACNIC Deaggregation factor: 4.44 Prefixes being announced from the LACNIC address blocks: 87740 Unique aggregates announced from the LACNIC address blocks: 39785 LACNIC Region origin ASes present in the Internet Routing Table: 6406 LACNIC Prefixes per ASN: 13.70 LACNIC Region origin ASes announcing only one prefix: 1776 LACNIC Region transit ASes present in the Internet Routing Table: 1179 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 33 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3925 Number of LACNIC addresses announced to Internet: 171368928 Equivalent to 10 /8s, 54 /16s and 225 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17437 Total AfriNIC prefixes after maximum aggregation: 3862 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 19330 Unique aggregates announced from the AfriNIC address blocks: 7080 AfriNIC Region origin ASes present in the Internet Routing Table: 1072 AfriNIC Prefixes per ASN: 18.03 AfriNIC Region origin ASes announcing only one prefix: 343 AfriNIC Region transit ASes present in the Internet Routing Table: 211 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 346 Number of AfriNIC addresses announced to Internet: 93461760 Equivalent to 5 /8s, 146 /16s and 29 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5296 4194 88 ERX-CERNET-BKB China Education and Rese 7545 3845 406 387 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2934 901 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2827 11126 753 KIXS-AS-KR Korea Telecom, KR 9829 2744 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2389 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2259 1472 114 VNPT-AS-VN VNPT Corp, VN 9394 2174 4931 27 CTTNET China TieTong Telecommunications 4755 2104 422 221 TATACOMM-AS TATA Communications formerl 4134 1745 28203 462 CHINANET-BACKBONE No.31,Jin-rong Street Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3438 1341 88 SHAW - Shaw Communications Inc., CA 22773 3317 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2209 405 108 MEGAPATH5-US - MegaPath Corporation, US 6389 2044 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2040 2250 429 CHARTER-NET-HKY-NC - Charter Communicat 209 1914 5067 645 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1859 3964 553 AMAZON-02 - Amazon.com, Inc., US 30036 1842 330 257 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1687 854 229 ITCDELTA - Earthlink, Inc., US 701 1678 10589 626 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2911 912 2085 AKAMAI-ASN1, US 8551 2457 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2049 330 429 TELLCOM-AS, TR 9121 1927 1691 17 TTNET, TR 12389 1756 1644 677 ROSTELECOM-AS, RU 12479 1708 1052 63 UNI2-AS, ES 13188 1604 100 52 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1202 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3567 542 229 Telmex Colombia S.A., CO 8151 3200 3468 584 Uninet S.A. de C.V., MX 11830 2099 370 65 Instituto Costarricense de Electricidad 6503 1565 437 53 Axtel, S.A.B. de C.V., MX 10481 1563 351 525 Prima S.A., AR 7303 1557 1023 241 Telecom Argentina S.A., AR 6147 1277 377 27 Telefonica del Peru S.A.A., PE 3816 1033 510 92 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 965 2285 181 CLARO S.A., BR 11172 913 126 85 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1203 398 48 LINKdotNET-AS, EG 37611 766 91 8 Afrihost, ZA 36903 708 356 136 MT-MPLS, MA 36992 662 1383 31 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 29571 422 36 10 CITelecom-AS, CI 37492 415 354 77 ORANGE-, TN 8452 357 1730 17 TE-AS TE-AS, EG 15399 357 35 7 WANANCHI-, KE 23889 306 103 14 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5296 4194 88 ERX-CERNET-BKB China Education and Rese 7545 3845 406 387 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3567 542 229 Telmex Colombia S.A., CO 6327 3438 1341 88 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 22773 3317 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8151 3200 3468 584 Uninet S.A. de C.V., MX 17974 2934 901 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2911 912 2085 AKAMAI-ASN1, US 4766 2827 11126 753 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3845 3458 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3438 3350 SHAW - Shaw Communications Inc., CA 10620 3567 3338 Telmex Colombia S.A., CO 22773 3317 3160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2934 2863 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8151 3200 2616 Uninet S.A. de C.V., MX 8551 2457 2416 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2389 2357 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2744 2204 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65010 PRIVATE 46.56.192.0/19 42772 VELCOM-AS, BY 65010 PRIVATE 46.56.224.0/19 42772 VELCOM-AS, BY 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.128.126.0/23 62878 XLITT - Xlitt, US 27.100.7.0/24 56096 UNKNOWN 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 62878 XLITT - Xlitt, US 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:106 /12:283 /13:551 /14:1048 /15:1868 /16:13425 /17:7771 /18:13648 /19:25304 /20:39242 /21:42715 /22:80092 /23:65224 /24:371401 /25:854 /26:635 /27:668 /28:37 /29:38 /30:216 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3234 3438 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2528 3317 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2094 2209 MEGAPATH5-US - MegaPath Corporation, US 8551 1922 2457 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1620 1842 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1520 3567 Telmex Colombia S.A., CO 11830 1489 2099 Instituto Costarricense de Electricidad y Telec 11492 1422 1601 CABLEONE - CABLE ONE, INC., US 9121 1373 1927 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1560 2:834 4:18 5:2452 6:31 7:1 8:1073 12:1856 13:159 14:1682 15:28 16:2 17:169 18:76 20:60 23:2458 24:1608 25:2 27:2370 29:1 31:1920 32:89 33:19 35:21 36:405 37:2361 38:1378 39:69 40:98 41:3036 42:492 43:1946 44:79 45:3089 46:2816 47:171 49:1248 50:1010 51:19 52:826 54:368 55:1 56:4 57:44 58:1571 59:981 60:327 61:2013 62:1721 63:1906 64:4647 65:2210 66:4535 67:2256 68:1189 69:3353 70:1160 71:608 72:2140 74:2643 75:401 76:426 77:1484 78:1543 79:1895 80:1417 81:1411 82:1014 83:724 84:970 85:1878 86:467 87:1201 88:813 89:2228 90:171 91:6243 92:1030 93:2347 94:2379 95:2722 96:637 97:353 98:961 99:95 100:153 101:1440 102:1 103:15882 104:3046 105:189 106:544 107:1758 108:827 109:2917 110:1479 111:1751 112:1278 113:1332 114:1069 115:1551 116:1689 117:1757 118:2148 119:1638 120:725 121:1072 122:2426 123:1869 124:1502 125:1801 128:909 129:677 130:442 131:1484 132:600 133:194 134:704 135:225 136:305 137:468 138:1953 139:520 140:380 141:668 142:747 143:907 144:796 145:184 146:1104 147:701 148:1467 149:584 150:702 151:985 152:753 153:302 154:903 155:756 156:683 157:714 158:485 159:1558 160:749 161:748 162:2505 163:506 164:976 165:1429 166:382 167:1295 168:3034 169:845 170:3538 171:382 172:1017 173:2010 174:789 175:776 176:1856 177:3962 178:2540 179:1124 180:2202 181:2502 182:2441 183:770 184:874 185:10781 186:3427 187:2175 188:2591 189:1841 190:8850 191:1366 192:9651 193:5810 194:4740 195:3935 196:2131 197:1308 198:5529 199:5854 200:7625 201:4526 202:10375 203:9925 204:4516 205:2843 206:3008 207:3148 208:3954 209:4033 210:3945 211:2084 212:2877 213:2538 214:845 215:66 216:5880 217:2132 218:955 219:587 220:1676 221:930 222:761 223:1208 End of report From craigwashington01 at hotmail.com Fri Sep 22 18:23:36 2017 From: craigwashington01 at hotmail.com (craig washington) Date: Fri, 22 Sep 2017 18:23:36 +0000 Subject: AS PATH limits In-Reply-To: References: , Message-ID: Thank you all very much for the feedback. As always it is much appreciated. ________________________________ From: Tom Beecher Sent: Wednesday, September 20, 2017 8:01 PM To: craig washington Cc: nanog at nanog.org Subject: Re: AS PATH limits Too many prepends = any more than you really need for what you're trying to accomplish. :) I've cutoff paths as short as 4 to as long as 8 before in different jobs for different reasons. On Tue, Sep 19, 2017 at 9:33 AM, craig washington > wrote: Hello world. I was wondering and forgive me if this discussions has already taken place. How many AS PATHS are too many? Meaning how do we determine how many to filter on transit links or public peering links? Thanks in advance From steve.teusch at rtr.guru Fri Sep 22 20:47:48 2017 From: steve.teusch at rtr.guru (Steve Teusch) Date: Fri, 22 Sep 2017 20:47:48 +0000 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: VRRP failover and not having the route injected is a good point, although I could mitigate that with a lower lease time a little. I prefer to get V6 working. Plus, its dual stack we are talking about, V4 access is still available. Maybe a VRRP-DHCPv6 relay state table share would be nice to handle that. Although V6 still needs a lot more attention to get to that point. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl Sent: Saturday, September 23, 2017 1:52 AM To: nanog at nanog.org Subject: Re: DHCPv6-PD -> Lack of route injection in RFC This method is lacking because you might have several routers eg. using VRRP and the backup router will not learn anything from a relay on the primary. Den 22. sep. 2017 14.02 skrev "Steve Teusch" : I am running into venders that do not support injection of a delegated route when operating as a DHCPv6 relay (or server for that matter). Brocade supports this, but I am not finding this as part of any of the RFC's. This is to deliver home ISP service, so it is very important or return packets won't go to the client unless the route is manually added as a routing protocol is not an option. There should be a MUST activity for this somewhere. Anyone know what gives? From baldur.norddahl at gmail.com Fri Sep 22 21:46:54 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 22 Sep 2017 23:46:54 +0200 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: I know of several methods all flawed in some ways. There seems to be no progress in this obvious lack of a solid easy way to inject routes to match DHCP-PD. We use ExaBGP to inject routes via BGP that matches the configuration that our DHCP server has. But this is non standard and clumsy to implement. Does not work with all CPE routers either. Regards Baldur Den 22. sep. 2017 19.08 skrev "Nicholas Warren" : Which method would you recommend as an alternative? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl Sent: Friday, September 22, 2017 11:52 AM This method is lacking because you might have several routers eg. using VRRP and the backup router will not learn anything from a relay on the primary. Den 22. sep. 2017 14.02 skrev "Steve Teusch" : I am running into venders that do not support injection of a delegated route when operating as a DHCPv6 relay (or server for that matter). Brocade supports this, but I am not finding this as part of any of the RFC's. This is to deliver home ISP service, so it is very important or return packets won't go to the client unless the route is manually added as a routing protocol is not an option. There should be a MUST activity for this somewhere. Anyone know what gives? From marka at isc.org Fri Sep 22 22:47:32 2017 From: marka at isc.org (Mark Andrews) Date: Sat, 23 Sep 2017 08:47:32 +1000 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: Your message of "Fri, 22 Sep 2017 23:46:54 +0200." References: Message-ID: <20170922224733.0669887B0F1E@rock.dv.isc.org> You know CPE devices are routers. They can tell you what routes DHCP has given them. That annoucement could be cryptographically authenticated. Send a CPE generated public key with the PD request. Generate a CERT for the prefix delegation using those two pieces of information and return it with the prefix delegation. The CPE announces the route using that CERT to sign the announcement to prevent spoofing. Each ISP can be its own CA here if it wants to be or they can tie into the public infrastructure. Mark In message , Baldur Norddahl writes: > I know of several methods all flawed in some ways. There seems to be no > progress in this obvious lack of a solid easy way to inject routes to match > DHCP-PD. > > We use ExaBGP to inject routes via BGP that matches the configuration that > our DHCP server has. But this is non standard and clumsy to implement. Does > not work with all CPE routers either. > > Regards > > Baldur > > > Den 22. sep. 2017 19.08 skrev "Nicholas Warren" : > > Which method would you recommend as an alternative? > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl > Sent: Friday, September 22, 2017 11:52 AM > > This method is lacking because you might have several routers eg. using > VRRP and the backup router will not learn anything from a relay on the > primary. > > > Den 22. sep. 2017 14.02 skrev "Steve Teusch" : > > I am running into venders that do not support injection of a delegated > route when operating as a DHCPv6 relay (or server for that matter). > Brocade supports this, but I am not finding this as part of any of the > RFC's. This is to deliver home ISP service, so it is very important or > return packets won't go to the client unless the route is manually added as > a routing protocol is not an option. There should be a MUST activity for > this somewhere. > > Anyone know what gives? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From valdis.kletnieks at vt.edu Sat Sep 23 05:51:25 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 23 Sep 2017 01:51:25 -0400 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: <20170922224733.0669887B0F1E@rock.dv.isc.org> References: <20170922224733.0669887B0F1E@rock.dv.isc.org> Message-ID: <253258.1506145885@turing-police.cc.vt.edu> On Sat, 23 Sep 2017 08:47:32 +1000, Mark Andrews said: > You know CPE devices are routers. They can tell you what routes > DHCP has given them. That annoucement could be cryptographically > authenticated. This is, of course, a lot easier if the CPE already has onboard the needed software to do that, or you have the ability to push it out. Is anybody from Comcast or other eyeball network willing to say (even roughly) what percent of CPE is gear they supply, versus gear that people get at Best Buy or Walmart and just plug in, versus (if they can identify it) gear that's been reflashed by clued customers? (Personally, I have a Linksys that's been reflashed with Lede, and is configured to work with what Comcast does at their end, and I'm more than happy to reconfig/reflash with other options if Comcast changes their end. Damned if I know how I'd find out, though, other than debugging my connection going wonky.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From fredrik.sallinen at gmail.com Sat Sep 23 11:11:28 2017 From: fredrik.sallinen at gmail.com (Fredrik Sallinen) Date: Sat, 23 Sep 2017 14:41:28 +0330 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: <59BEAD26.1090901@netassist.ua> References: <59BEAD26.1090901@netassist.ua> Message-ID: CPE's are owned by our customers but we have control over ~60% of them using TR069. On Sun, Sep 17, 2017 at 9:43 PM, Max Tulyev wrote: > Hello, > > for my point of view, the start question is do you control CPEs (can > re-configure and re-flash it), or users buy and own CPEs themself? > > On 13.09.17 15:08, Fredrik Sallinen wrote: >> Hello, >> >> Recently we have decided to start IPv6 migration in our network. We >> have ~1K BNGs and connecting our customers to network using PPPoE. >> I'd be interested in hearing from the technical community about their >> experiences and recommendations on this process. I'm wondering: >> >> Shall I go for IPv6-only deployment or dual stack? >> Where to start with IPv6? (core, edge or ...) >> What are the best practices for ISPs? >> What are the costs and return on investment? >> How to identify address CPE and legacy application issues? >> >> Fredrik >> > From fredrik.sallinen at gmail.com Sat Sep 23 11:14:07 2017 From: fredrik.sallinen at gmail.com (Fredrik Sallinen) Date: Sat, 23 Sep 2017 14:44:07 +0330 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: <19206460-B77B-4E74-BBDD-084D438228C5@consulintel.es> References: <19206460-B77B-4E74-BBDD-084D438228C5@consulintel.es> Message-ID: Please correct me If I'm wrong, AFAIK 464XLAT works best with mobile networks and its not suitable for fixed broadband. right? On Mon, Sep 18, 2017 at 10:28 PM, JORDI PALET MARTINEZ wrote: > Fully agree, 464XLAT is the way to go. > > We have tested this in many IPv6-only access deployments, non-cellular networks (cellular is well tested by T-Mobile and others, that have got it in production for years). > > We always have the issue of the CPEs support, but this is the same problem if you want to go to lw4o6, MAP, etc. In general, newer transition mechanisms, aren’t well supported. > > So, you either use OpenWRT if you can re-flash the CPEs, or you push your vendors to make sure they provide a firmware upgrade. > > This is the reason I started to work on an update of the RFC7084 (https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ and https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis-transition/) and see also the related discussion in v6ops. > > Also, I run a panel with CPE vendors in the last week APNIC meeting, and the interesting thing is that they confirmed there is no any technical issue to support those (hardware is ok), and they have already developed it, just waiting for customers to ask for it. > > https://conference.apnic.net/44/program/schedule/#/day/6/bof-discussion-with-ipv6-ce-vendors > > I will compile a report out of this panel ASAP. > > So please, keep pushing your vendors for it! > > Regards, > Jordi > > > -----Mensaje original----- > De: NANOG en nombre de Brock Tice > Responder a: > Fecha: viernes, 15 de septiembre de 2017, 17:14 > Para: Fredrik Sallinen > CC: > Asunto: Re: IPv6 migration steps for mid-scale isp > > We are small but we are just about out of IPv4 and aren't going to get > or buy any more. We have been testing for a while. > > > Shall I go for IPv6-only deployment or dual stack? > > You should plan for adding customers eventually that are IPv6-only, > unless you have all the v4 you will ever need, and you will need to > reserve IPv4 address blocks for translation. > > > How to identify address CPE and legacy application issues? > > Legacy application issues can be solved (for the most part) with > 464XLAT, which also solves IP-literal-in-HTML problems. You need PLAT at > the core and CLAT at the client. Unfortunately so far the only good way > we've found to do CLAT is OpenWRT on the CPE or router. We are getting > ready to bundle Linksys routers flashed with OpenWRT. > > For PLAT at the core we are running jool. It's actually quite simple to > set up and we are currently using OSPF to do anycast, but we will > probably be migrating to a single set of HA servers in the core. The > good news is that even if it goes down, Netflix and Facebook will still > work as they are fully functional on v6. > > We have tested this in my home and at my office with IPv6-only > VLANs/wireless SSIDs, mostly without a hitch. > > If you run this setup without the CLAT on the client side you get NAT64 > so it still will work for most things. > > I would be very, very happy if larger ISPs would put pressure on router > manufacturers to support CLAT, we have no clout. I would also love to > hear if any of this is stupid or if there's a better way. > > --Brock > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > From swmike at swm.pp.se Sat Sep 23 11:19:57 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 23 Sep 2017 13:19:57 +0200 (CEST) Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: <19206460-B77B-4E74-BBDD-084D438228C5@consulintel.es> Message-ID: On Sat, 23 Sep 2017, Fredrik Sallinen wrote: > Please correct me If I'm wrong, AFAIK 464XLAT works best with mobile > networks and its not suitable for fixed broadband. right? It's most widely deployed in mobile networks, yes. There is nothing that says it couldn't work anywhere else. However, in fixed networks with PPPoE the most commonly used model is dual stack with RFC7084 style routers. -- Mikael Abrahamsson email: swmike at swm.pp.se From colton.conor at gmail.com Sat Sep 23 14:13:33 2017 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 23 Sep 2017 09:13:33 -0500 Subject: Application Layer Gateways In-Reply-To: References: Message-ID: So you do recommend we disable them all? Just not sure why big vendors like Alcatel and Comtrend would have them enabled by default if they do more harm than good? On Thu, Sep 21, 2017 at 11:02 PM, Ca By wrote: > > On Thu, Sep 21, 2017 at 8:12 PM Colton Conor > wrote: > >> Working with an ISP, we recently deployed Comtrend VDSL routers, and >> Alcatel-Lucent GPON ONTs. Both of these devices uses chipsets made by >> Broadcom, and as such probably use the same underlying Broadcom operating >> system if I had to guess. They are different chipsets though as one is >> from >> VDSL2, and the other for GPON >> >> By default, the Comtrend had the following Firewall -- ALG/Pass-Throughs >> enabled: >> >> FTP >> H323 >> IPSec >> IRC >> PPTP >> RTSP >> SIP >> TFTP >> >> On the Acatel-Lucent (Nokia) ONT, the following came enabled by default >> from the factory: >> >> FTP >> H323 >> IPSEC >> L2TP >> PPTP >> RTSP >> SIP >> TFTP >> >> >> The only difference between these two is the Comtrend has an IRC as a ALG, >> and Acatel has L2TP as a protocol type. The other seven ALG protocols as >> the same. >> >> My question is in general, is it a good idea to disable all Application >> Layer Gateways? >> > > Yes. ALG are frequently too smart for their own good. > > > >> The only ALG I have had experience with was a SIP ALG. Almost all SIP >> providers strongly recommend you disable SIP ALGs as it does more harm and >> breaks more things than it does good, so we always disable SIP ALG. But >> what about the other protocols on these two? Do you think they should be >> enabled or disabled by default? >> >> I am leaning towards disabling them all for our standard config. >> > From cb.list6 at gmail.com Sat Sep 23 14:47:33 2017 From: cb.list6 at gmail.com (Ca By) Date: Sat, 23 Sep 2017 14:47:33 +0000 Subject: Application Layer Gateways In-Reply-To: References: Message-ID: On Sat, Sep 23, 2017 at 7:13 AM Colton Conor wrote: > So you do recommend we disable them all? > Yes. A good rule of thumb is to turn off any feature you do not need. If you find customers complain, you can turn it on one by one. The reverse is not true, once the ALG is on you will be affraid you might break something if you turn it off Just not sure why big vendors like Alcatel and Comtrend would have them > enabled by default if they do more harm than good? > Turns out vendors focus on building and selling gear but are not experienced in running networks > On Thu, Sep 21, 2017 at 11:02 PM, Ca By wrote: > >> >> On Thu, Sep 21, 2017 at 8:12 PM Colton Conor >> wrote: >> >>> Working with an ISP, we recently deployed Comtrend VDSL routers, and >>> Alcatel-Lucent GPON ONTs. Both of these devices uses chipsets made by >>> Broadcom, and as such probably use the same underlying Broadcom operating >>> system if I had to guess. They are different chipsets though as one is >>> from >>> VDSL2, and the other for GPON >>> >>> By default, the Comtrend had the following Firewall -- ALG/Pass-Throughs >>> enabled: >>> >>> FTP >>> H323 >>> IPSec >>> IRC >>> PPTP >>> RTSP >>> SIP >>> TFTP >>> >>> On the Acatel-Lucent (Nokia) ONT, the following came enabled by default >>> from the factory: >>> >>> FTP >>> H323 >>> IPSEC >>> L2TP >>> PPTP >>> RTSP >>> SIP >>> TFTP >>> >>> >>> The only difference between these two is the Comtrend has an IRC as a >>> ALG, >>> and Acatel has L2TP as a protocol type. The other seven ALG protocols as >>> the same. >>> >>> My question is in general, is it a good idea to disable all Application >>> Layer Gateways? >>> >> >> Yes. ALG are frequently too smart for their own good. >> >> >> >>> The only ALG I have had experience with was a SIP ALG. Almost all SIP >>> providers strongly recommend you disable SIP ALGs as it does more harm >>> and >>> breaks more things than it does good, so we always disable SIP ALG. But >>> what about the other protocols on these two? Do you think they should be >>> enabled or disabled by default? >>> >>> I am leaning towards disabling them all for our standard config. >>> >> > From list at satchell.net Sat Sep 23 16:45:27 2017 From: list at satchell.net (Stephen Satchell) Date: Sat, 23 Sep 2017 09:45:27 -0700 Subject: Application Layer Gateways In-Reply-To: References: Message-ID: On 09/23/2017 07:47 AM, Ca By wrote: > On Sat, Sep 23, 2017 at 7:13 AM Colton Conor wrote: >> Just not sure why big vendors like Alcatel and Comtrend would have them >> enabled by default if they do more harm than good? > Turns out vendors focus on building and selling gear but are not > experienced in running networks I don't have any quarrel with your statement about experience with running networks, but I would surmise the real reason is that same one that caused Microsoft to turn on so much Bad Stuff(tm) in Windows by default: reduction in tech support calls. How many times have you read a manual cover-to-cover for a new piece of equipment before doing ANYTHING with it? Especially when the manual is on CD-ROM, and the PDFs take up about 500 MB of the 700 MB of available space. I have yet to find a piece of network gear that has a "cheat sheet" that bullet-lists all the options (and perhaps a 25-word description) and where in the manual to find how to turn it on/off. Even better would be a collection of canned configuration files, from "absolute minimum" (EVERYTHING turned off) to "all the bells and whistles enabled". Note that this corresponds to the concept of "mostly closed" firewalls and "mostly open" firewalls. I've seen model configuration files in Unix/Linux where all the defaults (which constitutes an absolute minimum of turned-on options) are shown in comments, so that you can just go through the config and turn on exactly what you need. From jfmezei_nanog at vaxination.ca Sat Sep 23 17:33:19 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 23 Sep 2017 13:33:19 -0400 Subject: Application Layer Gateways In-Reply-To: References: Message-ID: <1316e25e-0cc9-f6a5-7654-e6dec18b53d2@vaxination.ca> What you do with the CPE "firewall" settings depends on what sort of ISP you are. Do you cater to geeks or aunts/grand mothers? Whatever you do, I would suggest that you document in a place that is easy for customers to find exactlyt what apps/protocols are open/closed with the settings you've decided on (especially if it deviates from any documentation available on the net for that device) You could consider configuring it by default to protect the aunts and grand mothers, but make sure geeks get the info on how to easily open ports for their apps. Also depends on what you block at the network level. If you block all incoming calls to port 25, then blocking it at the CPE router won't add much resilience against attacks as it is already blocked. From javier at advancedmachines.us Sat Sep 23 21:01:20 2017 From: javier at advancedmachines.us (Javier J) Date: Sat, 23 Sep 2017 17:01:20 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: T-Mobile PR on twitter just posted that two of it's submarine cables are out of service. Claro PR Wireless (this is the ILEC in PR) website can't even be reached. I am assuming this is due to power and submarine cable issues since I'm sure t-mobile and many other providers are using the same cables. Link to the post on twitter: https://twitter.com/tmobilepr/status/911644083155869697 - Javier On Fri, Sep 22, 2017 at 10:43 AM, Sean Donelan wrote: > > Following up - there are three cable landing stations and 9 submarine > cable systems connecting Puerto Rico. > > One of the cable landing stations experienced flooding, and shutdown its > power system affecting some circuits. I haven't been able to determine how > many submarine cable systems are affected, since they share cable landing > stations. > > From sean at donelan.com Sat Sep 23 21:52:59 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 23 Sep 2017 17:52:59 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: Reportedly most (All?) operational cellular carriers on Puerto Rico have activated "universal roaming" service. All working towers will accept roaming connections from any phone from any carrier (or no service provider). You may need to turn the phone off & on so it scans for a working signal. Roaming still requires a working cell tower. 48 counties and county-equivalents in Puerto Rico have 0% cell sites working. Less than 25% of cell sites in the remaining counties are working. Capacity is extremely limited, so use SMS/Text rather than voice or data. A side-effect of universal roaming is lack of billing, so expect carriers to announce they are waiving charges and overages in Puerto Rico. From sean at donelan.com Sat Sep 23 23:08:42 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 23 Sep 2017 19:08:42 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: According to PREPA Net, the fiber subsidary of the Electric Power Authority, the power system for the Punta las Marías submarine cable station is back in service after flooding. I think Isla Verde and Punta las Marias refer to the same landing point. I don't know the status of individual submarine cable systems using that landing station. The Miramar and San Juan cable landing stations are also in service. From sean at donelan.com Sun Sep 24 19:28:35 2017 From: sean at donelan.com (Sean Donelan) Date: Sun, 24 Sep 2017 15:28:35 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: The ILEC, Claro, is reporting all 24 central offices in Puerto Rico are now operating on generators, and maintaining re-fueling operations. The CO's in the (San Juan?) metro area have voice, data and long distance service including to the mainland. The CO's elsewhere in Puerto Rico have only local voice service. The offices are isolated, with no long distance or inter-office data service. Although the CO's are operational, substantial outside plant is damaged. Which means most subscribers do not have service. Inter-office facilities outside the (San Juan) metro area are damaged, which means people with service in those areas can only make local calls. Wireless sites are still being evaluated. The Puerto Rico Transportation Department is providing road crews to clear/rebuild roads and escort cellular providers repair convoys to remote cell sites. The Puerto Rican government has not re-established communications with officials in the following municipalities: Aibonito, Jayuya, Lajas, Mayaguez, Quebradillas, Rincón, Sabana Grande, Vieques and Villalba. From raymond.beaudoin at icarustech.com Sun Sep 24 19:32:09 2017 From: raymond.beaudoin at icarustech.com (Raymond Beaudoin) Date: Sun, 24 Sep 2017 14:32:09 -0500 Subject: Settle Free Peering - Default Route Abuse Monitoring Message-ID: Hello, Everyone! Many SFP agreements include terms that the peering link will not be used as an upstream with static defaults. A few examples are provided below. *h. must agree not to abuse the peering relationship by engaging in activities such as but not limited to: pointing a default route at the other or otherwise forwarding traffic for destinations not explicitly advertised, resetting next-hop, selling or giving next-hop to others;* Source: http://www.level3.com/en/legal/ip-traffic-exchange-policy/ *2.6. Neither Network shall point default into or transit the other Network where that network has* *not advertised a route for the destination in question.* Source: http://www.zayo.com/wp-content/uploads/2017/02/ZayoPeeringPolicy.pdf How is this monitored and tracked? Are ACLs applied to help enforce this (seems to be limited at scale)? Flow export and alarming? Analytics and anomalous behavior detection? Common professional courtesy? Thanks so much for any insight you may have. I'd like to ensure I'm following all best practices when in IX and peer situations. -Raymond Beaudoin From job at ntt.net Sun Sep 24 20:05:18 2017 From: job at ntt.net (Job Snijders) Date: Sun, 24 Sep 2017 20:05:18 +0000 Subject: Settle Free Peering - Default Route Abuse Monitoring In-Reply-To: References: Message-ID: Dear Raymond, On Sun, 24 Sep 2017 at 21:33, Raymond Beaudoin < raymond.beaudoin at icarustech.com> wrote: > How is this monitored and tracked? Are ACLs applied to help enforce this > (seems to be limited at scale)? Flow export and alarming? Analytics and > anomalous behavior detection? Common professional courtesy? This RFC https://tools.ietf.org/html/rfc7789 covers the topic of “unexpected traffic flows” which is essentially the same as having default being pointed at you without you permission. May be worth reading! A most scalable option is to use a flow collection / monitoring program like pmacct (http://pmacct.net/) to inspect flows and flag the ones that shouldn’t exist according to your policy. Paolo Lucente has done excellent work to make this problem space manageable: http://wiki.pmacct.net/DetectingRoutingViolations Also, if you are at an internet exchange, make sure to enable MAC accounting (if available) on the IX facing interface, so you can easily monitor for traffic coming from MAC addresses with which you don’t have a BGP session. Kind regards, Job From nanog at ics-il.net Sun Sep 24 20:09:22 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 24 Sep 2017 15:09:22 -0500 (CDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <1264907839.2452.1506283758921.JavaMail.mhammett@ThunderFuck> >From one of my colleages that has a decent sized WISP in Puerto Rico. " Guys, we are ok, network hurt pretty bad… will need help " There are a bunch of WISPs waiting to go rebuild, but waiting for the clearance to do so. https://radar.qrator.net/as14979/providers#startDate=2017-08-09&endDate=2017-09-23&tab=current It looks like they're still online via Critical Hub Networks and Columbus Networks, but not Liberty. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Sean Donelan" To: nanog at nanog.org Sent: Sunday, September 24, 2017 2:28:35 PM Subject: Re: Hurricane Maria: Summary of communication status - and lack of The ILEC, Claro, is reporting all 24 central offices in Puerto Rico are now operating on generators, and maintaining re-fueling operations. The CO's in the (San Juan?) metro area have voice, data and long distance service including to the mainland. The CO's elsewhere in Puerto Rico have only local voice service. The offices are isolated, with no long distance or inter-office data service. Although the CO's are operational, substantial outside plant is damaged. Which means most subscribers do not have service. Inter-office facilities outside the (San Juan) metro area are damaged, which means people with service in those areas can only make local calls. Wireless sites are still being evaluated. The Puerto Rico Transportation Department is providing road crews to clear/rebuild roads and escort cellular providers repair convoys to remote cell sites. The Puerto Rican government has not re-established communications with officials in the following municipalities: Aibonito, Jayuya, Lajas, Mayaguez, Quebradillas, Rincón, Sabana Grande, Vieques and Villalba. From sean at donelan.com Sun Sep 24 21:13:33 2017 From: sean at donelan.com (Sean Donelan) Date: Sun, 24 Sep 2017 17:13:33 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <1264907839.2452.1506283758921.JavaMail.mhammett@ThunderFuck> References: <1264907839.2452.1506283758921.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, 24 Sep 2017, Mike Hammett wrote: > There are a bunch of WISPs waiting to go rebuild, but waiting for the > clearance to do so. I'm not sure what clearances they are waiting for. If they are already in Puerto Rico, self-sufficient, and respect curfews and other emergency responders, they should be able to start local restoration and recovery activities. Several local ISPs and communication providers have announced open public WiFi hotspots outside their Puerto Rico offices during non-curfew hours. I've also seen reports from individuals volunteering on the Virigin Islands setting up internet access. If they are not already on the island, most Puerto Rican airports and ports are still closed to non-military or relief activities. There is no U.S. mail or freight service. Only one airport was open for limited commercial flights. They will need to bring everything neccessary to support themselves, including food, water, shelter, etc. Managing volunteers who want to help is difficult in all disasters. Unless they have training how to survive and take care of themselves in such a situation, letting in outside well-meaning volunteers sometimes become additional people who need to rescue. WISPs already on Puerto Rico or U.S. Virigin Islands, with resources for recovery and restoration of communications; can contact the FCC Operations Center, (202) 418-1122, FCCOperationCenter at fcc.gov http://transition.fcc.gov/Daily_Releases/Daily_Business/2017/db0920/DA-17-913A1.pdf From sean at donelan.com Sun Sep 24 22:54:32 2017 From: sean at donelan.com (Sean Donelan) Date: Sun, 24 Sep 2017 18:54:32 -0400 (EDT) Subject: Why San Juan National Weather Service RADAR is out of service Message-ID: The National Weather Service office in San Juan Puerto Rico is back on line. They have posted pictures of the weather radardome, or rather what's left of the radardome after Hurricane Maria. https://twitter.com/NWSSanJuan/status/912082857518092288 From surfer at mauigateway.com Sun Sep 24 23:03:03 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 24 Sep 2017 16:03:03 -0700 Subject: Why San Juan National Weather Service RADAR is out of service Message-ID: <20170924160303.33A36BA9@m0117458.ppops.net> --- sean at donelan.com wrote: From: Sean Donelan The National Weather Service office in San Juan Puerto Rico is back on line. They have posted pictures of the weather radardome, or rather what's left of the radardome after Hurricane Maria. https://twitter.com/NWSSanJuan/status/912082857518092288 --------------------------------------------------- I got a "page does not exist". Go to their main page and it's there. https://twitter.com/NWSSanJuan scott From raymond.beaudoin at icarustech.com Mon Sep 25 00:21:40 2017 From: raymond.beaudoin at icarustech.com (Raymond Beaudoin) Date: Sun, 24 Sep 2017 19:21:40 -0500 Subject: Settle Free Peering - Default Route Abuse Monitoring In-Reply-To: References: Message-ID: Job, Thanks so much for the helpful information, especially the RFC. This is exactly what I was looking for. Have a fantastic week! Warm Regards, Raymond Beaudoin On Sun, Sep 24, 2017 at 3:05 PM, Job Snijders wrote: > Dear Raymond, > > On Sun, 24 Sep 2017 at 21:33, Raymond Beaudoin < > raymond.beaudoin at icarustech.com> wrote: > >> How is this monitored and tracked? Are ACLs applied to help enforce this >> (seems to be limited at scale)? Flow export and alarming? Analytics and >> anomalous behavior detection? Common professional courtesy? > > > This RFC https://tools.ietf.org/html/rfc7789 covers the topic of > “unexpected traffic flows” which is essentially the same as having default > being pointed at you without you permission. May be worth reading! > > A most scalable option is to use a flow collection / monitoring program > like pmacct (http://pmacct.net/) to inspect flows and flag the ones that > shouldn’t exist according to your policy. Paolo Lucente has done excellent > work to make this problem space manageable: http://wiki.pmacct.net/ > DetectingRoutingViolations > > Also, if you are at an internet exchange, make sure to enable MAC > accounting (if available) on the IX facing interface, so you can easily > monitor for traffic coming from MAC addresses with which you don’t have a > BGP session. > > Kind regards, > > Job > From nanog at ics-il.net Mon Sep 25 00:50:17 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 24 Sep 2017 19:50:17 -0500 (CDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <1264907839.2452.1506283758921.JavaMail.mhammett@ThunderFuck> Message-ID: <266987641.2535.1506300616024.JavaMail.mhammett@ThunderFuck> Sorry, WISPs in the US48 to go to PR to help rebuild downed WISPs. Yes, they need to be able to get there first. Those already on the island are doing what they can until more supplies arrive. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Sean Donelan" To: nanog at nanog.org Sent: Sunday, September 24, 2017 4:13:33 PM Subject: Re: Hurricane Maria: Summary of communication status - and lack of On Sun, 24 Sep 2017, Mike Hammett wrote: > There are a bunch of WISPs waiting to go rebuild, but waiting for the > clearance to do so. I'm not sure what clearances they are waiting for. If they are already in Puerto Rico, self-sufficient, and respect curfews and other emergency responders, they should be able to start local restoration and recovery activities. Several local ISPs and communication providers have announced open public WiFi hotspots outside their Puerto Rico offices during non-curfew hours. I've also seen reports from individuals volunteering on the Virigin Islands setting up internet access. If they are not already on the island, most Puerto Rican airports and ports are still closed to non-military or relief activities. There is no U.S. mail or freight service. Only one airport was open for limited commercial flights. They will need to bring everything neccessary to support themselves, including food, water, shelter, etc. Managing volunteers who want to help is difficult in all disasters. Unless they have training how to survive and take care of themselves in such a situation, letting in outside well-meaning volunteers sometimes become additional people who need to rescue. WISPs already on Puerto Rico or U.S. Virigin Islands, with resources for recovery and restoration of communications; can contact the FCC Operations Center, (202) 418-1122, FCCOperationCenter at fcc.gov http://transition.fcc.gov/Daily_Releases/Daily_Business/2017/db0920/DA-17-913A1.pdf From josh at imaginenetworksllc.com Mon Sep 25 02:10:59 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sun, 24 Sep 2017 22:10:59 -0400 Subject: Why San Juan National Weather Service RADAR is out of service In-Reply-To: <20170924160303.33A36BA9@m0117458.ppops.net> References: <20170924160303.33A36BA9@m0117458.ppops.net> Message-ID: Not sure why linking is difficult today ;) Here's the post with pictures of the destroyed radome - https://twitter.com/NWSSanJuan/status/912088552145645568 Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sun, Sep 24, 2017 at 7:03 PM, Scott Weeks wrote: > > > --- sean at donelan.com wrote: > From: Sean Donelan > > The National Weather Service office in San Juan Puerto Rico is back on > line. They have posted pictures of the weather radardome, or rather > what's left of the radardome after Hurricane Maria. > > https://twitter.com/NWSSanJuan/status/912082857518092288 > --------------------------------------------------- > > I got a "page does not exist". Go to their main page and it's there. > > https://twitter.com/NWSSanJuan > > scott > > From jordi.palet at consulintel.es Mon Sep 25 09:42:37 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 25 Sep 2017 11:42:37 +0200 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: <19206460-B77B-4E74-BBDD-084D438228C5@consulintel.es> Message-ID: There are several ISPs doing trials (thousands of users). RFC6877 (464XLAT), section 4. Network Architecture, indicates clearly “Wireline Network Architecture can be used in situations where there are clients behind the CLAT, regardless of the type of access service -- for example, fiber to the home (FTTH), Data Over Cable Service Interface Specification (DOCSIS), or WiFi.” Vendors confirmed two weeks ago they have implementations in CEs. RFC7084 was created before all the new transition technologies (including 464XLAT and MAP, for example, or even lw4o6 that has many advantages compared to DS-LITE, being the same but requiring a much simpler CGN), so that’s why I’m working to update it (most probably as an “accompanying document” only for the transition part: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis-transition New versions to be publish this week hopefully … Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Mikael Abrahamsson Organización: People's Front Against WWW Responder a: Fecha: sábado, 23 de septiembre de 2017, 13:22 Para: Fredrik Sallinen CC: Asunto: Re: IPv6 migration steps for mid-scale isp On Sat, 23 Sep 2017, Fredrik Sallinen wrote: > Please correct me If I'm wrong, AFAIK 464XLAT works best with mobile > networks and its not suitable for fixed broadband. right? It's most widely deployed in mobile networks, yes. There is nothing that says it couldn't work anywhere else. However, in fixed networks with PPPoE the most commonly used model is dual stack with RFC7084 style routers. -- Mikael Abrahamsson email: swmike at swm.pp.se ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From aaron1 at gvtc.com Mon Sep 25 11:59:58 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Mon, 25 Sep 2017 06:59:58 -0500 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: <000b01d335f5$cfddb6f0$6f9924d0$@gvtc.com> I don't know about brocade, but here's what I see in Junos and IOS... ....dhcpv6 relay binding seen... {master:0} agould at eng-lab-5048-2> show dhcpv6 relay binding routing-instance three Prefix Session Id Expires State Interface Client DUID 2699:2699:0:7::100/128 199 2591002 BOUND irb.26 LL_TIME0x1-0x1861ed8c-e8:03:9a:eb:0d:21 ....that same binding above is seen as a /128 route of type access-internal... {master:0} agould at eng-lab-5048-2> show route table three.inet6.0 2699:2699:0:7::100/128 three.inet6.0: 16 destinations, 38 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2699:2699:0:7::100/128 *[Access-internal/12] 1w5d 03:19:06 > to fe80::fd61:6bfe:da75:4801 via irb.26 --------------------------------------------------------------------------- ....dhcpv6 relay binding seen... eng-lab-3600-1#sh ipv6 dhcp relay binding vrf three Prefix: 2699:2699:FE00:30::/64 (Vlan26) DUID: 00030001B0B2DCCB1D1E IAID: Unknown lifetime: 2592000 expiration: 06:21:48 CDT Oct 25 2017 ....that same binding above is seen as a /64 route of type static... eng-lab-3600-1#sh ipv6 route vrf three 2699:2699:FE00:30::/64 Routing entry for 2699:2699:FE00:30::/64 Known via "static", distance 1, metric 0 Route count is 1/1, share count 0 Routing paths: FE80::B2B2:DCFF:FECB:1D1E, Vlan26 Last updated 3w4d ago eng-lab-3600-1#sh ipv6 route vrf three static IPv6 Routing Table - three - 18 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2 IA - ISIS interarea, IS - ISIS summary, ND - ND Default, NDp - ND Prefix DCE - Destination, NDr - Redirect, O - OSPF Intra, OI - OSPF Inter OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1 ON2 - OSPF NSSA ext 2 .... S 2699:2699:FE00:30::/64 [1/0] via FE80::B2B2:DCFF:FECB:1D1E, Vlan26 ...and as you can see, I have no static routes configured ... so it's interesting that these routes are seen as static.... eng-lab-3600-1#sh run | in ip route eng-lab-3600-1# -Aaron Gould From craigwashington01 at hotmail.com Mon Sep 25 13:31:07 2017 From: craigwashington01 at hotmail.com (craig washington) Date: Mon, 25 Sep 2017 13:31:07 +0000 Subject: Regex expression Message-ID: Hello all, not sure if this is the right place for this. I am not the best with Regex and was looking for an expression in a Juniper that will match on only so many numbers. Meaning, I am looking at the mpls lsp statistics "show mpls lsp transit statistics" and I only want to see the LSP's that have larger Bytes, for instance I only want to see stuff that has at least 12 digits or longer. Any help would be greatly appreciated, and if this is the wrong thing to ask here, I have no qualms with that either 😊 Thanks again. From job at instituut.net Mon Sep 25 13:33:27 2017 From: job at instituut.net (Job Snijders) Date: Mon, 25 Sep 2017 15:33:27 +0200 Subject: Regex expression In-Reply-To: References: Message-ID: Hi Craig, You are probably best off by reaching out to the Juniper NSP mailing list at https://puck.nether.net/mailman/listinfo/juniper-nsp Kind regards, Job On Mon, Sep 25, 2017 at 3:31 PM, craig washington < craigwashington01 at hotmail.com> wrote: > Hello all, not sure if this is the right place for this. > > I am not the best with Regex and was looking for an expression in a > Juniper that will match on only so many numbers. > > Meaning, I am looking at the mpls lsp statistics "show mpls lsp transit > statistics" and I only want to see the LSP's that have larger Bytes, for > instance I only want to see stuff that has at least 12 digits or longer. > > > > Any help would be greatly appreciated, and if this is the wrong thing to > ask here, I have no qualms with that either 😊 > > > Thanks again. > > From tshaw at oitc.com Mon Sep 25 13:42:38 2017 From: tshaw at oitc.com (TR Shaw) Date: Mon, 25 Sep 2017 09:42:38 -0400 Subject: Regex expression In-Reply-To: References: Message-ID: <5671FD86-A1AA-4469-ACC8-D8C3C2914754@oitc.com> \d{12,} > On Sep 25, 2017, at 9:31 AM, craig washington wrote: > > Hello all, not sure if this is the right place for this. > > I am not the best with Regex and was looking for an expression in a Juniper that will match on only so many numbers. > > Meaning, I am looking at the mpls lsp statistics "show mpls lsp transit statistics" and I only want to see the LSP's that have larger Bytes, for instance I only want to see stuff that has at least 12 digits or longer. > > > > Any help would be greatly appreciated, and if this is the wrong thing to ask here, I have no qualms with that either 😊 > > > Thanks again. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP URL: From mohamed.boucadair at orange.com Mon Sep 25 12:11:34 2017 From: mohamed.boucadair at orange.com (mohamed.boucadair at orange.com) Date: Mon, 25 Sep 2017 12:11:34 +0000 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: Message-ID: <787AE7BB302AE849A7480A190F8B93300A048BE2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Dear Steve, We used to have this in the IETF: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 and https://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00. We abandoned that effort because there wasn't sufficient support for it at that time. Cheers, Med > -----Message d'origine----- > De : NANOG [mailto:nanog-bounces+mohamed.boucadair=orange.com at nanog.org] > De la part de Steve Teusch > Envoyé : vendredi 22 septembre 2017 09:12 > Cc : nanog at nanog.org > Objet : DHCPv6-PD -> Lack of route injection in RFC > > I am running into venders that do not support injection of a delegated > route when operating as a DHCPv6 relay (or server for that matter). > Brocade supports this, but I am not finding this as part of any of the > RFC's. This is to deliver home ISP service, so it is very important or > return packets won't go to the client unless the route is manually added > as a routing protocol is not an option. There should be a MUST activity > for this somewhere. > > Anyone know what gives? From cgrundemann at gmail.com Mon Sep 25 15:24:07 2017 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 25 Sep 2017 11:24:07 -0400 Subject: Open-IX BCOP Committee Call for Volunteers Message-ID: Pardon the interruption. There is a new effort underway to ensure that BCOP has a home in North America and your help is needed. Following the publication of the Open-IX Document Development Policy (OIX DDP) and the formation of the Best Current Operational Practices committee (BCOP) , the Open-IX Board of Directors is now seeking volunteers to take on this valuable work. Open-IX Best Current Operational Practices (BCOP) Committee members are expected to seek out subject matter experts and encourage the documentation of BCOPs from the global network engineering community. This is typically done through activity on mailing lists, conversations at industry events, and leveraging personal relationships. Committee members are further expected to shepherd appropriate documents through the process from Appeal to published BCOP, including updates to existing documents as needed. If you share a passion for sharing knowledge, increasing the resiliency and efficiency of the global internet infrastructure, and have a few hours a month to dedicate to this effort, we encourage you to volunteer! Please send your name, email address, and a brief statement of interest to cgrundemann open-ix.org. While we continuously seek new voices for all committees, this call is expected to close on 31 October, 2017. Please submit before that time to be considered for an immediate opening on the BCOP committee. Thank you, ~Chris From sean at donelan.com Mon Sep 25 15:57:31 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Sep 2017 11:57:31 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: As of this morning, the ILEC Claro is reporting 8 central offices have voice, data and long distance service operating, mostly in metro areas. This does not include outside plant or local loops serving customers. Central offices serving 55 of 78 municipalities have local voice service, no inter-office or long-distance service. Again, not including the local loop to a customer. 27% of cell sites in service, mostly in the north and east parts of the island, operating. I'm not sure if this is 27% of all cell sites on the island, or 27% of cell sites only in the north and east. Other providers say they are working to restore service, but are not releasing specific data about their network status (AT&T, Open Mobile, Sprint, T-Mobile). Cable provider, LibertyPR, hasn't said anything to local reporters that I could find in any of the PR newspaper websites; and appears to be completely out of service. There are several competitive providers and small providers I don't have information about in PR. I just don't know the market. If anyone has status about any small providers operating, let me know their status. From jfmezei_nanog at vaxination.ca Mon Sep 25 23:55:41 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 25 Sep 2017 19:55:41 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <1264907839.2452.1506283758921.JavaMail.mhammett@ThunderFuck> Message-ID: <4100e623-97d0-01ae-94a5-249afe254e9c@vaxination.ca> On 2017-09-24 17:13, Sean Donelan wrote: > I'm not sure what clearances they are waiting for. If they are already in > Puerto Rico, self-sufficient, and respect curfews and other emergency > responders, they should be able to start local restoration and recovery > activities. Priority is to restore communications to emergency responders, restore power to hospitals and other critical infrastructure). So workers that clear roads, remove dangling electrical wires would prioritize fixing of that critical infrastructure. That road you need cleared to get to your fixed wireless antenna will wait. Similarly, I get the impression that all cargo capacity into the island is still controlled to prioritize essentials. So those spare circuit board you need to fix a router have to wait. Also, with residences overwhelmingly without power, fixing the "normal" ISP business won't do much when nobody can use it. It is best to focus on wi-fi in central locations such as shelters, and cellular for first responders and others. There are good reasons local governments work out disaster plans because they need to identify in advance what gets priority after a disaster. From nanog at ics-il.net Tue Sep 26 00:10:41 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 25 Sep 2017 19:10:41 -0500 (CDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <4100e623-97d0-01ae-94a5-249afe254e9c@vaxination.ca> References: <1264907839.2452.1506283758921.JavaMail.mhammett@ThunderFuck> <4100e623-97d0-01ae-94a5-249afe254e9c@vaxination.ca> Message-ID: <2009595291.4436.1506384639744.JavaMail.mhammett@ThunderFuck> You're assuming the WISP isn't providing infrastructure to critical facilities. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jean-Francois Mezei" To: nanog at nanog.org Sent: Monday, September 25, 2017 6:55:41 PM Subject: Re: Hurricane Maria: Summary of communication status - and lack of On 2017-09-24 17:13, Sean Donelan wrote: > I'm not sure what clearances they are waiting for. If they are already in > Puerto Rico, self-sufficient, and respect curfews and other emergency > responders, they should be able to start local restoration and recovery > activities. Priority is to restore communications to emergency responders, restore power to hospitals and other critical infrastructure). So workers that clear roads, remove dangling electrical wires would prioritize fixing of that critical infrastructure. That road you need cleared to get to your fixed wireless antenna will wait. Similarly, I get the impression that all cargo capacity into the island is still controlled to prioritize essentials. So those spare circuit board you need to fix a router have to wait. Also, with residences overwhelmingly without power, fixing the "normal" ISP business won't do much when nobody can use it. It is best to focus on wi-fi in central locations such as shelters, and cellular for first responders and others. There are good reasons local governments work out disaster plans because they need to identify in advance what gets priority after a disaster. From sean at donelan.com Tue Sep 26 04:52:29 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 26 Sep 2017 00:52:29 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: It looks like someone kicked the cellular carriers public relations people into gear. Today, instead of the normal "we care" messages; they released statements providing more concrete details about their restoration activity in PR and USVI. Overall, 91.2% cell sites out of service in Puerto Rico. 34 of 78 counties have 100% cell sites out of service. This will continue to change up and down, as sites are restored and circuits are damaged by cleanup activity. There are over 2,671 cell sites on Puerto Rico and 106 cell sites in U.S. Virgin Islands. As carriers bring in tens of generators and repair equipment at a time, gives you some idea how long restoration will take. In alphabetical order... ATT: "We continue to send aircraft with essential supplies and network resources as we help the people of Puerto Rico. These flights include portable temporary cell sites, high capacity generators to provide temporary power, and other larger network equipment on cargo planes and barges to help restore services on the island. We planning to set up a number of portable cell sites in the San Juan area as soon as possible. So far, we’ve sent multiple flights carrying the following supplies: More than 30 generators 5,000+ gallons of water We are also focused on network restoration in the U.S. Virgin Islands are bringing additional resources there." Claro (google translate from Spanish): They reported that in the metropolitan area specifically, Claro's signal was already reaching 31 percent of customers in San Juan, 22 percent in Guaynabo and 18 percent in Carolina and Bayamón. At the island level, the Claro signal is up in 14 municipalities today, covering an average of 20 percent of the clients in Aguada, Manatí, Mayaguez, San Germán, Cabo Rojo, Trujillo Alto, Dorado, Camuy, Quebradillas, Humacao, Juncos , Caguas, Aguadilla and Toa Baja. That number will increase in the coming days. Sprint: "A vessel has already arrived in Puerto Rico with the generators and parts required to begin the work. In turn, a body of over 40 Sprint engineers and technicians in the United States were sent to the Island to join the local technical staff, coordinate the delivery of the equipment received and continue work to speed up the communication. A second shipment will arrive on the island this Wednesday, September 27 with additional spare parts and materials." T-Mobile: "The damage to the infrastructure is unprecedented, but equally it is the support we are receiving from T-Mobile US. Between Saturday and Sunday, six MD11 cargo planes and one AM124 (second largest cargo plane in the world) arrived with 80 generators, 16 trucks, equipment to build 100 communication facilities. More cargo planes will arrive today with more equipment and personnel." T-Mobile also mentions while T-Mobile's field engineering crew was at the Luis Muñoz Marín Airport, they were drafted to help install a generator for the FAA Control Tower. That's one way to help get your supplies on the island. If you have information about other telecommunication providers in Puerto Rico or U.S. Virgin Islands, let me know. Due to damage to the FAA communications and guidance systems, only a dozen or so commercial flights can land during daylight hours each day. Airlines report over 20,000 people on standby lists, and nearly 1,000 people waiting at the airport for any flight. The Port of San Juan is open, daylight hours only, and receiving freight barges. While there is a plenty of fuel, food and supplies at the port; getting truck drivers to the port and damage/blocked roads is slowing distribution of supplies to the rest of the island. U.S. Mail and other express delivery companies still do not have service in Puerto Rico. Limited U.S. Mail hand-out service is available at a few post offices in U.S. Virgin Islands. From web at typo.org Tue Sep 26 05:10:00 2017 From: web at typo.org (Wayne Bouchard) Date: Mon, 25 Sep 2017 22:10:00 -0700 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <20170926051000.GA77544@spider.typo.org> On Tue, Sep 26, 2017 at 12:52:29AM -0400, Sean Donelan wrote: > T-Mobile also mentions while T-Mobile's field engineering crew was at the > Luis Mu??oz Mar??n Airport, they were drafted to help install a generator > for the FAA Control Tower. That's one way to help get your supplies on the > island. You know, that's a really good point. In such situations, the sooner you can get the basic infrastructure operational again and transportation, electrical systems, and fuel distribution (generators have to run on something...) in particular, the faster everything can start coming back together. First and foremost, this means making the place habitable again so you actually have customers to serve. So any time spent doing something like what is related above is extremely worth while and can only serve to facilitate future work for everyone on the island. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From randy at psg.com Tue Sep 26 07:26:39 2017 From: randy at psg.com (Randy Bush) Date: Tue, 26 Sep 2017 16:26:39 +0900 Subject: looking for cyclades acs terminal server fu Message-ID: have cyclades acs48. trying to use as craft port server. it does everything except connect to the serial device(s). if you have clue and a bit of patience, please contact me out of band. thanks. randy From swmike at swm.pp.se Tue Sep 26 08:03:31 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 26 Sep 2017 10:03:31 +0200 (CEST) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: On Tue, 26 Sep 2017, Sean Donelan wrote: > It looks like someone kicked the cellular carriers public relations > people into gear. Today, instead of the normal "we care" messages; they > released statements providing more concrete details about their > restoration activity in PR and USVI. What is the US government role in all of this? It sounds like a few https://en.wikipedia.org/wiki/Lockheed_C-5_Galaxy could be of use here to airlift in lots of gear. -- Mikael Abrahamsson email: swmike at swm.pp.se From chaim.rieger at gmail.com Tue Sep 26 08:07:41 2017 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Tue, 26 Sep 2017 01:07:41 -0700 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: I doubt the runway is stable enough to hold the weight of a loaded c5. On Sep 26, 2017 01:05, "Mikael Abrahamsson" wrote: > On Tue, 26 Sep 2017, Sean Donelan wrote: > > It looks like someone kicked the cellular carriers public relations people >> into gear. Today, instead of the normal "we care" messages; they released >> statements providing more concrete details about their restoration activity >> in PR and USVI. >> > > What is the US government role in all of this? It sounds like a few > https://en.wikipedia.org/wiki/Lockheed_C-5_Galaxy could be of use here to > airlift in lots of gear. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From marcel.duregards at yahoo.fr Tue Sep 26 09:29:21 2017 From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr) Date: Tue, 26 Sep 2017 11:29:21 +0200 Subject: CPE that support 1G with BGP multihomed Message-ID: <59CA1DF1.9030405@yahoo.fr> Dear Nanoger, Anyone have an advice on CPE which can support the following features, please: 1) 1 Gigabits/s ipv4 or ipv6 forwarding IMIX or Internet traffic, full duplex (not sure if cisco or miercom are conducting bidirectionals traffic flows at the same time). 2) with ACLs and with uRPF with prefix filtering with bgp ext-communities (rfc 8092 would be a ++, but not mandatory) 3) with BGP full route, 1 eBGP session + 1 iBGP (--> multihomed, single attached solution, so there is 2 CPE connected to 2 bgp transit)) 4) vrf light and SNMP + telnet/ssh with ACLs Currently on Cisco side, we see the following candidates: - ASR 1001-x - ASR 1002 - ISR 4431, 4451 - ISR G2 2921 + 2951 + 3925(E) (EoL soon, so we are currently in the process of evaluating other solution). But we would like also to include other manufacturer : juniper, mikrotik , etc.... Thank for your help, - Marcel From javier at advancedmachines.us Tue Sep 26 10:37:58 2017 From: javier at advancedmachines.us (Javier J) Date: Tue, 26 Sep 2017 06:37:58 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: Keep on posting this great info Sean. It is being passed along. Just wanted you to be aware. On Tue, Sep 26, 2017 at 12:52 AM, Sean Donelan wrote: > It looks like someone kicked the cellular carriers public relations people > into gear. Today, instead of the normal "we care" messages; they released > statements providing more concrete details about their restoration activity > in PR and USVI. > > Overall, 91.2% cell sites out of service in Puerto Rico. 34 of 78 counties > have 100% cell sites out of service. This will continue to change up and > down, as sites are restored and circuits are damaged by cleanup activity. > > There are over 2,671 cell sites on Puerto Rico and 106 cell sites in U.S. > Virgin Islands. As carriers bring in tens of generators and repair > equipment at a time, gives you some idea how long restoration will take. > > > In alphabetical order... > > ATT: > "We continue to send aircraft with essential supplies and network > resources as we help the people of Puerto Rico. These flights include > portable temporary cell sites, high capacity generators to provide > temporary power, and other larger network equipment on cargo planes and > barges to help restore services on the island. We planning to set up a > number of portable cell sites in the San Juan area as soon as possible. > > So far, we’ve sent multiple flights carrying the following supplies: > More than 30 generators > 5,000+ gallons of water > We are also focused on network restoration in the U.S. Virgin Islands are > bringing additional resources there." > > > Claro (google translate from Spanish): > They reported that in the metropolitan area specifically, Claro's signal > was already reaching 31 percent of customers in San Juan, 22 percent in > Guaynabo and 18 percent in Carolina and Bayamón. > > At the island level, the Claro signal is up in 14 municipalities today, > covering an average of 20 percent of the clients in Aguada, Manatí, > Mayaguez, San Germán, Cabo Rojo, Trujillo Alto, Dorado, Camuy, > Quebradillas, Humacao, Juncos , Caguas, Aguadilla and Toa Baja. > > That number will increase in the coming days. > > > Sprint: > "A vessel has already arrived in Puerto Rico with the generators and parts > required to begin the work. In turn, a body of over 40 Sprint engineers and > technicians in the United States were sent to the Island to join the local > technical staff, coordinate the delivery of the equipment received and > continue work to speed up the communication. > A second shipment will arrive on the island this Wednesday, September 27 > with additional spare parts and materials." > > > T-Mobile: > "The damage to the infrastructure is unprecedented, but equally it is the > support we are receiving from T-Mobile US. Between Saturday and Sunday, six > MD11 cargo planes and one AM124 (second largest cargo plane in the world) > arrived with 80 generators, 16 trucks, equipment to build 100 communication > facilities. More cargo planes will arrive today with more equipment and > personnel." > > T-Mobile also mentions while T-Mobile's field engineering crew was at the > Luis Muñoz Marín Airport, they were drafted to help install a generator for > the FAA Control Tower. That's one way to help get your supplies on the > island. > > > If you have information about other telecommunication providers in Puerto > Rico or U.S. Virgin Islands, let me know. > > > > Due to damage to the FAA communications and guidance systems, only a dozen > or so commercial flights can land during daylight hours each day. Airlines > report over 20,000 people on standby lists, and nearly 1,000 people waiting > at the airport for any flight. > > The Port of San Juan is open, daylight hours only, and receiving freight > barges. While there is a plenty of fuel, food and supplies at the port; > getting truck drivers to the port and damage/blocked roads is slowing > distribution of supplies to the rest of the island. U.S. Mail and other > express delivery companies still do not have service in Puerto Rico. > Limited U.S. Mail hand-out service is available at a few post offices in > U.S. Virgin Islands. > From blake at ispn.net Tue Sep 26 13:34:00 2017 From: blake at ispn.net (Blake Hudson) Date: Tue, 26 Sep 2017 08:34:00 -0500 Subject: CPE that support 1G with BGP multihomed In-Reply-To: <59CA1DF1.9030405@yahoo.fr> References: <59CA1DF1.9030405@yahoo.fr> Message-ID: <9bad19e5-2513-d388-477f-3f954c09fb64@ispn.net> marcel.duregards--- via NANOG wrote on 9/26/2017 4:29 AM: > Currently on Cisco side, we see the following candidates: > > - ASR 1001-x > - ASR 1002 > - ISR 4431, 4451 > - ISR G2 2921 + 2951 + 3925(E) (EoL soon, so we are currently in the > process of evaluating other solution). > Keep in mind the ASR1002 is also EoL, and only the configuration with upgraded RAM and ESP10 would meet your stated need for a full BGP table (the ESP2.5/5 does not have enough FIB memory to store the full routing table). The 1001-X offers the pay as you go model, so you may want to check with Cisco regarding FIB availability at different license price points. I believe the ASR9001 would also meet your needs; I don't have experience with the other options. From ahad at swiftelnetworks.com Tue Sep 26 14:00:13 2017 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Wed, 27 Sep 2017 00:00:13 +1000 Subject: CPE that support 1G with BGP multihomed In-Reply-To: <59CA1DF1.9030405@yahoo.fr> References: <59CA1DF1.9030405@yahoo.fr> Message-ID: Hi Marcel, I've personnel tested similar requirements on the followings; ASR1001 - 8G RAM ASR1001-X ASR1002 8G RAM with two eBGP sessions / full routes via two upstreams and mutiple iBGP sessions to the core. The ASR1K is a safe bet. The ISR G2 2921 or 2951 suffers under load if you have PBR or NAT/PAT rules. Hope this info helps with your research and router selections. Cheers, Ahad On Tue, Sep 26, 2017 at 7:29 PM, marcel.duregards--- via NANOG < nanog at nanog.org> wrote: > Dear Nanoger, > > Anyone have an advice on CPE which can support the following features, > please: > > 1) > 1 Gigabits/s ipv4 or ipv6 forwarding IMIX or Internet traffic, full > duplex (not sure if cisco or miercom are conducting bidirectionals > traffic flows at the same time). > > 2) > with ACLs and with uRPF > with prefix filtering > with bgp ext-communities (rfc 8092 would be a ++, but not mandatory) > > 3) > with BGP full route, 1 eBGP session + 1 iBGP (--> multihomed, single > attached solution, so there is 2 CPE connected to 2 bgp transit)) > > 4) > vrf light and > SNMP + telnet/ssh with ACLs > > > Currently on Cisco side, we see the following candidates: > > - ASR 1001-x > - ASR 1002 > - ISR 4431, 4451 > - ISR G2 2921 + 2951 + 3925(E) (EoL soon, so we are currently in the > process of evaluating other solution). > > > But we would like also to include other manufacturer : juniper, mikrotik > , etc.... > > > Thank for your help, > > - > Marcel > > > > > > > > From mis at seiden.com Tue Sep 26 19:35:03 2017 From: mis at seiden.com (mark seiden) Date: Tue, 26 Sep 2017 12:35:03 -0700 Subject: Nanog attendees are invited to Friday Lunch at the Internet Archive (in,San Francisco) and a tour... Message-ID: <601fd3b5-60ca-a11d-b1e2-e397a677b0bb@seiden.com> You've probably used the Wayback Machine, but have you ever wondered how it works? We think of Nanog folks as part of our natural community. So Nanog attendees who will be in the Bay Area before or after the upcoming San Jose Nanog meeting are particularly welcome to be our guests at community lunch at the Internet Archive (300 Funston at Clement,  San Francisco) on either Friday Sept 29, or Friday Oct 6.  Lunch, buffet style, starts promptly at noon, and prepare to say what you're up to, because we go around the room making brief self-introductions.  Afterwards, you can tour the Archive -- see what we do and possibly get involved in helping out with some ambitious plans. To come on Sept 29, RSVP by tomorrow (Sept 27) with a count (so we have enough food) to jcg at archive.org or to come on Oct 6, RSVP by Wednesday (Oct 4) with a count to jonah at archive.org   (who will also be at the conference). (There is often street parking for at least 2 hours.  Public transportation involves the 38L bus -- we're at the other end of town from Bart/Caltrain, very close to the Presidio and the Golden Gate Bridge.) If you are local to the Bay Area or hanging around after Nanog, you may want to attend our upcoming Annual Celebration on the evening of Oct 11: https://blog.archive.org/2017/08/30/the-internet-archives-annual-bash-come-celebrate-with-us/ More information about the Internet Archive at https://archive.org From lee at asgard.org Tue Sep 26 20:50:52 2017 From: lee at asgard.org (Lee Howard) Date: Tue, 26 Sep 2017 16:50:52 -0400 Subject: IPv6 migration steps for mid-scale isp In-Reply-To: References: <19206460-B77B-4E74-BBDD-084D438228C5@consulintel.es> Message-ID: On 9/23/17, 7:14 AM, "NANOG on behalf of Fredrik Sallinen" wrote: >Please correct me If I'm wrong, AFAIK 464XLAT works best with mobile >networks and its not suitable for fixed broadband. right? Should work fine in landline networks, but (as Jordi says) it’s hard to find support in retail CPE your customers are likely to own. Same is true for MAP-T and MAP-E. If anyone knows of retail CPE supporting any of those, or if you’re a gateway vendor selling those, let me know, I’m interested. Lee > >On Mon, Sep 18, 2017 at 10:28 PM, JORDI PALET MARTINEZ > wrote: >> Fully agree, 464XLAT is the way to go. >> >> We have tested this in many IPv6-only access deployments, non-cellular >>networks (cellular is well tested by T-Mobile and others, that have got >>it in production for years). >> >> We always have the issue of the CPEs support, but this is the same >>problem if you want to go to lw4o6, MAP, etc. In general, newer >>transition mechanisms, aren’t well supported. >> >> So, you either use OpenWRT if you can re-flash the CPEs, or you push >>your vendors to make sure they provide a firmware upgrade. >> >> This is the reason I started to work on an update of the RFC7084 >>(https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ and >>https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis-transition >>/) and see also the related discussion in v6ops. >> >> Also, I run a panel with CPE vendors in the last week APNIC meeting, >>and the interesting thing is that they confirmed there is no any >>technical issue to support those (hardware is ok), and they have already >>developed it, just waiting for customers to ask for it. >> >> >>https://conference.apnic.net/44/program/schedule/#/day/6/bof-discussion-w >>ith-ipv6-ce-vendors >> >> I will compile a report out of this panel ASAP. >> >> So please, keep pushing your vendors for it! >> >> Regards, >> Jordi >> >> >> -----Mensaje original----- >> De: NANOG en nombre de Brock Tice >> >> Responder a: >> Fecha: viernes, 15 de septiembre de 2017, 17:14 >> Para: Fredrik Sallinen >> CC: >> Asunto: Re: IPv6 migration steps for mid-scale isp >> >> We are small but we are just about out of IPv4 and aren't going to >>get >> or buy any more. We have been testing for a while. >> >> > Shall I go for IPv6-only deployment or dual stack? >> >> You should plan for adding customers eventually that are IPv6-only, >> unless you have all the v4 you will ever need, and you will need to >> reserve IPv4 address blocks for translation. >> >> > How to identify address CPE and legacy application issues? >> >> Legacy application issues can be solved (for the most part) with >> 464XLAT, which also solves IP-literal-in-HTML problems. You need >>PLAT at >> the core and CLAT at the client. Unfortunately so far the only good >>way >> we've found to do CLAT is OpenWRT on the CPE or router. We are >>getting >> ready to bundle Linksys routers flashed with OpenWRT. >> >> For PLAT at the core we are running jool. It's actually quite >>simple to >> set up and we are currently using OSPF to do anycast, but we will >> probably be migrating to a single set of HA servers in the core. The >> good news is that even if it goes down, Netflix and Facebook will >>still >> work as they are fully functional on v6. >> >> We have tested this in my home and at my office with IPv6-only >> VLANs/wireless SSIDs, mostly without a hitch. >> >> If you run this setup without the CLAT on the client side you get >>NAT64 >> so it still will work for most things. >> >> I would be very, very happy if larger ISPs would put pressure on >>router >> manufacturers to support CLAT, we have no clout. I would also love >>to >> hear if any of this is stupid or if there's a better way. >> >> --Brock >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >>confidential. The information is intended to be for the exclusive use of >>the individual(s) named above and further non-explicilty authorized >>disclosure, copying, distribution or use of the contents of this >>information, even if partially, including attached files, is strictly >>prohibited and will be considered a criminal offense. If you are not the >>intended recipient be aware that any disclosure, copying, distribution >>or use of the contents of this information, even if partially, including >>attached files, is strictly prohibited, will be considered a criminal >>offense, so you must reply to the original sender to inform about this >>communication and delete it. >> >> >> > From lee at asgard.org Tue Sep 26 21:02:51 2017 From: lee at asgard.org (Lee Howard) Date: Tue, 26 Sep 2017 17:02:51 -0400 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: <253258.1506145885@turing-police.cc.vt.edu> References: <20170922224733.0669887B0F1E@rock.dv.isc.org> <253258.1506145885@turing-police.cc.vt.edu> Message-ID: On 9/23/17, 1:51 AM, "nanog-bounces at nanog.org on behalf of valdis.kletnieks at vt.edu" wrote: >On Sat, 23 Sep 2017 08:47:32 +1000, Mark Andrews said: >> You know CPE devices are routers. They can tell you what routes >> DHCP has given them. That annoucement could be cryptographically >> authenticated. > >This is, of course, a lot easier if the CPE already has onboard the needed >software to do that, or you have the ability to push it out. Right. How many residential market gateways support any routing protocol at all? How many support RIPv2? How many support RIPng. Being routers does not mean they support any dynamic routing protocol. If I were an ISP, I would be very skeptical of the return on adding routing support to every gateway I supported, plus an RPKI. > >Is anybody from Comcast or other eyeball network willing to say (even >roughly) >what percent of CPE is gear they supply, versus gear that people get at >Best >Buy or Walmart and just plug in, versus (if they can identify it) gear >that's >been reflashed by clued customers? It varies 0-100% based on network, year, and the mood of whoever makes the decision about how to handle CPE. Some ISPs provide a gateway to all of their customers, and some of those customers then put them into bridged mode. (I think Vz FiOS, for instance, always comes with a gateway). Some provide a gateway for free, which may be worth much more or less than you paid for it, depending on the philosophy of the ISP. Some assume you want a gateway and charge you several dollars a month for it. Lee From rod.beck at unitedcablecompany.com Tue Sep 26 21:41:08 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 26 Sep 2017 21:41:08 +0000 Subject: Major European Continental Long Haul Conduit Message-ID: I would to tap the collective wisdom of NANOG. What are the major conduit systems in Europe? I know when MFN Europe went bankrupt, everybody jumped in and bought their fiber. So I list GTT/Hibernia, EUNetworks, Zayo, and who else rids this conduit system. And who rides the Level3 conduit and what the other key systems. And yes, I am thinking of the terrestrial routes connecting the European racetrack: Amsterdam, Frankfurt, Paris, and Milan. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From ikiris at gmail.com Tue Sep 26 22:05:28 2017 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 26 Sep 2017 15:05:28 -0700 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: <20170922224733.0669887B0F1E@rock.dv.isc.org> <253258.1506145885@turing-police.cc.vt.edu> Message-ID: Isn't this the topic area that the home networking working group was supposed to resolve? On Tue, Sep 26, 2017 at 2:02 PM, Lee Howard wrote: > > > On 9/23/17, 1:51 AM, "nanog-bounces at nanog.org on behalf of > valdis.kletnieks at vt.edu" valdis.kletnieks at vt.edu> wrote: > >>On Sat, 23 Sep 2017 08:47:32 +1000, Mark Andrews said: >>> You know CPE devices are routers. They can tell you what routes >>> DHCP has given them. That annoucement could be cryptographically >>> authenticated. >> >>This is, of course, a lot easier if the CPE already has onboard the needed >>software to do that, or you have the ability to push it out. > > Right. How many residential market gateways support any routing protocol > at all? How many support RIPv2? How many support RIPng. Being routers does > not mean they support any dynamic routing protocol. If I were an ISP, I > would be very skeptical of the return on adding routing support to every > gateway I supported, plus an RPKI. > >> >>Is anybody from Comcast or other eyeball network willing to say (even >>roughly) >>what percent of CPE is gear they supply, versus gear that people get at >>Best >>Buy or Walmart and just plug in, versus (if they can identify it) gear >>that's >>been reflashed by clued customers? > > It varies 0-100% based on network, year, and the mood of whoever makes the > decision about how to handle CPE. Some ISPs provide a gateway to all of > their customers, and some of those customers then put them into bridged > mode. (I think Vz FiOS, for instance, always comes with a gateway). Some > provide a gateway for free, which may be worth much more or less than you > paid for it, depending on the philosophy of the ISP. Some assume you want > a gateway and charge you several dollars a month for it. > > Lee > > From chris.brown at acsalaska.net Tue Sep 26 22:15:47 2017 From: chris.brown at acsalaska.net (Christopher E. Brown) Date: Tue, 26 Sep 2017 14:15:47 -0800 Subject: Anyone else having issues with AS209 in the Northwest? Message-ID: We have no direct peerings with 209, but a large percentage of traffic flowing through 4 different peers and into 209 in the Seattle area has serious issues. -- ------------------------------------------------------------------------ Christopher E. Brown desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ------------------------------------------------------------------------ From sean at donelan.com Wed Sep 27 04:12:45 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 27 Sep 2017 00:12:45 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: Things are better and worse in Puerto Rico and other Caribbean islands. Help is needed, but anyone wanting to help in the field, be certain you understand what you would be doing, and whether you are actually helping or hindering on the ground efforts. >From Washington Post: [U.S. FEMA Director] Long also warned people not involved with the relief effort to stay away. “If you’re going to Puerto Rico right now, it should be for only a life-sustaining, life-support mission,” he said. “Because everybody that’s trying to get in that’s not supporting that is getting in the way.” According to reports, the major (but not named) telecommunication companies met today with the Puerto Rico Telecommunications Regulatory Bureau about coordinating restoration efforts. Several companies have agreed to joint repairts. Instead of each company sending multiple crews to the shared cell sites, they will agree to divide the work among all the companies. This will distribute more repair crews from all participating companies to more cell sites from different companies around the island. Claro, the ILEC, is the only company that has publically confirmed the joint repair agreement. AT&T, T-Mobile and Sprint also have repair crews on the island, but I haven't been able to confirm which companies have signed the joint repair agreement. Claro also said they've re-connected 55% of its Central Offices, including voice, data and long distance. Once again, I'm guessing this is inter-office trunks, and not local subscriber loops. The FCC reports 2,429 of 2,671 cell sites (90.9%) are out of service in Puerto Rico. And 65 out of 106 cell sites (61.3%) are out of service in the U.S. Virgin Islands. Broadcast Radio and Television 14 AM stations on the air on Puerto Rico 8 FM stations on the air on Puerto Rico 2 TV stations on the air on Puerto Rico Special notice: On Wednesday, September 27, 2017 at 2:20pm Easter Time, FEMA will be conducting a scheduled national test of the Emergency Alert System. This national test was scheduled in July, 2017. The test will take about a minute, and sound like a typical monthly EAS test "This is a national test of the Emergency Alert System. This is only a test." Most people probably won't pay attention to the national EAS test on Wednesday. But there are always few news stories about some people being alarmed by the national test. If there is an *new* emergency or severe weather at the time, the national test will be rescheduled for October 4, 2017. Although the disasters in Puerto Rico and U.S. Virgin Islands are continuing, the national test will be a very brief interruption on radio and TV on the islands. The telecommunications damage in PR and USVI will be a good test how well the EAS works during extreme telecommunications damage. From EPers at ansencorp.com Wed Sep 27 14:21:00 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Wed, 27 Sep 2017 14:21:00 +0000 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: > The telecommunications damage in PR and USVI will be a good test how well the EAS works during extreme telecommunications damage. From my brief time as a radio station tech, all you need for EAS to function properly is power to the receiver/decoder and for the station's transmitter to be alive From keiths at neilltech.com Wed Sep 27 15:20:05 2017 From: keiths at neilltech.com (Keith Stokes) Date: Wed, 27 Sep 2017 15:20:05 +0000 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <6953B67B-9FD1-4F58-A4F9-2352E2A5D091@neilltech.com> And your upstream(s) to work. And their upstream(s) to work. etc. If 90% of the stations in the EAS web are down you may end up with nothing working. On Sep 27, 2017, at 9:21 AM, Edwin Pers > wrote: The telecommunications damage in PR and USVI will be a good test how well the EAS works during extreme telecommunications damage. >From my brief time as a radio station tech, all you need for EAS to function properly is power to the receiver/decoder and for the station's transmitter to be alive --- Keith Stokes From swmike at swm.pp.se Wed Sep 27 15:28:48 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 27 Sep 2017 17:28:48 +0200 (CEST) Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: <20170922224733.0669887B0F1E@rock.dv.isc.org> <253258.1506145885@turing-police.cc.vt.edu> Message-ID: On Tue, 26 Sep 2017, Blake Dunlap wrote: > Isn't this the topic area that the home networking working group was > supposed to resolve? HOMENET was never looking into running a routing protocol between the ISP and the HGW. It was all about running a routing protocol WITHIN the home, not between the home and the ISP. All the work I saw took for granted there was for instance a DHCPv6-PD lease handed to the home gateway router. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Wed Sep 27 15:36:58 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 27 Sep 2017 17:36:58 +0200 (CEST) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: On Wed, 27 Sep 2017, Sean Donelan wrote: > Things are better and worse in Puerto Rico and other Caribbean islands. > Help is needed, but anyone wanting to help in the field, be certain you > understand what you would be doing, and whether you are actually helping > or hindering on the ground efforts. https://www.vox.com/science-and-health/2017/9/26/16365994/hurricane-maria-2017-puerto-rico-san-juan-humanitarian-disaster-electricty-fuel-flights-facts This seems to indicate that it will be 4-6 months until things get back to normal, if there indeed is a huge effort to do so. "But as first responders on the ground in Puerto Rico told Fernández Campbell, this isn’t enough. Trump should also ask Congress to pass a relief package for Puerto Rico to give FEMA and the island more money to rebuild. He could deploy more military resources to help with search and rescue operations." I hope this happens. -- Mikael Abrahamsson email: swmike at swm.pp.se From valdis.kletnieks at vt.edu Wed Sep 27 15:45:04 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 27 Sep 2017 11:45:04 -0400 Subject: DHCPv6-PD -> Lack of route injection in RFC In-Reply-To: References: <20170922224733.0669887B0F1E@rock.dv.isc.org> <253258.1506145885@turing-police.cc.vt.edu> Message-ID: <8607.1506527104@turing-police.cc.vt.edu> On Tue, 26 Sep 2017 17:02:51 -0400, Lee Howard said: > Right. How many residential market gateways support any routing protocol > at all? Depends on how flabby a definition you use. Does "ask for a default route" count? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From sean at donelan.com Wed Sep 27 16:03:55 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 27 Sep 2017 12:03:55 -0400 (EDT) Subject: Information about the national test of the Emergency Alert System Message-ID: > And your upstream(s) to work. And their upstream(s) to work. etc. If 90% > of the stations in the EAS web are down you may end up with nothing > working. 6% of TV stations are operating in Puerto Rico 15% of radio stations are operating in Puerto Rico Nationally, there are about 28,000 cable systems, radio and television stations. This test will not use the FEMA primary entry point system, so its only a partial test of the national EAS. Today's national test of the Emergency Alert System will be the same as the 2016 national test. It is a partial test of the EAS, using the FEMA IPAWS system over the internet (i.e. Akamai and Cloudfront are used as CDNs) to the distribute the emergency test message. Cable, radio and TV stations need a working Internet connection as well as radio receivers and transmitters for IPAWS and EAS. Although the national test was scheduled back in July, its still a good test opportunity to see how the internet and EAS works in Puerto Rico and the U.S. VI with so much damage to the infrastructure. The one minute national test should not intefere with disaster recovery efforts in PR or USVI. For more information: https://www.fema.gov/news-release/2017/09/19/mandatory-nationwide-test-emergency-alert-system-be-conducted-september-27 https://www.fcc.gov/document/nationwide-emergency-alert-system-test-planned-september-27 From code at joelwhitehouse.com Wed Sep 27 05:00:56 2017 From: code at joelwhitehouse.com (Joel Whitehouse) Date: Wed, 27 Sep 2017 00:00:56 -0500 Subject: Google DNS64 misconfigured? Message-ID: I had an ipv6-only lab environment cease being able to browse much of the internet on Monday. Tracked the issue down to google's public DNS64 service; the following queries should return DNS64 responses from the 64:9bff::/96 prefix, however, I'm getting 0 DNS64 answers from dig on both their servers for the last 60 hours: dig @2001:4860:4860::64 ipv4only.arpa AAAA dig @2001:4860:4860::6464 ipv4only.arpa AAAA DNS works fine, just not DNS64. A forum topic [0] suggests this behavior might be intermittent but no official response from google there. Is google's public DNS64 down for anyone else? [0] https://groups.google.com/d/topic/public-dns-discuss/dD_lSPfqXHA/discussion -- Joel Whitehouse From brock at bmwl.co Wed Sep 27 20:41:34 2017 From: brock at bmwl.co (Brock Tice) Date: Wed, 27 Sep 2017 14:41:34 -0600 Subject: Google DNS64 misconfigured? In-Reply-To: References: Message-ID: <113a99c9-b50b-b799-9f09-8827a7fa3d6f@bmwl.co> On 09/26/2017 11:00 PM, Joel Whitehouse wrote: > A forum topic [0] suggests this behavior might be intermittent but no > official response from google there. I have seen intermittent issues with IPv6 queries to google's nameservers as well. Some sites simply would not load, which is what caused me to notice it. --Brock From sean at donelan.com Wed Sep 27 21:44:30 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 27 Sep 2017 17:44:30 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: After a week without power, all the stationary batteries throughout the telecommunications network are likely completely drained. This makes restoration even more difficult, like a dead car battery needing a jump start. I am focusing on U.S. territories, but there is also disaster response from Hurricanes Irma and Maria on Antigua and Barbuda, Cuba, Dominica, Montserrat, Saint Martin, and St. Kitts and Nevis. Fatalities, including deaths attributed to post-hurricane recovery: Hurricane Iram: 72 - Florida; 40 - Caribbean Hurricane Maria: 16 - Puerto Rico; 2 - U.S. Virigin Islands; 15 - Dominica, 3 - Haiti; 2 - Guadeloupe Department of Defense: Supporting FEMA, the Department of Defense has deployed USNORTHCOM Brigadier General Rich Kim to Puerto Rico to manage the Title 10 (military) response efforts in Puerto Rico and U.S. Virgin Islands. USSOUTHCOM continues to support relief activities elsewhere in the Caribbean. Airports and sea ports: Puerto Rico: 3 sea ports open; 5 sea ports open with restrictions, daylight hours only. 9 airports are open. Only San Juan Airport open to commercial air traffic, approximately 15-20 commercial flights. All other flights reserved for priority military and relief activities. U.S Virgin Islands: 4 sea ports open with restrictions, daylight hours only. U.S. VI airports closed except military and relief flights. Electricity: Puerto Rico: 1.57 million customers out of service. An estimate of 4% has been restored. Restoring power to airports, hospitals, sea ports and water treatment plants are still critical priorities. 80% of transmission lines damaged, power generation plants appear intact. U.S. Virgin Islands: 55,000 customers out of service, most of the islands. St. Thomas has five feeders partially energised. St. Croix has three feeders partially energized. Restoring power to airports, hospitals, sea ports and water treatment plants are still critical priorities. Telecommunications: Pictures posted on twitter of joint restoration meeting between telecommunications providers, FEMA and Puerto Rico Telecommunications Regulatory Board. From the logos & colors on shirts: Claro, T-Mobile, Sprint, and many other company logos I couldn't make out (estimate 20 people in the room). Reports of generators and fuel stolen from cell sites and remote telecommunications locations. This is not unusual during disasters. The Puerto Rico Telecommunications Industry Alliance, which appears to be a lobbying group of communication companies in Puerto Rico, has sent a letter about the need for FEMA to coordinate logistics and prioritize access to fuel and security. PRTIA (or APT in Spanish) has existed for a few years, but I can't judge if its letter represents telecommunication companies in Puerto Rico. Puerto Rico: 2,432 of 2,671 cell sites (91%) out of service. No update/change to cable and wireline systems, about 55% of central offices with voice, data and long-distance. The rest with only local voice, no inter-office connections. No clear description about status of local loops or subscribers with service. Pictures of Liberty Cable PR repair crews posted on twitter. I still haven't found a public statement about LibertyPR's status. Approximately 450-500 out of 1200 Internet networks and 35-38 out of 48 ASNs are present in the global Internet routing table, with occasional up/down changes due to restoration activity. U.S. Virigin Islands: 70 of 106 cell sites (66%) out of service. No update/change to cable and wireline systems. U.S. Virgin Islands Internet routes have nearly returned to normal, with occasional up/down blips due to restoration activity. I'm not ignoring the status competitive and smaller USVI and PR communication providers, its just difficult to find official statements from them. If you have status about them, let me know. From jfmezei_nanog at vaxination.ca Wed Sep 27 22:25:00 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 27 Sep 2017 18:25:00 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <6931a7fc-d427-cdbd-61e4-aaaa71880db1@vaxination.ca> On 2017-09-27 17:44, Sean Donelan wrote: > After a week without power, all the stationary batteries throughout the > telecommunications network are likely completely drained. from the point of view of cell sites, wouldn't battery autonomy be measured in hours rather than days? I could see some site having autonomy in days due to permanent generator, and when fuel runs out so does the cell site. > I'm not ignoring the status competitive and smaller USVI and PR > communication providers, its just difficult to find official statements > from them. If you have status about them, let me know. One aspect often forgotten is that people have homes (or what is left of them) families and the need to find food/water which can involve standing in line for hours in a day and they may not be able to show up for work. larger companies can usually find enough employees not so hindered, but smaller outfits may not be able to remain functional due to not enough staff able to work. Smaller outfits may not have the ability to get petrol for their trucks to go out oand fix things. (whereas the big guys have the credentials to get petrol form authorities/army. From sean at donelan.com Wed Sep 27 22:59:40 2017 From: sean at donelan.com (Sean Donelan) Date: Wed, 27 Sep 2017 18:59:40 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <6931a7fc-d427-cdbd-61e4-aaaa71880db1@vaxination.ca> References: <6931a7fc-d427-cdbd-61e4-aaaa71880db1@vaxination.ca> Message-ID: On Wed, 27 Sep 2017, Jean-Francois Mezei wrote: >> After a week without power, all the stationary batteries throughout the >> telecommunications network are likely completely drained. > > from the point of view of cell sites, wouldn't battery autonomy be > measured in hours rather than days? I could see some site having > autonomy in days due to permanent generator, and when fuel runs out so > does the cell site. Yes, long-term power is generators. But there is always a catch. What happens during disaster recovery is the batteries are damaged by being drained repeatedly, dirty power from generators, and enviromental conditions. After too many deep-discharge cycles during the disaster, the batteries won't hold a charge any more. The battery failure rate, requiring replacement, goes through the roof after about a week in a disaster. Even those 10-year telco batteries don't last 10-years during disaster conditions. Since a lot of telecommunications gear actually runs off -48 volt battery string, and the generators recharge the batteries; when the batteries completely fail even with a generator, no more telecom. You have to replace the battery string or run the telecom gear on raw generator power (which then damages the telecom gear even more). Sometimes even the battery starter on the generator fail to start after too many refueling stops. Most backup generators are only rated for "stand-by" service, not continuous operation for weeks. Generators need more maintenance, and fail more often. Disaster logistics is a string of dominos. If they start being knocked over, it just gets worse. Stuff that works great during normal conditions doesn't anymore. Simple fixes are all complicated now. From jra at baylink.com Wed Sep 27 23:47:40 2017 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 27 Sep 2017 23:47:40 +0000 (UTC) Subject: New TRANSLANT cable - US/VA to ES Message-ID: <977476011.18083.1506556060566.JavaMail.zimbra@baylink.com> Microsoft, Facebook, Telxius. 160TB, presumably each way, but no technical detail in this piece: https://interestingengineering.com/microsoft-and-facebook-just-laid-a-6600-km-cable-across-the-atlantic-ocean Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From javier at advancedmachines.us Thu Sep 28 01:40:16 2017 From: javier at advancedmachines.us (Javier J) Date: Wed, 27 Sep 2017 21:40:16 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: > Telecommunications: Pictures posted on twitter of joint restoration meeting between.......... What twitter feed was this? I didn't catch it. On Wed, Sep 27, 2017 at 5:44 PM, Sean Donelan wrote: > > After a week without power, all the stationary batteries throughout the > telecommunications network are likely completely drained. This makes > restoration even more difficult, like a dead car battery needing a jump > start. > > I am focusing on U.S. territories, but there is also disaster response > from Hurricanes Irma and Maria on Antigua and Barbuda, Cuba, Dominica, > Montserrat, Saint Martin, and St. Kitts and Nevis. > > Fatalities, including deaths attributed to post-hurricane recovery: > Hurricane Iram: 72 - Florida; 40 > - > Caribbean > Hurricane Maria: 16 - Puerto Rico; 2 > - > U.S. Virigin Islands; 15 - Dominica, 3 - Haiti; 2 - Guadeloupe > > Department of Defense: > Supporting FEMA, the Department of Defense has deployed USNORTHCOM > Brigadier General Rich Kim to Puerto Rico to manage the Title 10 (military) > response efforts in Puerto Rico and U.S. Virgin Islands. USSOUTHCOM > continues to support relief activities elsewhere in the Caribbean. > > > Airports and sea ports: > Puerto Rico: 3 sea ports open; 5 sea ports open with restrictions, > daylight hours only. 9 airports are open. Only San Juan Airport open to > commercial air traffic, approximately 15-20 commercial flights. All other > flights reserved for priority military and relief activities. > > U.S Virgin Islands: 4 sea ports open with restrictions, daylight hours > only. U.S. VI airports closed except military and relief flights. > > > Electricity: > Puerto Rico: 1.57 million customers out of service. An estimate of 4% > has been restored. Restoring power to airports, hospitals, sea ports and > water treatment plants are still critical priorities. 80% of transmission > lines damaged, power generation plants appear intact. > > U.S. Virgin Islands: 55,000 customers out of service, most of the > islands. St. Thomas has five feeders partially energised. St. Croix has > three feeders partially energized. Restoring power to airports, hospitals, > sea ports and water treatment plants are still critical priorities. > > > Telecommunications: > > Pictures posted on twitter of joint restoration meeting between > telecommunications providers, FEMA and Puerto Rico Telecommunications > Regulatory Board. From the logos & colors on shirts: Claro, T-Mobile, > Sprint, and many other company logos I couldn't make out (estimate 20 > people in the room). > > Reports of generators and fuel stolen from cell sites and remote > telecommunications locations. This is not unusual during disasters. The > Puerto Rico Telecommunications Industry Alliance, which appears to be a > lobbying group of communication companies in Puerto Rico, has sent a letter > about the need for FEMA to coordinate logistics and prioritize access to > fuel and security. PRTIA (or APT in Spanish) has existed for a few years, > but I can't judge if its letter represents telecommunication companies in > Puerto Rico. > > Puerto Rico: > 2,432 of 2,671 cell sites (91%) out of service. > No update/change to cable and wireline systems, about 55% of central > offices with voice, data and long-distance. The rest with only local > voice, no inter-office connections. No clear description about status of > local loops or subscribers with service. > > Pictures of Liberty Cable PR repair crews posted on twitter. I still > haven't found a public statement about LibertyPR's status. > > Approximately 450-500 out of 1200 Internet networks and 35-38 out of > 48 ASNs are present in the global Internet routing table, with occasional > up/down changes due to restoration activity. > > U.S. Virigin Islands: > 70 of 106 cell sites (66%) out of service. > No update/change to cable and wireline systems. > > U.S. Virgin Islands Internet routes have nearly returned to normal, > with occasional up/down blips due to restoration activity. > > > I'm not ignoring the status competitive and smaller USVI and PR > communication providers, its just difficult to find official statements > from them. If you have status about them, let me know. > From hugo at slabnet.com Thu Sep 28 03:18:37 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 27 Sep 2017 20:18:37 -0700 Subject: Google DNS64 misconfigured? In-Reply-To: References: Message-ID: <20170928031837.GA2845@bamboo.slabnet.com> On Wed 2017-Sep-27 00:00:56 -0500, Joel Whitehouse wrote: >I had an ipv6-only lab environment cease being able to browse much of >the internet on Monday. Tracked the issue down to google's public >DNS64 service; the following queries should return DNS64 responses >from the 64:9bff::/96 prefix, however, I'm getting 0 DNS64 answers >from dig on both their servers for the last 60 hours: > >dig @2001:4860:4860::64 ipv4only.arpa AAAA >dig @2001:4860:4860::6464 ipv4only.arpa AAAA > >DNS works fine, just not DNS64. A forum topic [0] suggests this >behavior might be intermittent but no official response from google >there. Is google's public DNS64 down for anyone else? I do not regularly use their public DNS64, but those queries also return no ANSWER for me from a couple of test points when I just checked now. One is on Teksavvy (AS20375) crossing through Peer1 (AS13768), the other crosses directly through peering with Google at the SIX. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From aaron at heyaaron.com Thu Sep 28 04:01:29 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 27 Sep 2017 21:01:29 -0700 Subject: Information about the national test of the Emergency Alert System In-Reply-To: References: Message-ID: I didn't see a blip on my TV, or hear anything on the local radio stations. I didn't even get an alert on my cell phone. Did I miss it, or did it get cancelled? -A On Wed, Sep 27, 2017 at 9:03 AM, Sean Donelan wrote: >> And your upstream(s) to work. And their upstream(s) to work. etc. If 90% >> of the stations in the EAS web are down you may end up with nothing working. > > > 6% of TV stations are operating in Puerto Rico > 15% of radio stations are operating in Puerto Rico > > Nationally, there are about 28,000 cable systems, radio and television > stations. > > This test will not use the FEMA primary entry point system, so its only a > partial test of the national EAS. > > Today's national test of the Emergency Alert System will be the same as the > 2016 national test. It is a partial test of the EAS, using the FEMA IPAWS > system over the internet (i.e. Akamai and Cloudfront are used as CDNs) to > the distribute the emergency test message. Cable, radio and TV stations need > a working Internet connection as well as radio receivers and transmitters > for IPAWS and EAS. > > Although the national test was scheduled back in July, its still a good test > opportunity to see how the internet and EAS works in Puerto Rico and the > U.S. VI with so much damage to the infrastructure. The one minute national > test should not intefere with disaster recovery efforts in PR or USVI. > > For more information: > > https://www.fema.gov/news-release/2017/09/19/mandatory-nationwide-test-emergency-alert-system-be-conducted-september-27 > > https://www.fcc.gov/document/nationwide-emergency-alert-system-test-planned-september-27 > From mike.lyon at gmail.com Thu Sep 28 04:08:42 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Wed, 27 Sep 2017 21:08:42 -0700 Subject: Information about the national test of the Emergency Alert System In-Reply-To: References: Message-ID: Went through this AM. Here in the SF BA, alerts went out on the airwaves around 11:20am today. -Mike > On Sep 27, 2017, at 21:01, Aaron C. de Bruyn via NANOG wrote: > > I didn't see a blip on my TV, or hear anything on the local radio > stations. I didn't even get an alert on my cell phone. Did I miss > it, or did it get cancelled? > > -A > > > > On Wed, Sep 27, 2017 at 9:03 AM, Sean Donelan wrote: >>> And your upstream(s) to work. And their upstream(s) to work. etc. If 90% >>> of the stations in the EAS web are down you may end up with nothing working. >> >> >> 6% of TV stations are operating in Puerto Rico >> 15% of radio stations are operating in Puerto Rico >> >> Nationally, there are about 28,000 cable systems, radio and television >> stations. >> >> This test will not use the FEMA primary entry point system, so its only a >> partial test of the national EAS. >> >> Today's national test of the Emergency Alert System will be the same as the >> 2016 national test. It is a partial test of the EAS, using the FEMA IPAWS >> system over the internet (i.e. Akamai and Cloudfront are used as CDNs) to >> the distribute the emergency test message. Cable, radio and TV stations need >> a working Internet connection as well as radio receivers and transmitters >> for IPAWS and EAS. >> >> Although the national test was scheduled back in July, its still a good test >> opportunity to see how the internet and EAS works in Puerto Rico and the >> U.S. VI with so much damage to the infrastructure. The one minute national >> test should not intefere with disaster recovery efforts in PR or USVI. >> >> For more information: >> >> https://www.fema.gov/news-release/2017/09/19/mandatory-nationwide-test-emergency-alert-system-be-conducted-september-27 >> >> https://www.fcc.gov/document/nationwide-emergency-alert-system-test-planned-september-27 >> From bicknell at ufp.org Thu Sep 28 11:04:49 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Sep 2017 04:04:49 -0700 Subject: New TRANSLANT cable - US/VA to ES In-Reply-To: <977476011.18083.1506556060566.JavaMail.zimbra@baylink.com> References: <977476011.18083.1506556060566.JavaMail.zimbra@baylink.com> Message-ID: <20170928110449.GA40774@ussenterprise.ufp.org> In a message written on Wed, Sep 27, 2017 at 11:47:40PM +0000, Jay R. Ashworth wrote: > Microsoft, Facebook, Telxius. > > 160TB, presumably each way, but no technical detail in this piece: TB or Tbps? Either way, they are old hat. Can we get that expressed in Likes/second, or perhaps Windows Updates/second? -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From Mark_Feldman at comcast.com Thu Sep 28 11:17:01 2017 From: Mark_Feldman at comcast.com (Feldman, Mark) Date: Thu, 28 Sep 2017 11:17:01 +0000 Subject: 1and1 DNS contact Message-ID: If there's anyone from 1and1 (specifically, someone involved with apps-1and1.com), please contact me off list. We're running across a DNS resolution issue from some places on our network and would like to discuss. Thanks. Mark Comcast T&P Core Network Services From nanog at ics-il.net Thu Sep 28 12:05:12 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 28 Sep 2017 07:05:12 -0500 (CDT) Subject: New TRANSLANT cable - US/VA to ES In-Reply-To: <977476011.18083.1506556060566.JavaMail.zimbra@baylink.com> References: <977476011.18083.1506556060566.JavaMail.zimbra@baylink.com> Message-ID: <1769168253.3619.1506600311779.JavaMail.mhammett@ThunderFuck> https://youtu.be/YQ8J7U2bO3Q https://www.nanog.org/sites/default/files/2_Gaudette_Open_Undersea_Cable_Systems.pdf ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jay R. Ashworth" To: "North American Network Operators' Group" Sent: Wednesday, September 27, 2017 6:47:40 PM Subject: New TRANSLANT cable - US/VA to ES Microsoft, Facebook, Telxius. 160TB, presumably each way, but no technical detail in this piece: https://interestingengineering.com/microsoft-and-facebook-just-laid-a-6600-km-cable-across-the-atlantic-ocean Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From aaron1 at gvtc.com Thu Sep 28 15:25:16 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 28 Sep 2017 10:25:16 -0500 Subject: isp/cdn caching Message-ID: <001a01d3386d$fcd710a0$f68531e0$@gvtc.com> Hi, I've been aware of a few caching providers for a few years now, but I'm learning of others as time goes on. which makes me curious if there are more springing up and gaining popularity. I'm speaking of ISP-type caching whereas the cache provider sends hardware servers and perhaps a switch to the local ISP to install locally in their network. Can someone please send a simple list of what they know is the current players in this ISP Caching space? I'll list the ones I know about and you please let me know of others. This seems to be an evolving/growing thing and I'm curious of where we are today for significant providers and possibly up-and-coming ones that I should know about. (amazon prime has my wondering also.) Google (GGC) Netflix (OCA) Akamai (AANP) Facebook (FNA) Apple (I heard this isn't isp-located like the others, but unsure) ? others ? ? others ? ? others ? -Aaron Gould From morrowc.lists at gmail.com Thu Sep 28 15:39:21 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 Sep 2017 11:39:21 -0400 Subject: New TRANSLANT cable - US/VA to ES In-Reply-To: <1769168253.3619.1506600311779.JavaMail.mhammett@ThunderFuck> References: <977476011.18083.1506556060566.JavaMail.zimbra@baylink.com> <1769168253.3619.1506600311779.JavaMail.mhammett@ThunderFuck> Message-ID: ha! isn't the last picture (the 'thankyou' slide) in that pack using a picture from: http://networkstatic.net/google-data-center-pictures-year-in-review/ specifically: http://networkstatic.net/wp-content/uploads/2012/12/google-datacenter2.jpg it's a cool presentation though :) On Thu, Sep 28, 2017 at 8:05 AM, Mike Hammett wrote: > https://youtu.be/YQ8J7U2bO3Q > > https://www.nanog.org/sites/default/files/2_Gaudette_Open_ > Undersea_Cable_Systems.pdf > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Jay R. Ashworth" > To: "North American Network Operators' Group" > Sent: Wednesday, September 27, 2017 6:47:40 PM > Subject: New TRANSLANT cable - US/VA to ES > > Microsoft, Facebook, Telxius. > > 160TB, presumably each way, but no technical detail in this piece: > > https://interestingengineering.com/microsoft-and-facebook-just- > laid-a-6600-km-cable-across-the-atlantic-ocean > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > > From matt.larson at icann.org Thu Sep 28 18:12:47 2017 From: matt.larson at icann.org (Matt Larson) Date: Thu, 28 Sep 2017 18:12:47 +0000 Subject: Root KSK roll delayed Message-ID: (Please pardon the repetition if you've seen this message on another list) ICANN has decided to postpone the root KSK roll previously scheduled for 11 October 2017 for at least one quarter. This message gives some background and explanation for that decision. Historically there has been no way to determine which trust anchors DNSSEC validators have configured, making it difficult to assess the potential impact of the root KSK rollover. "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)" (defined in RFC 8145) is a recent protocol extension that allows a validator to report which trust anchors it has configured for a zone to that zone's name servers. The protocol was only finalized in April, 2017, and only the most recent versions of BIND (9.10.5b1 and 9.11.0b3 and later) and Unbound (1.6.4 and later) support it. This protocol was not expected to have sufficient deployment to provide useful information for the first root KSK rollover. However, initial research by Verisign and then by ICANN has found a growing number of validators reporting trust anchor configuration to the root servers. Based on data from six root server addresses, approximately 12,000 unique source IP addresses have sent trust anchor configuration reports so far in September 2017. The number reporting is growing and now approaches 1400 unique addresses per day. Significantly, approximately 5% of the total validators and about 6%-8% on any given day report only KSK-2010, the root zone KSK currently signing the root's DNSKEY RRset. These validators would not resolve correctly after the planned root KSK roll. There are various reasons a validator might report only KSK-2010. One reason is an old configuration with a statically configured trust anchor (e.g., BIND's "trusted-key" statement). ICANN has always known that a small percentage of validators would not be ready for the rollover because they had manually configured their trust anchor, and that operators of those validators would need to take action when the root KSK rollover happened. Another reason is a failure to automatically update the trust anchor using the RFC 5011 automated update protocol because of a software defect, operator error or other reason. Based on our research and preliminary investigation, we also believe it is possible that some operators believe that they are ready for the rollover because they configured their validator to use RFC 5011 automated updates, but will not trust KSK-2017 when the rollover happens due to configuration issues or software defects. Given the relatively high percentage of validators with just KSK-2010, ICANN believes it is important to better understand the reasons before proceeding with the root KSK roll. We will soon be publishing the list of resolvers reporting only KSK-2010 and will ask for the operational community's help in identifying, diagnosing and correcting these systems. Throughout the project we have emphasized that the root KSK is being rolled under normal operational conditions and have proceeded cautiously and without haste. The decision to postpone was taken in that spirit of caution because there is no operational pressure to proceed given our continued confidence in the security of KSK-2010. We appreciate the community's understanding and we look forward to your assistance in gathering the information necessary to move forward with the root KSK roll. Matt -- Matt Larson, VP of Research ICANN Office of the CTO -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From mfidelman at meetinghouse.net Thu Sep 28 19:02:13 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 28 Sep 2017 12:02:13 -0700 Subject: anybody here from earthlink operations? Message-ID: If there's someone here from earthlink operations, can you contact me privately.  Thanks! Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jfmezei_nanog at vaxination.ca Thu Sep 28 19:22:13 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 28 Sep 2017 15:22:13 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6931a7fc-d427-cdbd-61e4-aaaa71880db1@vaxination.ca> Message-ID: FYI: White House announces that the US Army Corp of Engineers is in charge of power in Puerto Rico, and were given priorities to hospitals and other emergency services. No mention of telecom being part of those priorities. Initial push is installing temporary power generation. They are not yet working on fixing the electrical grid. (44 of 69 hospitals now have power). (Note: FEMA has decided to stick to road deliveries, not air drops for supplies). From sf at lists.esoteric.ca Thu Sep 28 20:33:05 2017 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Thu, 28 Sep 2017 16:33:05 -0400 Subject: Best way to San Jose Fairmont from SFO? Message-ID: Hi all, I'm flying in for the conference, landing in San Francisco. What's the best way to get from SFO to the conference hotel? Thanks, -- Stephen From bob at FiberInternetCenter.com Thu Sep 28 20:47:55 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 28 Sep 2017 13:47:55 -0700 Subject: Best way to San Jose Fairmont from SFO? In-Reply-To: References: Message-ID: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> Depending on commute times with traffic - you will most likely travel 101 south. Uber works well from SFO. You catch an Uber ride on the arrival level. Rental car....Google Maps knows several pathways. But it will most likely take you via 101. This hotel is popular in downtown San Jose - not hard to find. Train and Bus travel is not worth considering. However, there are airport shuttle van services like supershuttle 4-5 passengers being dropped off on your way south. Thank You Bob Evans CTO > Hi all, > > I'm flying in for the conference, landing in San Francisco. What's the > best way to get from SFO to the conference hotel? > > Thanks, > > -- Stephen > From sf at lists.esoteric.ca Thu Sep 28 20:49:24 2017 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Thu, 28 Sep 2017 16:49:24 -0400 Subject: Best way to San Jose Fairmont from SFO? In-Reply-To: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> References: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> Message-ID: <59561c86-d642-f45d-f40a-5535b915b5a7@lists.esoteric.ca> Thanks Bob! -- Stephen On 2017-09-28 4:47 PM, Bob Evans wrote: > Depending on commute times with traffic - you will most likely travel 101 > south. > Uber works well from SFO. You catch an Uber ride on the arrival level. > > Rental car....Google Maps knows several pathways. But it will most likely > take you via 101. > This hotel is popular in downtown San Jose - not hard to find. > > Train and Bus travel is not worth considering. However, there are airport > shuttle van services like supershuttle 4-5 passengers being dropped off on > your way south. > > Thank You > Bob Evans > CTO > > > > >> Hi all, >> >> I'm flying in for the conference, landing in San Francisco. What's the >> best way to get from SFO to the conference hotel? >> >> Thanks, >> >> -- Stephen >> > > From khomyakov.andrey at gmail.com Fri Sep 29 01:16:37 2017 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Thu, 28 Sep 2017 18:16:37 -0700 Subject: Best way to San Jose Fairmont from SFO? In-Reply-To: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> References: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> Message-ID: I've taken Uber to and from SFO multiple times (I live in Sunnyvale). Take Uber (or Lyft as sometimes that is cheaper than Uber) pool and you'll be paying around $30-40 one way, which is not too bad for 1hr long ride... --Andrey On Thu, Sep 28, 2017 at 1:47 PM, Bob Evans wrote: > Depending on commute times with traffic - you will most likely travel 101 > south. > Uber works well from SFO. You catch an Uber ride on the arrival level. > > Rental car....Google Maps knows several pathways. But it will most likely > take you via 101. > This hotel is popular in downtown San Jose - not hard to find. > > Train and Bus travel is not worth considering. However, there are airport > shuttle van services like supershuttle 4-5 passengers being dropped off on > your way south. > > Thank You > Bob Evans > CTO > > > > > > Hi all, > > > > I'm flying in for the conference, landing in San Francisco. What's the > > best way to get from SFO to the conference hotel? > > > > Thanks, > > > > -- Stephen > > > > > From nanog at ics-il.net Fri Sep 29 02:56:36 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 28 Sep 2017 21:56:36 -0500 (CDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <1563155637.5113.1506653792999.JavaMail.mhammett@ThunderFuck> The WISP I'm getting updates from is having thefts as well. Still having logistics issues. The leading idea at the moment is tower-mounted solar panels and batteries. Nothing is foolproof without armed guards, but it's better than nothing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Sean Donelan" To: nanog at nanog.org Sent: Wednesday, September 27, 2017 4:44:30 PM Subject: Re: Hurricane Maria: Summary of communication status - and lack of After a week without power, all the stationary batteries throughout the telecommunications network are likely completely drained. This makes restoration even more difficult, like a dead car battery needing a jump start. I am focusing on U.S. territories, but there is also disaster response from Hurricanes Irma and Maria on Antigua and Barbuda, Cuba, Dominica, Montserrat, Saint Martin, and St. Kitts and Nevis. Fatalities, including deaths attributed to post-hurricane recovery: Hurricane Iram: 72 - Florida; 40 - Caribbean Hurricane Maria: 16 - Puerto Rico; 2 - U.S. Virigin Islands; 15 - Dominica, 3 - Haiti; 2 - Guadeloupe Department of Defense: Supporting FEMA, the Department of Defense has deployed USNORTHCOM Brigadier General Rich Kim to Puerto Rico to manage the Title 10 (military) response efforts in Puerto Rico and U.S. Virgin Islands. USSOUTHCOM continues to support relief activities elsewhere in the Caribbean. Airports and sea ports: Puerto Rico: 3 sea ports open; 5 sea ports open with restrictions, daylight hours only. 9 airports are open. Only San Juan Airport open to commercial air traffic, approximately 15-20 commercial flights. All other flights reserved for priority military and relief activities. U.S Virgin Islands: 4 sea ports open with restrictions, daylight hours only. U.S. VI airports closed except military and relief flights. Electricity: Puerto Rico: 1.57 million customers out of service. An estimate of 4% has been restored. Restoring power to airports, hospitals, sea ports and water treatment plants are still critical priorities. 80% of transmission lines damaged, power generation plants appear intact. U.S. Virgin Islands: 55,000 customers out of service, most of the islands. St. Thomas has five feeders partially energised. St. Croix has three feeders partially energized. Restoring power to airports, hospitals, sea ports and water treatment plants are still critical priorities. Telecommunications: Pictures posted on twitter of joint restoration meeting between telecommunications providers, FEMA and Puerto Rico Telecommunications Regulatory Board. From the logos & colors on shirts: Claro, T-Mobile, Sprint, and many other company logos I couldn't make out (estimate 20 people in the room). Reports of generators and fuel stolen from cell sites and remote telecommunications locations. This is not unusual during disasters. The Puerto Rico Telecommunications Industry Alliance, which appears to be a lobbying group of communication companies in Puerto Rico, has sent a letter about the need for FEMA to coordinate logistics and prioritize access to fuel and security. PRTIA (or APT in Spanish) has existed for a few years, but I can't judge if its letter represents telecommunication companies in Puerto Rico. Puerto Rico: 2,432 of 2,671 cell sites (91%) out of service. No update/change to cable and wireline systems, about 55% of central offices with voice, data and long-distance. The rest with only local voice, no inter-office connections. No clear description about status of local loops or subscribers with service. Pictures of Liberty Cable PR repair crews posted on twitter. I still haven't found a public statement about LibertyPR's status. Approximately 450-500 out of 1200 Internet networks and 35-38 out of 48 ASNs are present in the global Internet routing table, with occasional up/down changes due to restoration activity. U.S. Virigin Islands: 70 of 106 cell sites (66%) out of service. No update/change to cable and wireline systems. U.S. Virgin Islands Internet routes have nearly returned to normal, with occasional up/down blips due to restoration activity. I'm not ignoring the status competitive and smaller USVI and PR communication providers, its just difficult to find official statements from them. If you have status about them, let me know. From nanog at studio442.com.au Fri Sep 29 06:07:36 2017 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 29 Sep 2017 16:07:36 +1000 Subject: Best way to San Jose Fairmont from SFO? In-Reply-To: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> References: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> Message-ID: <213bd208-10f5-259d-068a-044193149c28@studio442.com.au> On 29/09/17 06:47, Bob Evans wrote: > Train and Bus travel is not worth considering. However, there are airport > shuttle van services like supershuttle 4-5 passengers being dropped off on > your way south. I'm arriving on Sunday morning, so have plenty of time, and will take Caltrain down (BART to Millbrae, then Caltrain), sure it'll take 2h, but any van service wouldn't be much faster. During the week, or out of daylight hours it's a much less sensible idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 232 bytes Desc: OpenPGP digital signature URL: From imawsog at yahoo.com Fri Sep 29 06:18:20 2017 From: imawsog at yahoo.com (i mawsog) Date: Fri, 29 Sep 2017 06:18:20 +0000 (UTC) Subject: Best way to San Jose Fairmont from SFO? In-Reply-To: <213bd208-10f5-259d-068a-044193149c28@studio442.com.au> References: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> <213bd208-10f5-259d-068a-044193149c28@studio442.com.au> Message-ID: <702296859.319099.1506665900735@mail.yahoo.com> Google SFO SJC  From: Julien Goodwin To: nanog at nanog.org Sent: Thursday, September 28, 2017 11:09 PM Subject: Re: Best way to San Jose Fairmont from SFO? On 29/09/17 06:47, Bob Evans wrote: > Train and Bus travel is not worth considering. However, there are airport > shuttle van services like supershuttle 4-5 passengers being dropped off on > your way south. I'm arriving on Sunday morning, so have plenty of time, and will take Caltrain down (BART to Millbrae, then Caltrain), sure it'll take 2h, but any van service wouldn't be much faster. During the week, or out of daylight hours it's a much less sensible idea. From michalis.bersimis at hq.cyta.gr Fri Sep 29 13:38:50 2017 From: michalis.bersimis at hq.cyta.gr (michalis.bersimis at hq.cyta.gr) Date: Fri, 29 Sep 2017 13:38:50 +0000 Subject: isp/cdn caching In-Reply-To: <001a01d3386d$fcd710a0$f68531e0$@gvtc.com> References: <001a01d3386d$fcd710a0$f68531e0$@gvtc.com> Message-ID: <4f33d5950a5d4c27ada387560e115c44@DASMAIL01.corp.cyta> I think that Cloudflare has a caching solution, but I think they have strict requirements towards the isp in order to install them on their premises. Best Regards, Michalis Bersimis -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Thursday, September 28, 2017 6:25 PM To: Nanog at nanog.org Subject: isp/cdn caching Hi, I've been aware of a few caching providers for a few years now, but I'm learning of others as time goes on. which makes me curious if there are more springing up and gaining popularity. I'm speaking of ISP-type caching whereas the cache provider sends hardware servers and perhaps a switch to the local ISP to install locally in their network. Can someone please send a simple list of what they know is the current players in this ISP Caching space? I'll list the ones I know about and you please let me know of others. This seems to be an evolving/growing thing and I'm curious of where we are today for significant providers and possibly up-and-coming ones that I should know about. (amazon prime has my wondering also.) Google (GGC) Netflix (OCA) Akamai (AANP) Facebook (FNA) Apple (I heard this isn't isp-located like the others, but unsure) ? others ? ? others ? ? others ? -Aaron Gould From owen at delong.com Fri Sep 29 13:56:43 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Sep 2017 08:56:43 -0500 Subject: Best way to San Jose Fairmont from SFO? In-Reply-To: <213bd208-10f5-259d-068a-044193149c28@studio442.com.au> References: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> <213bd208-10f5-259d-068a-044193149c28@studio442.com.au> Message-ID: > On Sep 29, 2017, at 1:07 AM, Julien Goodwin wrote: > > On 29/09/17 06:47, Bob Evans wrote: >> Train and Bus travel is not worth considering. However, there are airport >> shuttle van services like supershuttle 4-5 passengers being dropped off on >> your way south. > > I'm arriving on Sunday morning, so have plenty of time, and will take > Caltrain down (BART to Millbrae, then Caltrain), sure it'll take 2h, but > any van service wouldn't be much faster. > > During the week, or out of daylight hours it's a much less sensible idea. > I disagree… I’ve done it during the week and it’s not that bad. I find Lyft to be the most desirable option (About $65), with Uber as a second choice. Third choice would be BaRT/CalTrain (to Diridon) followed by either a very short Lyft ride or VTA bus or light rail. Another option (if you get on the right CalTrain) is Tamien station and connection to light rail there. Light rail gets you _VERY_ close to the Fairmont. The Fairmont has entrances on Market St. (Front Door direct to Lobby) and First St. (Back door, hallway to lobby). The VTA light rail northbound is on First St. I’m not 100% sure of the light rail routing from the Diridon station to downtown as it’s tied to the Almaden line and I’m usually dealing with the Santa Teresa line. I, myself intend to bicycle to the meeting as my home is only about 7 miles away. Owen From aj at sneep.net Fri Sep 29 14:20:05 2017 From: aj at sneep.net (Alastair Johnson) Date: Fri, 29 Sep 2017 10:20:05 -0400 Subject: Best way to San Jose Fairmont from SFO? In-Reply-To: References: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> <213bd208-10f5-259d-068a-044193149c28@studio442.com.au> Message-ID: <7D040297-EB57-49D8-8FF7-18E0DC748CEB@sneep.net> I live in the next block along from the Fairmont. For people who want to use CalTrain then there is the Downtown Area Shuttle (DASH) that runs from Diridon around the downtown area and will pass by the Fairmont on San Fernando St. The shuttle is timed to connect with CalTrain in both directions and is free, so it's probably the most convenient. That said... I would just take Lyft/Uber. SFO to downtown SJC via public transport is annoying. I try to fly in/out of SJC as much as possible. AJ > On Sep 29, 2017, at 9:56 AM, Owen DeLong wrote: > > >> On Sep 29, 2017, at 1:07 AM, Julien Goodwin wrote: >> >> On 29/09/17 06:47, Bob Evans wrote: >>> Train and Bus travel is not worth considering. However, there are airport >>> shuttle van services like supershuttle 4-5 passengers being dropped off on >>> your way south. >> >> I'm arriving on Sunday morning, so have plenty of time, and will take >> Caltrain down (BART to Millbrae, then Caltrain), sure it'll take 2h, but >> any van service wouldn't be much faster. >> >> During the week, or out of daylight hours it's a much less sensible idea. >> > > I disagree… I’ve done it during the week and it’s not that bad. > > I find Lyft to be the most desirable option (About $65), with Uber as > a second choice. > > Third choice would be BaRT/CalTrain (to Diridon) followed by either a very > short Lyft ride or VTA bus or light rail. > > Another option (if you get on the right CalTrain) is Tamien station and > connection to light rail there. > > Light rail gets you _VERY_ close to the Fairmont. The Fairmont has entrances > on Market St. (Front Door direct to Lobby) and First St. (Back door, hallway > to lobby). The VTA light rail northbound is on First St. > > I’m not 100% sure of the light rail routing from the Diridon station to downtown > as it’s tied to the Almaden line and I’m usually dealing with the Santa Teresa > line. > > I, myself intend to bicycle to the meeting as my home is only about 7 miles away. > > Owen > From marco at marcoslater.com Fri Sep 29 14:22:06 2017 From: marco at marcoslater.com (Marco Slater) Date: Fri, 29 Sep 2017 15:22:06 +0100 Subject: isp/cdn caching In-Reply-To: <4f33d5950a5d4c27ada387560e115c44@DASMAIL01.corp.cyta> References: <001a01d3386d$fcd710a0$f68531e0$@gvtc.com> <4f33d5950a5d4c27ada387560e115c44@DASMAIL01.corp.cyta> Message-ID: <1376887C-D0FC-403D-819C-BBA1D155B0E7@marcoslater.com> Do they publicly have any more info on this? I thought CloudFlare didn’t consider doing that because of their vast coverage and peering arrangements provided by their PoPs. Regards, Marco Slater > On 29 Sep 2017, at 14:38, wrote: > > I think that Cloudflare has a caching solution, but I think they have strict requirements towards the isp in order to install them on their premises. > > Best Regards, > > Michalis Bersimis > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould > Sent: Thursday, September 28, 2017 6:25 PM > To: Nanog at nanog.org > Subject: isp/cdn caching > > Hi, I've been aware of a few caching providers for a few years now, but I'm learning of others as time goes on. which makes me curious if there are more springing up and gaining popularity. I'm speaking of ISP-type caching whereas the cache provider sends hardware servers and perhaps a switch to the local ISP to install locally in their network. Can someone please send a simple list of what they know is the current players in this ISP Caching space? I'll list the ones I know about and you please let me know of others. This seems to be an evolving/growing thing and I'm curious of where we are today for significant providers and possibly up-and-coming ones that I should know about. (amazon prime has my wondering also.) > > > > Google (GGC) > > Netflix (OCA) > > Akamai (AANP) > > Facebook (FNA) > > Apple (I heard this isn't isp-located like the others, but unsure) > > ? others ? > > ? others ? > > ? others ? > > > > -Aaron Gould > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3868 bytes Desc: not available URL: From llabas at gmail.com Fri Sep 29 15:05:16 2017 From: llabas at gmail.com (Larry LaBas) Date: Fri, 29 Sep 2017 08:05:16 -0700 Subject: Best way to San Jose Fairmont from SFO? In-Reply-To: <7D040297-EB57-49D8-8FF7-18E0DC748CEB@sneep.net> References: <7eac9995b35c991dd5896e4ad8eac4f0.squirrel@66.201.44.180> <213bd208-10f5-259d-068a-044193149c28@studio442.com.au> <7D040297-EB57-49D8-8FF7-18E0DC748CEB@sneep.net> Message-ID: <89E4EC61-AAF0-472B-A626-36B2EF6CBAE2@gmail.com> If one uses Caltrain and has luggage there is a luggage car with racks. Also no wifi on Caltrain but wifi is available on Bart and the VTA (light rail and express buses). The car with the assistance ramp has a washroom, the rest do not. As a long time commuter (Gilroy to SF) I do recommend Bart to Caltrain to Light Rail as it will be cheaper than Uber. When I last returned from London we took that route. It's also very reliable and usually on schedule. Yes, I'm a bit jaded on driving in traffic in the area as I've also been doing that for many years. I've found Citymapper the best app for directions and public transport. Not only was it great here but was fantastic for using the tube in London and walking around. You can call uber or get driving directions from it also. TTFN, Larry > On Sep 29, 2017, at 07:20, Alastair Johnson wrote: > > I live in the next block along from the Fairmont. For people who want to use CalTrain then there is the Downtown Area Shuttle (DASH) that runs from Diridon around the downtown area and will pass by the Fairmont on San Fernando St. The shuttle is timed to connect with CalTrain in both directions and is free, so it's probably the most convenient. > > That said... I would just take Lyft/Uber. SFO to downtown SJC via public transport is annoying. I try to fly in/out of SJC as much as possible. > > AJ > >> On Sep 29, 2017, at 9:56 AM, Owen DeLong wrote: >> >> >>> On Sep 29, 2017, at 1:07 AM, Julien Goodwin wrote: >>> >>> On 29/09/17 06:47, Bob Evans wrote: >>>> Train and Bus travel is not worth considering. However, there are airport >>>> shuttle van services like supershuttle 4-5 passengers being dropped off on >>>> your way south. >>> >>> I'm arriving on Sunday morning, so have plenty of time, and will take >>> Caltrain down (BART to Millbrae, then Caltrain), sure it'll take 2h, but >>> any van service wouldn't be much faster. >>> >>> During the week, or out of daylight hours it's a much less sensible idea. >>> >> >> I disagree… I’ve done it during the week and it’s not that bad. >> >> I find Lyft to be the most desirable option (About $65), with Uber as >> a second choice. >> >> Third choice would be BaRT/CalTrain (to Diridon) followed by either a very >> short Lyft ride or VTA bus or light rail. >> >> Another option (if you get on the right CalTrain) is Tamien station and >> connection to light rail there. >> >> Light rail gets you _VERY_ close to the Fairmont. The Fairmont has entrances >> on Market St. (Front Door direct to Lobby) and First St. (Back door, hallway >> to lobby). The VTA light rail northbound is on First St. >> >> I’m not 100% sure of the light rail routing from the Diridon station to downtown >> as it’s tied to the Almaden line and I’m usually dealing with the Santa Teresa >> line. >> >> I, myself intend to bicycle to the meeting as my home is only about 7 miles away. >> >> Owen >> > From sean at donelan.com Fri Sep 29 15:15:03 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 29 Sep 2017 11:15:03 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: Career federal employees are taught to write situation reports in very boring language with just the facts known. Nevertheless, after reading lots of situation reports, you start to notice when the bubureaucratic language changes. Perhaps the most famous was the commander of Apollo 13's report "Houston, We have a problem." Puerto Rico has announced a new web site with current status: http://status.pr/ However, in the last 24 hours I've noticed some agency situation reports used different statistics to report "happy, happy, joy, joy" stuff. In the bureaucratic world, this is very concerning, such as when the Veterans Administration was misreporting appointment waiting times to look better. You can't fix problems, if the real situation isn't being reported accurately to senior leadership even if its bad news. From craigwashington01 at hotmail.com Fri Sep 29 17:41:55 2017 From: craigwashington01 at hotmail.com (craig washington) Date: Fri, 29 Sep 2017 17:41:55 +0000 Subject: Peering at public exchange authentication Message-ID: Hello all, Wondering your views or common practices for using authentication via BGP at public exchange locations. Just for example, lets say you peer with 5 people in the TELX in Atlanta, do you require them to all use authentication for the BGP session? Ive seem some use it and some not use it, is it just a preference? From patrick at ianai.net Fri Sep 29 17:56:52 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 29 Sep 2017 13:56:52 -0400 Subject: Peering at public exchange authentication In-Reply-To: References: Message-ID: <1879C90C-92CA-4035-B504-6BE3015D5712@ianai.net> MD5 on BGP Considered Harmful -- TTFN, patrick Composed on a virtual keyboard, please forgive typos. > On Sep 29, 2017, at 13:41, craig washington wrote: > > Hello all, > > > Wondering your views or common practices for using authentication via BGP at public exchange locations. > > Just for example, lets say you peer with 5 people in the TELX in Atlanta, do you require them to all use authentication for the BGP session? > > Ive seem some use it and some not use it, is it just a preference? From cscora at apnic.net Fri Sep 29 18:02:54 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Sep 2017 04:02:54 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170929180254.25F70C44AD@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 Sep, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 664412 Prefixes after maximum aggregation (per Origin AS): 258107 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 320310 Total ASes present in the Internet Routing Table: 58459 Prefixes per ASN: 11.37 Origin-only ASes present in the Internet Routing Table: 50491 Origin ASes announcing only one prefix: 22271 Transit ASes present in the Internet Routing Table: 7968 Transit-only ASes present in the Internet Routing Table: 230 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 55 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 91 Number of instances of unregistered ASNs: 91 Number of 32-bit ASNs allocated by the RIRs: 20109 Number of 32-bit ASNs visible in the Routing Table: 15925 Prefixes from 32-bit ASNs in the Routing Table: 65301 Number of bogon 32-bit ASNs visible in the Routing Table: 20 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 359 Number of addresses announced to Internet: 2851720800 Equivalent to 169 /8s, 249 /16s and 206 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219606 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 183498 Total APNIC prefixes after maximum aggregation: 52398 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 182418 Unique aggregates announced from the APNIC address blocks: 74771 APNIC Region origin ASes present in the Internet Routing Table: 8348 APNIC Prefixes per ASN: 21.85 APNIC Region origin ASes announcing only one prefix: 2300 APNIC Region transit ASes present in the Internet Routing Table: 1198 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 55 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3207 Number of APNIC addresses announced to Internet: 765499872 Equivalent to 45 /8s, 160 /16s and 153 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 199474 Total ARIN prefixes after maximum aggregation: 95708 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 201183 Unique aggregates announced from the ARIN address blocks: 93502 ARIN Region origin ASes present in the Internet Routing Table: 17897 ARIN Prefixes per ASN: 11.24 ARIN Region origin ASes announcing only one prefix: 6628 ARIN Region transit ASes present in the Internet Routing Table: 1779 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2191 Number of ARIN addresses announced to Internet: 1107083552 Equivalent to 65 /8s, 252 /16s and 193 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 177712 Total RIPE prefixes after maximum aggregation: 86956 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 173663 Unique aggregates announced from the RIPE address blocks: 104888 RIPE Region origin ASes present in the Internet Routing Table: 24439 RIPE Prefixes per ASN: 7.11 RIPE Region origin ASes announcing only one prefix: 11209 RIPE Region transit ASes present in the Internet Routing Table: 3480 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6225 Number of RIPE addresses announced to Internet: 713272704 Equivalent to 42 /8s, 131 /16s and 173 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 86153 Total LACNIC prefixes after maximum aggregation: 19113 LACNIC Deaggregation factor: 4.51 Prefixes being announced from the LACNIC address blocks: 87391 Unique aggregates announced from the LACNIC address blocks: 39768 LACNIC Region origin ASes present in the Internet Routing Table: 6436 LACNIC Prefixes per ASN: 13.58 LACNIC Region origin ASes announcing only one prefix: 1793 LACNIC Region transit ASes present in the Internet Routing Table: 1187 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3958 Number of LACNIC addresses announced to Internet: 172130784 Equivalent to 10 /8s, 66 /16s and 129 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17482 Total AfriNIC prefixes after maximum aggregation: 3857 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 19398 Unique aggregates announced from the AfriNIC address blocks: 7096 AfriNIC Region origin ASes present in the Internet Routing Table: 1073 AfriNIC Prefixes per ASN: 18.08 AfriNIC Region origin ASes announcing only one prefix: 340 AfriNIC Region transit ASes present in the Internet Routing Table: 208 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 344 Number of AfriNIC addresses announced to Internet: 93275136 Equivalent to 5 /8s, 143 /16s and 68 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5270 4192 76 ERX-CERNET-BKB China Education and Rese 7545 3970 407 406 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2857 900 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2788 11126 753 KIXS-AS-KR Korea Telecom, KR 9829 2754 1499 540 BSNL-NIB National Internet Backbone, IN 45899 2389 1472 112 VNPT-AS-VN VNPT Corp, VN 9808 2367 8699 32 CMNET-GD Guangdong Mobile Communication 9394 2175 4931 27 CTTNET China TieTong Telecommunications 4755 2106 423 222 TATACOMM-AS TATA Communications formerl 4134 1746 28203 462 CHINANET-BACKBONE No.31,Jin-rong Street Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3442 1341 88 SHAW - Shaw Communications Inc., CA 22773 3295 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2208 405 107 MEGAPATH5-US - MegaPath Corporation, US 6389 2045 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2041 2254 430 CHARTER-NET-HKY-NC - Charter Communicat 209 1923 5067 645 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1834 3963 546 AMAZON-02 - Amazon.com, Inc., US 30036 1809 322 355 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1688 853 228 ITCDELTA - Earthlink, Inc., US 701 1679 10589 626 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2884 898 2068 AKAMAI-ASN1, US 8551 2448 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2049 330 429 TELLCOM-AS, TR 12389 1803 1662 687 ROSTELECOM-AS, RU 12479 1722 1055 71 UNI2-AS, ES 9121 1720 1691 17 TTNET, TR 13188 1604 100 52 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1208 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3564 541 244 Telmex Colombia S.A., CO 8151 3208 3467 580 Uninet S.A. de C.V., MX 11830 2097 370 65 Instituto Costarricense de Electricidad 6503 1564 437 53 Axtel, S.A.B. de C.V., MX 7303 1548 1015 242 Telecom Argentina S.A., AR 6147 1278 377 27 Telefonica del Peru S.A.A., PE 3816 1033 510 92 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 962 2285 181 CLARO S.A., BR 11172 915 127 87 Alestra, S. de R.L. de C.V., MX 18881 901 1056 24 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1205 398 48 LINKdotNET-AS, EG 37611 767 91 8 Afrihost, ZA 36903 708 356 136 MT-MPLS, MA 36992 665 1383 31 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 29571 422 36 10 CITelecom-AS, CI 37492 416 354 77 ORANGE-, TN 8452 398 1730 18 TE-AS TE-AS, EG 15399 357 35 7 WANANCHI-, KE 2018 297 327 73 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5270 4192 76 ERX-CERNET-BKB China Education and Rese 7545 3970 407 406 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3564 541 244 Telmex Colombia S.A., CO 6327 3442 1341 88 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 22773 3295 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8151 3208 3467 580 Uninet S.A. de C.V., MX 20940 2884 898 2068 AKAMAI-ASN1, US 17974 2857 900 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2788 11126 753 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3970 3564 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3442 3354 SHAW - Shaw Communications Inc., CA 10620 3564 3320 Telmex Colombia S.A., CO 22773 3295 3138 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2857 2780 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8151 3208 2628 Uninet S.A. de C.V., MX 8551 2448 2407 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2367 2335 CMNET-GD Guangdong Mobile Communication Co.Ltd. 45899 2389 2277 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65099 PRIVATE 95.173.150.0/24 43797 RSNET2-AS RSNET2, RU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.128.126.0/23 62878 XLITT - Xlitt, US 27.100.7.0/24 56096 UNKNOWN 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 62878 XLITT - Xlitt, US 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:105 /12:283 /13:554 /14:1051 /15:1864 /16:13424 /17:7766 /18:13656 /19:25316 /20:39490 /21:42801 /22:80287 /23:65309 /24:369979 /25:853 /26:627 /27:654 /28:37 /29:39 /30:217 /31:2 /32:34 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3238 3442 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2519 3295 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2094 2208 MEGAPATH5-US - MegaPath Corporation, US 8551 1913 2448 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1589 1809 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1521 3564 Telmex Colombia S.A., CO 11830 1487 2097 Instituto Costarricense de Electricidad y Telec 34984 1356 2049 TELLCOM-AS, TR 6389 1355 2045 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1560 2:840 4:18 5:2485 6:33 7:1 8:1072 12:1853 13:157 14:1722 15:28 16:3 17:172 18:76 20:59 23:2459 24:1609 25:2 27:2387 29:1 31:1929 32:89 33:22 35:21 36:408 37:2355 38:1384 39:73 40:97 41:2974 42:494 43:1965 44:81 45:3099 46:2821 47:171 49:1253 50:1012 51:19 52:824 54:354 55:2 56:4 57:44 58:1580 59:982 60:352 61:2022 62:1711 63:1907 64:4711 65:2207 66:4557 67:2288 68:1191 69:3340 70:1161 71:613 72:2143 74:2646 75:402 76:429 77:1504 78:1520 79:1890 80:1415 81:1403 82:1024 83:724 84:974 85:1882 86:465 87:1212 88:806 89:2231 90:172 91:6240 92:1038 93:2346 94:2369 95:2659 96:634 97:353 98:961 99:95 100:153 101:1224 102:1 103:15915 104:3036 105:207 106:542 107:1763 108:830 109:2917 110:1469 111:1754 112:1275 113:1305 114:1069 115:1559 116:1689 117:1782 118:2141 119:1644 120:725 121:1072 122:2432 123:1872 124:1501 125:1800 128:916 129:677 130:444 131:1507 132:599 133:193 134:733 135:225 136:305 137:466 138:1962 139:522 140:379 141:669 142:750 143:928 144:787 145:184 146:1110 147:701 148:1497 149:589 150:702 151:1000 152:716 153:300 154:917 155:761 156:686 157:732 158:516 159:1559 160:771 161:748 162:2503 163:507 164:984 165:1428 166:384 167:1289 168:3010 169:844 170:3566 171:383 172:989 173:1946 174:775 175:781 176:1867 177:3941 178:2527 179:1153 180:2210 181:2076 182:2454 183:769 184:886 185:10836 186:3268 187:2250 188:2590 189:1850 190:8405 191:1363 192:9604 193:5800 194:4732 195:3930 196:2133 197:1373 198:5470 199:5799 200:7608 201:4428 202:10350 203:9972 204:4490 205:2838 206:2960 207:3111 208:3872 209:3929 210:3931 211:2070 212:2879 213:2537 214:838 215:66 216:5796 217:2103 218:958 219:590 220:1676 221:922 222:759 223:1202 End of report From job at instituut.net Fri Sep 29 18:06:16 2017 From: job at instituut.net (Job Snijders) Date: Fri, 29 Sep 2017 11:06:16 -0700 Subject: Peering at public exchange authentication In-Reply-To: References: Message-ID: Hi Craig, It may be simplest to use GTSM https://tools.ietf.org/html/rfc5082 Kind regards, Job On Fri, Sep 29, 2017 at 10:41 AM, craig washington wrote: > Hello all, > > > Wondering your views or common practices for using authentication via BGP at public exchange locations. > > Just for example, lets say you peer with 5 people in the TELX in Atlanta, do you require them to all use authentication for the BGP session? > > Ive seem some use it and some not use it, is it just a preference? > From bob at FiberInternetCenter.com Fri Sep 29 18:20:10 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 29 Sep 2017 11:20:10 -0700 Subject: Peering at public exchange authentication In-Reply-To: <1879C90C-92CA-4035-B504-6BE3015D5712@ianai.net> References: <1879C90C-92CA-4035-B504-6BE3015D5712@ianai.net> Message-ID: Almost all good and popular peering points utilize MAC locks on ports for all peers. (With few exceptions. ) To hijack a bgp session one would need not only a port on the peering network but a MAC address registered with the peering network - or their packets won't transverse the port through the switches to your port. So the extra CPU load of MD5, in my opinon, is a waste on an peering edge router with many peers. With lots of peers on a router - all the timing and table building after a needed maintenance reboot could lead to table building slowness and establishment timing sluggishness issues (depending on the router of course). If a peering network doesn't lock most all participants (and any router servers they have) by the MAC of the peering device I won't be a participant. All that said - I know of a way a customer of a network can create havoc by using a device/router that allows the MAC to be modified like a variable. However, for the most part that havoc would be limited to that network that hacking customer is located on. This would also be a truly rare event as there needs to be something the network also allowed for the customer to get routable layer 2 access to the peering port. Bob Evans CTO > MD5 on BGP Considered Harmful > > -- > TTFN, > patrick > > Composed on a virtual keyboard, please forgive typos. > > >> On Sep 29, 2017, at 13:41, craig washington >> wrote: >> >> Hello all, >> >> >> Wondering your views or common practices for using authentication via >> BGP at public exchange locations. >> >> Just for example, lets say you peer with 5 people in the TELX in >> Atlanta, do you require them to all use authentication for the BGP >> session? >> >> Ive seem some use it and some not use it, is it just a preference? > From bruns at 2mbit.com Fri Sep 29 18:34:50 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 29 Sep 2017 12:34:50 -0600 Subject: CenturyLink VDSL2 Support For RFC 4638 or IPoE? Message-ID: <0b0e75ca-03d5-7da2-a119-96dc6a4ac7e6@2mbit.com> Hey everyone, Don't suppose if anyone on this list knows if RFC 4638 (baby jumbos, aka MTU of 1508) or IPoE is supported on CenturyLink VDSL2 connections? I know IPoE is supported on connections with their TV service option. Would be nice to either get PPPoE out of the picture or have a proper 1500 MTU. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From job at instituut.net Fri Sep 29 19:44:38 2017 From: job at instituut.net (Job Snijders) Date: Fri, 29 Sep 2017 12:44:38 -0700 Subject: zayo / AS 6461 maximum prefix limit Message-ID: <20170929194438.GS1319@Vurt.local> Hi all, It appears one of our fellow network operators ran into some issues earlier today, probably due to the turn-up of a some new circuits for customers. In order to expedite the restoration I'm sharing the below information. I recommend any peering partners that saw BGP sessions go down with Zayo / AS 6461 due to maximum prefix limits being hit, please increase the maximum prefix limit to 65,000 for IPv4 and 2,000 for IPv6 and/or clear BGP sessions. The information on https://www.peeringdb.com/net/541 is current. Kind regards, Job From barbara.roseman at icann.org Fri Sep 29 16:22:17 2017 From: barbara.roseman at icann.org (Barbara Roseman) Date: Fri, 29 Sep 2017 16:22:17 +0000 Subject: [Ext] Re: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: , Message-ID: Sean, thank you for all the excellent updates you have been providing. Status.pr is disturbing since there is no context to the stats offered on this page. 49% of supermarkets may be open, but with nothing on their shelves. And 11k refugees? Who are they trying to kid with a number like that. -Barb +1.808.385.1677 mauigrrl at earthlink.net Written on the move, apologies for any errors. > On Sep 29, 2017, at 8:15 AM, Sean Donelan wrote: > > Career federal employees are taught to write situation reports in very boring language with just the facts known. Nevertheless, after reading lots of situation reports, you start to notice when the bubureaucratic language changes. Perhaps the most famous was the commander of Apollo 13's report "Houston, We have a problem." > > Puerto Rico has announced a new web site with current status: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__status.pr_&d=DwIBAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=eFHwbDul3gCazAMQCZYPBUi5FR29U9pfCEZA3KSPp1U&m=8QGAW2zyikBvyqdqem1ufMWHN1wmpYs5CHOkKkgxHuY&s=zr44KzVhB4CMsDiVsjPo0RNdkIMb14m0WxW3UV60JYY&e= > > However, in the last 24 hours I've noticed some agency situation reports used different statistics to report "happy, happy, joy, joy" stuff. In the bureaucratic world, this is very concerning, such as when the Veterans Administration was misreporting appointment waiting times to look better. > > You can't fix problems, if the real situation isn't being reported accurately to senior leadership even if its bad news. > From brad.raymo at gmail.com Fri Sep 29 18:05:37 2017 From: brad.raymo at gmail.com (BRAD RAYMO) Date: Fri, 29 Sep 2017 11:05:37 -0700 Subject: Peering at public exchange authentication In-Reply-To: References: Message-ID: Its up to you and how you want to manage your sessions. Some networks require it, some prefer it but do not require it, and others do not want to use it at all. On Fri, Sep 29, 2017 at 10:41 AM, craig washington < craigwashington01 at hotmail.com> wrote: > Hello all, > > > Wondering your views or common practices for using authentication via BGP > at public exchange locations. > > Just for example, lets say you peer with 5 people in the TELX in Atlanta, > do you require them to all use authentication for the BGP session? > > Ive seem some use it and some not use it, is it just a preference? > > From Andrew.Stern at cumulus.com Fri Sep 29 22:09:26 2017 From: Andrew.Stern at cumulus.com (Andrew Stern) Date: Fri, 29 Sep 2017 22:09:26 +0000 Subject: AT&T-twtelecom LA issue Message-ID: <3df56e226cd44634a6bc24456bcb720d@MAIL-13-A.cumulus.com> Hello. We are experiencing traffic issues between AT&T and twtelecom between SF and LA (5-7% dropped and out-of-order packets, increased latency RTT). Issue occurs only during business hours pacific time. We are on the AT&T enterprise side of the equation. My personal guess is oversubscribed peering, but what do I know? If anyone from att or twtelecom sees this, help! Andrew Stern, CBNE | Broadcast Engineer Cumulus Media San Francisco KFOG | KNBR | KSAN | KTCT | KGO | KSFO office: 415-995-5740 andrew.stern at cumulus.com 750 Battery St. | 2nd Floor | San Francisco | CA 94111 ________________________________ Cumulus Media Disclaimer This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From ray at oneunified.net Sat Sep 30 03:00:11 2017 From: ray at oneunified.net (Raymond Burkholder) Date: Sat, 30 Sep 2017 00:00:11 -0300 Subject: CPE that support 1G with BGP multihomed In-Reply-To: <59CA1DF1.9030405@yahoo.fr> References: <59CA1DF1.9030405@yahoo.fr> Message-ID: <014884dd-668d-73b9-15f3-9b86945ea50b@oneunified.net> On 09/26/17 06:29, marcel.duregards--- via NANOG wrote: > Dear Nanoger, > > Anyone have an advice on CPE which can support the following features, > please: I've been building cpe devices using various models from http://www.lannerinc.com. I populate with Debian linux:.  I use pxeboot to autoboot into install mode with dnsmasq providing deb-install preseed build files.  On the auto reboot after o/s install, I finish up with consistent, documented builds with SaltStack.  This provides the necessary customized switching, routing, security, and monitoring. Raymond Burkholder https://blog.raymond.burkholder.net 441 705 7292 > 1) > 1 Gigabits/s ipv4 or ipv6 forwarding IMIX or Internet traffic, full > duplex (not sure if cisco or miercom are conducting bidirectionals > traffic flows at the same time). With an FW-7543, I can iperf bidirectional 1gbps with no acl.  I can get strongswan ipsec bidirectional at about 50mbps (the cpu has AES-NI).  I havn't tried ipsec on devices like the FW-7573. > > 2) > with ACLs and with uRPF > with prefix filtering > with bgp ext-communities (rfc 8092 would be a ++, but not mandatory) I can customize configs with various combinations of VRRP, FreeRangeRouting BGP/OSPF (full routes are no problem), nftables for ACL, lldpd, hostapd for wireless, openvswitch for bridging requirements/netflow/sflow ... The linux kernel supplies uRPF.  FreeRangeRouting (a fork of Quagga) can do prefix filtering, ext-communities, etc.  They have even recently implemented EVPN using VxLAN for encapsulation. > 3) > with BGP full route, 1 eBGP session + 1 iBGP (--> multihomed, single > attached solution, so there is 2 CPE connected to 2 bgp transit)) I've used the FW-7543 in pairs to a customer for this:  a management port,  a port between the two, an upstream port, and a downstream port. > 4) > vrf light and > SNMP + telnet/ssh with ACLs Linux kernel has VRF capabilities, or use namespaces or native containers for segregation of functions or for implementing virtual functions. > > > Currently on Cisco side, we see the following candidates: > > - ASR 1001-x > - ASR 1002 > - ISR 4431, 4451 > - ISR G2 2921 + 2951 + 3925(E) (EoL soon, so we are currently in the > process of evaluating other solution). > > > But we would like also to include other manufacturer : juniper, mikrotik > , etc.... > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sean at donelan.com Sat Sep 30 03:07:47 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 29 Sep 2017 23:07:47 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: The situation reports from Puerto Rico seems to be getting passed through public relations, so I'll try to add some context. Public Safety Primary Public Safety Answering Point (9-1-1) center generator ran out of diesel fuel. Switched to alternate PSAP. San Juan Police Department has restored its radio repeaters and police radio communications metro-wide. (translated from spanish, so I think I understood the technical translation). Landline Central Offices 813,546 subscribers (CIA World Factbook) 390,000 subscribers in 52 municipalities with voice, data and long distance (Claro) Repaired fiber optic cable conntecting CO's in Fajardo and Rio Grande. 65% of inter-office Central Office connections restored island-wide. Remaining CO's have only local voice calling. Optico Fiber reports most of its infrastructure is intact, and has open WiFi hotspots outside its offices. Wireless services 3,227,281 subscribers (CIA World Factbook) 29 municipalities have 0% working cell sites. It appears carriers are repairing one tower in each county/municipality to improve island-wide coverage. Several municipalities going from 0 to 1 cell site working. 310,000 subscribers in 28 municipalities with working cell towers (Claro) 34% of San Juan has working cell tower coverage (Claro) Cell on Wheels in Ponce (4 mile radius) serving 6,000 calls per hour, 35,000 texts per hour (AT&T) Dorado, Tao Baja and Toa Alta have T-Mobile service (T-Mobile) I don't know what FCC and PRTRB are counting: 286 working cell sites out of 2671 (according to FCC report) 96 working cell sites out of 1600 (according to PR Telecommunications Regulatory Board report) For context, the number of cell sites repaired each day since the end of Hurricane Maria is improving slowly - average less than 20 sites a day, but some days its negative, i.e. more cell towers failing than repaired. On U.S. Virigin Islands, the number of cell sites out of service decreased initially, but has slowly increased for the last 5 days. I created a spreadsheet of the FCC wirelss outage data from hurricane Harvey, Irma and Maria. https://www.donelan.com/FCC-Wireless-Outages.xlsx There is no consistent pattern between states, territories or hurricanes. Florida had the fatest wireless restoration, average 500 cell sites restored a day; while U.S. Virgin Islands averaged less than 1 cell site restored. But Florida was mostly restoring the electrical grid, which restored lots of cell sites. Harvey was slow to start restoring cell sites, the tropical storm lasted for days; but less than 6% of cell sites were out of service. Cable systems First official report from Liberty Cable Puerto Rico Most cable headends or in good condition, with backup generators. Internet connection to international circuits reconnected. Main fiber trunk between San Juan and Luquillo completed. Working to repair infrastructure and primary services such as physical plant, main repeater bases, fiber optic ring and fiber to distribution stations in neighborhoods. (LibertyPR) Satellite Services and Satellite Phones As more satellite phones are distributed, social media and news reporters are saying satellite capacity is getting worse. It may be user issues and lack of training, or running out of satellite bandwidth in the area. American Red Cross driving a VSAT station between shelters, and setting up temporary hotspots for an hour at each shelter so people can contact family members. From jfmezei_nanog at vaxination.ca Sat Sep 30 06:16:52 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 30 Sep 2017 02:16:52 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: On 2017-09-29 23:07, Sean Donelan wrote: > I don't know what FCC and PRTRB are counting: > > 286 working cell sites out of 2671 (according to FCC report) > 96 working cell sites out of 1600 (according to PR Telecommunications > Regulatory Board report) I had noticed the different numbers too. My speculation: The 1600 may refer to antenna sites, whereas the 2671 may be the sum of the number of sites reported by each carrier (think a mast supporting antennas from multiple carriers). Assuming my logic is correct, the 96/1600 statistic may be of more use in a "can I dial 911" point of view. Having multiple carriers "up" at the same tower doesn't increase geographic footprint where some coverage exists. >From a disaster management point of view, in a town where each carrier has its own tower, deciding which one to light up first could be interesting. (aka carriers getting together to compare state of antennas in town and somehow elevating that info to whoever controls the generators (army corps of engineers who are "foreigners" with no local knowledge). From pr at isprime.com Sat Sep 30 13:47:44 2017 From: pr at isprime.com (Phil Rosenthal) Date: Sat, 30 Sep 2017 09:47:44 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Has anyone heard anything about Liberty Cablevision / AS14638? Our Netflow stats show a traffic drop to zero at the moment of landfall of Maria, late on 9/19, and a continued flat line at zero until now. Almost 11 days without a single packet exchanged. This is (as far as I am aware), the #2 largest ISP in Puerto Rico. By comparison, Claro’s traffic certainly has dropped by a large degree, but it always stayed at least slightly above zero, and is roughly at 10% of normal traffic levels today. -Phil From rod.beck at unitedcablecompany.com Sat Sep 30 14:14:18 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sat, 30 Sep 2017 14:14:18 +0000 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> References: , <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: The whole thing is a disgrace. ________________________________ From: NANOG on behalf of Phil Rosenthal Sent: Saturday, September 30, 2017 3:47 PM To: Jean-Francois Mezei Cc: nanog at nanog.org Subject: Re: Hurricane Maria: Summary of communication status - and lack of Has anyone heard anything about Liberty Cablevision / AS14638? Our Netflow stats show a traffic drop to zero at the moment of landfall of Maria, late on 9/19, and a continued flat line at zero until now. Almost 11 days without a single packet exchanged. This is (as far as I am aware), the #2 largest ISP in Puerto Rico. By comparison, Claro’s traffic certainly has dropped by a large degree, but it always stayed at least slightly above zero, and is roughly at 10% of normal traffic levels today. -Phil From math at sizone.org Sat Sep 30 14:41:34 2017 From: math at sizone.org (Ken Chase) Date: Sat, 30 Sep 2017 10:41:34 -0400 Subject: AS PATH limits Message-ID: <20170930144134.GU17040@sizone.org> If you're on cogent, since 22:30 UTC yesterday or so this has been happening (or happened). *> 186.177.184.0/23 38.*.*.* 45050 0 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 ? oddly, i see other pops with 174 sources giving a more sane route (even 6939 is giving us a route that goes thru 174 after 2 hops). 'Sup, 174? Wonder if this is just stuck in the router Im looking at and the update process is failing because the route is too long to process properly for removal or something. mmm, bugs!) /kc -- Ken Chase - math at sizone.org Guelph Canada From sthaug at nethelp.no Sat Sep 30 15:09:42 2017 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 30 Sep 2017 17:09:42 +0200 (CEST) Subject: AS PATH limits In-Reply-To: <20170930144134.GU17040@sizone.org> References: <20170930144134.GU17040@sizone.org> Message-ID: <20170930.170942.74741203.sthaug@nethelp.no> > If you're on cogent, since 22:30 UTC yesterday or so this has been happening > (or happened). Still happening here. I count 562 prepends (563 * 262197) in the advertisement we receive from Cogent. I see no good reason why we should accept that many prepends. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From deleskie at gmail.com Sat Sep 30 15:52:26 2017 From: deleskie at gmail.com (jim deleskie) Date: Sat, 30 Sep 2017 12:52:26 -0300 Subject: AS PATH limits In-Reply-To: <20170930.170942.74741203.sthaug@nethelp.no> References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> Message-ID: Maybe the next best path had, had 562 prepends? :) On Sat, Sep 30, 2017 at 12:09 PM, wrote: > > If you're on cogent, since 22:30 UTC yesterday or so this has been > happening > > (or happened). > > Still happening here. I count 562 prepends (563 * 262197) in the > advertisement we receive from Cogent. I see no good reason why we > should accept that many prepends. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From dave at temk.in Sat Sep 30 16:25:08 2017 From: dave at temk.in (Dave Temkin) Date: Sat, 30 Sep 2017 09:25:08 -0700 Subject: Peering at public exchange authentication In-Reply-To: References: Message-ID: Talks about GSRs and Sup720's, but still relevant today. https://www.nanog.org/meetings/nanog39/presentations/Scholl.pdf -Dave On Fri, Sep 29, 2017 at 11:05 AM, BRAD RAYMO wrote: > Its up to you and how you want to manage your sessions. Some networks > require it, some prefer it but do not require it, and others do not want to > use it at all. > > On Fri, Sep 29, 2017 at 10:41 AM, craig washington < > craigwashington01 at hotmail.com> wrote: > > > Hello all, > > > > > > Wondering your views or common practices for using authentication via BGP > > at public exchange locations. > > > > Just for example, lets say you peer with 5 people in the TELX in Atlanta, > > do you require them to all use authentication for the BGP session? > > > > Ive seem some use it and some not use it, is it just a preference? > > > > > From math at sizone.org Sat Sep 30 16:47:26 2017 From: math at sizone.org (Ken Chase) Date: Sat, 30 Sep 2017 12:47:26 -0400 Subject: AS PATH limits In-Reply-To: <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> Message-ID: <20170930164726.GY17040@sizone.org> I dont see that as the solution. Someone else will offend again. However, I also don't see trusting major backbones as our filters (for many other reasons). Our software should be handling what's effectively a buffer overflow or equivalent (beware long paths that are actually shellcode). Quagga among others seems to be subject to this bug, pre 0.99.23 or so (.99.24+ seems ok). So upgrading is a solution. There was also some chatter on the quagga mailing list on how it's more pleasant to stab your eyeballs out rather than constructing extremely long regexp's that might work as a filter. https://lists.quagga.net/pipermail/quagga-users/2017-September/thread.html /kc On Sat, Sep 30, 2017 at 05:30:03PM +0200, Niels Raijer said: >My message to NANOG about this from 12:31 UTC today is still in the moderation queue. I had opened a support case with Cogent before writing my message to NANOG and Cogent has let me know approximately 40 minutes ago that they have contacted their customer. > >Niels > > > >On 30 Sep 2017, at 17:09, sthaug at nethelp.no wrote: > >>> If you're on cogent, since 22:30 UTC yesterday or so this has been happening >>> (or happened). >> >> Still happening here. I count 562 prepends (563 * 262197) in the >> advertisement we receive from Cogent. I see no good reason why we >> should accept that many prepends. >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no > -- Ken Chase - math at sizone.org Guelph Canada From sean at donelan.com Sat Sep 30 19:53:52 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 30 Sep 2017 15:53:52 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: The Government of Puerto Rico has created a map of working cell sites in puerto Rico. I'm not certain about the source of the information. Cellular carriers usually object/refuse to release details about their operations. http://status.pr/Maps The map shows most working cell sites are in metro areas around San Juan. As I guessed, one or two cell sites in each county/municipality around the island. There are almost no working cell sites covering the interior of the island. Comparing the map to census bureau population maps indicates the working cell sites are in high population areas, which is necessary for disaster triage. Satellite phones are being distributed to mayors in the other counties/municipalities. From sean at donelan.com Sat Sep 30 20:16:30 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 30 Sep 2017 16:16:30 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: On Sat, 30 Sep 2017, Phil Rosenthal wrote: > Has anyone heard anything about Liberty Cablevision / AS14638? The first public statement I've seen from LibertyPR was yesterday. Their network was completely down. They've restored some of their main infrastructure, i.e. cable headends and main fiber connections. 100% of subscribers are out of service. I've seen pictures on twitter of LibertyPR crews fixing cables and poles on the island. From sean at donelan.com Sat Sep 30 20:39:11 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 30 Sep 2017 16:39:11 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: On Sat, 30 Sep 2017, Sean Donelan wrote: > The first public statement I've seen from LibertyPR was yesterday. Their > network was completely down. They've restored some of their main > infrastructure, i.e. cable headends and main fiber connections. > 100% of subscribers are out of service. > > I've seen pictures on twitter of LibertyPR crews fixing cables and poles on > the island. Liberty cable Puerto Rico has put out a press release today. LibertyPR is opening one public WiFi hot spot in Bahia Urbana in San Juan from 3pm to 7pm Saturday, and 8am to 7pm daily starting Sunday. Additional hot spots will be announced by LibertyPR via press release in the future. I guess this is a sign LibertyPR's public relations office is back in operation. From bill at herrin.us Sat Sep 30 22:29:36 2017 From: bill at herrin.us (William Herrin) Date: Sat, 30 Sep 2017 18:29:36 -0400 Subject: Long BGP AS paths Message-ID: To the chucklehead who started announcing a 2200+ byte AS path yesterday around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga that's present in all versions released in the last decade. Your announcement causes routers based on Quagga to send a malformed update to their neighbors, collapsing the entire BGP session. Every 30 seconds or so. For everyone else: please consider filtering BGP announcements with stupidly long AS paths. There's no need nor excuse for them to be present in the DFZ and you could have saved me a painful Saturday. Cisco: router bgp XXX bgp maxas-limit 50 Juniper: https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 Quagga: ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50} ip as-path access-list maxas-limit50 permit .* Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From math at sizone.org Sat Sep 30 22:34:42 2017 From: math at sizone.org (Ken Chase) Date: Sat, 30 Sep 2017 18:34:42 -0400 Subject: Long BGP AS paths In-Reply-To: References: Message-ID: <20170930223442.GD17040@sizone.org> The quagga thread I read specifically indicates that some (most?) versions don't accept the {n,m} regexp repeat format. Thus the regexps as long as the path you want to filter... :/ ..or upgrade. /kc On Sat, Sep 30, 2017 at 06:29:36PM -0400, William Herrin said: >To the chucklehead who started announcing a 2200+ byte AS path yesterday >around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga >that's present in all versions released in the last decade. Your >announcement causes routers based on Quagga to send a malformed update to >their neighbors, collapsing the entire BGP session. Every 30 seconds or so. > >For everyone else: please consider filtering BGP announcements with >stupidly long AS paths. There's no need nor excuse for them to be present >in the DFZ and you could have saved me a painful Saturday. > >Cisco: > >router bgp XXX > bgp maxas-limit 50 > > >Juniper: >https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 > > >Quagga: > >ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50} >ip as-path access-list maxas-limit50 permit .* > > >Regards, >Bill Herrin > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: -- Ken Chase - math at sizone.org Guelph Canada From job at instituut.net Sat Sep 30 22:44:54 2017 From: job at instituut.net (Job Snijders) Date: Sat, 30 Sep 2017 22:44:54 +0000 Subject: Long BGP AS paths In-Reply-To: References: Message-ID: On Sat, 30 Sep 2017 at 15:33, William Herrin wrote: > To the chucklehead who started announcing a 2200+ byte AS path yesterday > around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga > that's present in all versions released in the last decade. Your > announcement causes routers based on Quagga to send a malformed update to > their neighbors, collapsing the entire BGP session. Every 30 seconds or so. > > For everyone else: please consider filtering BGP announcements with > stupidly long AS paths. Nowhere in the BGP RFCs it says it is okay for the software to crash. Bugs happen. You patch and move on. :-) > From bill at herrin.us Sat Sep 30 22:52:16 2017 From: bill at herrin.us (William Herrin) Date: Sat, 30 Sep 2017 18:52:16 -0400 Subject: Long BGP AS paths In-Reply-To: <20170930223442.GD17040@sizone.org> References: <20170930223442.GD17040@sizone.org> Message-ID: On Sat, Sep 30, 2017 at 6:34 PM, Ken Chase wrote: > The quagga thread I read specifically indicates that some (most?) versions > don't > accept the {n,m} regexp repeat format. Thus the regexps as long as the > path you want to filter... :/ > Howdy, If it was configured with --enable-pcreposix I believe it supports the regex. Most installs that come straight from a Linux distro used this flag. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: